Hi guys,
We've had a few tickets on this and it appears to plausibly be enforcement of something that should have been enforced before, and the fix simply enforces some other error. So it's just exposing problems with the cert/key pairs being used, rather than silently giving up and using the server cert.
A few options can be used, so there are 3 ways to go about sorting out the issue:
- Simply to ensure that the cert/key pair being used for this SNI connection is valid, as it appears the invalid pair that "should fallback to the main cert"?, instead fails the handshake entirely. This is recommended.
Martynas and I have written a script to help check your cert/key pairs, it can be found here. Instructions below.
- Or disable the /etc/virtual/snidomains (rename the file for now), but this means that valid ones in question would no longer work, so probably not what you want.
- Fallback to exim 4.91, again not a great solution.
The change log for 4.92 is here:
https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeLog
The change most likely to be the trigger is this one:
JH/35 OpenSSL: fail the handshake when SNI processing hits a problem, server side. Previously we would continue as if no SNI had been received.
That being said, we can see there are already a whole slew of OpenSSL related to change for 4.93 (not yet released), perhaps they're addressing it in one of those, but possibly not.
For #1, to test your cert/key pairs, use the mentioned script, like this:
Code:
wget http://files.directadmin.com/services/all/ssl/verify_certs/verify_snidomains_certs.sh
chmod 755 verify_snidomains_certs.sh
./verify_snidomains_certs.sh
note that it uses /bin/bash, so ensure you have bash present.
If there are any errors, they'll end up in verify_snidomains_certs.sh.log, right beside the script.
It's possible that the cases in question are in fact a truly broken cert/key pair, in which case it's not an exim bug at all, just either expired or no longer valid, not sure.
If you happen to hit this error and can narrow down exactly which state the cert/key pair are in (.combined is preferred over the .cert), let us know, and we could even add it a nightly check on certs if needed (although, LetsEncrypt certs are already checked, so not sure exactly what people are running in to)
Any issues, feel free to let us know so we can sort out the
exact cause/scenarios, and add preventative measures if needed.
John
