Open Bug 51466 Opened 23 years ago Updated 2 months ago

SSL client rejects server cert with keyUsage = digitalSignature


(NSS :: Libraries, defect, P3)


(Not tracked)


(Reporter: nelson, Unassigned)




(1 obsolete file)

In the IETF-TLS mailing list, Rene Eberhard wrote:

> But be careful with server key exchange messages
> containing a cert with keyUsage = digitalSignature.
> Not all browsers can handle this properly =(. Some reject
> the cert even it has been used for signing a temp rsa key.

When I asked him what browsers do that, he replied to me:

> Unfortunately only Netscape browsers behave that way.
> At least when RSA_EXPORT is used and the temp RSA key
> has been signed with a signing only cert NS should 
> accept that cert.

By reviewing the code, I have found that:
1) the client will only accept a server key exchange message if 
   a) The cipher suite's KEA is limited to 512 bits, or 
   b) it's fortezza.
   It should also allow it if the server's cert is signing-only.

2) our server code only sends the server key exchange message if
   a) it's fortezza, or 
   b) the KEA is RSA_EXPORT and the RSA private key size is > 512.
   It should also allow it if the server's cert is signing-only.

Note that SSL3 and TLS specs differ in the permitted uses of 
signing-only certs.
Fixing this will require some additional code in the cert library.
I should create another bug, against the cert library, and make 
this bug depend on that one.
Target Milestone: --- → 3.2
Doh! the attachment above got attached to the wrong bug.
I wish there was a way to delete that attachment.
Changing target milestone to 3.3
Target Milestone: 3.2 → 3.3
The fix for this will not be in NSS 3.3 or 3.4
Target Milestone: 3.3 → Future
Comment on attachment 15065 [details]
Proposed new implementation of CERT_GetNickName()

obsoleting this attachment. It was attached to the wrong bug, and is not
relevant to this bug.
Attachment #15065 - Attachment is obsolete: true
QA Contact: wtchang → libraries
Assignee: nelson → nobody
Target Milestone: Future → ---
The problem still exists today.

A digitalSignature only server certificate, used with a DHE+RSA ciphersuite, displays an error message on the client (sec_error_inadequate_key_usage).
It seems like, in order to support this, we need to pass the intended key usage (encryption or digitalSignature) to the cert authentication callback, which means we would need a new cert auth callback interface. Also, if the application does any caching of cert authentication results, it needs to consider the key usage to be part of the cache key.

Perhaps, we could add this new cert auth callback function as part of the work on enabling non-blocking cert auth callbacks (bug 542832).
I remember I wrote a comment about this problem in some other
bug report recently, so there is a duplicate of this bug in
Isn't it more CERT_CheckKeyUsage() in certdb.c which might have to be tweaked (the rsaKey case)?
See the comments in bug 237877, especially Nelson's comment bug 237877 comment 1.

For ECDHE_RSA and DHE_RSA cipher suites, we should verify the cert is valid for digital signatures; for normal RSA cipher suites, we should verify the cert is valid for encryption. It seems like it will be impossible to do this with the old non-libpkix API, but it should be possible with libpkix.

Do we guarantee that SSL_GetChannelInfo can be called by the auth cert callback to retrieve the cipher suite used? If so, SSL_GetChannelInfo + SSL_GetCipherSuiteInfo can be used to determine which key agreement scheme is used, and this can be used to determine the required key usage. So, perhaps no new auth certificate callback is needed.
As Kaspar noted, we can tweak CERT_CheckKeyUsage to require
digitalSignature or keyEncipherment for RSA server certificates.
We already give ecKey that kind of special treatment:,1259,1274-1276#1246

Proper key usage extension of an RSA server certificate can be enforced
in ssl3_HandleServerKeyExchange (or rather ssl3_VerifySignedHashes)
and ssl3_SendClientKeyExchange.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.