Certificate Transparency (CT) logs don’t just passively record certificate issuance; they actively force Certificate Authorities (CAs) to make their issuance public, fundamentally altering the trust model of the web.
Imagine a CA issuing a rogue certificate for google.com. Without CT, this could happen in secret, and only a massive, widespread compromise or a targeted inspection would ever reveal it. CT logs turn this into a public broadcast. Any certificate issued by a participating CA is immediately submitted to one or more CT logs. These logs then issue a Signed Certificate Timestamp (SCT) for that certificate, proving it was seen by the log at a specific time. Browsers and other clients then demand to see these SCTs before trusting a certificate.
Here’s how it looks in practice. A CA generates a certificate for example.com.
{
"header": {
"version": "0.9",
"logId": "...",
"timestamp": 1678886400000,
"batchNumber": 1,
"index": 123456789
},
"body": {
"type": "PRECERT_CHAIN",
"details": {
"preCertificate": {
"tbsCertificate": {
"version": "v3",
"serialNumber": "...",
"signature": {
"algorithm": "sha256WithRSAEncryption"
},
"issuer": {
"country": ["US"],
"organization": ["Example CA"],
"commonName": ["Example CA Root"]
},
"validity": {
"notBefore": "2023-03-15T00:00:00Z",
"notAfter": "2024-03-15T00:00:00Z"
},
"subject": {
"organization": ["Example Inc."],
"commonName": ["example.com"]
},
"subjectPublicKeyInfo": {
"algorithm": {
"algorithm": "rsaEncryption"
},
"subjectPublicKey": "..."
},
"extensions": [
{
"extnId": "authorityKeyIdentifier",
"critical": false,
"value": "..."
},
{
"extnId": "subjectKeyIdentifier",
"critical": false,
"value": "..."
},
{
"extnId": "basicConstraints",
"critical": true,
"value": "cA: false"
},
{
"extnId": "keyUsage",
"critical": true,
"value": ["digitalSignature", "keyEncipherment"]
},
{
"extnId": "extendedKeyUsage",
"value": ["serverAuth"]
},
{
"extnId": "certificatePolicies",
"value": [
{
"policyIdentifier": "2.23.140.1.2.1",
"qualifiers": []
}
]
},
{
"extnId": "subjectAltName",
"critical": false,
"value": [
{
"type": "dNSName",
"value": "example.com"
},
{
"type": "dNSName",
"value": "www.example.com"
}
]
}
]
},
"signatureAlgorithm": {
"algorithm": "sha256WithRSAEncryption"
},
"signatureValue": "..."
},
"extraExtensions": [
{
"extnId": "preCertificatePoison",
"critical": false,
"value": "..."
}
]
}
}
}
This precertificate is then submitted to a CT log. The log processes it and returns an SCT.
{
"id": {
"keyId": "..."
},
"sct_list": [
{
"serial_number": "...",
"version": "v1",
"timestamp": 1678886400000,
"extensions": "...",
"signature": {
"algorithm": "sha256WithRSAEncryption",
"signature": "..."
}
}
]
}
The CA then embeds this SCT (or multiple SCTs from different logs) into the final certificate’s "Signed Certificate Timestamp" extension.
{
"tbsCertificate": {
// ... other fields ...
"extensions": [
// ... other extensions ...
{
"extnId": "signedCertificateTimestampList",
"critical": false,
"value": [
{
"version": "v1",
"timestamp": 1678886400000,
"extensions": "...",
"signature": {
"algorithm": "sha256WithRSAEncryption",
"signature": "..."
}
}
]
}
]
},
// ... rest of certificate ...
}
When a browser receives this certificate, it checks if the SCTs are valid, if the SCTs themselves are signed by trusted CT log operators, and if the certificate details match what the SCT claims. This creates a chain of trust not just from root CA to end-entity, but also from the public CT log to the CA.
The primary problem CT solves is undetected CA compromise or misissuance. Historically, a CA could be compromised or an insider could issue fraudulent certificates for any domain. These would then be presented to users, potentially enabling sophisticated man-in-the-middle attacks that would be extremely difficult to detect. CT logs make this impossible to hide. Every certificate issued by a participating CA is publicly logged, providing an auditable trail.
The core mechanism involves a distributed network of CT log servers, overseen by various entities. These logs are append-only and cryptographically verifiable. When a CA submits a certificate (or a precertificate), the log returns an SCT. This SCT is essentially a timestamped, signed promise from the log that it saw the certificate. The CA must then include this SCT in the final certificate. Browsers, by default, require at least one valid SCT from a trusted log to trust a certificate, and this requirement is enforced by policies like those of the CA/Browser Forum.
You control your exposure to CT through a few key levers:
- CT Log Policy: Browsers and operating systems maintain lists of trusted CT log operators. You can see these in your browser’s settings or trust store.
- Certificate Issuance: CAs are responsible for submitting certificates to logs and embedding SCTs. Your choice of CA directly impacts whether your certificates will be CT-compliant.
- Monitoring: You can monitor CT logs to detect if certificates for your domains are being issued, potentially identifying unauthorized issuance. Tools like crt.sh or specialized monitoring services query these logs.
The most surprising aspect is how CT transforms the "trust" relationship. Instead of solely relying on the CA’s internal security and auditing, CT introduces a public, external, and cryptographically enforced auditability. The assumption shifts from "CAs are secure" to "CAs must prove they are secure publicly."
The next major evolution in this space is Expect-CT headers and their eventual deprecation in favor of hard enforcement via browser policies.