Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
For tracking purposes (this problem is fixed in 1.3.6+).
FWIW as well, 4 years ago, stunnel got rid of custom CRL handling code and started relying on OpenSSL's built-in handling instead. That was between 5.23 and 5.24, compare src/verify.c from https://www.usenix.org.uk/mirrors/stunnel/archive/5.x/stunnel-5.23.tar.gz and https://www.usenix.org.uk/mirrors/stunnel/archive/5.x/stunnel-5.24.tar.gz .
I didn't hit this issue in the summer of 2018 when dealing with TLS CRLs using CentOS 7's ProFTPD 1.3.5e package, because the set of test CRLs only contained CRLs revoking at most one certificate, but I noticed it in the 1.3.5 -> 1.3.6 diff.