Changing the SSL certificate expiration date from 398 days to 47 days is shown through calendars with an arrow between them.
Certificate validity is getting shorter

Until recently, an SSL certificate was perceived as a routine service: you paid once a year, configured it, and remembered it the next season. However, the security industry is steadily moving toward a point where the notion of a “year-long” certificate will disappear. Website owners will have to get used to a much more dynamic rhythm.

Timeline of validity reduction

Since 2020, 398 days had been considered the standard. Now we are entering a phase of gradual “compression” of these periods. Google and other key market players have already outlined the timeframes:

  • from March 15, 2026 – up to 200 days
  • from March 15, 2027 – up to 100 days
  • from March 15, 2029 – up to 47 days

Here it is important to separate the financial and technical sides. You will still be able to purchase an SSL subscription for a year or two to lock in the price. But physically replacing the files on the server will have to be done much more often: first twice a year, and later – monthly.

Re-issue mechanics

Re-issue is not a new purchase, but an update of an existing document. When the current file approaches its expiration, you generate a new Certificate Signing Request (CSR), confirm ownership of the domain, and receive a fresh certificate.

In practice, it looks like this: in the hosting or registrar control panel, the re-issue button is pressed, verification проходит via email or a DNS record, and the system provides a new set of codes. They need to be placed on the server instead of the old ones. If the site runs on popular CMS platforms or modern control panels, these processes can often be delegated to support or configured through automation scripts.

What this actually gives to security

The main argument in favor of such changes is minimizing the window for abuse. If a certificate is compromised or a domain changes ownership, the “old” access is naturally invalidated within weeks rather than after a year.

In addition, certificate revocation systems (CRL and OCSP) often work with delays. A short lifecycle solves this problem in a radical way: the certificate simply becomes invalid before critical vulnerabilities can arise. It also pushes the market to move faster toward new encryption algorithms, without waiting years for the entire network to update.

Impact on site stability

For an ordinary visitor, nothing changes. The HTTPS protocol works as usual, the browser “lock” remains in place. The main risk now lies on the administrator’s side. If earlier an administrative mistake might happen once a year, with a transition to 47-day cycles the chance of forgetting about renewal increases many times over.

When the validity expires, browsers instantly block access to the site with a large security warning. This immediately drops traffic and trust in the resource.

How to adapt

The only logical way out is to abandon manual management. The world is moving toward full automation, where human involvement in key renewal is no longer required. It is already worth checking whether your server software supports automatic retrieval of updated certificate files. SSL is gradually becoming not a “document,” but a streaming service that requires constant, albeit invisible, maintenance.