Is your TLS certificate publicly logged so AI agents can verify it is genuine?
Checks that your HTTPS certificate is registered in public Certificate Transparency logs that prove it is not forged.
What this signal tests
Certificate Transparency is a system where every legitimate certificate authority publishes the certificates it issues to public, append-only logs. Each entry in a log returns a small receipt called an SCT, or Signed Certificate Timestamp. We look inside your TLS certificate for at least two such receipts from two different recognised logs, which is the modern baseline that browsers and trust systems require.
Why it matters for your visibility in AI
Without Certificate Transparency receipts embedded, an AI agent cannot easily confirm that your certificate was issued by a legitimate authority rather than a rogue or compromised one. AI systems that perform verified retrieval, agent-to-agent commerce, or any kind of identity-bound transaction treat missing SCTs as a reason to fall back to a less trusted handling path. In practice, every certificate issued by a public certificate authority since 2018 includes SCTs automatically, so a failure here usually indicates an old certificate, a self-signed certificate, or a private CA in use on a public-facing site. The fix is almost always to reissue the certificate from a mainstream provider, which is a low-effort change with significant trust benefits.
Pass criteria at a glance
| Criterion | Passes when |
|---|---|
| >=2 SCTs from distinct qualified CT logs. |
How we test it
When we open a TLS connection to your server, your server sends its certificate as part of the handshake. We parse that certificate and look for a specific extension that lists Certificate Transparency receipts. We count how many receipts there are and which logs issued them. We do not need to talk to the logs themselves; the receipts are signed and self-contained, so the check completes during the normal handshake.
Show technical detection method
Parse X.509 from handshake; look for extension OID 1.3.6.1.4.1.11129.2.4.2 (SCT list).
If your site fails: how to fix it
- First, check which certificate authority issued your current certificate. Run a quick check at ssllabs.com or look at the certificate details in your browser. Free providers like Let's Encrypt and ZeroSSL, and paid ones like DigiCert and Sectigo, all log to CT by default.
- If your certificate is self-signed, was issued by a private corporate CA, or comes from a small provider, replace it with one from a mainstream public CA. Let's Encrypt is free and automated through tools like Certbot or acme.sh.
- If your site sits behind a CDN like Cloudflare, Fastly, or Akamai, the CDN manages certificates for you and CT is always on. Confirm by checking which certificate is presented at your public domain.
- After reissuing, deploy the new certificate to your server, restart the web server or CDN edge, and re-run the AI Ready Test scan. CT receipts are embedded at issuance, so no separate publishing step is needed.
Quick facts
| Maturity | ESTABLISHED |
|---|---|
| Weight | medium |
| Category | Trust & Provenance |
Primary sources
Related signals
Frequently asked questions
Do I need to do anything beyond renewing my certificate?
No. Every modern public certificate authority logs to CT automatically and embeds the receipts at issuance. Simply renewing your certificate from a mainstream CA gives you compliant SCTs without any additional configuration on your end.
Will I need IT help to fix this?
Only if your certificate management is fully manual. Managed hosts, CDNs, and tools like Certbot handle reissuance with one command. If you use a load balancer or custom appliance, you may need someone with server access to install the new certificate.
What if my company uses an internal certificate authority?
Internal CAs do not log to Certificate Transparency, which is by design for private networks. For public-facing sites, you should use a publicly trusted CA. Keep your internal CA for internal services only.
How long until the change takes effect?
As soon as the new certificate is installed and the server is reloaded. There is no propagation delay because the SCTs travel inside the certificate itself. Browsers and crawlers see the change on their next connection.
Run your own scan
Run a free scan and see how your site grades across all 155 AI-readiness signals.