With stunnel 4.26 (or ealier), in order to verify revocation of clients' certificates, I use this configuration file :
-------------------8<------------------
CAfile=/etc/ssl/stunnel/ca_certs.pem
CRLfile=/etc/ssl/stunnel/crl.pem
cert=/etc/ssl/stunnel/server.pem
key=/etc/ssl/stunnel/server.key
sslVersion=TLSv1
verify=2
[WEB]
accept=8080
connect=127.0.0.1:3128
------------------->8------------------
1/ If there is no CRLfile when stunnel starts, stunnel dies and logs show "Failed to load /etc/ssl/stunnel/crl.pem revocation lookup file"
-> ok.
2/ If the CRLfile is correct, stunnel starts. When the CRL expires, stunnel rejects any new connection.
Logs then show : " Found CRL is expired - revoking all certificates until you get updated CRL"
-> ok
3/ If the CRLfile is not a valid CRL, stunnel starts and ignores the CRLfile.
Then, for any new connection, logs show "CRL: verification passed".
-> NOT ok, IMO.
examples of wrong CRLs : a CRL issued by an unknown CA or a certificate in the PEM format.
This can happen when the CRL expires (soon) and the administrator puts a "new one" but misfits files. He then restarts stunnel, which works.
This behaviour can be annoying because the logs of CRL are now in level 6 (INFO) and not any more in level 5 (NOTICE). My configuration was in debug=5 and logs showed only "CRL: verification passed", I could not determine what CRL was really used.
I propose the attached patch to modify behaviour in case 3/, ie if no CRL corresponding to the issuer of each certificate of the chain is found :
- reject connection if CRLdir or CRLfile was specified in the config file
- accept connection but warn in logs if the use of CRL was not explicitly set in the config file.
NB : the source code of function "crl_check" shows "/* based on BSD-style licensed code of mod_ssl */".
I looked into the code of "mod_ssl-2.8.31-1.3.41" (file pkg.sslmod/ssl_engine_kernel.c, line 1601-1769) and there is actually the same behaviour.
--
Christophe Nanteuil