When creating self signed certificate, no prompts
-
@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.
-
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
-
@stephenw10 I agree, probably the best. Probably good to deal an alarming site vs threats (just ribbing a bit jimp, I understand). I need to get their attention especially in the no-pay situation and perhaps even RIAA infractions. Was hoping to expand to outages to entire pool but doubtful I'll do that with cert prompts. I'll use it sparingly. Thanks again guys.
-
Well, the wrench is an old joke, but threats to the pocketbook also work. "If you unplug this device without authorization, it will result in a service charge of $$$$"
-
@jimp Funny! Tried to keep it simple...
-
@johnpoz Hey John, when I create a server CA and Cert within PfSense Certificate Manager I'm given the option of downloading a .crt and .key file but not a .pem. Can you instruct?
-
crt is just a pem file.. look at it..
-
@johnpoz Ahhh, so just rename. Thanks.
-
@johnpoz Unfortunately simply renaming doesn't fly.
root/: /usr/local/etc/rc.d/mini_httpd.sh start
34381057080:error:0906D06C:PEM routines:PEM_read_bio:no start line:/builder/pfsense-234/tmp/FreeBSD-src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pem/pem_lib.c:696:Expecting: ANY PRIVATE KEY
34381057080:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib:/builder/pfsense-234/tmp/FreeBSD-src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:635: -
I do not run that... But what I can tell you is the file you export is PEM... simple enough to test it with openssl.
Here I just created a cert for another thread.. Tested it..
-
Combine the cert and key in one file:
-----BEGIN PRIVATE KEY----- keydatakeydatakeydatakeydatakeydatakeydatakeydatakeydata -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- certdatacertdatacertdatacertdatacertdatacertdatacertdatacertdata -----END CERTIFICATE-----
At least that's what it looks like it's expecting.
Steve
-
@stephenw10 Thanks Steve, even tho freebsd “openssl verify ...” said the pem was bad that did the trick.
-
It's been a while since I tested this but co-incidentally did today and in fact every browser I tested is able to detect a captive portal redirect and trigger some alert to login without some huge error screen. It won't do that with a port forward lik you're doing here.
Kind of scary from a security view but makes it slick for end users.You would have to use it in some inverse way though. White-list all clients and remove those who need to see the redirect.
Steve
-
@markn6262 said in When creating self signed certificate, no prompts:
said the pem was bad that did the trick.
Then you got a bad copy or something in your download..
-
Maybe I wasn't clear enough in my last post. Combining the cert and key files into a pem file works with mini_httpd as stephen suggested. I'm golden! It's just that freebsd openssl verify reports the pem file as bad, oddly enough. I've never got a pem to report good creating from a freebsd comand line or from within PfSense GUI.
-
Report good from where... I just showed you checking a pem file that was downloaded from the gui.. I don't use whatever app your using... But sure they can be finicky... Trying to get plex to use different cert for its domain was a whole freaking learning curve in itself..
"Custom certificate encryption key"
Thought they wanted the path to the key - no they wanted the "password" you put on the p12 file that you combined the cert and key file in, etc..But have had zero issues using the CA manager and export certs and keys from it. I use the certs from there in multiple things. My switches, my unifi controller, my plex box, etc. etc. Certs for my windows machines for RDP, etc.. Its a great overall CA.. only thing is wish you could put passwords on your p12 when you export them..
-
@johnpoz I was wondering if I needed to use to p12. I didn't and it worked fine simply combining the CERT and KEY in a PEM file with the mini_httpd daemon. The PEM file PfSense creates reports bad from PfSense command prompt using "openssl verify fiiename.pem", try it. I'm not using some app to check PEM integrity. Until this thread, I had no idea the PfSense Cert Manager could make them for apps other than PfSense itself. That's good to know.