The key point
Your service period and each certificate expiry are separate. Track both, and allow time to validate and install each replacement.
The validity schedule
The CA/Browser Forum requirements reduce the maximum validity for newly issued public TLS certificates in stages. The table below shows the issuance-date schedule. These are upper limits, so read the expiry of the actual certificate you receive.
One service period, separate certificate lifetimes
Your purchased service period and a certificate validity period are different. A reissue creates a replacement with its own expiry date. It does not extend your service end date. Check the product terms for included reissues.
Request, validate and install each replacement
Start reissue from your account before the deployed certificate expires. Complete any requested validation, download the replacement and install it on every relevant endpoint. With shorter lifetimes, it is more important to keep an accurate inventory and allow time for these steps.
Current maximum for newly issued public TLS certificates: 200 days
| Issued from | Maximum validity |
|---|---|
| 398 days | |
| 200 days | |
| 100 days | |
| 47 days |
Worked example
Service end date and certificate expiry
Buying a service period does not make the certificate on your server valid for that whole period. A replacement must be requested, issued and installed before the currently deployed certificate expires.
- Service end date
- The end of the purchased service, shown in your account.
- Certificate expiry
- The validity end of one issued certificate. Read the actual certificate, not just the invoice.
- Replacement installed
- The server now presents a new certificate with its own expiry. The service end date is unchanged.
Your next steps
- Keep an inventory of the certificate expiry and service end date for every endpoint.
- Start replacement early enough to complete domain and, where required, organisation checks.
- After installation, check the live certificate and update your expiry tracking.