Is this a bad certificate? (Having nine-bit long key usage extension)
Ingela Andin
ingela.andin@REDACTED
Tue Sep 21 09:48:17 CEST 2021
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/72789327/attachment.htm>
More information about the erlang-questions
mailing list