Problem
curl rejects the CA certificate below with 60) Certificate type not approved for application for SEC_ERROR_INADEQUATE_CERT_TYPE. I would like to understand the reason.
SEC_ERROR_INADEQUATE_CERT_TYPE
A certificate has an extended key usage extension that does not assert a required usage, or an end-entity certificate asserts the id-kp-OCSPSigning usage when it shouldn't
Because as far as I looked at the RFC 3218, it looks all the required extended key usage extensions are asserted.
The curl command and reply
$ sudo curl -ivL \
> --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
> --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
> --cacert /var/lib/kubelet/pki/kubelet.crt \
> https://ip-172-31-4-117.us-west-1.compute.internal:10250/healthz
* Trying 172.31.4.117...
* TCP_NODELAY set
* Connected to ip-172-31-4-117.us-west-1.compute.internal (172.31.4.117) port 10250 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /var/lib/kubelet/pki/kubelet.crt
CApath: none
* Server certificate:
* subject: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
* start date: Dec 23 05:13:30 2017 GMT
* expire date: Dec 23 05:13:30 2018 GMT
* common name: ip-172-31-4-117.us-west-1.compute.internal@1514006010
* issuer: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
* NSS error -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE)
* Certificate type not approved for application.
* stopped the pause stream!
* Closing connection 0
curl: (60) Certificate type not approved for application.
More details here: https://curl.haxx.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 web page mentioned above.
CA certificate rejected by curl
$ openssl x509 -noout -text -in /var/lib/kubelet/pki/kubelet.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
Validity
Not Before: Dec 23 05:13:30 2017 GMT
Not After : Dec 23 05:13:30 2018 GMT
Subject: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d5:48:65:86:4e:ec:08:a1:b1:26:4b:da:7c:e0:
d9:d0:16:96:93:9e:c0:f3:78:cb:27:a9:e1:99:d2:
10:73:70:e5:1e:ee:03:1a:55:51:29:c6:2e:62:71:
d9:c2:72:19:d3:36:41:9b:ef:74:ac:20:97:25:1b:
63:55:96:07:4d:02:01:c9:44:7d:f9:63:2b:50:98:
2a:fb:b7:03:0d:96:6d:6a:36:9d:93:ad:2c:6a:87:
7d:b8:aa:22:ca:f2:c4:a6:90:24:2b:4c:94:d1:4a:
3c:0d:c5:fa:48:fb:e5:82:30:17:f9:67:3a:1d:9b:
85:7a:bc:e9:e9:79:48:0e:53:41:fc:64:3a:c3:c1:
7e:ae:51:23:17:8e:db:1e:4c:99:56:a4:77:ad:74:
64:64:ab:a7:84:02:40:ec:c8:b1:51:2b:b3:80:7e:
b2:51:68:5c:d2:40:9d:f3:54:b9:76:2d:47:ea:f4:
51:c6:03:e9:c4:63:5c:5a:a7:7e:9a:97:89:45:99:
e8:a0:9b:5d:1d:15:94:f9:c9:2a:a4:19:a2:07:25:
2b:e6:0e:50:63:c0:6e:f9:a0:a7:ce:4a:ca:97:17:
64:2f:8a:e2:39:d5:e2:c9:c7:c4:53:f1:6e:14:22:
ca:02:cb:8a:0c:47:68:31:f2:0b:20:2c:a3:a5:5f:
cd:95
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:ip-172-31-4-117.us-west-1.compute.internal
Signature Algorithm: sha256WithRSAEncryption
bc:84:b2:5c:c1:a5:52:b7:03:ae:9c:53:47:4b:ca:8b:4a:90:
7f:41:0f:09:ff:77:5e:cc:7c:2c:0c:bc:37:71:c9:22:4e:7f:
eb:9f:a9:f8:04:1d:8d:39:67:52:46:9c:3b:dc:d8:1f:b0:00:
64:ed:2f:bf:8f:4c:8c:f2:6b:96:ec:99:66:19:39:1d:11:77:
52:6b:a8:f4:88:e1:ad:6b:61:af:bd:c0:fc:f7:c2:37:a2:c2:
7f:cc:de:98:a4:61:25:e2:78:b2:ab:94:31:0d:8f:2f:92:7b:
4a:4f:5b:1c:c2:e8:bd:43:cb:78:0e:f2:4b:b9:a5:54:0c:46:
0f:b0:92:f8:3c:57:08:6a:df:a4:cd:78:63:23:2f:13:12:7f:
89:7f:3d:c0:dd:c7:33:8d:55:76:10:38:47:2b:16:ce:d0:93:
c4:9e:28:42:1e:2b:f4:78:15:dd:89:1e:67:a5:a1:a1:13:30:
9a:2f:60:82:71:db:29:47:af:e7:61:71:1c:d6:72:27:61:17:
e1:31:aa:ee:84:0d:53:f8:66:18:49:34:5d:fb:50:fb:4f:c7:
b5:a1:8e:34:86:81:25:ad:31:d4:5c:9e:da:8d:08:85:a9:91:
c6:f8:83:c7:23:57:11:04:dc:90:5a:c9:5a:bf:dd:3c:9c:6a:
17:d8:d0:1f
Research
The kubernetes GitHub says:
- Change self signed certificates to not include extended key usage #311
- Switch to wget for integration apiserver checks
The NSS encryption library does not allow a CA to be used with the extended key usage present, at least in the way we are currently doing so. The generated self signed certificates extension section looks like:
...
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:127.0.0.1, IP Address:127.0.0.1
RFC 3218
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
and
X509v3 Basic Constraints: critical
CA:TRUE
should be satisfying RFC 3218 4.2.1.3 Key Usage.
The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted. ...
The keyCertSign bit is asserted when the subject public key is used for verifying a signature on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (section 4.2.1.10) MUST also be asserted.
X509v3 Extended Key Usage:
TLS Web Server Authentication
should be satisfying RFC 3218 4.2.1.13 Extended Key Usage
If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that a particular purpose be indicated in order for the certificate to be acceptable to that application.
If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special keyPurposeID anyExtendedKeyUsage. If the anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT be critical.
If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose.
...
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
Root certificate key usage (non-self-signed end entity) suggests it would be OK not to have cRLSign/CRL signing flag.
Since a CA is supposed to issue certificate and CRL, it should have, on a general basis, the keyCertSign and cRLSign flags. These two flags are sufficient. If the CA does not intend to sign its own CRL, then it may omit the cRLSign flag;
Question
So why curl thinks the CA certificate does not assert a required usage?
Related
- Key usage extensions and extended key usage
- Missing 'Key Usage' on a CA certificate: can sign certificates?
- SSL Certs issued with PKI backend don't work with firefox: sec_error_inadequate_cert_type #987
- curl: (60) Certificate type not approved for application where wget works
- GitHub - Network Security Services
- curl source code control
