A certificate is a dated assertion. It says that at one moment a domain was controlled by the party named in it, that a key pair belongs to that party, and that a certification authority checked both. The internet’s browsers and libraries then treat that assertion as usable until the expiry date printed inside it, which is why the length of that date has always been an operational parameter rather than a legal footnote.
For a gambling platform the parameter just changed twice, and a third change is on a published schedule. A certificate that must be replaced every 200 days — and later every 47 — is not a renewal task that belongs on a quarterly calendar with a reminder set a month ahead. It is a lifecycle that has to be inventory-driven, automated, monitored and evidenced, because the failure mode is not a warning in a log: it is players who cannot open the site at all.
The schedule, in the words of the document that sets it
The CA/Browser Forum’s TLS Baseline Requirements are the common rulebook that browsers and public certificate authorities agree to follow. Section 6.3.2 sets the maximum validity period of a publicly trusted subscriber certificate, and since 15 March 2026 it reads, for the current tier: a certificate issued on or after 2026-03-15 and before 2027-03-15 “SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days”. The same section continues to 100 days from 2027-03-15 and 47 days from 2029-03-15, and it defines a day for calculation as 86,400 seconds, adding that certificates should not be issued for the maximum permissible time by default, so that fractional seconds and leap seconds do not push a value over the limit.
The ballot that set that schedule is worth reading for its reasoning rather than only its table. Ballot SC-081v3 was proposed by Clint Wilson of Apple, endorsed by Sectigo, Google Chrome and Mozilla, and it voted through with 25 certificate-issuer votes in favour and none against, plus the four consumer votes. Its own summary of the change is blunt: an eventual reduction of maximum validity from 398 days to 47 days, with the reductions “proposed to occur starting in March 2026 and concluding in March 2029”. Its first stated benefit is the sentence worth pinning to a wall — certificates “are representations of a point in time state of reality” — followed by the observation that the longer a certificate lives, the more likely its contents have diverged from reality.
Two paragraphs of that ballot matter to a platform team in a way that a date table does not. The first is its scope: the Baseline Requirements “address requirements only for certificates which are ‘intended to be used for authenticating servers accessible through the Internet’”. A private CA inside your own estate is not governed by this schedule — which is a decision you now have to make deliberately, because the public schedule will pull your public endpoints onto a much faster cadence than the internal ones, and a platform that treats the two identically will either over-automate a low-risk internal service or under-automate a public one. The second is a reminder about revocation: the requirements already carry a duty for a CA to revoke a certificate within 24 hours in certain circumstances, and the ballot notes that the practical management of certificates has not always reflected an expectation of being able to replace one inside a day.
What else changed with it
The validity period is the headline, but the same schedule moved the validation data underneath it, and the validation methods themselves, which changes what an automated issuance flow is allowed to do.
| Requirement | Effective | Where it is written |
|---|---|---|
| Domain name and IP address validation data reuse: 200 days | 2026-03-15 | Baseline Requirements §4.2.1 |
| Subject identity information validation data reuse: 398 days, reduced from 825 | 2026-03-15 | Baseline Requirements §4.2.1 |
| DNSSEC validation must be performed on all DNS queries used for domain validation and CAA lookups | 2026-03-15 | Baseline Requirements §3.2.2.4 and §4.2.2.2 |
| Email-based and phone-based domain validation should no longer be used to issue subscriber certificates | 2026-03-15 | Baseline Requirements §3.2.2.4 |
| All remaining use of SHA-1 in certificates and CRLs sunset | 2026-09-15 | Baseline Requirements §7.1.3.2.1 |
CAA parameters accounturi and validationmethods processed per RFC 8657 |
2027-03-15 | Baseline Requirements §4.2.2.1.2 |
| Domain name and IP validation data reuse: 100 days, then 10 days | 2027-03-15, 2029-03-15 | Baseline Requirements §4.2.1 |
The practical reading is that the number of days a validation stays reusable is shrinking faster than the certificate lifetime, and the manual methods that used to rescue a stuck renewal — an email to a mailbox at the domain, a phone call — are being withdrawn from the automated path. An issuance flow that depends on a human answering a message is now a flow that violates the intent of the rulebook even before it becomes a flow that breaks.
Inventory first, because you cannot automate what you have not named
The most common certificate incident in a mid-sized platform is not a cryptographic failure. It is a certificate nobody remembered: a wildcard bought by a former team for an integration that still calls it, a certificate on an appliance console, a certificate inside a tenant-specific domain that a partner introduced, a certificate in the mobile backend that never appears in the web infrastructure’s list.
So the first deliverable is a register, and it has to answer questions rather than merely count rows:
| Column | Why it is needed |
|---|---|
| Certificate and key identifier | The fingerprint and serial that resolves a support ticket to one object |
| Subject and subject alternative names | Which hostnames the assertion actually covers, including the ones nobody uses yet |
| Issuer and issuing CA account | Which authority can renew it, under which account, through which API |
| Consumer | Every service, load balancer, appliance, mobile build and partner endpoint that will break at expiry |
| Owner | A team, not a group mailbox |
| Automation path | The exact job, repository and secret store that performs the renewal |
| Renewal state and last renewal date | Whether the automation has ever actually run in production |
| Key custody | Whether the private key is generated in and never leaves a hardware module, or exists as a file |
Two of those columns are the ones organisations routinely leave empty, and they are the two that decide how bad the next expiry is: the consumer list, because it is what turns one expired certificate into an outage whose blast radius nobody can predict in the first ten minutes; and the automation path, because an automated renewal that has never been exercised is an assumption. Whether the private key leaves a hardware module is a design decision rather than a universal rule; what is not defensible is not knowing the answer per certificate when a reviewer asks. The multi-tenant isolation guide covers the related question of who owns a hostname inside a shared platform, and the migration and cutover guide covers why a domain that moves between operators has to be tracked rather than assumed.
Automate issuance, and prove the automation works
ACME, specified in RFC 8555, is the ordinary way to do this. Its abstract describes it plainly: a protocol that a certification authority and an applicant “can use to automate the process of verification and certificate issuance”, with facilities for other certificate management functions including revocation. The protocol is only half of the automation; the other half is the plumbing around it — the credential the client uses, the DNS or HTTP challenge it must satisfy, the reload that hands the new certificate to the service, and the alert that fires when any of those steps stops happening.
Four properties separate an automated renewal from a script that happens to run:
- The renewal is driven by the certificate, not by a calendar. Asking the deployed certificate when it expires and renewing inside a stated window survives a certificate that was issued manually, a domain that was added late, and a job that was skipped once.
- The identity of the requester is constrained in DNS. A CAA record, defined by RFC 8659, lets a domain holder “specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name”, which is a control against mis-issuance by an authority you never intended to use. RFC 8657 extends it with two parameters that pin the account that may request issuance and the validation methods that may be used for it, and the Baseline Requirements bring the latter into force in 2027. Specifying your own ACME account in a CAA record is one of the few controls that makes a compromised credential elsewhere less useful.
- The reload is part of the test. A renewed certificate that the service does not pick up until the next deploy is a scheduled outage with an extra step. Whatever the mechanism — a reload hook, a sidecar, a proxy that reads the file per handshake — the acceptance test is that a replaced certificate is served immediately, and it belongs in the non-production environment where the renewal path can be run and failed on purpose.
- Expiry is monitored from outside the platform. Internal monitoring shares fate with the system it watches. A check made from a separate network, against the address players actually reach, and alerting at a threshold expressed in days rather than hours, is the only check that catches a broken renewal chain before the players do. Under a 200-day cadence an annual review still works; under 47 days it does not, and the alerting threshold has to be set from the renewal window rather than from habit.
Name the subscriber, not just the host
Certificates do two jobs in a gambling platform, and they are often confused. One is to present the operator’s own service to a player’s browser. The other is to identify a service to another service: the platform to the payment provider, the platform to the RGS, the back office to an internal API, one microservice to another.
The second job is the one where a hostname-centred habit goes wrong. RFC 9525, which obsoletes RFC 6125, specifies “procedures for representing and verifying the identity of application services” in TLS, and its point is that the identity being verified is the service on the other end of the connection, not a machine and not an IP address. In a platform assembled from services and suppliers, that distinction is the difference between an internal API that authenticates a caller and an internal API that merely encrypts the connection while trusting anything inside the perimeter.
For supplier integrations the register and the trust store have to move together. When a partner rotates its certificate, the change is usually announced through a support channel rather than through your DNS, and a platform that pins the partner’s certificate in a configuration file without an owner and a review date will discover the rotation at the moment the integration stops settling. Pinning between parties who both control the pipeline is reasonable; pinning between parties who do not is a dependency on a notification you may not receive.
Mobile applications add their own version of this problem, because an app already installed on a device carries whatever trust decision it shipped with. The app integrity guide covers the wider question of what a client can be trusted to prove about itself; the certificate-specific rule is narrower and worth stating alone: any trust decision baked into a released build has to be checked against the release cadence of that build, because a certificate that changes every 47 days cannot be a permanent trust anchor in an app that updates twice a year.
Keep the private key where it belongs
A certificate is public. The private key is not, and the key’s own lifecycle is separate from the certificate’s — a key pair has a usage period and a cryptoperiod, and the certificate’s expiry date is only one of the events that ends them.
NIST’s key management guidance is the general reference here: SP 800-57 Part 1 Revision 5 provides “general guidance and best practices for the management of cryptographic keying material”, including the security services cryptography can provide and the protection expected of each key type, and it treats the metadata around keys — who owns them, where they came from, when they may be used — as part of the material to be protected. For the module that holds the keys, FIPS 140-3, “Security Requirements for Cryptographic Modules”, is the standard that a validated hardware security module is tested against. For the protocol configuration on top of that, SP 800-52 Revision 2 gives “guidance to the selection and configuration of TLS protocol implementations while making effective use of Federal Information Processing Standards (FIPS) and NIST-recommended cryptographic algorithms”.
None of those documents certifies a gambling platform, and none of them replaces the operator’s own judgement about which integrations justify a hardware module. What they establish is a structure: generate the key where it will live, keep it there, give it a stated usage period, and record who may use it and for what. The questions a reviewer asks are correspondingly specific — where was this key generated, has it ever left the module, who can request a signature with it, when does it stop being valid, and what happens to data encrypted under it when it is retired. A platform that can answer those per certificate is finished with the hardest part of this work, because the rest of the lifecycle is scheduling.
Detect issuance you did not ask for
Monitoring expiry protects availability. It does not protect against the other failure: a certificate issued for your domain by an authority you did not choose, in a moment you did not know about.
Certificate Transparency exists for exactly that. RFC 9162 describes a protocol for “publicly logging the existence of TLS server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates”. Public authorities are required to submit certificates to logs, which turns a public log into a monitoring surface: a query for your own domains, run continuously, against a list you maintain, produces an alert when something is issued that your inventory does not explain.
That monitor belongs in the same review as the register, and it should be able to answer the question a security reviewer will ask after a mis-issuance headline: would we have known, how quickly, and from which source. The security logging and audit evidence guide covers the general evidence discipline; the certificate-specific version is that the alert record, the log entry and the ticket that closed it are the artefacts, not the dashboard.
Revocation is a runbook, not a status endpoint
Revoking a certificate is a decision with a procedure attached, and the procedure is what fails under pressure. The status protocol is only the announcement: RFC 6960 specifies the Online Certificate Status Protocol as a way of “determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs)”. Whether your relying parties actually consult it is a separate question, and the ballot that shortened validity periods says why it now matters less: it argues that certificate status services “do not adequately protect relying parties at the current scale of the internet”, citing privacy, performance, timeliness and accuracy, and it treats a short lifetime as the protection that does not depend on every party doing the right thing on time. Short-lived certificates do not remove the need to revoke; they reduce the window in which a revocation has to be believed.
Two pieces of engineering follow. First, stapling: RFC 7633 defines the TLS feature extension, whose purpose is to prevent downgrade attacks and which “may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling”. A certificate marked with that extension makes a missing staple a hard failure rather than a silent skip, which is a deliberate availability trade-off and should be recorded as one.
Second, the runbook itself. A certificate compromise is a security incident with a fixed opening sequence: identify every service using the key, revoke through the issuing authority, reissue with a new key pair rather than the same one, confirm what the old certificate protected, and decide what has to be treated as exposed. The incident response plan is where that sequence belongs, and the reason to write it while nothing is wrong is that the first decision in a real event is usually the one nobody can make quickly: is this a key compromise, a mis-issuance, or a configuration error, and who declares it.
What a 47-day world does to the rest of the stack
Shortening the lifetime does not change cryptography. It changes the cost of every operation that touches a certificate, and the operations that ignore this are the ones that will produce the outage.
- Alerting calibrated to a lifetime, not a year. A renewal window, a warning threshold and a critical threshold expressed as fractions of the actual validity period survive the 2027 and 2029 steps without being rewritten. Fixed values like “30 days” do not: they are 15 per cent of a 200-day certificate and 64 per cent of a 47-day one.
- Change management that can carry a weekly change. If a certificate replacement is a change ticket that requires a maintenance window, then at 47 days the platform has about seven windows per certificate per year. Automation that is trusted without a window is the only version of this that scales, and trust has to be earned by evidence: a rehearsal in a non-production environment, a rollback path, and a record of renewals that already happened unattended.
- A reload path that does not restart the world. The most common way a routine renewal becomes an incident is that applying it requires a process restart that drains sessions or resets a shared connection pool. Under a long lifetime that is a rare cost; under a short one it is a recurring one, and the fix is architectural rather than procedural.
- Keys rotated with the certificate. A renewal that reuses the existing key pair is cheaper and keeps the old key in service for another term. Reissuing with a fresh key pair is the practice that makes a compromise retrospective rather than open-ended, and it is worth deciding deliberately rather than by default.
- A supplier list with dates on it. Any interface where the other side controls a certificate — payments, identity, game content, a regulator’s reporting endpoint — is a dependency with its own expiry. The register should carry those certificates too, marked as not-ours, with the contact route recorded.
Turn it into acceptance evidence
The pack an operator, buyer or auditor should be able to read is short, and every item in it is checkable rather than asserted:
- The certificate register described above, with a named owner and a consumer list per entry.
- The public schedule each public certificate is being managed against, with the dates that apply today and the next step already planned for.
- For each automated renewal: the account or credential used, the challenge method, the DNS control that constrains issuance, and the date the path was last exercised in a non-production environment.
- The reload mechanism, and the evidence that a replaced certificate is served by the running service without a manual step.
- The external expiry monitor, its vantage points, its thresholds and the route its alerts take.
- The certificate transparency monitor for the domains you own, and the review that closes an unexplained issuance.
- The key custody statement: where each private key is generated, whether it can leave the module, its usage period, and who may use it.
- The revocation runbook, with the reissue-with-a-new-key rule written into it.
None of this is exciting work, which is why it is so often deferred until an expiry date forces it. The engineering habit it belongs to — specifying behaviour before building it, and keeping the specification current when the rules change — is the same one behind the platform development discipline this site applies elsewhere. For certificates, the rules changed in March and will change again in 2027 and 2029. A platform that has already built the register, the automation and the monitor will read those dates as a scheduling input. A platform that has not will read them as three separate incidents with a common cause.
Questions a platform team asks
Does the 200-day limit apply to our internal certificates?
Not under these requirements. The Baseline Requirements govern certificates intended to authenticate servers reachable over the internet, and a certificate issued by your own internal authority to a service that is not publicly reachable is outside that scope. That is a scope statement rather than a promise of safety: an internal certificate with a two-year lifetime and no automation is still an expiry waiting to happen, and the useful question is whether the internal estate has an owner, a register and a renewal path of its own rather than whether it is legally covered.
We renew annually today. What actually breaks first?
The renewal order, not the cryptography. An annual cycle is one renewal per certificate per year with a month of warning; at 200 days it is roughly two, and at 47 days it is roughly eight. The first things to fail are the ones that assumed the old pace: a reminder that was sent to one person, a change window that was booked quarterly, an alert threshold set in days that no longer leaves enough time to act, and a manual reload step that everyone tolerated because it happened once a year.
Do short-lived certificates mean we can ignore revocation?
No. Shorter lifetimes reduce the time a revocation decision has to propagate reliably and reduce how much of the ecosystem depends on status services behaving, which is part of why the change was adopted. They do not replace revocation for the cases that matter most: a compromised private key still has to be revoked through its authority, because until the certificate expires, anyone holding the key can present it. The practical difference is that revocation becomes a rare, incident-driven procedure with a runbook rather than a routine operation, so it deserves a rehearsal rather than a script nobody has run.
Is a wildcard certificate a way to reduce the number of renewals?
It reduces the number of certificates and increases the value of each one. One expiry date replacing twenty is a genuine operational simplification, and it also means one leaked key or one missed renewal affects every hostname the wildcard covers. The register entry has to carry that blast radius honestly, the consumer list becomes the whole set of covered services, and the wildcard should not be the answer for a hostname that has a different owner, a different exposure or a different availability requirement.
What is the smallest thing to build first if we have nothing?
The register, with the consumer column filled in. It costs a few days, it needs no new platform component, and it immediately answers the two questions that decide how bad the next expiry is — which services break, and who is responsible for each certificate. Automation without that list renews the certificates you remembered, which is precisely the set that was never going to cause the incident.
