TLS trust of a chain of certificates up to a root CA. Certificate Sign extenstion not set

[Mourad Cherfaoui]

Hi,

 

I have a chain of certificates C->B->A->RootCA. The TLS client only presents C during the TLS handshake. RootCA has the Certificate Sign extension set but not B and A.

 

The TLS server fails the TLS handshake because of the absence of the Certificate Sign extension in B and A.

 

My first question: if the TLS server has the entire chain of certificates B->A->RootCA in its truststore, is it correct to assume that the Certificate Sign extension is not required in B and A? My second question: by default the TLS server will fail the TLS handshake because of the absence of the Certificate Sign extension. Is there a recommended way to disables the check for this extension in the TLS handshake?

 

Thanks,

 

Mourad.

[Dr. Stephen Henson]

On Tue, Oct 27, 2009, Mourad Cherfaoui wrote:

>
> Hi,   I have a chain of certificates C->B->A->RootCA. The TLS client only
> presents C during the TLS handshake. RootCA has the Certificate Sign
> extension set but not B and A.    The TLS server fails the TLS handshake
> because of the absence of the Certificate Sign extension in B and A.    My
> first question: if the TLS server has the entire chain of certificates
> B->A->RootCA in its truststore, is it correct to assume that the Certificate
> Sign extension is not required in B and A? My second question: by default
> the TLS server will fail the TLS handshake because of the absence of the
> Certificate Sign extension. Is there a recommended way to disables the check
> for this extension in the TLS handshake?    Thanks,   Mourad.
>
>
>      

The client is broken then the standard requires that the entire chain be
presented with the possible exception of the root.

What do you mean by "Certificate Sign extension"? Do you mean the keyUsage
extension is present but doesn't set the certificate sign bit? If so the
certificate is broken.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Mourad Cherfaoui (mcherfao)]

Thanks Steve,

Yes, the keyUsage is present but the sign bit is not set. As a background on this, the user does not want his CA to set the sign bit for non-root certificates.

I am not sure I understand why the client is broken? Did you mean that the sign bit can be omitted if the client sends the entire chain of certificates (except maybe the root) AND the server has the certificates chain as well? Thanks.

Mourad.

Here is a snippet of the extensions:

            X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points:  

-----Original Message-----
From: owner-openssl-users@... [mailto:owner-openssl-users@...] On Behalf Of Dr. Stephen Henson
Sent: Wednesday, October 28, 2009 5:00 AM
To: openssl-users@...
Subject: Re: TLS trust of a chain of certificates up to a root CA.Certificate Sign extenstion not set

On Tue, Oct 27, 2009, Mourad Cherfaoui wrote:

>
> Hi,   I have a chain of certificates C->B->A->RootCA. The TLS client
> only presents C during the TLS handshake. RootCA has the Certificate
> Sign extension set but not B and A.    The TLS server fails the TLS
> handshake because of the absence of the Certificate Sign extension in
> B and A.    My first question: if the TLS server has the entire chain
> of certificates
> B->A->RootCA in its truststore, is it correct to assume that the
> B->A->Certificate
> Sign extension is not required in B and A? My second question: by
> default the TLS server will fail the TLS handshake because of the
> absence of the Certificate Sign extension. Is there a recommended way
> to disables the check for this extension in the TLS handshake?    Thanks,   Mourad.
>
>
>      

The client is broken then the standard requires that the entire chain be presented with the possible exception of the root.

What do you mean by "Certificate Sign extension"? Do you mean the keyUsage extension is present but doesn't set the certificate sign bit? If so the certificate is broken.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Patrick Patterson-3]

On October 28, 2009 12:10:16 pm Mourad Cherfaoui (mcherfao) wrote:
> Thanks Steve,
>
> Yes, the keyUsage is present but the sign bit is not set. As a background
> on this, the user does not want his CA to set the sign bit for non-root
> certificates.
>
If the keyUsage is present and the certSign bit is NOT set in a CA certificate
(even an intermediate cert), then that cert may NOT be used to sign
certificates.

From RFC5280:

The digitalSignature bit is asserted when the subject public key
      is used for verifying digital signatures, *other than signatures on
      certificates (bit 5) and CRLs (bit 6)*, such as those used in an
      entity authentication service, a data origin authentication
      service, and/or an integrity service.

The keyCertSign bit is asserted when the subject public key is
      used for verifying signatures on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section 4.2.1.9) MUST also be asserted.


(Emphasis mine).

> I am not sure I understand why the client is broken? Did you mean that the
> sign bit can be omitted if the client sends the entire chain of
> certificates (except maybe the root) AND the server has the certificates
> chain as well? Thanks.
>
The Intermediate CA Certificate is broken, not the client. The client software
is 100% right in rejecting the chain. I would strongly suggest to go back and
re-issue the intermediate CA following RFC5280. If you do not, your PKI will
keep failing in new and interesting ways.

Have fun.

--
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Wed, Oct 28, 2009, Mourad Cherfaoui (mcherfao) wrote:

>
> I am not sure I understand why the client is broken? Did you mean that the
> sign bit can be omitted if the client sends the entire chain of certificates
> (except maybe the root) AND the server has the certificates chain as well?
> Thanks.
>

My comment about it being broken (or more likely misconfigured) was nothing to
do with the keyUsage extension. The SSL/TLS standards do not allow a client to
just present the EE certificate: the whole chain has to be presented with
the possible exception of the root.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Eisenacher, Patrick]

Hi Mourad,

-----Original Message-----
> From: On Behalf Of Mourad Cherfaoui
> Sent: Wednesday, October 28, 2009 6:23 AM
> To: openssl-users@...
> Subject: TLS trust of a chain of certificates up to a root CA. Certificate
> Sign extenstion not set

> I have a chain of certificates C->B->A->RootCA. The TLS client only presents C
> during the TLS handshake. RootCA has the Certificate Sign extension set but not
> B and A.

SSL requests the client to send all certificates necessary to verify its identity. Only when the client knows that the server has access to part of its certificate chain, it is allowed to send less.

If you have control over the client, you should configure it to send its whole certificate chain. If you don't have control over the client, you need to add all certificates of the client's certificate chain that the client doesn't send to the server's truststore.

This is your first requirement. Fix this first, then move on to the extension topic.

> The TLS server fails the TLS handshake because of the absence of the
> Certificate Sign extension in B and A.

If the server can't build the client's certificate chain to a cert in its truststore, verification of the client's identity fails, and as such the handshake.

> My first question: if the TLS server has the entire chain of certificates
> B->A->RootCA in its truststore, is it correct to assume that the Certificate
> Sign extension is not required in B and A?

No, your assumption is wrong.

> My second question: by default the
> TLS server will fail the TLS handshake because of the absence of the
> Certificate Sign extension. Is there a recommended way to disables the check
> for this extension in the TLS handshake?

Once the server has constructed the client's certificate chain to one of its own trusted certificates, it starts verifying the certificate chain according to some verification profile. OpenSSL uses the PKIX profile has specified in RFC 5280. PKIX requires CA certificates to have the keyUsage extension and it should be marked critical. As such the extension needs to have at least the value keyCertSign. Check the RFC for more info about the keyUsage extension.

4 options come to mind how to solve your problem:

- fix your configuration & your certificates. This is the recommended way.

- use X.509v1 certificates - they don't contain extensions

- don't use SSL with client authentication, but then your client will probably fail to verify the server's identity as well, if the server is certified by a CA whose certificate is missing the keyUsage extension.

- configure the server to move on with the handshake even in the case of a failed verification of the client's identity, i.e. request client authentication but grant access to anonymous clients as well


HTH,
Patrick Eisenacher
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Joe Orton]

On Wed, Oct 28, 2009 at 06:51:02PM +0100, Dr. Stephen Henson wrote:

> On Wed, Oct 28, 2009, Mourad Cherfaoui (mcherfao) wrote:
> > I am not sure I understand why the client is broken? Did you mean that the
> > sign bit can be omitted if the client sends the entire chain of certificates
> > (except maybe the root) AND the server has the certificates chain as well?
> > Thanks.
>
> My comment about it being broken (or more likely misconfigured) was nothing to
> do with the keyUsage extension. The SSL/TLS standards do not allow a client to
> just present the EE certificate: the whole chain has to be presented with
> the possible exception of the root.

Well, per the BUGS section in SSL_CTX_set_client_cert_cb it is nigh-on
impossible for a client author to DTRT with OpenSSL because of the
limitations of the API.

Regards, Joe
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Thu, Oct 29, 2009, Joe Orton wrote:

> On Wed, Oct 28, 2009 at 06:51:02PM +0100, Dr. Stephen Henson wrote:
> > On Wed, Oct 28, 2009, Mourad Cherfaoui (mcherfao) wrote:
> > > I am not sure I understand why the client is broken? Did you mean that the
> > > sign bit can be omitted if the client sends the entire chain of certificates
> > > (except maybe the root) AND the server has the certificates chain as well?
> > > Thanks.
> >
> > My comment about it being broken (or more likely misconfigured) was nothing to
> > do with the keyUsage extension. The SSL/TLS standards do not allow a client to
> > just present the EE certificate: the whole chain has to be presented with
> > the possible exception of the root.
>
> Well, per the BUGS section in SSL_CTX_set_client_cert_cb it is nigh-on
> impossible for a client author to DTRT with OpenSSL because of the
> limitations of the API.
>

Hmm... seems to be a little out of date. It is possible to add certs to the
store and set them to an appropriate trust value to avoid them being
acceptable as server roots. Though we should really have a callback which can
return the whole chain too.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[wolfoftheair]

If a certificate does not have the standard keyUsage: signature, then that certificate cannot sign any message, at all.  No email, no client signature of TLS authentication parameters, nothing.

-Kyle H

On Wed, Oct 28, 2009 at 9:10 AM, Mourad Cherfaoui (mcherfao) <mcherfao@...> wrote:

> Thanks Steve,
>
> Yes, the keyUsage is present but the sign bit is not set. As a background on this, the user does not want his CA to set the sign bit for non-root certificates.
>
> I am not sure I understand why the client is broken? Did you mean that the sign bit can be omitted if the client sends the entire chain of certificates (except maybe the root) AND the server has the certificates chain as well? Thanks.
>
> Mourad.
>
> Here is a snippet of the extensions:
>
>            X509v3 Key Usage: critical
>            Digital Signature, Key Encipherment
>            X509v3 CRL Distribution Points:
>
> -----Original Message-----
> From: owner-openssl-users@... [mailto:owner-openssl-users@...] On Behalf Of Dr. Stephen Henson
> Sent: Wednesday, October 28, 2009 5:00 AM
> To: openssl-users@...
> Subject: Re: TLS trust of a chain of certificates up to a root CA.Certificate Sign extenstion not set
>
> On Tue, Oct 27, 2009, Mourad Cherfaoui wrote:
>
>>
>> Hi,   I have a chain of certificates C->B->A->RootCA. The TLS client
>> only presents C during the TLS handshake. RootCA has the Certificate
>> Sign extension set but not B and A.    The TLS server fails the TLS
>> handshake because of the absence of the Certificate Sign extension in
>> B and A.    My first question: if the TLS server has the entire chain
>> of certificates
>> B->A->RootCA in its truststore, is it correct to assume that the
>> B->A->Certificate
>> Sign extension is not required in B and A? My second question: by
>> default the TLS server will fail the TLS handshake because of the
>> absence of the Certificate Sign extension. Is there a recommended way
>> to disables the check for this extension in the TLS handshake?    Thanks,   Mourad.
>>
>>
>>
>
> The client is broken then the standard requires that the entire chain be presented with the possible exception of the root.
>
> What do you mean by "Certificate Sign extension"? Do you mean the keyUsage extension is present but doesn't set the certificate sign bit? If so the certificate is broken.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...
>