Is this a bad certificate? (Having nine-bit long key usage extension)

Tue Sep 21 10:26:09 CEST 2021

Hi Ingela,

I was looking into this too, and I noticed that this particular leaf certificate, once decoded as an OTPCertificate record, does not encode back to the same DER value (which is likely due to the unusual representation of the KeyUsage extension in the original file):

1> {ok, PEM} = file:read_file("cert.pem").
{ok,<<"-----BEGIN CERTIFICATE-----\nMIIEfDCCAuSgAwIBAgIUdcWg+bxobl7OWSOjbNxyaXTnqx8wDQYJKoZIhvcNAQEL\nBQAwMTEXMBUGA1U"...>>}
2> DER = element(2, hd(public_key:pem_decode(PEM))).
<<48,130,4,124,48,130,2,228,160,3,2,1,2,2,20,117,197,160,
249,188,104,110,94,206,89,35,163,108,220,...>>
3> DER = public_key:pkix_encode('OTPCertificate', public_key:pkix_decode_cert(DER, otp), otp).
** exception error: no match of right hand side value <<48,130,4,123,48,130,2,227,160,3,2,1,2,2,20,117,197,160,
249,188,104,110,94,206,89,35,163,108,220,...>>

(That would presumably mean the original DER representation is not really proper DER, as I believe ASN.1's DER encoding is supposed to always produce the same (canonical) byte sequence, in order to allow for reliable signature verification...)

I haven't quite pinned it down, but this commit https://github.com/erlang/otp/pull/4941/commits/80f9b71323c9c5a3bc111fcbc5c6c5ee497e27a6 that was included in 24.0.4 seems to sometimes reconstruct a DER representation from an OTPCertificate record, and if that DER value is passed to public_key:pkix_verify/2 instead of the original DER representation, the signature won't match and ssl will throw the reported error.

Hope that might help,

Bram

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, September 21st, 2021 at 10:48 AM, Ingela Andin <ingela.andin@REDACTED> wrote:

> Hello again!
>
> I thought of a possible cause of your strange problem. If the ROOT-cert is sent as part of the chain (optional in the protocol). We must check that it is a certificate that we trust, part of our "trust store". This was done by a match of the DER-version of the cert and we should match the decode structure instead.
>
> In such cases the following patch ought to solve your problem. Can you please test it? It is based on the latest maint!
>
> diff --git a/lib/ssl/src/ssl_certificate.erl b/lib/ssl/src/ssl_certificate.erl
> index cbeb4e4521..1a277964b6 100644
> --- a/lib/ssl/src/ssl_certificate.erl
> +++ b/lib/ssl/src/ssl_certificate.erl
> @@ -596,13 +596,13 @@ path_candidate(Cert, ChainCandidateCAs, CertDbHandle) ->
> [Root | lists:reverse(Chain)]
> end.
>
> -handle_partial_chain([#cert{der=DERIssuerCert, otp=OtpIssuerCert}=Cert| Rest] = Path, PartialChainHandler,
> +handle_partial_chain([#cert{otp=OtpIssuerCert}=Cert| Rest] = Path, PartialChainHandler,
> CertDbHandle, CertDbRef) ->
> case public_key:pkix_is_self_signed(OtpIssuerCert) of
> true -> %% IssuerCert = ROOT (That is ROOT was included in chain)
> {ok, {SerialNr, IssuerId}} = public_key:pkix_issuer_id(OtpIssuerCert, self),
> case ssl_manager:lookup_trusted_cert(CertDbHandle, CertDbRef, SerialNr, IssuerId) of
> - {ok, #cert{der=DERIssuerCert}} -> %% Match sent ROOT to trusted ROOT
> + {ok, #cert{otp = OtpIssuerCert}} -> %% Match sent ROOT to trusted ROOT
> maybe_shorten_path(Path, PartialChainHandler, {Cert, Rest});
> {ok, _} -> %% Did not match trusted ROOT
> maybe_shorten_path(Path, PartialChainHandler, {invalid_issuer, Path});
>
> Regards Ingela Erlang/OTP team- Ericsson AB
>
> Den fre 17 sep. 2021 kl 18:24 skrev Jesse Bickel - NOAA Affiliate <jesse.bickel@REDACTED>:
>
>> Good morning,
>>
>> This is part question and part potential bug report. I don't have a github
>> account associated with my workplace at the moment which is why I ask here.
>>
>> When we tested an upgrade to rabbitmq, the tls v1.2 server rejected client
>> certificates with the following message: "In state certify at
>> ssl_handshake.erl:1975 generated SERVER ALERT: Fatal - Bad Certificate." The
>> issue happens with otp versions 24.0.4 and later. The earlier version 24.0.3
>> interoperates with the certificates successfully. After we took a closer look,
>> the issue has something to do with the key usage extension. If we generate a
>> similar certificate in all other respects but remove the key usage extension
>> otp does not reject the certificate. The issue also occurs without mutual
>> authentication as a CLIENT ALERT when an erlang/otp client validates the same
>> kind of server certificate.
>>
>> The certificates that otp 24.0.4+ rejects were generated by gnutls certtool,
>> but more specifically the difference in the certificate itself is the length of
>> the bit string in the key usage extension. Both openssl and gnutls certtool in
>> their high-level text forms of the working and not working certificates show
>> the key usage as having the same two values of digital signature and key
>> encipherment. The difference underneath is that the one generated by gnutls
>> certtool version 3.6.9 (rejected by otp) is nine bits, value 101000000, whereas
>> the one generated by openssl 1.1.1f (accepted by otp) is three bits, value 101.
>> Both versions appear to be valid asn.1, several tools appear to see both
>> versions as valid certificates, and I cannot easily tell from the relevant ietf
>> and itu documents that either is invalid.
>>
>> Below are sample certificate authority and leaf certificates that can reproduce
>> the issue in two local erlang/otp sessions in a typical mode of server-only
>> authentication with tls v1.2 during the handshake.
>>
>> Is this a bug introduced in otp 24.0.4 or is this an invalid certificate?
>>
>> Jesse Bickel
>>
>> --
>> Contractor, ERT, Inc.
>> Federal Affiliation: NWC/OWP/NOAA/DOC
>>
>> Sample certificate authority x.509 certificate:
>>
>> -----BEGIN CERTIFICATE-----
>> MIIEMzCCApugAwIBAgIUcgjKevzc6MaGOyaSC0VdidlvgO4wDQYJKoZIhvcNAQEL
>> BQAwMTEXMBUGA1UEAxMORmFrZWRvbWFpbjIgQ0ExFjAUBgNVBAoTDUZha2UgRG9t
>> YWluIDIwHhcNMjEwOTE0MTgzNDI5WhcNMjIwOTE0MTgzNDMxWjAxMRcwFQYDVQQD
>> Ew5GYWtlZG9tYWluMiBDQTEWMBQGA1UEChMNRmFrZSBEb21haW4gMjCCAaIwDQYJ
>> KoZIhvcNAQEBBQADggGPADCCAYoCggGBALLOuMsXBwU57q2cauVHr1zUneJ3KKt7
>> 6H8RzZJB/yoltld/9RjGeQGZ3EfeLb1dm9Gag2AwTBRzrnYIcQz215ABLfcdMYyo
>> B3UE4rU+E3N9XMmGAEWbQh3lAprYeUnKbt7yjKOuUrQvfNtHhvNOpDQjg2VRbYnx
>> TQS6Go/ycRSywoBKSlr3G/sZ0pKt+8BumfMfIZZtPQw9j46+VibBW9UyQZJ7iBUH
>> q1AXT8XiFtAzVq33dwb+B5gd1QVrIu1vIzyGQt5dliEHHfJcdksmZBLru1GR6uzF
>> bndg3Y9MyYj5YQ+6M9wtcLKgJwHHfLgb30FPmY5a945tSHL9cv38sk11o7zgI6Vn
>> d+KhHxFRs8g0dBq8/ZKXF4UA7RxihXAB/SwVW4XVgpMGCMh/hrDzqKS/oexuOt8n
>> NDumTd2NYsUx06+uV/lc405DGmnF0cvCsV+3wulBs09lUsQlwFvFhU3z2pDSWWPs
>> 8qCwcPn1WKBx1bZvBMZzys8qPc6NP4sjIQIDAQABo0MwQTAPBgNVHRMBAf8EBTAD
>> AQH/MA8GA1UdDwEB/wQFAwMHhAAwHQYDVR0OBBYEFFJsVCuIulfHcznrk/ALXKSn
>> Q+9IMA0GCSqGSIb3DQEBCwUAA4IBgQA6/WBJ5IYfcvxQnMeCQI2ewRiMxEQQxqFX
>> E9aXJDq5ohhY+lquWcMD8+yNAQbsE2Sw3KQppelEvN1aLgDwW8e7LR5Dw7SLtwZB
>> tFtWx2eJoqjuTLoxhjnWaR3A50YUgjNOiV5UIV5E8A1f1wsJcdM2VobQgdNyfvnm
>> vDdHKaGP9+TfmrdGimVwVLmQCtXzp62pyIkJbc8lOOGifCNzDmRgl1ehsEYn4T/M
>> NWxan3mRGLBjGn90ojxAMBXASB6BrQNa4Kvrs0bzyUToBPHMeBWsYA6SlyfLMN9L
>> svajh99xEYN63+AVNpZMDIBe4Dhmw8dTU8z1beDJqdODG8+Krmp58KwTAZQYGp6o
>> iyA5W1PmEms3Our9pBoJZ6guE8qMMxo6th+CwXsOQQLcmUIienLfFv6x1hZidN6G
>> bTmD2GOK25J/2zXlEXQuT4HNZfDuIh2IBxlo607ct72Dq9OGENLL6ujGhzU2XL6J
>> /TM/05Gfa+buDfysohjCSbtAIqvolr8=
>> -----END CERTIFICATE-----
>>
>> Sample leaf certificate signed by above certificate authority:
>>
>> -----BEGIN CERTIFICATE-----
>> MIIEfDCCAuSgAwIBAgIUdcWg+bxobl7OWSOjbNxyaXTnqx8wDQYJKoZIhvcNAQEL
>> BQAwMTEXMBUGA1UEAxMORmFrZWRvbWFpbjIgQ0ExFjAUBgNVBAoTDUZha2UgRG9t
>> YWluIDIwHhcNMjEwOTE0MTgzOTA0WhcNMjIwOTEzMTgzOTA2WjAsMRIwEAYDVQQD
>> Ewlsb2NhbGhvc3QxFjAUBgNVBAoTDUZha2UgRG9tYWluIDIwggGiMA0GCSqGSIb3
>> DQEBAQUAA4IBjwAwggGKAoIBgQDcNlMZrrMMWS5mKBCZKegx78hQutjQN4BEWsnK
>> WNPEpgtBV6H7Ihk43Jn19EArCujglZfI5sdV9il/8uJFB9DplICnPvet6HvspxLa
>> 4hLFm+dI1Av6MglB6vaJInEXK6zVM39NMJVAy7LcryJYAhVMIuC4wTUOHRqAgx8o
>> w6dtb7fKSV3OTN3UmGJRPnzGULR3wc8yjGCXnPgu0D497w2FoZ4IWU2H/T+djQDx
>> i8giZ7KV+11XHfm3ZEsukutJIwsehP3XmCrvttZz8oQuNzJvA05BYRmgOkc7rJeW
>> ioXL8SC3rMeN4tZHPOd1O6QMVA3IqRGqoobwvt6HKKgE5LWw8GMG5HBDUFuYFDWY
>> cNkNObTM+x06WVoOKqjDUMb0x+clZwHSclTbEACzxT+iv3hh7+zQ9/0Z7BgYKxfN
>> QQgtDxIvguFI5O/BKzWAeBY24InHyBphprXmAL+q79hqjpt6Diaz8GEY7qHJcvss
>> npx7Q9HWqPd+GsPMBjGHRmy6Wk0CAwEAAaOBkDCBjTAUBgNVHREEDTALgglsb2Nh
>> bGhvc3QwDAYDVR0TAQH/BAIwADAPBgNVHQ8BAf8EBQMDB6AAMBYGA1UdJQEB/wQM
>> MAoGCCsGAQUFBwMBMB0GA1UdDgQWBBSblx0hTlJdxGO9+sAQnevrQUtX+jAfBgNV
>> HSMEGDAWgBRSbFQriLpXx3M565PwC1ykp0PvSDANBgkqhkiG9w0BAQsFAAOCAYEA
>> fHfAPrLNL2oChRjhS5h7twylgoxlAL06CITEwQtRSbdoP/g+XUdv/CFp7fqE9rKz
>> XNrtgM6KSgK7N7riYojCheEo/76Jk+PHPljzCrv9BoX6K44liU1Nf2IXIAG2+llY
>> aDmMeZPFI3pZ92oFCmKmzMvCaf/idOqNFihS/hBNXfbczuROnAuw/zip1QItnCJt
>> YTk1Og7BMjF3LNQYZRwz3KuG/fyDJx7DMrKL+EOsOmebFnIqiM0Em0TGIzdY2aTG
>> 3hDbMUQz82R/8kO5d9keIGiL4pXp1gGDf8TdK7cEDblcwt1cyNX6jm6F1+qGWgCw
>> EbnNn2MjpdBD0BDNluQaysQb6KDomv2HHhwDtB6RDM26GN3uUyZfPDzvzH8TmNbH
>> UIymPlYs9XHlvEYJeeu9shd9hLegAidWHBs31eUKZaURJrsHd110iGhVpGEjvdvS
>> +YxkNsVwgmiPjJpjxsHOABdwpFBO54F8ayEiYDiLhboXEHJj0ju57TMstzcOmQBL
>> -----END CERTIFICATE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210921/24252b3d/attachment.htm>