News

Once a year is no longer enough: HTTPS certificate lifetimes are shrinking

Until now, a website's HTTPS certificate could be valid for up to 398 days. Many teams replaced it by hand once a year, and a calendar reminder was enough. That routine is ending.

What changed?

The CA/Browser Forum, the joint body of certificate issuers and browser makers, adopted ballot SC-081 in April 2025. Its current Baseline Requirements set this schedule:

The first step is already in force: certificates issued since March are valid for at most 200 days. That means at least two renewals a year now, and roughly one a month from 2029.

The same ballot also shortens how long an issuer may reuse an earlier domain validation: 200 days today, 10 days from 2029. Domains will have to be re-validated more and more often.

What does it mean for a business?

When a certificate expires, browsers show visitors a warning page, and most of them leave. Wherever renewal is still a manual task, that risk grows every year: two renewals a year are manageable by hand, monthly renewals are not.

What to check now

1. Is renewal automated? Most hosting providers and Cloudflare handle it, but ask your provider or developer.
2. Where are certificates still installed by hand: subdomains, mail servers, old admin panels?
3. Is there an alert when a certificate is close to expiry?

Secageo's free check looks at your website's certificate from the outside and flags it if it expires within 14 days.

Blocking GPTBot is not enough: how OpenAI visits your website

Many companies have added a single line to their robots.txt to block "GPTBot", so that ChatGPT would not learn from their content. According to OpenAI's documentation, though, several separate crawlers visit websites, and each does something different. Without knowing that, it is easy to block something other than what you meant.

The three crawlers that matter

• GPTBot collects content that OpenAI may use to train its models. OpenAI says that disallowing it signals the site's content should not be used for training.
• OAI-SearchBot is the crawler behind ChatGPT search. In OpenAI's words, sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers.
• ChatGPT-User visits when a user asks ChatGPT to open a page. OpenAI says it does not crawl the web automatically, and because these actions are user-initiated, robots.txt rules may not apply.

The documentation also lists a fourth, OAI-AdsBot, which checks landing pages submitted as ads.

Why it matters

OpenAI says the GPTBot and OAI-SearchBot settings are independent: you can allow one and block the other. The most common case for a business:

• it does not want its content used for training, so it blocks GPTBot,
• but it wants ChatGPT to recommend it when someone searches for its service, so it allows OAI-SearchBot.

Blocking "all OpenAI crawlers" also removes you from search answers. With no rules at all, all three crawl freely.

What to check now

1. What your robots.txt says today for each of the three names.
2. Whether that is intentional: out of training and in search, or the other way round.
3. If your host or Cloudflare offers a "block AI bots" switch, which crawlers exactly it covers.

Secageo's free check reads your robots.txt and shows whether GPTBot, OAI-SearchBot and ChatGPT-User are allowed or blocked.

An actively exploited WordPress flaw: is your site updated?

On 22 September 2026 WordPress released a critical security fix (CVE-2026-87902). Three days later the US cybersecurity agency CISA added the flaw to its catalog of known exploited vulnerabilities. In other words, attackers are already using it; it is not just a theoretical risk.

What is the flaw?

It is in WordPress core, not in a plugin. According to the WordPress advisory, an unauthenticated attacker can make the site load another PHP file on the server. With certain theme and server settings this can lead to a full server takeover. The advisory names some affected themes (the legacy Twenty Twelve and Twenty Fourteen, and Neve, Hestia and Sydney).

Who is affected?

WordPress versions 4.7 through 7.1.1. The fix shipped in 7.1.2, and WordPress backported it to every older branch down to 4.7 (for example 7.0.6, 6.9.9 and 6.8.10).

What to check now

1. Which WordPress version your site runs. It is shown at the bottom of the dashboard or under Updates.
2. If automatic updates are on, the fix has probably been applied, but check.
3. If an agency or freelance developer runs the site, ask them when they updated.
4. If the update was weeks late, ask your developer to review the server, since the flaw has been actively exploited since late September.

Secageo's passive check does not log in to your site and does not detect the WordPress version. It does flag from the outside if the login page (such as /wp-admin) is reachable by anyone, which raises the risk of every flaw like this one.