[stunnel-users] Strange CRL verification behaviour

Christophe Nanteuil christophe.nanteuil at gmail.com
Mon Nov 3 15:44:43 CET 2008


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20081103/9c7ce6bc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stunnel-crl_verif.patch
Type: application/octet-stream
Size: 1294 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20081103/9c7ce6bc/attachment.obj>


More information about the stunnel-users mailing list