Add Intermediates validation check option

[atc0005]

I should also lookup current best practices and add a reference link both here in the documentation. This validation check would look for a minimum of 1 intermediate certificate in the chain. It might be useful to add an additional flag to specify a required number, but that could come later once sufficient testing has been performed.

It may be best to have this validation check set as ignored by default, depending on the severity of the language used in best practices documentation.

See also:

• Add support for explicitly applying or ignoring specific validation check results #64
• Expand certificate chain validation options #120

[atc0005]

Opting for Intermediates as the check name to match the intent behind Root as a check name for #124.

[atc0005]

The OP needs a refresh.

The checks applied would consider:

• 0 certs in the chain as critical
• no intermediate certs as ?
• invalid intermediate certs as critical

This would be the initial implementation.

[atc0005]

A later implementation requires some further thinking. The whiteboard items below are from scratch planning for evaluating how complete a certificate chain is (determining which intermediate certs are missing).

A cert's metadata indicates where the issuer (CA) cert can be downloaded. To do this at any scale, we need a way to cache the download, or cache the result of downloading & parsing the certificate so that we don't "thundering herd" an intermediate certificate when performing several hundred cert checks in a short timeframe.

One idea that comes to mind is to have each execution of the plugin attempt to find the CA cert in a file-based cache (e.g., SQLite db in WAL mode) and use it if present (and if cache entry is recent enough), otherwise download & parse & store the result for use by another execution of the plugin. This should work, but may be more brittle. The upside is that it does not require another app to query. Downside include CGO (bigger app, longer compile times) unless we use a newer sqlite3 library which doesn't have that requirement.

Another option is to setup a separate proxy process that does no more than cache the CA cert download and have the plugin reprocess it on each execution, skipping any cache management responsibility for the plugin.

Yet another option is to setup a certificate cache service that accepts requests for CA certs. The response could include just the cert, or the cert as part of a metadata payload.

Another option is to use an external datastore like Redis to cache content.

[atc0005]

Another option is to setup a separate proxy process that does no more than cache the CA cert download and have the plugin reprocess it on each execution, skipping any cache management responsibility for the plugin.

I think using Squid or similar will be the way forward for this. We can use the same thinking when implementing CRL-based revocation checking. It keeps the initial implementation simpler, more manageable.

[atc0005]

I think using Squid or similar will be the way forward for this.

I need to check the applicable RFCs to be sure of this, but it appears that Issuer Certificate URLs (Authority Information Access)¹ are provided via plantext HTTP.

That should be easy enough to have Squid cache them.

Footnotes

1. http://www.pkiglobe.org/auth_info_access.html ↩

[atc0005]

Other ref links:

• https://www.thesslstore.com/blog/aia-fetching/
• https://issues.chromium.org/issues/41299334
• https://issues.chromium.org/issues/42290282
• https://stackoverflow.com/questions/36838470/android-does-not-trust-a-certificate

It is unclear whether current versions of Android natively support cert chain path building via AIA.