TO: WARNING: SSL keys were successfully added for 'my-delivery-service', but the input certificate may be invalid (certificate verification produced a different chain)

[zrhoffman]

This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:

• Traffic Ops
• Traffic Portal

Current behavior:

POSTing a new certificate to /deliveryservices/sslkeys/add with the Root Certificate before the Leaf Certificate results in a 200-level response with a warning:

{
  "alerts": [
    {
      "text": "WARNING: SSL keys were successfully added for 'my-delivery-service', but the input certificate may be invalid (certificate verification produced a different chain)",
      "level": "warning"
    }
  ]
}

New behavior:

An additional field, Certificate Chain Order, should be added to determine whether the validation expects the Leaf Certificate or the Root Certificate to be first. If this validation fails, a 400-level HTTP status code should be returned. Mock screenshot:

[ragen14]

EXAMPLE of chain order

Certificate[1]:
Owner: CN=xyz.com, O=Company name, ST=state, C=country
Issuer: CN=COMODO RSA Organization Validation Secure Server CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
Valid from: Thu Jun 02 18:00:00 MDT 2022 until: Sat Jun 03 17:59:59 MDT 2023
  DNSName: abc.net
  DNSName: xyz.abc.com
  DNSName: www.abc.net
  DNSName: www.xyz.abc.com

Certificate[2]:
Owner: CN=COMODO RSA Organization Validation Secure Server CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
Issuer: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
Valid from: Tue Feb 11 17:00:00 MST 2014 until: Sun Feb 11 16:59:59 MST 2029

Certificate[3]:
Owner: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
Valid from: Wed Dec 31 17:00:00 MST 2003 until: Sun Dec 31 16:59:59 MST 2028

Certificate[4]:
Owner: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
Valid from: Wed Dec 31 17:00:00 MST 2003 until: Sun Dec 31 16:59:59 MST 2028

[ericholguin]

@zrhoffman thoughts on #3267 the first enhancement suggested relates to this issue:

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.

[zrhoffman]

Hmm I'm not seeing that TO changes the cert order. If the cert chain is in the wrong order, I get

verifying certificate: certificate (x509v3) validation error: server certificate missing 'serverAuth' extended key usage

Instead, the verifying certificate: certificate (x509v3) validation error: server certificate missing 'serverAuth' extended key usage warning seems to be coming from the fact that the TO host's root certificates are used for verification, rather than the user-provided root certificate. So, eliminating that warning does not seem related to the order of the certificate chain.

[zrhoffman]

But i we're genuinely interested in reordering the cert chain instead of getting the

verifying certificate: certificate (x509v3) validation error: server certificate missing 'serverAuth' extended key usage

error, we can probably always reorder it in leaf-intermediate-root order, since otherwise TO will produce that error.

[zrhoffman]

Okay, so @srijeet0406 and I looked into #7035, and the warning,

WARNING: SSL keys were successfully added for 'my-delivery-service', but the input certificate may be invalid (certificate verification produced a different chain)

Is not related to certificate chain order at all, it happens because the root certificate provided in the chain is not one of the CA certs provided in the TO host's /etc/pki/tls/certs directory. So, adding the root cert to /etc/pki/tls/certs on the TO host should make that warning go away.

Receiving a warning when the root cert is not in /etc/pki/tls/certs is expected behavior, but maybe Traffic Ops can provide a better warning that describes what the problem is?

[ericholguin]

Yes I think a better error is needed the existing one does not make sense in this case