New SSL features for Nginx.

Brice Figureau brice+nginx at
Wed Jul 22 23:13:55 MSD 2009

On 22/07/09 20:43, Igor Sysoev wrote:
> On Wed, Jul 22, 2009 at 07:20:39PM +0200, Brice Figureau wrote:
>> On 22/07/09 14:16, Igor Sysoev wrote:
>>> On Wed, Jul 22, 2009 at 12:21:23PM +0200, Brice Figureau wrote:
>>>> Hi Igor,
>>>> On Wed, 2009-07-22 at 12:44 +0400, Igor Sysoev wrote:
>>>>> On Tue, Jul 21, 2009 at 08:02:05PM +0200, Brice Figureau wrote:
>>>>>> Hi,
>>>>>> For Puppet[1] Nginx deployement (that is using Nginx as a front-end 
>>>>>> load-balancers to puppetmasters[2]), I had to create the following two 
>>>>>> patches, to match Apache behaviour:
>>>>>> * The first patch allows:
>>>>>>  + a new variant of ssl_client_verify: optional. In this mode, if the 
>>>>>> client sends a certificate it is verified, but if the client doesn't 
>>>>>> send a certificate, the connection is authorized too.
>>>>>>  + a new variable: $ssl_client_verify which contains, either NONE, 
>>>>>> SUCCESS or FAILURE depending on the verification status. It can be used 
>>>>>> to send information to the upstream about the client verification.
>>>>>> * The second patch adds CRL support to the client certificate 
>>>>>> verification:
>>>>>>  ssl_crl /path/to/crl.pem;
>>>>>> Nginx then verifies the client certificate hasn't been revoked in the 
>>>>>> given CRL before allowing the connection to proceed.
>>>>>> For access to the patches, please see my last blog article:
>>>>>> It would be great if those patches could be merged in the official 
>>>>>> Nginx source tree.
>>>>> Thank you, I have looked the patches, it was really surpise for me that
>>>>> OpenSSL 0.9.7 supports CRL. I read in old enough book "Network Security
>>>>> with OpenSSL" written when 0.9.7 was being developed, that OpenSSL has
>>>>> no built-in CRL support. 
>>>> Ah, ok. I based all my development on OpenSSL 0.9.8, since that's what
>>>> I'm building Nginx againt. And definitely there is CRL support.
>>>> Is OpenSSL 0.9.7 a strict dependency for Nginx?
>>> No. I think this code should be just "#ifdef'ed X509_V_FLAG_CRL_CHECK".
>> I'm OK with this. BTW, I checked and CRL support was added in 0.9.7.
>>>>> Then I have looked in Apache's mod_ssl sources and
>>>>> its CRL support seemed to me very heavy: mod_ssl does a lot of useless
>>>>> operations.
>>>> Which ones?
>>>> What I don't get is why they're doing the CRL verification themselves.
>>> Because mod_ssl were developed before 0.9.7.
>> Yes, I do think so. But it's error-prone and certainly less efficient.
>>>> I found this comment in the code:
>>>>     * OpenSSL provides the general mechanism to deal with CRLs but does
>>>> not
>>>>     * use them automatically when verifying certificates, so we do it
>>>>     * explicitly here. We will check the CRL for the currently checked
>>>>     * certificate, if there is such a CRL in the store.
>>>> This seems wrong to me, as I already tested, and it works fine at least
>>>> in version 0.9.8.
>>> Yes, this implementation. However, I made mistake: it's not too heavy as
>>> it seemed to me first time I have looked.
>>>>> I think that it's enough to store hash of only public key of
>>>>> all CRL certificates (including intermediate ones). 
>>>> Why reinvent the wheel?
>>>> The CRL is a standard thing (see RFC 3280), and basically this is a DER
>>>> encoded ASN1 structure containing the list of the revoked certificates
>>>> serial number, signed by the CA cert.
>>>>> Have you looked
>>>>> how CRL is implemented in OpenSSL ?
>>>> Yes, I did. It is pretty extensive, and matches RFC3280.
>>>> I'll fetch OpenSSL 0.9.7 to see if it supports or not CRL, but I'd be
>>>> suprised it wouldn't.
>> 0.9.7 definitely supports CRL verification.
> Yes. When I mentioned the book, I meant that CRL were not supported
> at least in 0.9.6.
>>>> Thanks for reviewing the patch (at least the first one could be merged,
>>>> isn't it?).
>>> Probabaly, I will commit the patches in next 0.8.7.
>> Will you merge the CRL one (feel free to rewrite it if you prefer), too ?
> Yes, the single issue is name of directive: ssl_crl. Should it be longer and
> more expressive ? Apache has SSLCARevocationFile.

Yes, the name is not very good but the other alternatives I thought 
about were too long:

Maybe the best one is: ssl_ca_revocation?
But that'd be the only directive with CA in it, although that's what's 
is really the ssl_client_certificate one.

So maybe, last try: ssl_client_revocation would be really better.

What do you think?
Brice Figureau
My Blog:

More information about the nginx mailing list