Closed 7lym closed 6 years ago
Hi,
We just tested it with self-signed certificates on localhost and valid certificates on mail.afterlogic.com and imap.gmail.com. The behavior is correct - cert error with the self-signed cert and no connection issues with valid certs. We can't confirm the issue.
Hey,
But what happens if i want to trust a self-signed certificate issued by my organization? It`s true that, from the code snippet above, the 'allow_self_signed'
option evaluates to false
, so the imap server must have a certificate signed by a trusted CA, self-signed will fail. But what is that path? Basically, where must i place the trusted root CA certificate (issued by my organization) in order for webmail to trust it and validate the trust chain?
My configuration is that i run webmail on a server and the imap service on another server (so it`s not a localhost communication). My own organization`s root CA issued a certificate for the imap server. Where must i place the "rootCA.crt" certificate in order for webmail to trust my imap server?
The above configuration works like a charm on Thunderbird, as soon as (obviously) i add the root CA cert to it`s trusted certs. That`s why i feel webmail has the above specified missing option.
Thanks for your time!
So your situation is quite special? You indeed have a self-signed certificate but still want to have it validated? At the same time, only your own self-signed certs (signed by your own root CA) must be trusted?
Exactly. I don't have anything to do with external imap/smtp providers (Google etc). My organization trusts it's own self signed root CA's certificate. It is an internal mail service offered to employees, managed within my organization completely, but at the same time it must be secured. And the quick fix I found does just that.
But I don't get why is this considered a "special" situation? What I want to say is that of course every trust chain ends with a trust anchor, which is a certificate (self-signed or not) in which we trust (so we specify a path to it). What if I want to trust Google's top level, self signed root CA? How do I specify that in webmail configuration? And what is the path used by webmail for trusting (non self signed at the moment) certificates?
Sorry for the long post :)
It's special because you're using your own root CA (which is certainly not the standard case). At first I thought you were implying that SocketVerifySsl setting didn't work at all (i.e. bug). However, it turned out it wasn't so. It works as expected. It doesn't cover your case with custom root CA but it was never intended to do so.
It's more like a feature request to add support for such cases, not a bug fix. We never got such requests so I doubt that there are many folks around who are in need of this feature but who knows. If you think it's mandatory for the product out-of-box, you can vote for it at https://afterlogic.uservoice.com. Thanks!
Ok, sorry for dragging this on, but let's forget for a moment the self signed situation.
Say that I actually purchased a certificate for my imap server from an unowned CA, so I have to add it to the trust list. Where does webmail look into (aka the path to trusted certificates) to validate the connection? Is it strictly using PHP's default locations?
We're using PHP defaults for root CAs.
When setting
"SocketVerifySsl"
totrue
(as described in doc), there is no way to specify the path to trusted CA certificates. As a result, the TLS handshake fails, because the incoming certificate cannot be verified against a trusted CA certificate.In my case, trying to connect to my dovecot server produces this log error:
dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=192.168.255.100, lip=192.168.255.100, TLS handshaking: SSL_accept() failed: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: SSL alert number 48, session=</kqR2bBy5JLAqP9k>
Digging further, i have found that the SSL context responsible of chain verification is created without an option for the needed CA certificates (code here)
This is obviously incomplete, because there`s no way to specify the trusted certificate. A quick fix is to specify the absolute path to the certificate via
cafile
option. Better yet, we can make use of this function (already included after deployment), which returns the path where all CA certificates are stored (and we must simply append the PEM CA certificate to that file).However, this solution is not flexible at all. A way to configure (or even upload using adminpanel) the trusted CA certificates is mandatory, otherwise the trust chain cannot be verified, rendering the connection completely vulnerable to MitM attacks.