From 0e94286ed10521e8670898b5cc2b0962e9b0a9b9 Mon Sep 17 00:00:00 2001 From: Jonas Meller Date: Fri, 10 Jul 2026 10:06:10 +0200 Subject: [PATCH 1/2] Update authorization reuse and validity limits --- content/en/docs/profiles.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/profiles.md b/content/en/docs/profiles.md index abf1d218d..3bd5750bc 100644 --- a/content/en/docs/profiles.md +++ b/content/en/docs/profiles.md @@ -1,7 +1,7 @@ --- title: Profiles slug: profiles -lastmod: 2026-07-09 +lastmod: 2026-07-10 show_lastmod: false --- @@ -115,7 +115,7 @@ This is how long an ACME client has to complete a domain control validation chal ### Authorization Reuse Period -This is how long an already-validated Authorization can be reused by new Orders containing the same identifier. The clock starts when a challenge is successfully fulfilled, and is represented by the [`expires` timestamp](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4) in the valid Authorization object. This value is restricted to [at most 398 days](https://github.com/cabforum/servercert/blob/main/docs/BR.md#421-performing-identification-and-authentication-functions) by the Baseline Requirements. +This is how long an already-validated Authorization can be reused by new Orders containing the same identifier. The clock starts when a challenge is successfully fulfilled, and is represented by the [`expires` timestamp](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4) in the valid Authorization object. The [Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#421-performing-identification-and-authentication-functions) limit this to 200 days, falling to 100 days for certificates issued from March 15, 2027, and 10 days from March 15, 2029. ### Order Lifetime @@ -139,7 +139,7 @@ TLS Certificates can have a ["Subject Key Identifier" extension](https://datatra ### Validity Period -This governs the amount of time between the [`notBefore` and `notAfter` timestamps](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5) that are embedded in a TLS Certificate, in other words, how long the certificate will be trusted before it expires. This value is restricted to [at most 200 days](https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods) by the Baseline Requirements. +This governs the amount of time between the [`notBefore` and `notAfter` timestamps](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5) that are embedded in a TLS Certificate, in other words, how long the certificate will be trusted before it expires. The [Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods) limit this to 200 days, falling to 100 days for certificates issued from March 15, 2027, and 47 days from March 15, 2029. ### Revocation Information From 4cfee15c8c012c7169bf9f52679896fcbf616795 Mon Sep 17 00:00:00 2001 From: Jonas Meller Date: Fri, 10 Jul 2026 10:58:01 +0200 Subject: [PATCH 2/2] Clarify profile limits are maximums --- content/en/docs/profiles.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/profiles.md b/content/en/docs/profiles.md index 3bd5750bc..f3baf1caa 100644 --- a/content/en/docs/profiles.md +++ b/content/en/docs/profiles.md @@ -115,7 +115,7 @@ This is how long an ACME client has to complete a domain control validation chal ### Authorization Reuse Period -This is how long an already-validated Authorization can be reused by new Orders containing the same identifier. The clock starts when a challenge is successfully fulfilled, and is represented by the [`expires` timestamp](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4) in the valid Authorization object. The [Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#421-performing-identification-and-authentication-functions) limit this to 200 days, falling to 100 days for certificates issued from March 15, 2027, and 10 days from March 15, 2029. +This is how long an already-validated Authorization can be reused by new Orders containing the same identifier. The clock starts when a challenge is successfully fulfilled, and is represented by the [`expires` timestamp](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4) in the valid Authorization object. The [Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#421-performing-identification-and-authentication-functions) require this period not to exceed 200 days; the limit falls to 100 days for certificates issued from March 15, 2027, and to 10 days from March 15, 2029. ### Order Lifetime @@ -139,7 +139,7 @@ TLS Certificates can have a ["Subject Key Identifier" extension](https://datatra ### Validity Period -This governs the amount of time between the [`notBefore` and `notAfter` timestamps](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5) that are embedded in a TLS Certificate, in other words, how long the certificate will be trusted before it expires. The [Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods) limit this to 200 days, falling to 100 days for certificates issued from March 15, 2027, and 47 days from March 15, 2029. +This governs the amount of time between the [`notBefore` and `notAfter` timestamps](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5) that are embedded in a TLS Certificate, in other words, how long the certificate will be trusted before it expires. The [Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods) require this period not to exceed 200 days; the limit falls to 100 days for certificates issued from March 15, 2027, and to 47 days from March 15, 2029. ### Revocation Information