Add support for detecting misordered certificate chain entries

[atc0005]

This is implicitly covered by the goal to provide certificate chain verification (#29), but is worth covering explicitly so it can be singled out as an item in a problems report.

See also:

• https://github.com/atc0005/check-cert/issues/960
• https://github.com/atc0005/cert-payload
• https://security.stackexchange.com/questions/56824/what-happens-when-intermediate-certificates-are-installed-in-the-wrong-order

[atc0005]

Question: what happens if there is only one cert in the chain?

[atc0005]

Question: what happens if there is only one cert in the chain?

Opted to handle this as an error condition for this validation check. While it probably should be handled by a separate validation check, I think adding it here first can be helpful.

Currently I'm treating an incomplete cert chain (of length 1) as CRITICAL state with a misordered cert chain as WARNING state. The thinking is that most modern browsers will handle reordering a cert chain without much complaint while some modern clients will object to just a leaf cert present in a cert chain.

Between the two problems, a cert chain of just a leaf seems like it would have the biggest impact on users and so would warrant the strongest non-OK state rating.

[atc0005]

This may need to be tracked by a GH issue of its own, but this came up in a conversation today:

communicate which intermediate/root bundle link should be used when we receive the Sectigo email

This was from a follow-up conversation about the topic of sysadmins unintentionally installing the wrong intermediates bundle from Sectigo (InCommon).

In that earlier discussion I shared these guidelines for use when selecting certificate download links from "InCommon SSL certificate" notifications from Sectigo:

1. as Certificate only, PEM encoded
   • ➖ provides only the leaf certificate
   • 🆗 if you next append Issuing CA certificates only > as Intermediate(s)/Root only, PEM encoded to this cert
2. as Certificate (w/ issuer after), PEM encoded
   • ✅ everything already in the correct order
3. as Certificate (w/ chain), PEM encoded
   • ❌ everything reversed
4. Issuing CA certificates only > as Root/Intermediate(s) only, PEM encoded
   • ➖ intermediates only
   • ❌ everything reversed
5. Issuing CA certificates only > as Intermediate(s)/Root only, PEM encoded
   • ➖ intermediates only
   • 🆗 if you next append this to the file downloaded via the as Certificate only, PEM encoded option

Option 4 from this is (unfortunately) commonly paired with Option 1 to form a certificate chain. Instead, Option 2 will usually give the best results.

In the conversation today I responded with (snippet):

the plugin can be updated to offer some advice on this also.

I think on the next iteration I’ll update the logic to look for indicators of a InCommon/Sectigo intermediate being used to sign the leaf cert and offer a suggestion for the correct bundle link.

This should hopefully work well both for cert chains containing just the leaf and cert chains with the intermediates out of order.

The logic used to provide this advice could be extended to match intermediates used by other common certificate vendors and provide remediation advice for those as well.

[atc0005]

While working on #123 (and intentionally testing against a chain with the wrong intermediates bundle and an intentionally wrong intermediates from another CA), I realized that it may be worth combining this validation check with an intermediates validation check.

As a sysadmin, I'd first want to know if invalid intermediates are included, then missing intermediates and finally if the intermediates are present, but in the wrong order.

As things stand, the misordered check results will be displayed alongside check results for either missing or invalid intermediates. Coming at this with fresh eyes, I don't know if it's helpful to see both of those "needs to be fixed" items listed.

Instead, a sysadmin should update/replace the chain to remove invalid certificates or add missing intermediates. Then, if the chain is misordered that should be listed as the ordering may change significantly when the chain is fixed/replaced.

Still tinkering, trying to decide the best way to handle this.

[atc0005]

As things stand, the misordered check results will be displayed alongside check results for either missing or invalid intermediates. Coming at this with fresh eyes, I don't know if it's helpful to see both of those "needs to be fixed" items listed.

Additionally, the "misordered" validation results are likely to be wrong if the "misordered" detection logic doesn't exclude invalid certificates and first ensure that all intermediates are present.

For example, with the cert chain that I intentionally inserted a wrong cert and used an old intermediates bundle from the CA we ended up with this in the chain:

(1) InCommon RSA Server CA [intermediate]
(2) USERTrust RSA Certification Authority [intermediate]
(3) E5 [intermediate]
(4) AAA Certificate Services [root]

Position 0 (not shown) being the leaf cert.

After we have the modified "recommendation" logic exclude invalid certs, this is what it recommends:

(1) USERTrust RSA Certification Authority [intermediate]
(2) AAA Certificate Services [root]

Those two remaining certs are technically correct & ordered properly, but we're missing the issuer for the leaf certificate. We could modify the logic to just drop remaining unlinked elements from the chain, but then we'd just be recommending the leaf cert. Maybe that really is good advice whenever invalid certs are present and there are not enough certs available to construct a full chain, but it feels disjointed.

Instead, folding the logic into a single flow (assert no invalid, assert no missing, asserting not misordered) seems like the most reliable/maintainable approach.

[atc0005]

Loose thoughts as I continue trying to puzzle out next steps:

A chain can be declared as having both invalid (wrong intermediates present) and missing intermediates.

A chain can not be declared as both invalid and misordered. Likewise, a chain can not have missing intermediates and be misordered.

A misordered chain requires that all expected certs be present but out of the expected order. If an authoritative collection is not provided, we can still assert that what we're provided is not misordered by using the available certs in the given chain. This is not quite as reliable as when checking against an authoritative collection (i.e., AIA-sourced intermediate certs), but should be "good enough" for handling the most common scenarios.