Issue
I'm trying to use cURL to hit an API on an embedded server (from a Geo satellite modem) which I cannot change. My cURL request succeeds from my Mac with the following version
curl 8.1.2 (x86_64-apple-darwin22.0) libcurl/8.1.2 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.51.0
Release-Date: 2023-05-30
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL threadsafe UnixSockets
However on my Linux server, I run into SSL alert 35 with the following cURL:
curl 7.86.0 (x86_64-pc-linux-gnu) libcurl/7.86.0 OpenSSL/3.0.7 zlib/1.2.13 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.2 libssh2/1.10.0 nghttp2/1.49.0
Release-Date: 2022-10-26
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
curl -vvvv -L -k https://192.168.44.1/api/
* Trying 192.168.44.1:443...
* Connected to 192.168.44.1 (192.168.44.1) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Unknown (21):
* TLSv1.2 (IN), TLS alert, unsupported certificate (555):
* error:0A000413:SSL routines::sslv3 alert unsupported certificate
* Closing connection 0
curl: (35) error:0A000413:SSL routines::sslv3 alert unsupported certificate
My hope was that -k would skip certificate verification altogether, however this alert is still showing up. Is there any way to silence, ignore, avoid this OpenSSL error?
Chrome is also refusing to open the page with ERR_BAD_SSL_CLIENT_AUTH_CERT (from Mac), though below I can extract the (seemingly) faulty certificate from Firefox:
Solution
It is not fully clear to me what the server is choking about, but it might be that SHA-1 is missing in the signature_algorithms extension. There are servers out there which cannot properly deal with this even if the certificate they offer does not even use SHA-1 - see this and this answers for similar observations.
The fix work around is like in the referenced answers - use DEFAULT:@SECLEVEL=0 as cipher string when connecting to the server.
Answered By - Steffen Ullrich Answer Checked By - Dawn Plyler (WPSolving Volunteer)