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