Adding a Certificate Authority to PHP's store
-
Hi,
I am configuring pfSense to send alerts via SMTP (using the web GUI), currently it's failing with a TLS error and I believe this is because pfSense can't verify the certificate that the mail server presents it.
I would like to add my CA to pfSense, does anyone know where the CA store is that the SMTP service uses (think it'll be PHP's one)?
Thanks,
-
So your mail server presents some self signed cert?
-
The mail server presents a certificate signed by a CA which the pfSense system is not aware of. I would like to 'import' the additional CA to the pfSense system so that it will trust certificates signed by the additional CA.
-
Who is the CA.. If its a common public CA then this should be reported so pfsense can add it to the known CAs
-
It's not a common public CA, it's a private one.
On a Linux computer it would be done like this:
Copy your certificate in PEM format into /usr/local/share/ca-certificates and name it with a .crt file extension. Then run sudo update-ca-certificatesDoes anyone know how to do similar on pfSense?
Or to put it more into the context of pfSense, where is the file or directory which contains the CAs which the SMTP service (used for alerting) trusts?
-
"It's not a common public CA, it's a private one."
So its self signed then.. So its some sort of smart host that you are handing off email to to be delivered? Bad idea if you ask me.. If an email server is going to accept tls for email the CA should be public.
You run an issue with doing anything like this with pfsense that your changes could be lost on an update.
-
"So its self signed then.. "
No, it's not, check wikipedia: "a self-signed certificate is one signed with its own private key". That is not the case, the mail servers certificate is signed by a CA's private key.
"If an email server is going to accept tls for email the CA should be public."
Again, no, I've been running email servers for over 15 years, secure SMTP is opportunistic, meaning take what you can get. In this case, I have no need to trust a public CA.I understand that my changes may be lost on restart which is why I wanted to discuss the best way to approach it. If you know, please help, if not please stop second guessing reasons why I should or shouldn't do it.
-
If its not a public CA, and signed by a private CA.. My point of the term "self signed" is it is not trusted by the client out of the box!!
So you have been running smtp servers for 15 years and you find that servers have no issues sending you email using tls via a private signed CA.. That must be really great for people wanting to use tls to send your server email.. ::)
Good luck.. Your taking the wrong path to your solution.. I don't normally help with hacks sorry..
https://forum.pfsense.org/index.php?topic=121959.0
quoting jimp
"It (correctly) fails to validate the certificate because it's self-signed, it does not come from a CA recognized by the SMTP client.If you use a valid certificate and a proper matching hostname/cn it will work."
There is a redmine to have the system trust CAs you import into the Cert Manager.
https://redmine.pfsense.org/issues/4068But I believe if you add your CA to..
/usr/local/share/certs/ca-root-nss.crtBut like I said that is a hack..
-
Thank you, that's what I needed to know and that redmine looks like a good idea - In many cases secure TLS encryption is not dependant upon a public CA (many organisations have internal networks that trust only their private CA for example).
Your assumption about me using privately signed certificates on public SMTP port 25 is wrong again though, I've always used public CAs for that. This question was within the context of two private end points communicating securely and I have no need to involve (trust) a public CA with that.
I'm not taking a wrong path, I'm taking an alternative path. One that I have good reason to take and one that looks like it will soon be officially supported by pfSense. Until then, I'm quite partial to a little 'hacking' so I don't mind a workaround.
Anyway, thankyou for the help :)
-
If it is a private line of communication, then I agree use of self signed is fine. When the public needs to trust it is when you need a public signed cert.
I use private ca for lots of stuff that are internal… But to me an email server is never a private thing.. Unless it was some sort of smart host that I asked before where you just dumping mail to it so it can deliver it for you. And you are the only one sending it stuff..
You should of been more clear that you are the only one sending it mail via tls.. And then we wouldn't of gotten off on the wrong foot ;)
-
…looks like it will soon be officially supported by pfSense.
Don't hold your breath.
https://github.com/pfsense/pfsense/pull/3558
Thanks all for the feedback. I'm going to close this PR and submit another. (I will mention commenters above in the new PR.)
I've discovered after doing further testing that the way webConfigurator spawns pkg , curl , or calls curl_* functions varies too widely for any of the above solutions to address. The hardest obstacle to overcome is that nginx fastcgi sanitizes the environment variables. It is possible to set fastcgi_param in /var/etc/nginx-webConfigurator.conf (generated by /etc/inc/system.inc ), but those environment variables don't seem to make it all the way through to the exec() call that spawns pkg (or curl).
If you have any suggestions about whether it is worth implementing what amounts to kludges for each different way that pfSense spawns TLS-using processes, please chime in. Otherwise, my plan is to use the GUI code I've written and submit a PR that appends to the existing /etc/ssl/cert.pem while retaining the original /usr/local/share/certs/ca-root-nss.crt to use as the base file every time new CAs are added or removed.
That was 25 days ago now and I've not seen the new PR. Have you? Anyone?
There are technical hurdles that make a caveat free monolithic solution difficult. Maybe currently impossible. So unless author and pfSense team is willing to accept less than perfect it probably won't happen.
If you're up to it take a look through the code in that PR. The basic pieces are there to roll your own.
-
I also really don't get the tls email thing anyway.. As email bounces from server to server going from domain X to domain Y.. Its not going to be in a encrypted tunnel all the way through more than likely.. Is your email crossing a hostile network to get to this email server? Where does the email go from there? If your not sure it is implemented through the entire chain of delivery then really what is the point?
And I am curious about this email server.. So it does not accept mail for any public domain that anyone could send to?
I too have been running mail servers for year and years.. And I am huge fan of private signed or if you insist private ca signed certs – when appropriate!! But my curiosity cat is bugging me on the scenario you are in where you want/need to use tls for pfsense to send an alert email, but using an actual public ca signed cert wouldn't be an easier solution..
-
I consider email with regard to SMTP/S & STARTTLS in two parts. Authentication credentials and message contents.
Message Content:
If the message at some point in the transport to the recipient traverses an unsecured network, such as to/from a public MX, then TLS is not of much use for protecting the message contents.Authentication credentials:
Protecting user credentials when they connect their MSA (mail submission agent) is where TLS is useful.Example:
I provide SMTP/S and STARTTLS using a self-sign cert on my personal email server in order to keep authentication credentials protected. PfSense is configured to trust the self-signed cert CA so it can authenticate to the MSA to send notices. -
Sure, happy to explain more about my configuration…
Firstly, I must say, regardless of configuration, it is unusual for an email client to refuse connection to an email server due to an inability to verify its certificate and then provide no option for certificate pinning or the ability to import a CA. It's even more unusual in light of the assumption that there would be no authentication mechanism in place for this mail transfer i.e. that pfSense would send mail over port 25. Due to the opportunistic nature of SMTP encryption it is entirely possible to run a public facing mail server with self-signed or privately signed certificates and have successful TLS negotiation with other email servers; Google, MS, Protonmail etc. will all negotiate TLS with an un-verifiable certificates - I'm not saying this is ideal just that it's expected (and better than no encryption or worse, no connection at all!).
Back to my configuration and NOYB has hit the mail on the head really, it's about encrypting the credentials used for mail submission. As a client, pfSense should really be using the mail submission port 587, rather than 25 and best practice (from the Postfix community at least) for submitting mail in this way is by authentication (rather than IP white lists etc.).
In my case I'm running a public mail server which (will soon (I haven't completed setup)) use a publicly verifiable certificate on port 25 for communication with other mail servers but a certificate signed by a private CA on port 587 for mail submission. I do this because I try to adhere to the principal of least privilege when it comes to security and where as it's beneficial to be publicly identifiable on port 25, it is entirely unnecessary to place trust in a public CA (a lot of whom have a terrible track record with security) just so that about 7 private clients can verify my email server is who it says it is.
-
Agreed.. And thanks for the info it holds my curiosity cat at bay ;)
I send alerts from my pfsense box to google over 587.. Depending the server your sending to and connectivity to it, and who the sending email is saying its from and address its going to.. Its quite possible not to auth at all, etc.
I have not looked too deep into how exactly pfsense is sending the alerts. But I would think it possible to send to the server directly accepting the mail for the domain your sending too without any need to auth at all. Only reason you would have to auth if sending to an email server that would be sending the email to where its going for you. So sure such a mail server you would want to auth who is trying to get "me" the server to send mail for.. Making sure it really is you and not just some spammer.
But sure in such a scenario it should be easier to pin or trust in pfsense a private ca or self signed cert for secure auth to your sending email server - in this I do agree.. They prob have not gotten around to it as of yet since its prob not a lot of requests for it.. Since if sending through some public email domain the certs should be signed by some common public CA. If sending your own email server, its quite possible the server is actually internal to where pfsense sits and auth should not need to be via tls for security reasons, etc. etc.
I would think if was brought enough attention there is lots of need and not just a few one offs in setups that require trusting self signed or non public ca certs in the pfsense user community it would get more attention. If something you really want done - there is always the bounty program to have some put it together.
