I cannot curl https://example.com (on some distros)

Huh? #

It's a sunny day, and I try to test the network on my dear new NixOS system:

curl example.com

curl: (60) SSL certificate problem: certificate rejected More details here:curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the webpage mentioned above.

What? Let's dig a bit deeper...

openssl s_client -connect example.com:443

Connecting to 104.18.26.120

subject=CN=example.com issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3 No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits SSL handshake has read 3043 bytes and written 402 bytes Verification error: unsuitable certificate purpose New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Protocol: TLSv1.3 Server public key is 256 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 26 (unsuitable certificate purpose)

(Full logs)

Connecting to 104.18.26.120 CONNECTED(00000003) depth=3 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services verify error:num=28:certificate rejected verify return:1 depth=3 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services verify error:num=28:certificate rejected verify return:1 depth=3 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services verify error:num=26:unsuitable certificate purpose verify return:1 depth=3 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services verify return:1 depth=2 C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2 verify return:1 depth=1 C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3 verify return:1 depth=0 CN=example.com verify return:1 Certificate chain 0 s:CN=example.com i:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256 v:NotBefore: Feb 13 18:53:48 2026 GMT; NotAfter: May 14 18:57:50 2026 GMT 1 s:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3 i:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384 v:NotBefore: May 29 19:49:45 2025 GMT; NotAfter: May 27 19:49:44 2035 GMT 2 s:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2 i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256 v:NotBefore: Jun 21 00:00:00 2024 GMT; NotAfter: Dec 31 23:59:59 2028 GMT Server certificate • ----BEGIN CERTIFICATE----- MIID5jCCA4ygAwIBAgIQUa2YfqEkb/NCRGJqCD0VLzAKBggqhkjOPQQDAjBRMQsw CQYDVQQGEwJVUzEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMSgwJgYDVQQDDB9D bG91ZGZsYXJlIFRMUyBJc3N1aW5nIEVDQyBDQSAzMB4XDTI2MDIxMzE4NTM0OFoX DTI2MDUxNDE4NTc1MFowFjEUMBIGA1UEAwwLZXhhbXBsZS5jb20wWTATBgcqhkjO PQIBBggqhkjOPQMBBwNCAATDeETtTiz/RLkvUrmylW1bF3goLCqKxvhHfT/UVmUx R/pA7Vq9zirXXx9lY5ndZcyo5IDieuz7HNOIB07KN3CBo4ICfzCCAnswDAYDVR0T AQH/BAIwADAfBgNVHSMEGDAWgBSDA/3n9vVKTRVB9O0iFtMyCj7KZjBsBggrBgEF BQcBAQRgMF4wOQYIKwYBBQUHMAKGLWh0dHA6Ly9pLmNmLWkuc3NsLmNvbS9DbG91 ZGZsYXJlLVRMUy1JLUUzLmNlcjAhBggrBgEFBQcwAYYVaHR0cDovL28uY2YtaS5z c2wuY29tMCUGA1UdEQQeMByCC2V4YW1wbGUuY29tgg0qLmV4YW1wbGUuY29tMCMG A1UdIAQcMBowCAYGZ4EMAQIBMA4GDCsGAQQBgqkwAQMBATATBgNVHSUEDDAKBggr BgEFBQcDATBTBgNVHR8ETDBKMEigRqBEhkJodHRwOi8vYy5jZi1pLnNzbC5jb20v YWU4MDFlZDFjNTViYjU3OWQ3OTIwOGIwZDc3MmFjZmI4Y2MzYTIwOC5jcmwwDgYD VR0PAQH/BAQDAgeAMA8GCSsGAQQBgtpLLAQCBQAwggEDBgorBgEEAdZ5AgQCBIH0 BIHxAO8AdgBkEcRspBLsp4kcogIuALyrTygH1B41J6vq/tUDyX3N8AAAAZxYY1Lf AAAEAwBHMEUCIQDtV+1kykKuK8JG9jUIOII1tq3xukiVDnAUn8+UHlEB4QIgAX+B obl9S3i2kjqnefQ2ZE1jvxtHosAi9UtiXuH4VPsAdQDLOPcViXyEoURfW8Hd+8lu 8ppZzUcKaQWFsMsUwxRY5wAAAZxYY1L0AAAEAwBGMEQCIC8vIT4CL+YnfWB9wDK0 YuP2Ad/rM6Nf8tZgHgJeBqpxAiB5/xrUS3nexJIyl1Aj3QzVNZzMtvlvv6U5BaQx 5pSKJDAKBggqhkjOPQQDAgNIADBFAiAs+b0WCg1xl0hEemeiBaUm1RjOSoRkMIO1 LQn2aASnDgIhAKoCmSZdAEK75XMztoGhfaPZR1miNV57wbzLVlqDnVSb • ----END CERTIFICATE----- subject=CN=example.com issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3 No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits SSL handshake has read 3043 bytes and written 402 bytes Verification error: unsuitable certificate purpose New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Protocol: TLSv1.3 Server public key is 256 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 26 (unsuitable certificate purpose)

" unsuitable certificate purpose ". I beg your pardon, sir?

I tried on my Arch Linux device, and it also fails with a different openssl error:

Verify return code: 20 (unable to get local issuer certificate)

I tried on another Debian server, doing curl example.com - it works normally.

I went on Firefox on my device and had a try again... and it works very fine - cannot be finer!

A page full of innocence.

The certificate page does not show anything problematic, either:

Since example.com is maintained by IANA (Internet Assigned Number Authority), one of the most important organizations related to the Internet, it's very likely that they are correct, and it's basically definitely me that had some configurations wrong. Right?

Let me take some time to investigate and fix it...

Investigation #

"Certificate Purpose" #

When it comes to TLS issues, the first place I go for help is always Qualys' SSL Labs, as it does pretty extensive checks. However, IANA seems to feel uncomfortable about this:

No check, mate.

Hmm... let's use another website to do the checks. I used testtls.com; it shows everything working okay for the ECDSA certificate, and some error for the RSA certificate:

Luckily, I follow CA/Browser Forum affairs pretty closely and know it's not accurate:

What Key Usage should a TLS server certificate have?

According to CA/Browser Forum [1] 's Baseline Requirements, in section 7.1.2.7.11 Subscriber Certificate Key Usage:

(for RSA Public Keys) The digitalSignature bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the keyEncipherment bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites.

As for ECDSA Public Keys digitalSignature is the only required (MUST) Key Usage.

Also, openssl told me that I was using an ECDSA certificate, so issues on the RSA certificate should be unrelated:

Peer signature type: ECDSA

Sneaky certificate chain #

I heard that the browser is a bit much smarter than OpenSSL when it comes to weird certificate chain settings. Let's have a check:

openssl s_client -connect example.com:443 -showcerts

Certificate chain 0 s:CN=example.com i:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256 v:NotBefore: Feb 13 18:53:48 2026 GMT; NotAfter: May 14 18:57:50 2026 GMT • ----BEGIN CERTIFICATE----- MIID5jCCA4ygAwIBAgIQUa2YfqEkb/NCRGJqCD0VLzAKBggqhkjOPQQDAjBRMQsw CQYDVQQGEwJVUzEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMSgwJgYDVQQDDB9D bG91ZGZsYXJlIFRMUyBJc3N1aW5nIEVDQyBDQSAzMB4XDTI2MDIxMzE4NTM0OFoX DTI2MDUxNDE4NTc1MFowFjEUMBIGA1UEAwwLZXhhbXBsZS5jb20wWTATBgcqhkjO PQIBBggqhkjOPQMBBwNCAATDeETtTiz/RLkvUrmylW1bF3goLCqKxvhHfT/UVmUx R/pA7Vq9zirXXx9lY5ndZcyo5IDieuz7HNOIB07KN3CBo4ICfzCCAnswDAYDVR0T AQH/BAIwADAfBgNVHSMEGDAWgBSDA/3n9vVKTRVB9O0iFtMyCj7KZjBsBggrBgEF BQcBAQRgMF4wOQYIKwYBBQUHMAKGLWh0dHA6Ly9pLmNmLWkuc3NsLmNvbS9DbG91 ZGZsYXJlLVRMUy1JLUUzLmNlcjAhBggrBgEFBQcwAYYVaHR0cDovL28uY2YtaS5z c2wuY29tMCUGA1UdEQQeMByCC2V4YW1wbGUuY29tgg0qLmV4YW1wbGUuY29tMCMG A1UdIAQcMBowCAYGZ4EMAQIBMA4GDCsGAQQBgqkwAQMBATATBgNVHSUEDDAKBggr BgEFBQcDATBTBgNVHR8ETDBKMEigRqBEhkJodHRwOi8vY…