ACME authorization "expires" duration — 8 days vs CP/CPS 200-day validation-data reuse

Hi @Ayushkar,

Here are the technical answers to your questions regarding Google Trust Services (GTS) ACME authorization lifecycles:

1. Is this 8-day authorization validity an intentional policy?

Yes, this is intentional. The 200-day limit in Section 4.2.1 of the GTS CP/CPS represents the maximum allowable ceiling mandated by CA/Browser Forum guidelines for reusing domain validation data across the industry. CAs are free to enforce stricter operational limits within their ACME implementation. For GTS ACME endpoints (dv.acme-v02.api.pki.goog), the pending/valid authorization lifetime is set to 8 days (7 days + 1 day buffer) to minimize security risks associated with stale authorizations and dynamic DNS changes.

2. Is this duration stable, or could it change without notice?

While the current 8-day validity window is standard for GTS, you should not hardcode an 8-day assumption into your client automation. According to RFC 8555 (ACME), clients must dynamically inspect the expires field returned in the authorization object rather than assuming a fixed duration. GTS reserves the right to adjust internal validity periods or challenge lifetime policies to align with evolving security practices or CA/B Forum requirements.

3. Does this differ for wildcard domain authorizations?

No. The authorization validity period (and reuse behavior) applies per domain identifier (e.g., example.com or *.example.com). Wildcard authorizations follow the exact same DNS-01 challenge verification and authorization expiration lifetime as non-wildcard domains.

Key Recommendation for Reliable Production Automation

To ensure your production tool remains robust:

• Always parse the expires string in the ACME payload dynamically.

• Handle ACME authorization state transitions (pending vs valid) based on real-time API responses rather than relying on cached validation timelines.

Hope this helps clarify the behavior for your automation architecture!