Component: Traffic Ops
Endpoint URL: /api/$ver/deliveryservices/hostname/$hostname/sslkeys/add
Functional Area: API - X509 certificate/key import and validation for delivery services
Description: TO API - DS X509 Certificate/Key Import Validation Enhancements.
After careful review of this API endpoint, the following enhancements in the area of x509 certificate and RSA key validation need to be added to provide greater stability for the Traffic Router and the overall health of CDN(s) managed by Traffic Ops. The Traffic Router, in it's current state, absolutely depends on Traffic Ops as a x509 certificates/key validation agent. Lack of proper validation by Traffic Ops wrt to x509 certificates/keys, can cause the Traffic Router to behave in unknown ways related to HTTPS delivery services.
Enhancements for x509 certificate/key imports:
1. X509 certificate chain should be re-ordered by the API and not be the responsibility of the client. Currently the x509 certificate chain must be submitted in reverse order which is NOT apparent from the Traffic Portal UI or by reading the documentation.
Upon a POST to this API, the payload should be parsed into individual certificates, each one validated, and then re-ordered to be in reverse order (server, intermediate2, intermediate1, rootCA) and saved to Riak (Traffic Vault).
2. FIXED in PR #3382 Add Cryptographic verification of the x509 certificate against the RSA key using common modulus value.
The modulus of the x509 certificate the RSA key need to be extracted and compared. If the modulus does not match, a 4XX client error should be returned to the client.
3. If a rootCA is found in the input, actually pass the rootCA off to the x509.Verify() method as a rootCA and not an intermediate.
Currently, this conditional always evaluates to false even if a rootCA is found in the certificate payload:
// Always evaluates to false when importing certs/keys via the API.
if rootCA != "" {
// verify the certificate chain.
opts = x509.VerifyOptions{
Intermediates: intermediatePool,
Roots: rootPool,
}
} else {
opts = x509.VerifyOptions{
Intermediates: intermediatePool,
}
}
If a rootCA is found in the input, a rootPool should be created and passed along with any intermediate certs to x509.Verify()
4. Add routine to verify the certificate request and server certificate for valid RFC5890 characters.
At minimum, the certificate request (CSR) should be base64 decoded and verified as a proper request certificate with the golang x509 library.
Verify that the CN and SAN are compliant with RFC5890 FQDN allowed text characters. This is a check to verify that a X509 certificate isn't generated with uppercased FQDNs or contain underscores.
RFC 6066 - Transport Layer Security (TLS) Extensions - Server Name Indication (SNI) Page.7
"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a byte
string using ASCII encoding without a trailing dot. This allows the
support of internationalized domain names through the use of A-labels
defined in [RFC5890]. DNS hostnames are case-insensitive. The
algorithm to compare hostnames is described in [RFC5890], Section
2.3.2.4.
HTTPS clients typically (but not always) lowercase the hostname before sending the SNI during TLS handshake negotiation. Most HTTPD servers (including Apache Traffic Server) do x509 certificate lookup using the SNI string value via a case-sensitive string comparison against the X509 CN and SAN names list. Due to this, all x509 certificates imported by Traffic Ops must contain lowercase CN and SAN names list for the FQDN/wildcard. Related issue: #3234
5. Certificate sorting algorithm should use X509v3 subject/authoritative key identifiers.
When sorting certificates found in the payload, the x509v3 key identifier hash (subject/authoritative) should be used to re-order certificate chain in reverse order (server, int2, int1, root). If key identifiers are not present, the Issuer and Owner attributes of the x509 Subject field should be used for comparison. While public/commercial x509 CAs tend to include x509v3 key identifiers in all exported certificates, certificates that do not contain them are still valid and should remain importable, hence PR #3181 .
6. Update the unit test for this functional area to reflect the enhanced validation from 1-5 above.
Additional Unit tests were added to test x509v1 and x509v3 certificates and their respective public key signing fields with those contained in both RSA and EC private keys. Note: x509 certificates signed by EC digital signature algorithms are only supported on DNS delivery services until full support can be added. These changes were merged to master via PR #3382
Component: Traffic Ops
Endpoint URL: /api/$ver/deliveryservices/hostname/$hostname/sslkeys/add
Functional Area: API - X509 certificate/key import and validation for delivery services
Description: TO API - DS X509 Certificate/Key Import Validation Enhancements.
After careful review of this API endpoint, the following enhancements in the area of x509 certificate and RSA key validation need to be added to provide greater stability for the Traffic Router and the overall health of CDN(s) managed by Traffic Ops. The Traffic Router, in it's current state, absolutely depends on Traffic Ops as a x509 certificates/key validation agent. Lack of proper validation by Traffic Ops wrt to x509 certificates/keys, can cause the Traffic Router to behave in unknown ways related to HTTPS delivery services.
Enhancements for x509 certificate/key imports:
1. X509 certificate chain should be re-ordered by the API and not be the responsibility of the client. Currently the x509 certificate chain must be submitted in reverse order which is NOT apparent from the Traffic Portal UI or by reading the documentation.
Upon a POST to this API, the payload should be parsed into individual certificates, each one validated, and then re-ordered to be in reverse order (server, intermediate2, intermediate1, rootCA) and saved to Riak (Traffic Vault).
2. FIXED in PR #3382
Add Cryptographic verification of the x509 certificate against the RSA key using common modulus value.The modulus of the x509 certificate the RSA key need to be extracted and compared. If the modulus does not match, a 4XX client error should be returned to the client.3. If a rootCA is found in the input, actually pass the rootCA off to the x509.Verify() method as a rootCA and not an intermediate.
Currently, this conditional always evaluates to false even if a rootCA is found in the certificate payload:
If a rootCA is found in the input, a rootPool should be created and passed along with any intermediate certs to x509.Verify()
4. Add routine to verify the certificate request and server certificate for valid RFC5890 characters.
At minimum, the certificate request (CSR) should be base64 decoded and verified as a proper request certificate with the golang x509 library.
Verify that the CN and SAN are compliant with RFC5890 FQDN allowed text characters. This is a check to verify that a X509 certificate isn't generated with uppercased FQDNs or contain underscores.
RFC 6066 - Transport Layer Security (TLS) Extensions - Server Name Indication (SNI) Page.7
HTTPS clients typically (but not always) lowercase the hostname before sending the SNI during TLS handshake negotiation. Most HTTPD servers (including Apache Traffic Server) do x509 certificate lookup using the SNI string value via a case-sensitive string comparison against the X509 CN and SAN names list. Due to this, all x509 certificates imported by Traffic Ops must contain lowercase CN and SAN names list for the FQDN/wildcard. Related issue: #3234
5. Certificate sorting algorithm should use X509v3 subject/authoritative key identifiers.
When sorting certificates found in the payload, the x509v3 key identifier hash (subject/authoritative) should be used to re-order certificate chain in reverse order (server, int2, int1, root). If key identifiers are not present, the Issuer and Owner attributes of the x509 Subject field should be used for comparison. While public/commercial x509 CAs tend to include x509v3 key identifiers in all exported certificates, certificates that do not contain them are still valid and should remain importable, hence PR #3181 .
6. Update the unit test for this functional area to reflect the enhanced validation from 1-5 above.
Additional Unit tests were added to test x509v1 and x509v3 certificates and their respective public key signing fields with those contained in both RSA and EC private keys. Note: x509 certificates signed by EC digital signature algorithms are only supported on DNS delivery services until full support can be added. These changes were merged to master via PR #3382