200-Day TLS: Automating ERP Interface Certificates

The CA/Browser Forum is the body in which certification authorities and browser vendors define the Baseline Requirements for publicly trusted certificates. Ballot SC-081v3 introduced a staged schedule that reduces the maximum lifetime of server certificates in three steps and shortens the reuse period for domain validation data in parallel (CA/Browser Forum, Ballot SC-081v3). The first step has been in force since 15 March 2026. Anyone obtaining a certificate from a public certification authority today receives it with a maximum lifetime of 200 days (CA/Browser Forum, Ballot SC-081v3) – regardless of what the ordering process allowed in the past.

The second stage follows on 15 March 2027 with 100 days, the third on 15 March 2029 with 47 days (CA/Browser Forum, Ballot SC-081v3). Measured against the 398 days that applied until 14 March 2026 (CA/Browser Forum, Baseline Requirements), that is a reduction by a factor of roughly eight and a half. For a single web server this is a configuration question. For a grown integration landscape with an ERP system, middleware, marketplace connections and logistics partners, it is a process question.

The third column is frequently overlooked, yet it has the larger operational effect. By 2029, the period within which a completed domain and IP validation may be reused drops to 10 days (CA/Browser Forum, Ballot SC-081v3). In practice this means that from that stage onwards, almost every renewal also triggers a fresh control check over the domain. Anyone still performing that validation manually via a DNS record or a file on the web server will, from 2029, permanently tie staff to a task that can be fully automated.

A simple back-of-the-envelope calculation shows why the manual model no longer holds. At 398 days, one appointment per year and endpoint was enough. At 200 days it is two, at 100 days four, and at 47 days roughly eight to nine (CA/Browser Forum, Ballot SC-081v3). A mid-sized commerce landscape with a shop, an ERP system, middleware, two marketplace connections, a shipping provider and a payment reconciliation quickly reaches 15 to 25 TLS endpoints (project experience). By 2029, twenty calendar appointments per year turn into roughly 170 – spread across teams, service providers and systems, some of which are not even in your own data centre.

In the shop, an expired certificate is a loud event. The browser shows a warning page, customers get in touch, and the incident is known within minutes. On the ERP side that alarm does not exist. No browser talks to the interface there – a connector, a middleware or a nightly job does. If the certificate chain fails validation, the TLS handshake aborts before an HTTP request even exists. The application does not see an error code from the ERP system, it sees a connection error at transport level.

That difference is exactly what makes the outage dangerous. In the standard configuration, TLS 1.3 requires the server to authenticate with a certificate (IETF RFC 8446); if that fails, the connection ends before the application logic above it ever starts. For an order system this means the order has been accepted, paid for and confirmed in the shop – it simply never arrives in the ERP system. Depending on the architecture, the orders end up in a retry queue, in a dead-letter queue or in a log file that is opened at the next scheduled look.

Certificate expiry therefore belongs in the same category as any other disruption of the transfer path. How queued messages can be reprocessed cleanly without creating duplicates is described in our article on idempotency and retry strategies; the question of which signals an interface should emit in the first place is covered in the piece on observability and monitoring for interfaces. For classifying transport errors against business errors, the article on error handling in interfaces is worth a look as well.

Automation presupposes knowledge. A renewal job can only serve what is documented. In its practice guide SP 1800-16, "Securing Web Transactions: TLS Server Certificate Management" (June 2020), NIST describes exactly this connection: a formal certificate management programme should put organisations in a position to prevent, detect and recover from certificate-related incidents (NIST SP 1800-16). The first building block of such a programme is a complete inventory, the second a clear assignment of responsibilities (NIST SP 1800-16).

The second part is active verification. Monitoring that only fires on a connection error reports the outage – not the cause, and certainly not in time. What works is a dedicated check that performs the handshake regularly, reads the remaining lifetime and raises an alert below a threshold. A two-stage threshold has proven useful: an early warning at 30 days remaining and an escalation at 7 days (project experience). With a 47-day lifetime from 2029, the early warning moves close to the renewal itself – another reason not to run the process by hand.

The road from calendar entry to operating process can be walked in four steps, and it depends less on tooling than on clarity. Almost all the effort sits in the first step: once the inventory exists, the rest is routine. In a typical landscape with middleware between shop and ERP, this covers the connections to the inventory system, to marketplaces, to shipping providers and to payment reconciliation.

Two current developments add further pressure, because they introduce new external endpoints into the landscape: the reporting duties around packaging data under the PPWR and the changed data requirements of the customs reform for ERP and shop. Every additional connection to an authority or partner system is another TLS connection with its own certificate, its own truststore and its own ownership. Without an inventory, that list grows faster than it is maintained – which connections we look after is set out in the overview of our ERP integration services.