With stunnel 4.26 (or ealier), in order to verify revocation of clients' certificates, I use this configuration file :<br>-------------------8<------------------<br>CAfile=/etc/ssl/stunnel/ca_certs.pem<br>CRLfile=/etc/ssl/stunnel/crl.pem<br>
cert=/etc/ssl/stunnel/server.pem<br>key=/etc/ssl/stunnel/server.key<br>sslVersion=TLSv1<br>verify=2<br><br>[WEB]<br>accept=8080<br>connect=<a href="http://127.0.0.1:3128" target="_blank">127.0.0.1:3128</a><br>------------------->8------------------<br>
<br>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" <br>-> ok.<br><br>2/ If the CRLfile is correct, stunnel starts. When the CRL expires, stunnel rejects any new connection.<br>
Logs then show : " Found CRL is expired - revoking all certificates until you get updated CRL"<br>-> ok<br><br>3/ If the CRLfile is not a valid CRL, stunnel starts and ignores the CRLfile.<br>Then, for any new connection, logs show "CRL: verification passed".<br>
-> NOT ok, IMO.<br>examples of wrong CRLs : a CRL issued by an unknown CA or a certificate in the PEM format.<br>This can happen when the CRL expires (soon) and the administrator puts a "new one" but misfits files. He then restarts stunnel, which works.<br>
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.<br>
<br>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 :<br>
- reject connection if CRLdir or CRLfile was specified in the config file<br>- accept connection but warn in logs if the use of CRL was not explicitly set in the config file.<br><br>NB : the source code of function "crl_check" shows "/* based on BSD-style licensed code of mod_ssl */". <br>
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.<br><br>--<br>Christophe Nanteuil<br>