New SSL features for Nginx.

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

New SSL features for Nginx.

Brice Figureau-3
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:
http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/

It would be great if those patches could be merged in the official Nginx
source tree.

Thanks,

[1]: http://reductivelabs.com/products/puppet/
[2]: http://reductivelabs.com/trac/puppet/wiki/UsingMongrelNginx
--
Brice Figureau
My Blog: http://www.masterzen.fr/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
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:
> http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
>
> 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. 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. I think that it's enough to store hash of only public key of
all CRL certificates (including intermediate ones). Have you looked
how CRL is implemented in OpenSSL ?


--
Igor Sysoev
http://sysoev.ru/en/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Brice Figureau-3
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:
> > http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
> >
> > 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?

> 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.
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.

> 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.

Thanks for reviewing the patch (at least the first one could be merged,
isn't it?).
--
Brice Figureau
My Blog: http://www.masterzen.fr/


Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Brice Figureau-3
On Wed, 2009-07-22 at 12:21 +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:
> > > http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
> > >
> > > 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?
>
> > 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.
> 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.
>
> > 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.

Good news!
I checked the OpenSSL Changelog and CRL verification has been added in
version 0.9.7. So if Nginx requires this version (and up), which is I
think what it does, then my CRL patch is enough to get CRL support for
Nginx :-)

Thanks,
--
Brice Figureau
My Blog: http://www.masterzen.fr/


Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
In reply to this post by Brice Figureau-3
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:
> > > http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
> > >
> > > 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".

> > 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.

> 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.
>
> 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.


--
Igor Sysoev
http://sysoev.ru/en/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
In reply to this post by Brice Figureau-3
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:
> > > http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
> > >
> > > It would be great if those patches could be merged in the official Nginx
> > > source tree.

> Thanks for reviewing the patch (at least the first one could be merged,
> isn't it?).

Could you test the attached slightly changed first patch ?


--
Igor Sysoev
http://sysoev.ru/en/

patch.ssl.optional (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Brice Figureau-3
On 22/07/09 16:52, 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:
>>>> http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
>>>>
>>>> It would be great if those patches could be merged in the official Nginx
>>>> source tree.
>
>> Thanks for reviewing the patch (at least the first one could be merged,
>> isn't it?).
>
> Could you test the attached slightly changed first patch ?

It works fine, and passes all my tests.

Thanks,
--
Brice Figureau
My Blog: http://www.masterzen.fr/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Brice Figureau-3
In reply to this post by Igor Sysoev
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:
>>>> http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
>>>>
>>>> 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.

>> 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 ?

Thanks,
--
Brice Figureau
My Blog: http://www.masterzen.fr/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
In reply to this post by Brice Figureau-3
On Wed, Jul 22, 2009 at 07:15:54PM +0200, Brice Figureau wrote:

> On 22/07/09 16:52, 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:
> >>>>http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
> >>>>
> >>>>It would be great if those patches could be merged in the official
> >>>>Nginx source tree.
> >
> >>Thanks for reviewing the patch (at least the first one could be merged,
> >>isn't it?).
> >
> >Could you test the attached slightly changed first patch ?
>
> It works fine, and passes all my tests.

OK.


--
Igor Sysoev
http://sysoev.ru/en/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
In reply to this post by Brice Figureau-3
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:
> >>>>http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
> >>>>
> >>>>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.


--
Igor Sysoev
http://sysoev.ru/en/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Brice Figureau-3
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:
>>>>>> http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
>>>>>>
>>>>>> 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:
ssl_certificate_revocation
ssl_ca_revocation
ssl_ca_certificate_revocation

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: http://www.masterzen.fr/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
On Wed, Jul 22, 2009 at 09:13:55PM +0200, Brice Figureau wrote:

> 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:
> >>>>>>http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
> >>>>>>
> >>>>>>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:
> ssl_certificate_revocation
> ssl_ca_revocation
> ssl_ca_certificate_revocation
>
> 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?

Probably, ssl_client_revocation is better.
Question to native speakers: should it be ssl_client_revocationS ?


--
Igor Sysoev
http://sysoev.ru/en/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Brice Figureau-3
On 22/07/09 21:24, Igor Sysoev wrote:

> On Wed, Jul 22, 2009 at 09:13:55PM +0200, Brice Figureau wrote:
>
>> 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:
>>>>>>>> http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
>>>>>>>>
>>>>>>>> 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:
>> ssl_certificate_revocation
>> ssl_ca_revocation
>> ssl_ca_certificate_revocation
>>
>> 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?
>
> Probably, ssl_client_revocation is better.
> Question to native speakers: should it be ssl_client_revocationS ?

My idea was that this directive was an abbrevation of
ssl_client_revocation_file, so the 's' wasn't needed. But I'm not a
native speaker, or in fact I'm a native speaker, but not of English :-)
--
Brice Figureau
My Blog: http://www.masterzen.fr/

Reply | Threaded
Open this post in threaded view
|

Vyatta firewall with Nginx

Tom Keyser
Anyone have any experience running Nginx on a Vyatta firewall? Its using
32bit debian OS but allows you to get root access and install other
programs. Does Nginx run on 32bit Debian?

Reply | Threaded
Open this post in threaded view
|

Re: Vyatta firewall with Nginx

Glen Lumanau
Yes nginx can be run on 32bit or 64bit OS

------Original Message------
From: Tom Keyser
Sender: [hidden email]
To: [hidden email]
ReplyTo: [hidden email]
Subject: Vyatta firewall with Nginx
Sent: Jul 23, 2009 7:50 AM

Anyone have any experience running Nginx on a Vyatta firewall? Its using
32bit debian OS but allows you to get root access and install other
programs. Does Nginx run on 32bit Debian?




Best Regards,

Glen Lumanau


Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Edward Middleton
In reply to this post by Igor Sysoev
Igor Sysoev wrote:
> Brice Figureau wrote:
>  
>> 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.
>  

I think the original argument is better.  Anyone who uses a CRL[1] is
going to know what it is.  If you call the command something else they
have to search the manual to find out what you have chosen to called
it.  In my opinion it would be better to call it ssl_crl_file so that it
is obvious it expects a file path.

Edward

1. http://tools.ietf.org/html/rfc5280

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Cliff Wells
On Thu, 2009-07-23 at 11:26 +0900, Edward Middleton wrote:

> Igor Sysoev wrote:
> > Brice Figureau wrote:
> >  
> >> 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.
> >  
>
> I think the original argument is better.  Anyone who uses a CRL[1] is
> going to know what it is.  If you call the command something else they
> have to search the manual to find out what you have chosen to called
> it.  In my opinion it would be better to call it ssl_crl_file so that it
> is obvious it expects a file path.

I agree with this reasoning.   Making the name longer isn't going to
reduce the need to refer to the documentation and "crl" seems to be the
key word people will be searching for.

Cliff

--
http://www.google.com/search?q=vonage+sucks


Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
In reply to this post by Edward Middleton
On Thu, Jul 23, 2009 at 11:26:47AM +0900, Edward Middleton wrote:

> Igor Sysoev wrote:
> > Brice Figureau wrote:
> >  
> >> 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.
> >  
>
> I think the original argument is better.  Anyone who uses a CRL[1] is
> going to know what it is.  If you call the command something else they
> have to search the manual to find out what you have chosen to called
> it.  In my opinion it would be better to call it ssl_crl_file so that it
> is obvious it expects a file path.

It's seems you are right. CRL became well known abbreviation as SSL itself.


--
Igor Sysoev
http://sysoev.ru/en/

Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Igor Sysoev
In reply to this post by Brice Figureau-3
On Wed, Jul 22, 2009 at 07:20:39PM +0200, Brice Figureau wrote:

> >>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 ?

Could you test the attached patch ?


--
Igor Sysoev
http://sysoev.ru/en/

patch.ssl.crl (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New SSL features for Nginx.

Brice Figureau-3
On Thu, 2009-07-23 at 11:57 +0400, Igor Sysoev wrote:

> On Wed, Jul 22, 2009 at 07:20:39PM +0200, Brice Figureau wrote:
>
> > >>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 ?
>
> Could you test the attached patch ?

It works fine, all my CRL tests are passing.

Thanks!
--
Brice Figureau
My Blog: http://www.masterzen.fr/