Preventing HTTPS Certificate Forgery: Certificate Transparency and Expect-CT

The security of the HTTPS protocol relies on its certificate mechanism; if an attacker obtains a certificate identical to that of a legitimate site, the security guarantees collapse. This article discusses how to prevent HTTPS certificate forgery.

Certificate Issuance and Role

To deploy an HTTPS website, the owner must request a certificate from a CA . After verifying the applicant’s identity, the CA issues a certificate containing the site’s hostname and public key, and signs the certificate with its private key. The certificate serves two main purposes:

It allows visitors to confirm the server’s true identity, preventing man‑in‑the‑middle attacks.

It enables the client and server to use the public key (depending on the key‑exchange algorithm) to negotiate a Master Secret , which then encrypts and protects the communication.

Risks of Certificate Forgery

Forged certificates undermine the entire security model. Common causes include:

Careless or malicious CA behavior, such as issuing certificates without proper identity verification.

Profit‑driven CA practices that may issue unauthorized subordinate CA certificates.

Attackers using various techniques to impersonate domain owners and obtain fraudulent certificates.

Consequences for certificate owners include uncertainty about which CA issued a certificate, inability to detect forged certificates, and lack of browser‑side verification mechanisms.

Certificate Transparency (CT)

Google introduced Certificate Transparency as an auditing solution. CT logs record every certificate issuance, allowing:

CA operators to see all certificates they have issued and quickly detect malicious ones.

Website owners to view the full issuance history for their domains and request revocation of forged certificates.

Browser vendors to audit certificate usage and block connections that rely on malicious certificates.

CT log services use cryptographic techniques similar to blockchain—Merkle hash trees—to ensure logs are append‑only; any modification, insertion, or deletion is detectable.

Expect-CT Header

To make browsers enforce CT, Google proposed the Expect-CT HTTP Header . This header tells browsers to expect CT validation for a site and can operate in two modes:

Report‑only : If no valid CT information is found, the browser sends a report to a specified report-uri but continues the connection.

Enforce : The browser aborts the connection when CT validation fails and optionally sends a report.

Example header configurations:

Expect-CT: report-uri="<uri>", enforce, max-age=<age>

Report‑only configuration:

Expect-CT: max-age=0, report-uri="https://{$subdomain}.report-uri.com/r/d/ct/reportOnly"

Enforce configuration:

Expect-CT: enforce, max-age=30, report-uri="https://{$subdomain}.report-uri.com/r/d/ct/enforce"

When properly configured, browsers will check that the site’s certificate appears in a public CT log; if not, the connection is terminated and a report is sent. Adjusting the max-age value controls how long the enforcement state is cached.