Perché la libreria di cifratura curl / NSS non consente una CA con l'utilizzo della chiave estesa da SEC_ERROR_INADEQUATE_CERT_TYPE?

Question

Perché la libreria di cifratura curl / NSS non consente una CA con l'utilizzo della chiave estesa da SEC_ERROR_INADEQUATE_CERT_TYPE?

#1 da (2 voti)

4

Problema

arricciatura rifiuta il certificato CA di seguito con 60) Tipo di certificato non approvato per l'applicazione per SEC_ERROR_INADEQUATE_CERT_TYPE. Mi piacerebbe capirne il motivo.

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

Dal momento che ho esaminato la RFC 3218, sembra che tutte le estensioni di utilizzo della chiave estesa richieste siano state asserite.

Il comando di arricciatura e risposta

$ 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.

Certificato CA rifiutato da 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

Ricerca

Il kubernetes GitHub dice:

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

e

X509v3 Basic Constraints: critical
    CA:TRUE

dovrebbe essere soddisfacente per RFC 3218 4.2.1.3 Utilizzo chiave .

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

dovrebbe essere soddisfacente RFC 3218 4.2.1.13 Utilizzo chiavi estese

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

Utilizzo della chiave del certificato di root (non auto- entità finale firmata) suggerisce che sarebbe OK non avere il flag di firma cRLSign / CRL.

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;

Domanda

Quindi perché crede che il certificato CA non asserisca un utilizzo obbligatorio?

correlati

public-key-infrastructure certificate-authority rfc

posta mon 27.12.2017 - 09:59

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure certificate-authority rfc

In che modo un dispositivo invia la password Wi-Fi al router? [duplicare] Come rilevare una stringa in HTML con Snort?

score 2 · Accepted Answer

Per comprimere la tua lunga ed estesa domanda al centro: stai essenzialmente chiedendo se il comportamento della libreria NSS fallire con SEC_ERROR_INADEQUATE_CERT_TYPE per il tuo specifico certificato e utilizzo è corretto.

Il certificato che si sta tentando di utilizzare come CA (utilizzando l'argomento --cacert in curl) contiene entrambi i vincoli di base CA: true e anche vari attributi di utilizzo chiave estesa. È correttamente citare un problema da kubernetes / go-client che descrive la combinazione di (alcuni) utilizzo di chiave estesa e CA: true causa il problema che vedi. Se segui il secondo link su questo problema, ti porterai a questo problema per mozilla: pkix dove il problema è discusso in dettaglio e il comportamento spiegato. Per citare il primo commento:

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.

Dato che l'uso di chiavi estese nel certificato consente solo determinati utilizzi chiave e non consente anyExtendedKeyUsage del vincolo di base CA: true verrà ignorato, il che significa che questo certificato non può essere utilizzato come certificato CA mentre si tenta di fare. Per approfondire le discussioni su come interpretare RFC 5280 in questo caso, vedi il problema su Mozilla .