-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS server using intermediate CA with nameConstraints
extension always results in "Bad Certificate"
#8482
Comments
Berfore looking further in to this would you check if the following will help? Defalut = ssl:signature_algs(default, 'tlsv1.3'). Then suppling the option: {signature_algs_cert, After the release of OTP-27 we will make a patch for the case where this helps to report unsupported cert instead of bad cert #8476 |
Hi @IngelaAndin! I added your suggested code in this commit - lukebakken/erlang-otp-8482@90b0dda Unfortunately, I see the same error as before. I have attached the full debug output from the server and client here: |
Could you trace the functions:
in pubkey_cert for the server? I guess there is some kind of mistake/mismatch in algorithm choice somewhere. For connivance:
|
|
|
|
|
|
@lukebakken Thank you for the traces, I can now see that the signature algorithms are not the issue here. In the validate name trace we see the So the name check fails. Permitted names: [{'GeneralSubtree',{dNSName,".bakken.io"},0,asn1_NOVALUE}, SubjectAltNames extension from cert: First one in SubjectAltName extension will not be equivalent to any of the permitted names. |
That's not how https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10
In my test, the constraint I should have also said, earlier, that if I do not use an intermediate CA, but specify the same It does seem, in this case, to be the specific combination of using |
Yes you are right, that might just have been my memory failing to remember the details of this check. It looks to be implemented, if it behaves correctly there might be some other reason the check fails.
The Root (anchor) cert is not part of the path validation in the same way as an intermediate cert, it will setup initial values for
|
It's 100% new to me 😸 I will trace that for you today! |
Could you add local function match_name to the permitted trace? |
…maint * ingela/ssl/alerts-enhancements/GH-8482/OTP-19092: ssl: Enhance ALERT logs to help understand what causes the alert.
@lukebakken Thank you for latest trace, so I though it was a public_key bug, that I tried to fix in #8508 but I was just thinking it was strange that this was not covered by the PKIX test suite, and it turns out it was test are failing now so will have to analyze it further. |
Ok, think I sorted it out now. |
… maint * ingela/public_key/match_dnsName/GH-8482/OTP-19100: public_key: Correct match_name function for dnsNames
I just built Erlang from |
Describe the bug
This is the certificate chain I'm using:
If the intermediate CA certificate specifies the
nameConstraints
extension, running a TLS server using Erlang, while requiring client certificates, always results in the following error:Using
openssl s_server
andopenssl s_client
with the certificates works correctly.To Reproduce
Please see the following repository with code and instructions for reproducing this issue:
https://github.com/lukebakken/erlang-otp-8482
Expected behavior
TLS connection succeeds
Affected versions
Testing with Erlang 26.2.5 linked to OpenSSL 3.3.0 on Ubuntu 22.04
The text was updated successfully, but these errors were encountered: