If your website uses an SSL certificate from GoDaddy that was issued on 2025-05-30 between 00:00 and 22:04 UTC, it might fail to load in Safari with the message "This Connection Is Not Private". You can use our Certificate Transparency Policy Analyzer to see if your site is affected. If it is, you should request and install a new certificate as soon as possible. This blog post will explain what went wrong and how SSLMate detected it.

Certificate Transparency

Certificate Transparency (CT) is a system for publishing SSL certificates in public logs. Certificate Transparency monitors like Cert Spotter download the logs to help you track certificate expiration and detect unauthorized certificates.

At a high level, Certificate Transparency works like this:

1. Before issuing a certificate, the certificate authority (CA) creates a "precertificate" containing the details of the certificate it intends to issue.
2. The CA submits the precertificate to multiple Certificate Transparency logs.
3. Each log returns a receipt, called a Signed Certificate Timestamp (SCT), which confirms submission of the precertificate.
4. The CA embeds the SCTs in the certificate which it gives to the site operator.
5. When a browser loads a website, it makes sure the website's certificate has SCTs from a sufficient number of recognized logs. If it doesn't, the browser throws up an error page and refuses to load the website.

Certificate Transparency Log Lifecycle

Billions of SSL certificates are issued and logged to CT every year. To prevent logs from growing indefinitely, logs only accept (pre)certificates which expire within a certain range, typically six months long. For example, Sectigo's "Sabre 2025h1" log accepts certificates expiring between 2025-01-01 and 2025-06-30. Every log will eventually contain only expired certificates, allowing it to be shut down. Meanwhile, new logs are created to contain certificates expiring further in the future.

When log operators create a new log, they inform Apple and Google about their new log, including the expiration range. Apple and Google add the log to their JSON log lists (Apple's, Google's) so that Safari and Chrome clients know to accept SCTs from the log, and monitors like Cert Spotter know to download certificates from the log.

The Problem

Unfortunately, the information published by Apple and Google doesn't always match the true configuration of the log. When DigiCert submitted their Wyvern 2026h1 and Sphinx 2026h1 logs to Apple and Google in July 2024, they stated that the upper expiration bound was 2026-07-01. In reality, the two logs were configured with an upper bound of 2026-07-07. Since there was no reason to believe that it was wrong, Apple and Google copied the incorrect upper bound into their published log lists.

This problem went unnoticed for almost a full year, until last week when GoDaddy began logging precertificates to these logs with expiration dates between 2026-07-01 and 2026-07-07, and embedding the returned SCTs in the certificates given to site operators. Unfortunately for the site operators unlucky enough to receive such a certificate, Apple's certificate validator checks that the expiration date is within the log's range before accepting an SCT. Since the published upper bound of these logs is 2026-07-01, any SCTs for certificates expiring after that are rejected, causing the certificate to fail validation.

SSLMate noticed the problem because Cert Spotter checks that certificates expire within the log's range and raises a warning if not. The first warning was raised just after midnight UTC on 2025-05-30, and the next morning I reported the problem to DigiCert, CC'ing the ct-policy mailing list. DigiCert replied within a few hours, initially proposing to change the published log lists to match the logs' configuration. I replied back, pointing out the issue with Safari, and suggesting it would be better to reconfigure the logs to match the published date. DigiCert agreed and completed the reconfiguration at 22:04 UTC.

In the end, there were 5,070 out-of-range precertificates logged to Wyvern 2026h1, and 9 logged to Sphinx 2026h1. All were issued by GoDaddy.

Root Causes

DigiCert joins a growing list of other log operators, browser developers, and monitor operators (including myself) who have at some point made a mistake copying a log's expiration range from one place to another. The right fix is to take humans out of the equation, and just a day before this incident, Chrome updated their log policy to require log operators to provide their log's metadata in machine-readable JSON when requesting inclusion of their log. The Sunlight log implementation has already implemented an HTTP endpoint to return the necessary JSON object based on the log's actual configuration, and the Trillian log implementation will soon have the same feature. Moving forward, there should be no more need to manually copy log expiration ranges around, eliminating a frequent source of human error and preventing something like this incident from happening again.

As for GoDaddy, it's a mystery why they were trying to submit certificates expiring after 2026-07-01 to these logs when the Apple and Chrome JSON log lists both specified 2026-07-01 as the upper bound. Does GoDaddy manually configure logs instead of consuming the JSON log lists, and they too fat-fingered the expiration range? Or maybe they ignore expiration ranges and spray their certificates at every log to see who accepts them? We'll probably never know the answer - this type of mistake is considered a technical problem rather than a policy violation, so GoDaddy is not required to post a public incident report. Nevertheless, I emailed a list of affected certificates to their problem reporting address as a heads-up. They replied on Saturday that they were working on replacing affected certificates and preventing a recurrence of the issue.

Unfortunately, Certificate Transparency logging seems to be a recurring source of problems for GoDaddy. In 2021, they issued tens of thousands of certificates which didn't comply with Apple's new Certificate Transparency requirements. And two weeks ago, I found that they had embedded an SCT with an invalid signature in a certificate, indicating a failure to validate SCT signatures (which can have disastrous consequences). Clearly, GoDaddy needs to improve their logging practices.

About Cert Spotter

Certificate automation is great... until something breaks, taking your sites down with a certificate error. Sometimes it's your cron job that breaks, but other times it's a certificate authority that messes up, such as by issuing certificates that don't work in Safari, or worse, issuing an unauthorized certificate to an attacker.

Cert Spotter uses Certificate Transparency to find all of your domains' certificates, alerting you about upcoming expiration, unauthorized certificates, and other problems that can cause browser errors. Learn more