Change self signed certificates to not include extended key usage

[jpeeler]

The current code specifies server auth:

client-go/util/cert/cert.go

Line 155 in 82aa063

ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},

The problem is the current self generated certificates do not work with curl (on Fedora):

curl --cacert apiserver.crt https://localhost:32786 -v
* Rebuilt URL to: https://localhost:32786/
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 32786 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: apiserver.crt
  CApath: none
* Server certificate:
* 	subject: CN=<nil>@1507833167
* 	start date: Oct 12 18:32:47 2017 GMT
* 	expire date: Oct 12 18:32:47 2018 GMT
* 	common name: <nil>@1507833167
* 	issuer: CN=127.0.0.1@1507833167
* 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

Removing the extended key usage allows everything to work as expected. Since these are for self signed certificates, I am hoping that the removal isn't a security issue. Some potentially relevant links:

https://tools.ietf.org/html/rfc5280#section-4.2.1.12
https://bugzilla.mozilla.org/show_bug.cgi?id=1049176
google/stenographer#124
(?) golang/go#11087

[liggitt]

the goal was to prevent that cert from being used as a client certificate

[jpeeler]

@liggitt is this then an invalid way to use the certificates or can the key usage for the CA be changed? https://github.com/kubernetes-incubator/service-catalog/blob/5f4ca01ed86bd5e11a64390bcd3031767477ca63/contrib/hack/start-server.sh#L55

[jpeeler]

I didn't realize that Fedora 27 was switching crypto libraries for curl to OpenSSL. Given that curl with NSS was the only problematic scenario, I'm closing this.

https://fedoraproject.org/wiki/Changes/libcurlBackToOpenSSL

[oonisim]

@liggitt may I ask why autogenerated /var/lib/kubelet/pki/kubelet.crt includes the CA:TRUE if the certificate cannot be used as a CA as per https://bugzilla.mozilla.org/show_bug.cgi?id=1049176?

        X509v3 Basic Constraints: critical
            CA:TRUE

[liggitt]

If it doesn't, go will not allow specifying the cert as a trust root

[oonisim]

@liggitt please correct if I misunderstand.

As in Switch to wget for integration apiserver checks (#1384), the certificate includes the certificate extensions below.

        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment, Certificate Sign
        X509v3 Extended Key Usage:
            TLS Web Server Authentication
        X509v3 Basic Constraints: critical
            CA:TRUE

Based on RFC 3280, as Extended Key Usage extension is there, the certificate can be only used for a server certificate but cannot be used for CA certificate?

RFC 3280 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.

I think the point in SEC_ERROR_INADEQUATE_CERT_TYPE when root CA cert has extendedKeyUsage set which was originally cited by @jpeeler stating "it can't be used to issue certificates." indicates it cannot be used as a CA certificate.

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.

If the only purpose indicated in the certificate with the extension is OCSPSigning, then it can't be used for anything other than signing OCSP responses. In particular, it can't be used to issue certificates.

Therefore, it looks to me, having CA:TRUE will not have any effect. So I wonder why it is there.

        X509v3 Basic Constraints: critical
            CA:TRUE

If the intention is to use the certificate both for CA and also TLS server certificate, then perhaps ** anyExtendedKeyUsage** could be required which may allow applications (curl in the original problem statement) to accept the cert as CA?

I suppose the wget behaviour of accepting the certificate as CA cert could be incorrect and the curl behaviour rejecting would be correct.

If above makes sense, could you reconsider the original request of "not include extended key usage"? For myself, /var/lib/kubelet/pki/kubelet.crt has the same and I cannot use it as CA cert to talk to kubelet.