Add Root validation check option

[atc0005]

This validation check would look for the presence of a root certificate in the chain and note any found.

I should also lookup current best practices and add a reference link both here in the documentation. If best practices indicate that root certificates are allowed, but discouraged, then a WARNING could be issued. If best practices indicate that root certificates are disallowed (entirely), then a CRITICAL state could be flagged.

It may be best to have this validation check set as ignored by default.

See also:

• Add support for explicitly applying or ignoring specific validation check results #64
• Expand certificate chain validation options #120
• https://security.stackexchange.com/a/86918
• https://www.rfc-editor.org/rfc/rfc4346#section-7.4.2
• https://blog.mozilla.org/security/2025/03/12/enhancing-ca-practices-key-updates-in-mozilla-root-store-policy-v3-0/

[atc0005]

Perhaps a Got Root validation check name instead? :)

[atc0005]

Perhaps a Got Root validation check name instead? :)

No. While memorable, this implies a specific expected state and doesn't fit well with the other neutral check names.

I think just Root will do for now.

[atc0005]

RFC 5280 mandates, that you send along each necessary certificate. And optionally, you may send along the Root CA cert as well.

Refs:

• https://security.stackexchange.com/a/86918

I need to dig further into this, specifically whether best practices have changed and whether this RFC has been "clarified" or deprecated.

[atc0005]

From https://www.rfc-editor.org/rfc/rfc4346#section-7.4.2:

certificate_list

  This is a sequence (chain) of X.509v3 certificates.  The sender's
  certificate must come first in the list.  Each following
  certificate must directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority may optionally be omitted from the chain,
  under the assumption that the remote end must already possess it
  in order to validate it in any case.

[atc0005]

An initial implementation made it to the development branch (2024-12?), but after testing builds with this support alongside "intermediates" validation support I am leaning towards removing it.

The specific detection this offers can be folded into another validation check and/or be covered by the generated payload and perfdata metrics.

[atc0005]

Food for thought regarding outgoing root certificates:

• https://www.sectigo.com/knowledge-base/detail/Sectigo-Root-Certificates/kA03l000000c4KVCAY
• https://www.sectigo.com/sectigo-public-root-cas-migration

In this case, the AAA Certificate Services root cert is expiring 2028, but the CA has indicated that it will be retired before that date.

From the latter FAQ link:

Will this impact existing certificates?

No, your existing certificates will remain valid until they expire. The change only applies to certificates issued after the migration dates mentioned above.

If you hold a Multi-Year subscription certificate, a reissues occurs after migration dates mentioned. Sectigo will supply the new Public Root CAs with your end entity certificate.

Not sure this requires any action on the part of the plugin, but it's something to consider.

[atc0005]

Food for thought regarding outgoing root certificates:

• https://www.sectigo.com/knowledge-base/detail/Sectigo-Root-Certificates/kA03l000000c4KVCAY
• https://www.sectigo.com/sectigo-public-root-cas-migration

In this case, the AAA Certificate Services root cert is expiring 2028, but the CA has indicated that it will be retired before that date.

Follow-up item:

• https://wiki.mozilla.org/index.php?title=CA/Root_CA_Lifecycles

In accordance with the schedule above, and Bug #1937338, Mozilla will remove the websites trust bit for these eight (8) CAs on April 15, 2025:

CA Name	SHA 256 Hash
Baltimore CyberTrust Root (expires 5/12/2025)	16AF57A9F676B0AB126095AA5EBADEF22AB31119D644AC95CD4B93DBF3F26AEB
Entrust.net Certification Authority (2048)	6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177
AAA Certificate Services	D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4
Go Daddy Class 2 CA	C3846BF24B9E93CA64274C0EC67C1ECC5E024FFCACD2D74019350E81FE546AE4
Starfield Class 2 CA	1465FA205397B876FAA6F0A9958E5590E40FCC7FAA4FB7C2C8677521FB5FB658
XRamp Global Certification Authority	CECDDC905099D8DADFC5B1D209B737CBE2C18CFB2C10C0FF0BCF0D3286FC1AA2
Chunghwa Telecom Co., Ltd. - ePKI Root Certification Authority	C0A6F4DC63A24BFDCF54EF2A6A082A0A72DE35803E2FF5FF527AE5D87206DFD5
GlobalSign Root CA	EBD41040E4BB3EC742C9E381D31EF2A41A48B6685C96E7CEF3C1DF6CD4331C99

The AAA Certificate Services cert is still widely distributed in certificate bundles from InCommon.

The USERTrust RSA Certification Authority intermediate (https://crt.sh/?id=1282303295, hash 68B9C761219A5B1F0131784474665DB61BBDB109E00F05CA9F74244EE5F5F52B) chaining to that root is also widely distributed in the "Enrollment Successful - Your SSL certificate for host1.example.com is ready" email notifications.

The replacement intermediate is not listed within an AIA URL for the previously issued certificates.