4

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:

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

  • 1
    The output of curl shows that it is using the NSS library. Your question includes a description that NSS will not allow extended key usage within a CA certificate. But your certificate is a CA certificate and has extended key usage. Take all these three things together and your question is answered. – Steffen Ullrich Dec 27 '17 at 9:38
  • Hello @SteffenUllrich. I am not clear why curl rejects the CA certificate which (to me) is valid RFC 3218 compliant. Would like to know why it rejects. Is it the expected behaviour and I miss something, or wget behaviour accepting it is the correct behaviour then is it curl issue? – mon Dec 27 '17 at 20:05
  • Thus, you are essentially asking if the behavior of NSS which is described in your question is a feature or a bug? I.e. this statement: "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.". If this is the case, then you might just remove everything from your question which is not necessary to understand this statement (in other words: most of the question) and focus on this statement instead. – Steffen Ullrich Dec 27 '17 at 20:12
  • @SteffenUllrich not clear with your intention. If the curl/nss behaviour is aligned with RFC 3218 is relevant to me. If the CA cert does satisfy what RFC 3218 says (I am not 100% sure hence looking for input too), then it comes to the question if it is curl bug/nss or not. If it does not satisfy, then it comes to the question what is wrong with the cert. Either way, "Why does curl/NSS encryption library not allow a CA with the extended key usage by SEC_ERROR_INADEQUATE_CERT_TYPE?" is still the question to me. – mon Dec 28 '17 at 9:30
  • @SteffenUllrich, if you have insights, please share to help me understand. I appreciate your help to better ask the question or how to ask the question but that is another thing. Do you know/think if this is a NSS bug? If so why? Do you have the answer why "NSS error -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE)" is caused and which part of the cert is the cause? If so please share. – mon Dec 28 '17 at 9:39
2

To compress your long and extensive question to the core: You are are essentially asking if the behavior of the NSS library to fail with SEC_ERROR_INADEQUATE_CERT_TYPE for your specific certificate and usage is correct.

The certificate you are trying to use as CA (using --cacert argument in curl) contains both Basic Constraints CA:true and also various Extended Key Usage attributes. You correctly cite an issue from kubernetes/go-client which describes that combining (certain) Extended Key Usage and CA:true causes the problem you see. If you follow the second link on this issue it will lead you to this issue for mozilla:pkix where the problem is discussed in detail and the behavior explained. To cite from the first comment:

From rfc 5280, section 4.2.1.12: (Extended Key Usage)
If the extension is present, then the certificate MUST only be used for one of the purposes indicated.

Given that the Extended Key Usage in your certificate only allow certain key usages and don't allow anyExtendedKeyUsage the basic constraint CA:true will be ignored, which means that this certificate cannot be used as CA certificate as you attempt to do. For a deeper discussions on how to interpret RFC 5280 in this case please see the issue at Mozilla.

  • Thanks. Understood the curl behaviour is correct. The certificate can only be used as a server certificate and cannot be a CA certificate. – mon Dec 28 '17 at 12:00
  • With NSS, it's seems that if CA:TRUE is a critical or non-critical basic constraint, then even if the anyExtendedKeyUsage OID is set, it still won't accept a self-signed certificate for TLS server authentication. With certutil -V and -u L ("SSL CA"), it's accepted as a CA, but, as per -u V ("SSL server") it reports "Certificate type not approved for application". Comment #8 in the Mozilla issue suggests NSS has an overly strict interpretation of the RFC, but there're appear to be no further developments to address it. – JPvRiel yesterday

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.