<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Hi!<br></div><div dir="ltr"><div><br></div><div>Are you sure you got your configuration correct?   I could decode both these certificates using  OTP-24.0.4.</div><div>Looking at your error row 1975 in ssl_handshake is this clause:</div><div><br></div><div>path_validation_alert({bad_cert, invalid_signature}) -><br>    ?ALERT_REC(?FATAL, ?BAD_CERTIFICATE);<br></div><div><br></div><div>This indicates that we could not find a validate the certificate chain and that a signature check failed.</div><div>We will enhance the alert creation with extra info for the log message (as done in many other places).</div><div><br></div><div>Could you create dummy certs with a dummy key that fails so that I can recreate your scenario?</div><div>You can send them to <a href="mailto:ingela@erlang.org" target="_blank">ingela@erlang.org</a></div><div><br></div><div>Regards Ingela - Erlang/OTP team - Ericsson AB</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 17 sep. 2021 kl 18:24 skrev Jesse Bickel - NOAA Affiliate <<a href="mailto:jesse.bickel@noaa.gov" target="_blank">jesse.bickel@noaa.gov</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning,<br>
<br>
This is part question and part potential bug report. I don't have a github<br>
account associated with my workplace at the moment which is why I ask here.<br>
<br>
When we tested an upgrade to rabbitmq, the tls v1.2 server rejected client<br>
certificates with the following message: "In state certify at<br>
ssl_handshake.erl:1975 generated SERVER ALERT: Fatal - Bad Certificate." The<br>
issue happens with otp versions 24.0.4 and later. The earlier version 24.0.3<br>
interoperates with the certificates successfully. After we took a closer look,<br>
the issue has something to do with the key usage extension. If we generate a<br>
similar certificate in all other respects but remove the key usage extension<br>
otp does not reject the certificate. The issue also occurs without mutual<br>
authentication as a CLIENT ALERT when an erlang/otp client validates the same<br>
kind of server certificate.<br>
<br>
The certificates that otp 24.0.4+ rejects were generated by gnutls certtool,<br>
but more specifically the difference in the certificate itself is the length of<br>
the bit string in the key usage extension. Both openssl and gnutls certtool in<br>
their high-level text forms of the working and not working certificates show<br>
the key usage as having the same two values of digital signature and key<br>
encipherment. The difference underneath is that the one generated by gnutls<br>
certtool version 3.6.9 (rejected by otp) is nine bits, value 101000000, whereas<br>
the one generated by openssl 1.1.1f (accepted by otp) is three bits, value 101.<br>
Both versions appear to be valid asn.1, several tools appear to see both<br>
versions as valid certificates, and I cannot easily tell from the relevant ietf<br>
and itu documents that either is invalid.<br>
<br>
Below are sample certificate authority and leaf certificates that can reproduce<br>
the issue in two local erlang/otp sessions in a typical mode of server-only<br>
authentication with tls v1.2 during the handshake.<br>
<br>
Is this a bug introduced in otp 24.0.4 or is this an invalid certificate?<br>
<br>
Jesse Bickel<br>
<br>
-- <br>
Contractor, ERT, Inc.<br>
Federal Affiliation: NWC/OWP/NOAA/DOC<br>
<br>
Sample certificate authority x.509 certificate:<br>
<br>
-----BEGIN CERTIFICATE-----<br>
MIIEMzCCApugAwIBAgIUcgjKevzc6MaGOyaSC0VdidlvgO4wDQYJKoZIhvcNAQEL<br>
BQAwMTEXMBUGA1UEAxMORmFrZWRvbWFpbjIgQ0ExFjAUBgNVBAoTDUZha2UgRG9t<br>
YWluIDIwHhcNMjEwOTE0MTgzNDI5WhcNMjIwOTE0MTgzNDMxWjAxMRcwFQYDVQQD<br>
Ew5GYWtlZG9tYWluMiBDQTEWMBQGA1UEChMNRmFrZSBEb21haW4gMjCCAaIwDQYJ<br>
KoZIhvcNAQEBBQADggGPADCCAYoCggGBALLOuMsXBwU57q2cauVHr1zUneJ3KKt7<br>
6H8RzZJB/yoltld/9RjGeQGZ3EfeLb1dm9Gag2AwTBRzrnYIcQz215ABLfcdMYyo<br>
B3UE4rU+E3N9XMmGAEWbQh3lAprYeUnKbt7yjKOuUrQvfNtHhvNOpDQjg2VRbYnx<br>
TQS6Go/ycRSywoBKSlr3G/sZ0pKt+8BumfMfIZZtPQw9j46+VibBW9UyQZJ7iBUH<br>
q1AXT8XiFtAzVq33dwb+B5gd1QVrIu1vIzyGQt5dliEHHfJcdksmZBLru1GR6uzF<br>
bndg3Y9MyYj5YQ+6M9wtcLKgJwHHfLgb30FPmY5a945tSHL9cv38sk11o7zgI6Vn<br>
d+KhHxFRs8g0dBq8/ZKXF4UA7RxihXAB/SwVW4XVgpMGCMh/hrDzqKS/oexuOt8n<br>
NDumTd2NYsUx06+uV/lc405DGmnF0cvCsV+3wulBs09lUsQlwFvFhU3z2pDSWWPs<br>
8qCwcPn1WKBx1bZvBMZzys8qPc6NP4sjIQIDAQABo0MwQTAPBgNVHRMBAf8EBTAD<br>
AQH/MA8GA1UdDwEB/wQFAwMHhAAwHQYDVR0OBBYEFFJsVCuIulfHcznrk/ALXKSn<br>
Q+9IMA0GCSqGSIb3DQEBCwUAA4IBgQA6/WBJ5IYfcvxQnMeCQI2ewRiMxEQQxqFX<br>
E9aXJDq5ohhY+lquWcMD8+yNAQbsE2Sw3KQppelEvN1aLgDwW8e7LR5Dw7SLtwZB<br>
tFtWx2eJoqjuTLoxhjnWaR3A50YUgjNOiV5UIV5E8A1f1wsJcdM2VobQgdNyfvnm<br>
vDdHKaGP9+TfmrdGimVwVLmQCtXzp62pyIkJbc8lOOGifCNzDmRgl1ehsEYn4T/M<br>
NWxan3mRGLBjGn90ojxAMBXASB6BrQNa4Kvrs0bzyUToBPHMeBWsYA6SlyfLMN9L<br>
svajh99xEYN63+AVNpZMDIBe4Dhmw8dTU8z1beDJqdODG8+Krmp58KwTAZQYGp6o<br>
iyA5W1PmEms3Our9pBoJZ6guE8qMMxo6th+CwXsOQQLcmUIienLfFv6x1hZidN6G<br>
bTmD2GOK25J/2zXlEXQuT4HNZfDuIh2IBxlo607ct72Dq9OGENLL6ujGhzU2XL6J<br>
/TM/05Gfa+buDfysohjCSbtAIqvolr8=<br>
-----END CERTIFICATE-----<br>
<br>
Sample leaf certificate signed by above certificate authority:<br>
<br>
-----BEGIN CERTIFICATE-----<br>
MIIEfDCCAuSgAwIBAgIUdcWg+bxobl7OWSOjbNxyaXTnqx8wDQYJKoZIhvcNAQEL<br>
BQAwMTEXMBUGA1UEAxMORmFrZWRvbWFpbjIgQ0ExFjAUBgNVBAoTDUZha2UgRG9t<br>
YWluIDIwHhcNMjEwOTE0MTgzOTA0WhcNMjIwOTEzMTgzOTA2WjAsMRIwEAYDVQQD<br>
Ewlsb2NhbGhvc3QxFjAUBgNVBAoTDUZha2UgRG9tYWluIDIwggGiMA0GCSqGSIb3<br>
DQEBAQUAA4IBjwAwggGKAoIBgQDcNlMZrrMMWS5mKBCZKegx78hQutjQN4BEWsnK<br>
WNPEpgtBV6H7Ihk43Jn19EArCujglZfI5sdV9il/8uJFB9DplICnPvet6HvspxLa<br>
4hLFm+dI1Av6MglB6vaJInEXK6zVM39NMJVAy7LcryJYAhVMIuC4wTUOHRqAgx8o<br>
w6dtb7fKSV3OTN3UmGJRPnzGULR3wc8yjGCXnPgu0D497w2FoZ4IWU2H/T+djQDx<br>
i8giZ7KV+11XHfm3ZEsukutJIwsehP3XmCrvttZz8oQuNzJvA05BYRmgOkc7rJeW<br>
ioXL8SC3rMeN4tZHPOd1O6QMVA3IqRGqoobwvt6HKKgE5LWw8GMG5HBDUFuYFDWY<br>
cNkNObTM+x06WVoOKqjDUMb0x+clZwHSclTbEACzxT+iv3hh7+zQ9/0Z7BgYKxfN<br>
QQgtDxIvguFI5O/BKzWAeBY24InHyBphprXmAL+q79hqjpt6Diaz8GEY7qHJcvss<br>
npx7Q9HWqPd+GsPMBjGHRmy6Wk0CAwEAAaOBkDCBjTAUBgNVHREEDTALgglsb2Nh<br>
bGhvc3QwDAYDVR0TAQH/BAIwADAPBgNVHQ8BAf8EBQMDB6AAMBYGA1UdJQEB/wQM<br>
MAoGCCsGAQUFBwMBMB0GA1UdDgQWBBSblx0hTlJdxGO9+sAQnevrQUtX+jAfBgNV<br>
HSMEGDAWgBRSbFQriLpXx3M565PwC1ykp0PvSDANBgkqhkiG9w0BAQsFAAOCAYEA<br>
fHfAPrLNL2oChRjhS5h7twylgoxlAL06CITEwQtRSbdoP/g+XUdv/CFp7fqE9rKz<br>
XNrtgM6KSgK7N7riYojCheEo/76Jk+PHPljzCrv9BoX6K44liU1Nf2IXIAG2+llY<br>
aDmMeZPFI3pZ92oFCmKmzMvCaf/idOqNFihS/hBNXfbczuROnAuw/zip1QItnCJt<br>
YTk1Og7BMjF3LNQYZRwz3KuG/fyDJx7DMrKL+EOsOmebFnIqiM0Em0TGIzdY2aTG<br>
3hDbMUQz82R/8kO5d9keIGiL4pXp1gGDf8TdK7cEDblcwt1cyNX6jm6F1+qGWgCw<br>
EbnNn2MjpdBD0BDNluQaysQb6KDomv2HHhwDtB6RDM26GN3uUyZfPDzvzH8TmNbH<br>
UIymPlYs9XHlvEYJeeu9shd9hLegAidWHBs31eUKZaURJrsHd110iGhVpGEjvdvS<br>
+YxkNsVwgmiPjJpjxsHOABdwpFBO54F8ayEiYDiLhboXEHJj0ju57TMstzcOmQBL<br>
-----END CERTIFICATE-----<br>
<br>
</blockquote></div></div>
</div></div>