The Quick Fix
If you’re visiting a site and see this error, there isn’t much you can do. The problem lies with the server, not your computer. If you own the site, the fastest solution is to reissue your SSL certificate. Most modern Certificate Authorities (CAs) like Let's Encrypt, DigiCert, or Sectigo now include the required SCT (Signed Certificate Timestamp) data by default. A simple reissue usually clears the error in minutes.
Why is Chrome blocking your site?
Certificate Transparency (CT) is a security safeguard meant to stop CA-level fraud and mis-issuance. It acts as a public audit trail. Since July 2018, Google Chrome has required every public SSL certificate to be recorded in at least two or three publicly auditable logs. If Chrome can't find proof that your certificate was logged, it kills the connection to protect the user.
Your site might be triggering this for a few specific reasons:
- The CA failed to submit your certificate to the mandatory public logs.
- Your server is misconfigured and is stripping SCT data during the TLS handshake.
- The certificate is a legacy file issued before CT became a requirement.
- You are using a private or internal CA for a domain that Chrome thinks is public.
How to Fix the Error
1. Reissue the SSL Certificate
Most of the time, the certificate simply lacks the embedded SCTs. Reissuing the certificate forces your CA to generate new timestamps. If you use Let's Encrypt, you can trigger a fresh renewal with a single command:
sudo certbot renew --force-renewal
For commercial CAs like DigiCert or Namecheap, go to your dashboard and select "Reissue" or "Replace." This is usually free. Just make sure the "Certificate Transparency" option is checked if your provider offers a toggle for it.
2. Configure Policies for Internal/Private CAs
Internal domains often run into this because private CAs don't log to public servers. Chrome might mistakenly apply public requirements to your private network. To fix this on managed workstations, you need to tell Chrome to skip CT checks for specific internal URLs.
Windows (Registry Editor):
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. Create a key called CertificateTransparencyEnforcementDisabledForUrls. Then, add string values for your domains:
"1" = "internal.corp.com"
"2" = "*.dev.local"
macOS (Terminal):
defaults write com.google.Chrome CertificateTransparencyEnforcementDisabledForUrls -array "internal.corp.com" "*.dev.local"
3. Check Your Nginx or Apache Chain
Sometimes the certificate is fine, but the server isn't sending the full story to the browser. If you use OCSP Stapling, the server might be failing to pass along the SCTs. Ensure your web server points to the "full chain" file, which includes the intermediate certificates.
In Nginx, your config should look like this:
server {
listen 443 ssl;
# Use fullchain.pem, not just cert.pem
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}
Verification: Is it actually fixed?
Don't just take the browser's word for it. You can verify the SCT data manually.
Method A: Use Chrome DevTools
- Open your site and press
F12. - Navigate to the Security tab.
- Click View Certificate.
- Look for the Details tab and find the OID
1.3.6.1.4.1.11129.2.4.2. This is the technical ID for SCTs. If you see a list of timestamps here, Chrome should be happy.
Method B: Use OpenSSL
Run this command to see if your server is broadcasting the SCT list correctly:
openssl s_client -connect yourdomain.com:443 -status | grep -i "SCT"
If the output is empty, your server or certificate is still missing the required transparency data.
Bottom Line
The NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error isn't a bug; it's a security wall. For public websites, a certificate reissue is your best bet. For internal corporate tools, use Chrome policies to whitelist your domains. Never use --ignore-certificate-errors as a permanent fix, as it leaves your users vulnerable to man-in-the-middle attacks.