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

[Ingela Andin]

Hi!

Are you sure you got your configuration correct?   I could decode both
these certificates using  OTP-24.0.4.
Looking at your error row 1975 in ssl_handshake is this clause:

path_validation_alert({bad_cert, invalid_signature}) ->
    ?ALERT_REC(?FATAL, ?BAD_CERTIFICATE);

This indicates that we could not find a validate the certificate chain and
that a signature check failed.
We will enhance the alert creation with extra info for the log message (as
done in many other places).

Could you create dummy certs with a dummy key that fails so that I can
recreate your scenario?
You can send them to ingela@REDACTED

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/e29b0f7c/attachment.htm>