CRL update mechanism for mod_nss
Dear all, If you import an updated version of a CRL in mod_nss and you make use of the same nickname: * Is it necessary to restart the web server for mod_nss to take it into account? * Does mod_nss still remember the old CRL? kind regards, Dave -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox requires 2 times to select certificate for validation
2009/3/20 Nelson B Bolyard > > dave davesons wrote, On 2009-03-20 10:18: > > Dear all, > > > > I have configure a reverse proxy with client certificate validation. > > > > When accessing the site using firefox, firefox first asks the user to > > select the certificate to authenticate as it should do. After this first > > authentication, however, the user is asked again to choose the > > certificate to use. In the firefox traces, I see that this second > > authentication is needed for favicon.ico. > > The behavior you describe is due to server misconfiguration. You must > enable the server's session cache, and configure session cache lifetimes > to be long enough that they will last at least as long as a user's > typical session with that server. > -- Hi, thank you for the response. The Mod_nss standard settings have session cache enabled I think. I used the following: NSSSessionCacheSize 1 NSSSessionCacheTimeout 3600 NSSSession3CacheTimeout 3600 I also tried: NSSOptions +OptRenegotiate but this did not help either. kind regards, Dave -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Firefox requires 2 times to select certificate for validation
Dear all, I have configure a reverse proxy with client certificate validation. When accessing the site using firefox, firefox first asks the user to select the certificate to authenticate as it should do. After this first authentication, however, the user is asked again to choose the certificate to use. In the firefox traces, I see that this second authentication is needed for favicon.ico. I tried to deny access to favicon.ico, but then the same behaviour happens for the css files. My configuration is: NSSVerifyClient require NSSRequireSSL NSSOptions +FakeBasicAuth +StdEnvVars ProxyPass / http://10.10.11.10/ ProxyPassReverse / http://10.10.11.10/ I assume firefox opens some new connection for these files. Is there some workaround for this behaviour? With internet explorer, this problem does not occur. kind regards, Dave -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: delta crl support
Hi again,
Does anyone know of any benchmarks regarding the size of CRLs towards
performance? Or how much CRLs are supported at most?
2009/3/12 dave davesons
> Hi,
>
> thanks for the clarification. BTW: OCSP is available in belgium. But we
> like to have a fallback
>
> 2009/3/12 Nelson B Bolyard
>
> dave ("Mike") davesons wrote, On 2009-03-11 08:52:
>>
>> > In our organization we use nss to validate CRLs of the Belgian
>> Government.
>> > In a few months it is expected that these CRLs will grow exponentially.
>> > It will be necessary to download many gigabytes of CRLs each day.
>>
>> So, you see this problem coming in advance. That's good. Maybe someone
>> should be looking into how this revocation problem can be solved without
>> gigabytes of CRLs, like OCSP for example.
>>
>> > Therefore, delta CRL seem to become necessary.
>> > Is there already any progress on the delta CRLs?
>> >
>> > kind regards,
>> > Mike
>>
>> No, there are no plans for delta CRLs.
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
>
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: delta crl support
Hi,
thanks for the clarification. BTW: OCSP is available in belgium. But we like
to have a fallback
2009/3/12 Nelson B Bolyard
> dave ("Mike") davesons wrote, On 2009-03-11 08:52:
>
> > In our organization we use nss to validate CRLs of the Belgian
> Government.
> > In a few months it is expected that these CRLs will grow exponentially.
> > It will be necessary to download many gigabytes of CRLs each day.
>
> So, you see this problem coming in advance. That's good. Maybe someone
> should be looking into how this revocation problem can be solved without
> gigabytes of CRLs, like OCSP for example.
>
> > Therefore, delta CRL seem to become necessary.
> > Is there already any progress on the delta CRLs?
> >
> > kind regards,
> > Mike
>
> No, there are no plans for delta CRLs.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: delta crl support
Dear, In our organization we use nss to validate CRLs of the Belgian Government. In a few months it is expected that these CRLs will grow exponentially. It will be necessary to download many gigabytes of CRLs each day. Therefore, delta CRL seem to become necessary. Is there already any progress on the delta CRLs? kind regards, Mike sg4all wrote, On 2008-12-22 06:46: > Dear all, > does the current version of nss already support delta crls? No. Presently, No version of NSS supports delta CRLs. There are no definite plans to do so, at this time. It has been on the wish list for a long time. > I can only find old information about this. Where can I find up to date > info about such information? It may be that the information you found, while old, is nonetheless current. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
