When creating self signed certificate, no prompts
-
If you need to create and sign certs use the CA manager that is part of pfsense. You can download the file in PEM format and install to whatever you want.. Using some openssl cmd line from some freebsd doc is not how you would do it in pfsense.
-
I suspect he may be running mini_httpd in pfSense.
Which is why he's attempting to do it like this. -
A self-signed cert will result in browser errors for that kind of setup anyhow. Do not do this to/with your firewall. It is not going to have the result you want.
Back up and explain in more detail what you're trying to accomplish and why, maybe there will be an alternative solution that doesn't involve compromising the security of your firewall.
-
@johnpoz Thanks I’ll try the CA Mgr & report back.
@ stephenw10 I installed mini_httpd via ssl command line. Lauching with PfSense Cron so it survives PfSense reboots & updates. I have a few alias ip lists with rules that redirects webpage requests to the applicable mini_httpd hosted webpage to notify of RIAA violations, non-payment & maintenance downtime to reduce complaint calls & letters. Saves staff time & customer confusion. -
Unless customers trust the CA you create in the CA manager - they are still going to balk at any certs you create.. If you want to strangers to trust your certs - they have to be signed by public CA that everyone's browsers trust out of the box. You could use ACME for such certs.
-
@jimp Plan on purchasing a signed cert. Self-signed is for testing at this point. Dont want users to have to accept an unsigned cert through prompts. The rule after the redirect rule is to block all traffic in alias so a response to the redirect webpage is needed before a client is unblocked. Hope this helps the security question. Open to other approaches.
-
@johnpoz Thats my intent, thanks. Looking @ others, I’ll check out ACME.
-
@johnpoz Also should mention I’m running mini_httpd localhost with access only by client pool on private lan subnet.
-
If access is by clients under your control - then very simple to have them all trust your CA... Then you can issue whatever certs you want for any fqdn and or IP address via SAN and they will accept it without complaining.. This allows for use of domains and or IPs that no public CA would ever sign off on...
-
So this is to redirect customers trying to access pages on servers hosted behind your firewall?
Or your customers are on the inside trying to connect out and need to be notified?
I still expect a cert error there since users will be trying to connect to https://somehost and your error page will not be that host.
Steve
-
@stephenw10 Customers are on the inside trying to connect out and need to be notified.
-
Well that is always going to FAIL with cert error..
If I try and go to https://www.google.com you can not redirect me to https://whatever and expect it not to throw an error.. Not unless you doing MITM with a proxy - where your generating the certs for whatever fqdn they are trying to access.
-
@johnpoz You lost me a bit. I'm new to this CA stuff other than that needed for OpenVpn that I employ. I do know mini_httpd needs a CA with a common name equal to the host ip, 127.0.0.1 Are you saying ACME or other will not offer a signed CA to a private IP? Not understanding your work-around solution. Via SAN (storage area network)?
-
@stephenw10 Right now I'm getting cert warning because it's self-signed. View of self-signed shows company name, contact info, etc. but don't expect many will bother looking. When self-signed is accepted by client it does take the client to the proper hosted html page. Testing with myself as a client currently.
-
No you can offer up whatever cert you want... But since the common name or SAN does not match where your going the clients browser is going to throw a flag about it..
-
@johnpoz So your saying I can't purchase a signed CA with a matching common name to the host IP? Any solution to this so client doesn't get prompts. The latter is the only obstacle remaining to good functionality.
-
@johnpoz This is not what I wanted to hear. So is there another solution to this? Do I have to host in the public domain and redirect there? Seems less secure. And when the redirect is internet outage, I need a local host to serve the page.
-
You can for sure buy a cert or have a client trust a cert for host.domain.tld... And if your browser goes to host.domain.tld you will be fine and browser will be all happy.
But when client ties to go to https://otherhost.otherdomain.tld and gets some page signed for host.domain.tld its going to complain about it..
edit:
There really is no "solution" to this ;) Welcome to HTTPS.. You would have to generate a cert on the fly that is signed by a CA the client trusts for https://otherhost.otherdomain.tldAnd then even then with hsts you could have problems...
-
If you are only redirecting sites you control and have certs for, then use haproxy and offload the SSL to the firewall and then you can serve a page off a shared backend that is used when the main server is down.
That only works for domains you control, however, not random Internet hosts.
And a CA will not give you a cert for localhost/127.0.0.1 or a private IP address.
-
@jimp No, I'm redirecting any public site requested by private customers so I don't have control and certs for all the possible public sites. I'm redirecting select subgroup of customer group that will attempt to access any public site and I redirect them to a locally hosted page. Works great with http, even the 404 errors get the proper page.
