Hi Christopher, This is not specific to stunnel, but rather the way OpenSSL implements its certificate verification. The same issue for HAProxy includes a discussion that you may find helpful: https://github.com/haproxy/haproxy/issues/968 Consider checking whether this issue was already reported on https://github.com/openssl/openssl/issues?q=is%3Aissue and reporting it there if needed. Best regards,     Mike 16 Apr 2024 00:39:41 Christopher Schultz <[email protected]>:

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 _______________________________________________ stunnel-users mailing list -- [email protected] To unsubscribe send an email to [email protected]