cURL / Mailing Lists / curl-library / Single Mail


Re: Key use of test certificate

From: Von Hawkins <>
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: Etiquette:

List admin:
Received on 2014-07-23