RAUC Certificate Validation Time: Review the Security Cost Before Accepting Old Signed Bundles
Using a bundle’s signing time changes the time at which its certificate chain is evaluated; it does not prove when the signature was actually created. Review that distinction before treating an expired signing certificate as an operational nuisance that a configuration switch can solve.
This analysis pins RAUC 1.14 and uses OpenSSL 3.0.18 source for the detailed CRL cases. A vendor build with another library, patches or verification callbacks needs its own qualification. No keyring, configuration, certificate or device was changed, and no cryptographic test was executed.
1. Identify which clock the verifier uses
The RAUC 1.14 keyring reference describes use-bundle-signing-time: when enabled, bundle signing time replaces current system time for certificate validation. The tagged configuration parser defaults this option to false when it is absent.
In the tagged verification implementation, the enabled branch extracts the CMS signing-time attribute and sets the OpenSSL verification time before signature verification. It does not set the system clock or convert the attribute into an independent timestamp authority.
Record the effective setting, linked library version, trust-store generation and device-time source. Do not diagnose certificate expiry using the release filename, filesystem timestamp or dashboard upload date; none identifies the verifier’s chosen time.
2. Separate signed time from independently established time
RFC 5652 section 11.3 defines the signing-time attribute as the signer’s claimed time and imposes no guarantee that it is correct. Protecting the attribute with the signature prevents an unrelated party from editing it undetected, but the signer chooses its value.
The security consequence is important: if someone obtains the signing key, a claimed earlier date is not evidence that the signature predates that compromise. A historical-time policy therefore needs an incident analysis beyond certificate expiry. Do not describe this setting as trusted timestamp validation or as proof that an old bundle was authorized before a breach.
Keep this question separate from rollback authorization. A certificate valid at the selected time does not make an obsolete firmware version compatible, safe or permitted by independent anti-rollback policy.
3. Build a certificate-time matrix first
For this simplified matrix, assume a correctly formed signature, accepted chain and algorithms, and that all other certificate checks pass. CRLs are considered separately below. “Pass” means only that the stated certificate-time condition passes.
| Certificate/time condition | Current-time evaluation | Signing-time evaluation |
|---|---|---|
| Current and claimed signing times both within validity | Pass this gate | Pass this gate |
| Expired now; claimed signing time within validity | Reject for expiry | Can pass this gate |
| Claimed signing time before certificate validity begins | Depends on current time | Reject for not-yet-valid certificate |
| Claimed signing time after certificate validity ends | Depends on current time | Reject for expiry |
| Incorrect device clock; otherwise genuine old bundle | May produce an incorrect time decision | Uses claimed time, with its separate trust limitation |
Apply the matrix to the actual chain, not only the leaf signer. Keep trust-anchor and chain-building behavior within the chosen OpenSSL configuration. A test that changes several certificates and clocks simultaneously cannot isolate which condition caused rejection.
4. Add revocation and CRL freshness explicitly
RAUC’s check-crl is a separate setting. Merely storing a CRL does not mean checking is enabled. The OpenSSL 3.0 verification documentation also explains that this mechanism does not automatically download CRLs from certificate distribution-point URLs.
In OpenSSL 3.0.18’s CRL checks, the selected verification time is used for CRL date validation too. A CRL current today may be not yet valid relative to a much older claimed signing time. A historical CRL may pass its time check while lacking later revocation information.
| CRL fixture with checking enabled | Expected review point |
|---|---|
| No suitable required CRL available | Verification must not silently become a successful no-CRL check |
| CRL starts after selected verification time | Not-yet-valid CRL can block verification |
| CRL expired at selected verification time | Expiry can block verification; qualify any delta-CRL configuration separately |
| Usable CRL lists signer as revoked | Ordinary revoked entry is rejected |
| Historical CRL omits a later-compromised signer | No current revocation knowledge is established |
Do not assume that selecting a time before a listed revocation date makes the signer acceptable. In the pinned ordinary CRL lookup, a matching revoked entry is reported without comparing that entry’s revocation date to verification time; removeFromCRL is a distinct case. This is implementation-specific evidence, not a universal historical-validation model.
5. Qualify the policy in an isolated fixture
- Freeze the verifier binary, library, configuration and public trust metadata.
- Create a controlled test corpus through the organization’s approved test-PKI process; exclude production private material.
- Vary current time, claimed signing time and certificate validity independently.
- Repeat with missing, current, historical and revoked-entry CRLs.
- Include malformed or missing signing-time attributes and require bounded failure without installation; do not assume the documented happy path proves parser robustness.
- Record verification result and error category before testing any installation path.
Keep the fixture isolated from production time services and active devices. This checklist is a proposed qualification method, not a certificate-generation or trust-change command sequence.
Hypothetical long-offline controller
A controller returns after its release-signing certificate expired. Its archived bundle claims a date inside certificate validity. Current-time validation rejects the expired chain; historical-time validation may pass that condition.
The security review then discovers that the available recent CRL begins after the claimed date, while the older CRL predates a compromise report. Neither “the signature verifies” nor “the old CRL was valid then” resolves today’s authorization decision.
Escalate to the approved recovery and incident policy, preserving the failing evidence. Close the review with the selected time model, compromise assumptions, CRL distribution/freshness plan and exact acceptance matrix. Do not change verification policy merely to make the stranded unit’s error disappear.
