TO API - DeliveryServices AddSSLKeys Incorrectly stores X509 certificate missing Subject/Authority Key as zero length string.

Method: POST
Endpoint: api/1.4/deliveryservices/sslkeys/add
Description: Importing X509 SSL certificate and corresponding intermediate/root X509 certificates that do not contain X509v3 Subject Key Identifier (SKI) and corresponding Authority Key Identifier (AKI) results in the certificate being stored in Traffic Vault as a zero length string. Further, all intermediate CA certificates that follow are ignored for X509 certificate validation. Additionally, the RSA key and certificate-request (csr) do get stored correctly in traffic vault, but the certificate ('crt' field in json) is a zero length string. The response code for this import operation is incorrectly sent back to the client as a 200 indicating a successful import.

Impact: Traffic Router Languid SSL connector is impacted (partially and fully) upon receiving incomplete/invalid SSL Key/Certificate data from Traffic Ops SSLKeysAPIs. This presents a problem in that the incomplete/invalid SSL key/cert pair causes TrafficRouter to throw an exception related to an invalid X509 certificate. After exception has occurred, any new TLS handshake attempts hang and eventually timeout, thus a HTTPS services have been partially or fully impacted.

Possible Solution: All X509 certificates that do not contain Subject/Authority Key Identifier X509v3 should be rejected with proper 4XX HTTP code and corresponding JSON error description. Traffic Router should also be updated to handle invalid certificate data received from Traffic Ops without partial/full impact to SSL Languid connector.

From trafficops_golang/deliveryservices/keys.go: https://github.com/apache/trafficcontrol/blob/master/traffic_ops/traffic_ops_golang/deliveryservice/keys.go#L328-L335
pemEncodedChain remains as a zero length string if all certificates submitted for import are missing the Subjective/Authority Key Indicator X509v3 metadata.:

 	pemEncodedChain := ""
	for _, link := range chain[0] {
		// Only print non-self signed elements of the chain
		if link.AuthorityKeyId != nil && !bytes.Equal(link.AuthorityKeyId, link.SubjectKeyId) {
			block := &pem.Block{Type: "CERTIFICATE", Bytes: link.Raw}
			pemEncodedChain += string(pem.EncodeToMemory(block))
		}
	}

[rawlinp]

I'd think if there were self-signed elements in the chain, it wouldn't pass the previous check which calls https://golang.org/pkg/crypto/x509/#Certificate.Verify and causes TO to accept a self-signed cert with a warning. So maybe the if link.AuthorityKeyId != nil && !bytes.Equal(link.AuthorityKeyId, link.SubjectKeyId) { line is unnecessary, and it should just append all the links to pemEncodedChain regardless of the SKI and AKI? I'd think the Verify method would check if SKI and AKI don't properly match up through the chain.

@rawlinp
I will upload a Self-Signed Root CA and a Server certificate that is signed by this CA that does not contain the Subject/Authority Identifier Keys. Somehow the certificate generated in this way will completely pass the Verify() method, the loop that checks for Subject/Authority identifier keys doesn't do anything, and thus just a zero length string is left and stored into traffic vault. The http status is 200 with a success message back to the client.

This is a very rare code path since most real certificates now have x509v3 Subject/Authority identifier keys, so perhaps it may not be worth fixing.

[jhg03a]

I ran across this as well using certs and keys generated via ansible, including the ca.

If the Root CA certificate does have the Subject/Authoritive Key Identifers and both of them match, the root CA certificate is not used for certificate validation nor is the certificate appended to the certificate chain.

Why does traffic ops not allow self-signed x509 CA certificates to be included in the certificate chain? If the server certificate validates correctly against a root CA and one or more intermediate x509 certificates, it should not matter if any intermediate or root CA is self-signed.

[jhg03a]

As far as I can find the subjectKeyIdentifier & authorityKeyIdentifier V3 extension isn't actually required for a certificate to be valid, nor is it included by default with openssl. It's just an extra assurance most modern commercial CA embrace. Also, not all tools that generate csr and certs support adding these extensions.

The PR I submitted above removes the check for X509v3 Subject/Authority Key Identifiers. Technically, X509v3 certificates can still be valid without the SKI and AKI extensions.