Hello,
I was recently rotating a certificate for a service and I went through my usual procedure:
1. Generate a new client key+cert; don't place them into service, yet
2. Distribute the new certificate to all my stunnel servers that need to trust it by placing it at the end of each of my servers' CAFile files
3. Restart all stunnel services
4. Swap the old key+cert for the client with the new key+cert
5. Test that all is well
I've found that if the Distinguished Name of both the old and new certificate are the same, stunnel will only trust the one that is mentioned /first/ in the CAFile.
For example, if the CAFile contains:
-----BEGIN CERTIFICATE----- certificate A Serial Number: 12345678 Subject: C=US, OU=Testing, O=Example.com, CN=test -----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE----- certificate B Serial Number: 87654321 Subject: C=US, OU=Testing, O=Example.com, CN=test -----BEGIN CERTIFICATE-----
Certificate A will be trusted but Certificate B will not be trusted. The error shown in the logs is:
CERT: Pre-verification error: self signed certificate Apr 15 21:33:06 mirth-pcc.chadis.com stunnel[23421]: Certificate check failed: depth=0, /C=US/OU=Testing/O=Example.com/CN=test
While the certificates are both self-signed, that should not cause an error.
Removing the old certificate from the CAFile or moving it to the bottom of the file resolves the problem. (But of course then Certificate A is no longer trusted despite it appearing in the CAFile.)
Is this expected behavior? It would be very helpful if stunnel could support two different certificates with the same Subject DN for these kinds of cert-rotation processes. The alternatives are to always use a new DN each time or to add/remove at the same time which makes rolling-back more difficult. Note that everything else about these certificates is different: serial number, fingerprint, generating-key, etc. It's only the Subject DN that is the same.
This is stunnel 4.56 on x86_64-koji-linux-gnu platform, on Amazon Linux 2.
Thanks!
-chris