With digital certificates gradually being reduced to a 47-day lifecycle by 2029, France’s national cybersecurity agency ANSSI recommends “automating certificate management with ACME.” This is an effective approach, but it introduces new challenges: increased exposure for certification authorities, a larger attack surface on the client side, and incompatibility with certain types of certificates or specific equipment. As a result, a CLM solution is essential for securely managing the increasingly frequent renewal of all certificates.
The new digital certificate lifecycle schedule
On April 14, 2025, the CA/Browser Forum formalized its decision to reduce the lifespan of SSL/TLS certificates according to a progressive schedule: Starting March 15, 2026, certificates issued will have a maximum lifespan of 200 days, then 100 days starting March 15, 2027, and finally only 47 days on March 15, 2029.
In practice, this means that digital certificates will be rotated eight times more frequently (eight annual renewals instead of one currently). For system teams, application administrators, PKI administrators, and infrastructure administrators, manually managing digital certificate renewals will represent a significant burden. It should be automated to reduce administrative overhead and minimize the risk of service interruptions due to certificate expiration, which inevitably increases with the frequency of renewals.
Given the reduction in the lifespan of digital certificates, what are the ANSSI’s main recommendations?
To address the challenges posed by the reduction in the lifespan of certificates, the ANSSI has published recommendations for using the ACME (Automatic Certificate Management Environment) protocol to automate their renewal.
The agency recommends deploying an architecture consisting of seven main components:
- A certificate generation service
- A registration authority dedicated to creating external ACME administration accounts and managing binding elements
- A secure storage area (database or file system)
- An ACME server (to communicate with CAs such as Certigna).
- An ACME client
- A target web server
- A certificate requester associated with an external ACME administration account
ANSSI strongly recommends the use of external administration accounts, coupled with binding element management (MAC key and KeyID) that complies with the requirements of the General Security Reference (RGS) in order to strengthen the security of automated issuance and protect the confidentiality and integrity of keys.
The ANSSI recommendations enable the increasingly frequent renewal of certificates to be automated efficiently while maintaining a high level of security.
Read: How does the ACME protocol work?
Is the ACME protocol suitable in all cases?
However, the ACME protocol has certain limitations that restrict its use in some organizational and technical contexts.
Compatibility and coverage limitations
Although useful for automating the issuance of TLS certificates, the ACME protocol has certain limitations:
- It is not yet supported by all certification authorities (CAs), which can complicate its adoption in heterogeneous environments.
- It is restricted to issuing DV (Domain Validation) certificates and does not support OV (Organization Validation) or EV (Extended Validation) certificates, which require additional manual verification.
- Its integration may require the implementation of an internal ACME server or an ACME proxy, which represents a technical constraint for some organizations.
Operational security constraints
Network architecture and information system security constraints significantly limit the scope of ACME in most companies. For example:
- It is not recommended, and in any case impossible, to expose all endpoints to the Internet for obvious security reasons.
- Opening HTTP traffic on port 80 to internal servers is usually a violation of established security policies.
Operational constraints related to complex environments
ACME does not allow the management and supervision of the entire certificate fleet in complex multi-AC or multi-PKI environments, which is particularly problematic for large organizations.
These various constraints explain why the ACME protocol, in the vast majority of cases, is not sufficient to automate the management of all digital certificates.
How to manage DNS control proof (the ACME protocol challenge)?
Reducing the lifespan of certificates makes their operational management considerably more complex. For domain validation (DV) certificates, website owners will have to prove more frequently that they have administrative control over the domain. The constraint is even greater for companies using OV or EV certificates. For the latter, organizational or extended validation remains annual, but the automation of technical renewal becomes critical with a certificate lifetime of 47 days.
But the major challenge lies in integration with the main DNS managers. The so-called “DNS-01” challenge requires placing a specific value in a TXT record under the relevant domain name, a process that must be automated to avoid repeated manual interventions. By automatically positioning the certification authority’s DNS challenge in your DNS manager, a CLM (Certificate Lifecycle Management System) tool enables complete end-to-end automation.
ACME + CLM: the essential duo in complex IT environments
In addition to managing DNS challenges, a CLM can play several roles simultaneously in the ACME ecosystem. It can function as:
1. ACME client for communicating with external certification authorities (e.g., Certigna)
Fig. 1: Example of an architecture with BerryCert CLM positioned as ACME client
2. ACME server for endpoints that do not support ACME (in this case, CLM manages the protocol break)
3. ACME Authority for internal servers within the organization
Fig. 2: Example of an architecture with BerryCert CLM positioned as ACME server (ACME Authority)
CLM thus automates the management of the entire certificate fleet, whether they come from multiple public certification authorities or internal PKI infrastructures. It overcomes the main limitations of ACME while significantly reducing the operational risks identified above.
In addition, CLM, via its REST APIs, can also make your ADCS PKI or an internal server that does not natively support the ACME protocol compatible with ACME with an ACME-compatible certification authority.
CLM, an essential complement to ACME for automating certificate renewal
More generally, CLM provides:
- Centralized discovery and inventory of all certificates present in the IS, whether they come from internal or external authorities. This comprehensive view prevents the loss or omission of critical certificates.
- Real-time monitoring of certificate validity, sending alerts before they expire, and detecting anomalies (non-compliant certificates, unauthorized use).
- Automation of certificate renewal and deployment (using ACME or other protocols) and secure deployment on the relevant servers, thereby limiting human error and oversights.
- Centralized enforcement of security policies (authorized algorithms, lifetime, use of trusted CAs, domain restrictions, etc.) across all certificates, limiting the risk of misconfiguration or use of weak certificates.
- Management of incidents and compromises of a certificate or ACME account: CLM facilitates rapid revocation, reissuance, and traceability of actions, in accordance with ANSSI recommendations.
In anticipation of the reduction of the certificate lifetime to 47 days, one final point remains to be determined: which CLM to choose? There are many open source solutions on the market, but they often require in-depth technical skills and significant internal resources to deploy and maintain. On the other hand, vendor-supported CLM platforms benefit from dedicated technical support, regular updates, and simplified integration with existing environments.
