curl-library
Re: Key use of test certificate
Date: Tue, 22 Jul 2014 17:07:15 -0700
>I looked into why test 310 is failing to run on a CyaSSL build with a
>"failed starting HTTPS server (stunnel)" error. The answer is that the server
>verification is failing with
>
> * SSL_connect failed with error -283: Key Use digitalSignature not set Error
>
>CyaSSL doesn't like that the certificate that stunnel is using
>(tests/certs/Server-localhost-sv.pem) does not have the digitalSignature key
>usage extension bit 0x100 set. The certificate does have the
>keyEncipherment bit set, but no others. I'm no X.509 expert, but my reading of
>RFC 5280 is that this bit is not needed when verifying certificate signatures,
>which I imagine is all that's needed here. If that's the case, then CyaSSL is
>in the wrong. Otherwise, we'd have to regenerate that cert to add the bit.
>However, checking random certs on web sites, 9 out of 10 had both bits set, so
>for that reason I'm leaning towards regenerating our certs with this bit.
>Does anyone have any idea which side is right here?
Typically a person cert (ID or email signature) will have only digitalSignature and nonRepudiation in one a digital signature cert and keyEncipherment will be alone in an email encryption cert.
A server SSL cert will generally have keyEncipherment and digitalSignature set together in one cert.
It isn't so much a matter of what the RFC calls for as it is the use case. An SSL cert is both asserting the server's identity and encrypting a symmetric key to encrypt the session traffic. Your use case sounds like it should use both usages. I would think that curl would be checking the name in the cert unless that's disabled, so its crypto-library should be checking for the digitalSignature bit.
Why aren't the other crypto-libraries failing on this case?
That raises another question for me though. Digital signature is supposed to assert data integrity, not the identity of the signer. Non-repudiation asserts the identity, but most servers don't have that usage set. Oh, the RFC explains it. The identity assertion a server makes is not expected to protect against falsely denying an action. It just asserts the the server is the server the client called.
--V/r
Von
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-07-23