Robert Joop wrote:
> On 01-10-24 05:46:48 CEST, Nelson B. Bolyard wrote:

> > SEC_ERROR_INADEQUATE_CERT_TYPE means that the server certificate (or one
> > of the CA certificates in the server cert's chain) has some extension that
> > says it is not able to be used for SSL server certificates.

However, that's error -8102.  My mistake.  Here's a correct analysis of 
the problem.

Error -8101 is SEC_ERROR_INADEQUATE_CERT_TYPE which is translated 
Certificate type not approved for application.  That is, the application
needs an SSL server cert, and this one isn't setup that way.

In this case, the server's own cert lacks an extension that says it can be
used for SSL/TLS server authentication.  The problem is not in a CA cert
but rather is in the server's own cert.  

Your server cert should contain an "extended Key Usage" extension that 
identifies it as being valid for server authentication.  It should look
like this:

 563 A3   37:     [3] {
 565 30   35:       SEQUENCE {
 567 30   19:         SEQUENCE {
 569 06    3:           OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
            :             (X.509 id-ce (2 5 29))
 574 04   12:           OCTET STRING, encapsulates {
 576 30   10:               SEQUENCE {
 578 06    8:                 OBJECT IDENTIFIER serverAuth (1 3 6 1 5 5 7 3 1)
            :                   (PKIX key purpose)
            :                 }
            :               }
            :           }

The rule is that IF a server cert contains an extended Key Usage extension, 
then it MUST include the extended usage for server authentication.

Your server's cert has an Extended Key Usage extension, but it doesn't 
contain this value.  It contains some other usages that will not work you.

I have now succesfully connected to your server, by bypassing that check
in my own test version of the SSL library.  I observed 2 things about
your server that (IMO) are problems:

1. The server cert lacks the proper extended key usage extenstion, 
as mentioned above.

2. The server does not send out the proper cert "chain" to the client.

It sends the server's own cert, but it does not send the CA cert for the 
CA that issued the server's cert.  It is not necessary to send the issuer
CA cert when the issuer CA cert is a root CA cert.  But in your case,
you have an "intermediate" CA, one whose cert was issued by another root CA,
and which issued the server cert.  The intermediate CA cert(s) must also be
sent to the client in the same certificate message that sends the server's
own cert.  

To work around this second problem, you apparently have created a page that
allows users to also download that intermediate CA cert.  However that step
should not be necessary, and it would not be if the server sent the 
intermediate CA cert in the SSL certificate message.

Nelson Bolyard               Netscape Communications (subsidiary of AOL)
Disclaimer:                  I speak for myself, not for Netscape

Reply via email to