GeoTrust request for EV root inclusion

GeoTrust has applied to add a new EV root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=407168 and in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/#GeoTrust I have evalua

thawte request for EV root inclusion

thawte has applied to add a new EV root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=407163 and in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/#thawte I have evaluated

Re: Microsoft root CA cert requirements updated

Paul Hoffman wrote, On 2008-03-04 07:49: > Here is a slightly edited version of what a lead security developer > at Microsoft told me with regard to EKUs and path processing. [snip] > Every root certificate is stored with some properties that are not > cryptographically bound to the certificate, b

Re: Microsoft root CA cert requirements updated

Paul Hoffman wrote: > For this to work, Microsoft path validation also checks that the end > certificate is consistent with the EKU property of the root. This part > adds to X.509 and rfc 3280bis. A certificate is considered consistent > with the root EKU if each CA certificate in the path eithe

Re: Microsoft root CA cert requirements updated

Here is a slightly edited version of what a lead security developer at Microsoft told me with regard to EKUs and path processing. To the core issue. Does EKU need to be in the root certificate. The answer is: no. Every root certificate is stored with some properties that are not cryptographica

Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

D3|\||\|!$ wrote, On 2008-03-04 04:19: >> selfserv uses blocking sockets. > > I tried turning the PR_SockOpt_Nonblocking given at the below link to > PR_TRUE to see if the clien't behaviour changed but now the PR_Accept > function is throwing PR_WOULD_BLOCK_ERROR(The operation would have > blocked

Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

> selfserv uses blocking sockets. I tried turning the PR_SockOpt_Nonblocking given at the below link to PR_TRUE to see if the clien't behaviour changed but now the PR_Accept function is throwing PR_WOULD_BLOCK_ERROR(The operation would have blocked). How do I circumvent this..??? Kindly suggest a

Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

On Mar 4, 1:42 pm, Nelson Bolyard <[EMAIL PROTECTED]> wrote: > D3|\||\|!$ wrote, On 2008-03-03 21:57: > > > Hi All!!! > > > I wrote an SSL server similar to selfserv.c > > SSL_ConfigServerSessionIDCache is reinitializing the > > Server_Certificate_Nickname string to "", due to which the application

Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

D3|\||\|!$ wrote, On 2008-03-03 21:57: > Hi All!!! > > I wrote an SSL server similar to selfserv.c > SSL_ConfigServerSessionIDCache is reinitializing the > Server_Certificate_Nickname string to "", due to which the application > is not able to find out the certificate or the private key in the >

SSL_ConfigServerSessionIDCache re-initializing nickname string.

Hi All!!! I wrote an SSL server similar to selfserv.c accessible at the link below: http://lxr.mozilla.org/security/source/security/nss/cmd/selfserv/selfserv.c The options configuration string I passed to the application is "-n Server_Certificate_Nickname -d Certificate_Database_Path -w Password