When creating self signed certificate, no prompts
-
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.
-
Then you can't do that unless you do SSL interception with a custom CA like @johnpoz mentioned. That isn't going to be viable.
You're breaking the entire chain of trust laid down by TLS to prevent meddling with content and impersonating servers.
-
^ exactly!! How are you going to be helping anyone while doing MITM ;) of their SSL traffic - so you can notify them something is down.. No thanks! Any of your customers that noticed this wouldn't be a customer for long..
-
@johnpoz Exactly. Well, I'm disappointed to learn this. Need some way of notifying why no internet so they aren't hard rebooting customer owned premises equipment blowing out the config then calling on me to fix when it's not my equipment. I suppose the best will have to be an unsigned cert with prompts. Hopefully most will figure it out.
Correction; self-signed cert
-
Welcome to the world of end to end encryption "everywhere" ;)
-
That's a very poor reason to hijack people's secure browsing sessions.
A $5 wrench and some well-delivered threats will be a better deterrent. Or a locking cage and good signage.
-
@johnpoz Thanks so much for all your help john, jimp, steven. Not quite the homecoming I was expecting.
-
@jimp Threats don't go over well either. I think hijack is a bit strong for what I'm trying to do. Redirecting a customer's planned session that has not yet been established.
-
You might argue a self signed cert is actually better in that situation as it's obviously not the site you were trying to reach.
Vs a cert from a known CA but with the wrong host name.
Both produce an alarming error if you're not used to it though
Steve
