[Feature]: Provisioning certificate PFX validation gaps during domain profile upload can cause silent or hard-to-debug activation failures

[nmgaston]

Describe the feature

Several validation gaps in the certificate loading logic may cause silent TLS/mTLS failures or hard-to-debug errors after certificates are stored or loaded:

• notBefore check: No certificate should have a notBefore date in the future. Currently, neither ParseCertificateFromPEM nor LoadCertificateFromFile check notBefore; only notAfter is checked at domain upload in DecryptAndCheckCertExpiration.
• notAfter check on load paths: ParseCertificateFromPEM and LoadCertificateFromFile never check notAfter. An expired certificate will load and be used silently until a TLS handshake fails at runtime.
• Minimum RSA key size: Certificates must use at least 2048-bit RSA keys. This is enforced at generation time in GenerateRootCertificate, but the load paths (ParseCertificateFromPEM, LoadCertificateFromFile) accept externally provided or legacy certs with smaller keys silently.
• Root certificate self-signed and CA-flagged: The root certificate must be self-signed (issuer matches subject and signature verifies against its own public key) and must have IsCA: true with BasicConstraintsValid: true. Without this, a leaf cert could be loaded in place of a root cert and silently fail during certificate issuance or TLS verification.
• Root certificate KeyUsageCertSign: The root certificate must have KeyUsageCertSign set. An externally provided root cert missing this will produce an invalid signature when IssueWebServerCertificate signs the web server cert, resulting in a broken certificate chain that fails verification.

Steps to reproduce

1. Load a PEM certificate/key pair where:
   • The certificate has a notBefore date in the future.
   • The certificate has a notAfter date in the past.
   • The RSA key size is below 2048 bits.
   • A non-CA (leaf) certificate is provided as the root certificate.
   • The root certificate lacks KeyUsageCertSign.
2. Observe that all five cases are accepted without error and only fail at runtime (TLS handshake failure, signing error, or certificate issuance failure).

Expected behavior

All certificates loaded via ParseCertificateFromPEM and LoadCertificateFromFile are validated against:

• notBefore <= now
• notAfter > now
• RSA key size >= 2048 bits
• Root certificate is self-signed and has IsCA: true with BasicConstraintsValid: true
• Root certificate has KeyUsageCertSign set

Any failure results in a meaningful error at load time, before the certificate is used or stored.

Additional context

• The generation path (GenerateRootCertificate, IssueWebServerCertificate) already enforces all of these properties — the gap is only on the load path for externally provided or legacy certificates.
• The Intel AMT Activation EKU OID check from the PFX story does not apply here; console certificates are for TLS/mTLS, not AMT provisioning.
• Full chain integrity validation (multi-cert chains) applies only if externally supplied certificate chains are accepted in the future; it is not applicable to the current single-cert PEM load paths.