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 https://example.com
curl: (60) SSL certificate problem: certificate rejected
More details here: https://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 https://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
digitalSignaturebit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while thekeyEnciphermentbit 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: ECDSASneaky 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
BgEFBQcDATBTBgNVHR8ETDBKMEigRqBEhkJodHRwOi8vYy5jZi1pLnNzbC5jb20v
YWU4MDFlZDFjNTViYjU3OWQ3OTIwOGIwZDc3MmFjZmI4Y2MzYTIwOC5jcmwwDgYD
VR0PAQH/BAQDAgeAMA8GCSsGAQQBgtpLLAQCBQAwggEDBgorBgEEAdZ5AgQCBIH0
BIHxAO8AdgBkEcRspBLsp4kcogIuALyrTygH1B41J6vq/tUDyX3N8AAAAZxYY1Lf
AAAEAwBHMEUCIQDtV+1kykKuK8JG9jUIOII1tq3xukiVDnAUn8+UHlEB4QIgAX+B
obl9S3i2kjqnefQ2ZE1jvxtHosAi9UtiXuH4VPsAdQDLOPcViXyEoURfW8Hd+8lu
8ppZzUcKaQWFsMsUwxRY5wAAAZxYY1L0AAAEAwBGMEQCIC8vIT4CL+YnfWB9wDK0
YuP2Ad/rM6Nf8tZgHgJeBqpxAiB5/xrUS3nexJIyl1Aj3QzVNZzMtvlvv6U5BaQx
5pSKJDAKBggqhkjOPQQDAgNIADBFAiAs+b0WCg1xl0hEemeiBaUm1RjOSoRkMIO1
LQn2aASnDgIhAKoCmSZdAEK75XMztoGhfaPZR1miNV57wbzLVlqDnVSb
-----END CERTIFICATE-----
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
-----BEGIN CERTIFICATE-----
MIIC4jCCAmmgAwIBAgIQMe7oivuHzZ74M2YEdD+bJzAKBggqhkjOPQQDAzBPMQsw
CQYDVQQGEwJVUzEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMSYwJAYDVQQDDB1T
U0wuY29tIFRMUyBUcmFuc2l0IEVDQyBDQSBSMjAeFw0yNTA1MjkxOTQ5NDVaFw0z
NTA1MjcxOTQ5NDRaMFExCzAJBgNVBAYTAlVTMRgwFgYDVQQKDA9TU0wgQ29ycG9y
YXRpb24xKDAmBgNVBAMMH0Nsb3VkZmxhcmUgVExTIElzc3VpbmcgRUNDIENBIDMw
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9HRQUjiNCkybPcNCJ17Eecqw+XVlS
gd8c9dYludZ3B4ULjRKxKz9AuR9yBuD/QFIKk0n4yXGwfu7go0VRGER0o4IBIzCC
AR8wEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBQyosfYWIv/f8A88lVp
M+zOzB+8lzBIBggrBgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly9jZXJ0
LnNzbC5jb20vU1NMLmNvbS1UTFMtVC1FQ0MtUjIuY2VyMBEGA1UdIAQKMAgwBgYE
VR0gADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwPQYDVR0fBDYwNDAy
oDCgLoYsaHR0cDovL2NybHMuc3NsLmNvbS9TU0wuY29tLVRMUy1ULUVDQy1SMi5j
cmwwHQYDVR0OBBYEFIMD/ef29UpNFUH07SIW0zIKPspmMA4GA1UdDwEB/wQEAwIB
hjAKBggqhkjOPQQDAwNnADBkAjBkW/dgTArl36px6LVMWzfHLv0pFD+P9BoOYzir
Z2aS2IwsQPHb0rQdZMY5NghTTk4CMCiwDU71fhtYVRulUc575HJroLXgj+BkpkBu
bdHnb2+aPpCH7LP6QNQ/Xm9NiqdxAw==
-----END CERTIFICATE-----
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
-----BEGIN CERTIFICATE-----
MIID0DCCArigAwIBAgIRAK2NLfZGgaDTZEfqqU+ic8EwDQYJKoZIhvcNAQELBQAw
ezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNV
BAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0yNDA2MjEwMDAwMDBaFw0y
ODEyMzEyMzU5NTlaME8xCzAJBgNVBAYTAlVTMRgwFgYDVQQKDA9TU0wgQ29ycG9y
YXRpb24xJjAkBgNVBAMMHVNTTC5jb20gVExTIFRyYW5zaXQgRUNDIENBIFIyMHYw
EAYHKoZIzj0CAQYFK4EEACIDYgAEZOd9mQNTXJEe6vjYI62hvyziY4nvKGj27dfw
7Ktorncr5HaXG1Dr21koLW+4NrmrjZfKTCKe7onZAj/9enM6kI0rzC86N4PaDbQt
RRtzcgllX3ghPeeLZj9H/Qkp1hQPo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W
8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFDKix9hYi/9/wDzyVWkz7M7MH7yXMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEBMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAjBgNVHSAEHDAaMAgGBmeBDAECATAOBgwrBgEEAYKp
MAEDAQEwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20v
QUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQELBQAD
ggEBAB4oL4ChKaKGZVZK8uAXjj8wvFdm45uvhU/t14QeH5bwETeKiQQXBga4/Nyz
zvpfuoEycantX+tHl/muwpmuHT0Z6IKYoICaMxOIktcTF4qHvxQW2WItHjOglrTj
qlXJXVL+3HCO60TEloSX8eUGsqfLQkc//z3Lb4gz117+fkDbnPt8+2REq3SCvaAG
hlh/lWWfHqTAiHed/qqzBSYqqvfjNlhIfXnPnhfAv/PpOUO1PmxCEAEYrg+VoS+O
+EBd1zkT0V7CfrPpj30cAMs2h+k4pPMwcLuB3Ku4TncBTRyt5K0gbJ3pQ0Rk9Hmu
wOz5QAZ+2n1q4TlApJzBfwFrCDg=
-----END CERTIFICATE-----Wait a minute, what's "AAA Certificate Services"? Shouldn't it be "SSL.com TLS ECC Root CA 2022" according to Firefox?
Triple-A means "Ancient Authorities Abandoned" after all
A quick search took me to the Sectigo's article, stating that AAA Certificate Services will be not used for trusted certificate chains starting from April 15, 2025. The reason is that new policy has set a 15-year limit for root CA certificates.
Conclusion
Eureka! That leads us to the conclusion:
- The server provides a certificate chain that links to the now-deprecated root CA "AAA Certificate Services".
- The browser finds another certificate chain through "SSL.com TLS ECC Root CA 2022", and accepts it.
openssldoes not find extra intermediate certificates by itself, and thus rejects to proceed with the connection.
However, there are some questions that remain to be answered:
- Why everything works well on Debian?
- Why am I seeing "unsuitable certificate purpose" on NixOS?
Let's have a rest (BTW I recommend readers to have a look at Cosmic Princess Kaguya - that's a masterpiece!), and go on with our research.
(Appendix?) Comparison of ca-certificates across distros
Anyway, I picked the file from the following distros to compare:
- Arch Linux: ca-certificates-mozilla 3.120.1-1 (2026/2/11)
- Debian: ca-certificates 20250419 (2025/4/19)
- The ones on Debian Trixie and Sid are the same
- Fedora: ca-certificates 2025.2.80_v9.0.304 (2025/8/26)
- The ones on Fedora 43 and Rawhide are the same
- NixOS: cacert 3.115 (2025/8/16)
- The list is the same as Fedora
- OpenSUSE Tumbleweed: ca-certificates-mozilla 2.84.1-1 (2026/2/11)
NixOS has some BEGIN TRUSTED CERTIFICATE lines that embeds in trust rules - we are only collectin BEGIN CERTIFICATE lines as they are used by all distros.
Data
CA certificates present in all distros are omitted.
| Name | Arch Linux | Debian Trixie/Sid | Fedora 43/Rawhide & NixOS | OpenSUSE Tumbleweed |
|---|---|---|---|---|
| CN=TrustAsia TLS RSA Root CA,... 06c0...f4c3 | ✅ | ❌ | ✅ | ✅ |
| CN=TrustAsia TLS ECC Root CA,... c007...8711 | ✅ | ❌ | ✅ | ✅ |
| CN=SwissSign RSA TLS Root CA 2022 - 1,... 1931...ce41 | ✅ | ❌ | ✅ | ✅ |
| CN=OISTE Server Root RSA G1,... 9ae3...51e6 | ✅ | ❌ | ❌ | ✅ |
| CN=OISTE Server Root ECC G1,... eec9...0f49 | ✅ | ❌ | ❌ | ✅ |
| CN=e-Szigno TLS Root CA 2023,... b491...4fb4 | ❌ | ❌ | ❌ | ✅ |
| OU=Starfield Class 2 Certification Authority,... 1465...b658 | ❌ | ✅ | ❌ | ❌ |
| CN=Baltimore CyberTrust Root,... 16af...6aeb | ❌ | ✅ | ❌ | ❌ |
| CN=Entrust.net Certification Authority (2048),... 6dc4...b177 | ❌ | ✅ | ❌ | ❌ |
| OU=Go Daddy Class 2 Certification Authority,... c384...6ae4 | ❌ | ✅ | ❌ | ❌ |
| CN=XRamp Global Certification Authority,... cecd...1aa2 | ❌ | ✅ | ❌ | ❌ |
| CN=AAA Certificate Services,... d7a7...9ef4 | ❌ | ✅ | ❌ | ❌ |
| CN=GlobalSign Root CA,... ebd4...1c99 | ❌ | ✅ | ❌ | ❌ |
| CN=CommScope Public Trust RSA Root-01,... 02bd...ed81 | ❌ | ✅ | ✅ | ❌ |
| CN=CommScope Public Trust ECC Root-01,... 1143...c38b | ❌ | ✅ | ✅ | ❌ |
| CN=CommScope Public Trust RSA Root-02,... ffe9...01f1 | ❌ | ✅ | ✅ | ❌ |
| CN=CommScope Public Trust ECC Root-02,... 2ffb...ad4a | ❌ | ✅ | ✅ | ❌ |
Analysis
What happened to these certificates?
A fix by Cloudflare/IANA, or other Cloudflare users
Cloudflare, could you fix the certificate chain issue that is blocking newer (not older!) devices that followed up with Mozilla/Chrome's policies? I see some posts on Cloudflare Community discussing about it, but the issue is apparently not fixed, even on the high-impact high-traffic example.com.
For Cloudflare users use Cloudflare-issued TLS certificates, you may want to switch your CA to Google Trust Services to avoid such issue.
Acknowledgments
This story originates from the discussion around PR compio-rs/compio#692.
P.S. What about "unsuitable certificate purpose"?
Remember we had "unsuitable certificate purpose" before? Since NixOS doesn't trust "AAA Certificate Services", we should have gotten an error as in Arch Linux, which is:
# openssl s_client -connect example.com:443
Verify return code: 20 (unable to get local issuer certificate)The answer is actually in the full logs, which I never had a look at carefully:
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 purposeBecause NixOS actually has AAA's CA certificate in its store! Not for HTTPS though:
# grep 'Comodo AAA Services root' /etc/ssl/certs/ca-certificates.crt -A3
Comodo AAA Services root
Traditional PEM block omitted: this certificate is not trusted for authenticating servers.
Trusted for:
- 1.3.6.1.5.5.7.3.4 (RFC5280: emailProtection key usage)An emailProtection certificate is apparently not a fit for TLS servers!
Yes, it's the group that voted for some Apple's proposal that reduces certificate validity period to 47 days. ↩︎