feat: Enforce issuer validity limits and warnings

[aw1cks]

Name of feature:

Limit X.509 certificate validity to the issuing CA chain.

Pain or issue this feature alleviates:

A certificate can currently be issued with an expiry date later than its intermediate or root CA, even though it will stop being trusted when that CA expires.

This change shortens the certificate's lifetime to match its issuing chain and reports a warning. Operators can set authority.issuerValidityLimit to reject instead if they need requests for a longer lifetime to fail.

Why is this important to the project (if not answered above):

Users and renewal tools rely on a certificate's expiry date. Making that date reflect its usable lifetime avoids a misleading signal, while the warning tells operators that the issuing CA needs attention.

Is there documentation on how to use this feature? If so, where?

The README's Issuer validity limits section covers configuration, warnings, and operational caveats. The changelog records the behavior change.

In what environments or workflows is this feature supported?

• Local SoftCAS issuance: signing, renewal, rekey, and subordinate CA creation.
• Native CA requests and SSH-associated X.509 identities. Their responses include warnings when validity is shortened.
• ACME and SCEP issuance, with warnings in server logs and no changes to successful protocol responses.
• StepCAS forwarding of warnings from the upstream CA.

In what environments or workflows is this feature explicitly NOT supported (if any)?

This does not enforce limits in Vault, Cloud CAS, or other external signers, or in standalone step certificate create/sign. It does not change SSH certificate validity, automatically renew CAs, or add proactive startup-expiry warnings.

Existing renewal scheduling is unchanged. Shortened certificates can fall below the provisioner's minimum lifetime, and a fixed renewal interval longer than the remaining lifetime can cause repeated renewals. The reject policy also applies to the CA's own TLS certificate, so it can prevent startup near CA expiry.

Verification:

Much of the diff is regression coverage for the issuance paths affected by #381 and #560. The tests cover signing, renewal/rekey and subordinate CA creation, checking both certificate expiry and the warnings or errors returned through the relevant APIs and protocols. This guards against fixing one issuance path while leaving others inconsistent.

After rebasing onto current upstream, both repositories' full short test suites passed and both binaries built. Earlier verification also covered the TPM simulator, lint, focused CLI race checks, and real issuance and warning-handling scenarios.

Supporting links/other PRs/issues:

• Related issues: Certificate expiration date later than subCA expiration date #381 and Constrain lifetime of signed certificate by remaining lifetime of parent certificates. #560. This addresses issuance limits and warnings, not every request in those issues.
• Companion CLI warnings: feat(cli): Display certificate validity warnings cli#1715

[CLAassistant]

All committers have signed the CLA.