Opened 18 months ago
Closed 18 months ago
#2501 closed defect (invalid)
TLS handshake fails with internal_error if signature_algorithms is not provided
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | |
| Keywords: | Cc: | ||
| uname -a: | |||
| nginx -V: | I'm not the user of NGINX, I'm the end-user who has to deal with the TLS failures. | ||
Description
I suspect this issue was introduced when implementing ticket #814
Note:
See TracTickets
for help on using tickets.
The multiple certificates support as implemented in #814 relies on the corresponding OpenSSL feature. That is, nginx does not try to analyze the signature_algorithms extension itself. Rather, it is what OpenSSL does.
The particular internal_error you are seeing looks like this OpenSSL issue:
https://github.com/openssl/openssl/issues/15484
Incorrect handling of ClientHello messages without signature_algorithms extension (e.g. TLS 1.1 or TLS 1.0)
The issue is basically about OpenSSL using an incorrect alert (internal_error instead of handshake_failure) when SHA-1 is disabled on the server. It is expected to be fixed in OpenSSL 3.0.0 and above (and will send correct alert instead).
Note that SHA-1 is disabled by default in OpenSSL 3.0.0 and above, and also disabled by default at least by some Linux distributions using previous OpenSSL versions (by configuring SECLEVEL=2 in the system-wide OpenSSL configurations; at least Debian and derivatives are known to do this). See #2406 for more details.
That is, to connect to modern SSL servers which weren't specifically configured to support old protocols and algorithms, it is currently required to provide appropriate signature_algorithms. If your client does not support it, consider fixing the client.