self-signed.badssl.com and recent openssl

[drwetter]

Hi there,

it seems this test has a problem with recent versions of openssl, see https://github.com/drwetter/testssl.sh/issues/431.

Any change to remove the keyUsage extension so that the openssl bug isn't triggered?

Cheers, Dirk

[lgarron]

I'm not very familiar with keyUsage, but the badssl.com wildcard cert also has keyUsage, and nothing it seems to work fine. Are you sure that's what's the problem?

[lgarron]

https://github.com/drwetter/testssl.sh/issues/431#issuecomment-235627187 suggests that keyUsage should contain keyCertSign (or maybe any)?

[drwetter]

@lgarron it pretty much looks like it, see also https://github.com/openssl/openssl/issues/1418 . So according to the openssl developer it's not a bug...

The CI test of testssl fails because newer versions of openssl return 21= X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE (mesg: unable to verify the first certificate) instead of 18 = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT.

Any chance to get the certificate fixed?

[dcooper16]

While I disagree with the logic, the current versions of OpenSSL do not consider a certificate to be self-signed if the certificate includes a keyUsage extension and the keyCertSign bit is not set to 1.

The keyUsage extension contains a bit string (see below) indicating the purposes for which the public key may be used. The general rule is that if the keyUsage extension is absent, then there are no restrictions on the use of the public key, but if the extension is present then the public key may only be used for the purposes for which the corresponding bit is set to one.

So, in the case of the certificate associated with self-signed.badssl.com, the public key may be used for:

• digitalSignature: 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.
• nonRepudiation: verify digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), used to provide a non-repudiation service that protects against the signing entity falsely denying some action.
• keyEncipherment: enciphering private or secret keys, i.e., for key transport.

Since the keyCertSign bit is 0, the public key cannot be used for "verifying signatures on public key certificates."

(This all ignores the fact that extensions, such as keyUsage, in self-signed certificates can be ignored.)

I don't think this is a problem with the certificate since the public key is really only intended for use with TLS, where it will be used for enciphering keys and for verifying digital signatures on objects other than certificates and CRLs. However, the bottom line if that if you want the current version of OpenSSL to consider the certificate to be self-signed, then either the keyUsage extension needs to be removed or the keyCertSign bit needs to be set to 1.

      KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

[lgarron]

@dcooper16 Thanks for the details. I'll remove keyUsage from leaf certs for now.

But it sounds like we have found yet another edge case of SSLing badly. I've created #191 (Subdomain: self-signed without keyCertSign).

[lgarron]

Hmm, it seems that our OpenSSL commands result in a cert with explicit keyUsage even if the configuration file doesn't have it.

[lgarron]

Actually, turns out I just forgot to update the prod chains.

[lgarron]

@drwetter, @dcooper16 could you check that the new prod cert works as expected?

[drwetter]

Looks fine now, thx!