Certificate Lifecycle Automation¶
Objective¶
Establish automated certificate management across the organization to handle shortened certificate lifetimes (199-day and shrinking to 47-day) without relying on manual renewal processes.
Context¶
Certificate lifetimes are shrinking. InCommon (Sectigo, transitioning to CertiNext) moves to 199-day certificates on July 17, 2026, then drops to 90 days on December 31, 2026 as a consequence of CertiNext implementing Chrome's intermediate-CA policy. Industry trends continue downward — CA/B Forum Ballot SC-081v3 (approved April 11, 2025) mandates 100-day by March 2027 and 47-day by March 2029.
Certificate management for InCommon/Sectigo is largely manual — requesting, installing, and renewing certificates by hand. InCommon is the primary source of manually managed certificates and the most affected by shrinking lifetimes.
Certificates are used across a wide range of services — public-facing web sites, load balancers, API endpoints, RADIUS servers, WiFi infrastructure, LDAP/Active Directory, mail servers, VPN appliances, and clustered applications that share a single certificate across multiple nodes. Not all of these services expose a public HTTP endpoint or support running a tool to automate certificate renewal.
Certificate Lifetime Timeline¶
| Date | CA/B Max | InCommon Max | Change |
|---|---|---|---|
| March 15, 2026 | 200 days | 200 days | CA/B Forum: max validity drops to 200 days; DCV reuse 200 days |
| May 4, 2026 | 200 days | 200 days | InCommon: new intermediate CAs (Sectigo R46/E46); new cert chains required |
| July 17, 2026 | 200 days | 199 days | InCommon: max validity drops to 199 days (extended from originally announced 90 days) |
| December 31, 2026 | 200 days | 90 days | InCommon: max validity drops to 90 days |
| March 15, 2027 | 100 days | 90 days | CA/B Forum: max validity drops to 100 days; DCV reuse 100 days |
| March 15, 2029 | 47 days | 47 days | CA/B Forum: max validity drops to 47 days; DCV reuse 10 days |
Tools In Use¶
- Cloudflare (WAF, origin certs, Google Trust Services)
- HashiCorp Vault
- AWS ACM (public CA; private CA available)
- InCommon/CertiNext with ACME+EAB
- Let's Encrypt
- Certbot
- Windows PKI
Scope¶
In scope¶
- Public TLS certificates for web sites and services
- TLS certificates for non-web uses (RADIUS, LDAP, mail, etc.)
- Certificates for clustered services requiring shared certs across nodes
- Internal/private CA for services that don't need public trust
- ACME automation for all feasible certificate types
- Certificate expiration monitoring and alerting
Out of scope¶
- Code signing certificates
- mTLS / client certificates
- Windows internal CA (existing, separate management)
- Post-quantum cryptography
Phasing¶
Not yet defined. The December 31, 2026 drop to 90-day InCommon certificates is a hard external deadline roughly five months out, and the 199-day window that opened July 17, 2026 is the intended build-and-test runway. Delivery phases, target dates, and per-phase owners are outstanding — see Open Questions.
Risks¶
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| No centralized certificate inventory; unknown certs will surface as outages after lifetime shortens | High | High | Mandiant ASM for external certificate discovery; network scanning where feasible (less reliable as services move to cloud); automation reduces dependency on inventory |
| Services that cannot use ACME (no HTTP endpoint, no DNS control) | High | Medium | Identify these early; use Vault or ACM Private CA for internal trust, or manual process with monitoring |
| Clustered services need shared cert distribution | Medium | Medium | Evaluate Vault as central cert store with distribution, or configuration management patterns |
| 199-day lifetime (July–December 2026) provides runway but 90-day InCommon limit hits December 31, 2026 | Medium | High | Use the 199-day window (July–December) to build and test automation; must be operational before 90-day limit takes effect |
Success Criteria¶
- ACME-based automation deployed for every certificate where feasible
- Monitoring/alerting for certificate expiration across all CertiNext-issued certificates
- Manual renewal reduced to edge cases with documented exceptions
- Migration from Sectigo to CertiNext completed
- Documentation published for ASU IT staff covering certificate automation workflows, onboarding procedures, and exception handling
Open Questions¶
- What is the delivery schedule against the December 31, 2026 InCommon 90-day deadline, and who owns each phase?
- Which services cannot support any form of ACME (no HTTP, no DNS control, no API)?
- Vault private CA vs. ACM Private CA — cost, operational overhead, and trust distribution tradeoffs?
- How to handle cert distribution for clustered services — Vault, configuration management, something else?
- Are there compliance requirements that mandate specific certificate properties (key size, algorithm, SANs)?
References¶
- CA/B Forum Ballot SC-081v3 — Introduce Schedule of Reducing Validity and Data Reuse Periods — approved April 11, 2025; source of the 200 / 100 / 47-day validity schedule and the matching DCV reuse reductions
- CA/B Forum TLS Baseline Requirements — normative text the ballot amends
- InCommon Certificate Service — InCommon/Internet2 documentation for the CertiNext-era service
- Lifespan reduction for TLS certificates — UW–Madison KB — corroborates the December 31, 2026 drop to 90 days and attributes it to CertiNext implementing Chrome's intermediate-CA policy
- InCommon Certificate Service Vendor Transition (Sectigo → CertiNext) — UW–Madison KB — transition scope and timeline
- RFC 8555 — Automatic Certificate Management Environment (ACME) — protocol behind the automation in scope; §7.3.4 defines the External Account Binding that InCommon/CertiNext requires
- AWS Certificate Manager and AWS Private CA — public and private issuance options weighed in Open Questions
- HashiCorp Vault PKI secrets engine — candidate internal CA and shared-cert store for clustered services
- Cloudflare Origin CA — edge/origin issuance already in use
- Certbot — ACME client listed in Tools In Use
Decisions¶
| Date | Decision | Rationale |
|---|---|---|
| 2026-07-21 | InCommon → CertiNext transition does not change ACME+EAB workflows | Confirmed through transition; no workflow changes required |
Changelog¶
| Date | Status | Change |
|---|---|---|
| 2026-04-16 | draft | Initial draft |
| 2026-04-17 | draft | Updated for InCommon/CertiNext 199-day lifetime extension (was 90 days); adjusted risks and timeline |
| 2026-04-17 | draft | Added InCommon 90-day drop date (December 31, 2026); updated timeline and risks |
| 2026-07-21 | active | Added community documentation deliverable; resolved CertiNext ACME+EAB risk; promoted to active |
| 2026-07-21 | active | Scoped monitoring to CertiNext certificates; added Sectigo→CertiNext migration deliverable; added post-quantum cryptography to out of scope |
| 2026-07-24 | active | Review pass: added a Phasing section recording that no delivery schedule or owner exists against the hard 2026-12-31 deadline, plus a matching open question; verified every timeline date against CA/B Forum SC-081v3 and InCommon sources and added inline citations and a References section; renamed the non-standard Success Criteria/Deliverables heading; removed the resolved CertiNext risk row already captured in Decisions; corrected created to the first changelog date |