This chapter covers certificate pinning and Certificate Transparency (CT), two critical technologies for securing TLS against CA compromise and misissuance. For SY0-701 Objective 4.7 (Security Operations), you must understand how these controls detect and prevent Man-in-the-Middle (MITM) attacks using fraudulent certificates. We will explore the mechanisms, deployment considerations, and how attackers attempt to bypass them. This knowledge is essential for the exam's scenario-based questions on certificate trust and public key infrastructure (PKI) hardening.
Jump to a section
Imagine you live in a secure apartment building. Each apartment has a unique keyed lock that only the tenant's key can open. This is like traditional TLS certificate validation: your browser trusts any certificate signed by a trusted Certificate Authority (CA). But what if a locksmith (CA) is bribed or tricked into making a duplicate key for your apartment? An attacker could then enter. Certificate pinning is like you installing a secondary lock that only accepts your specific key—ignoring any master key the locksmith might issue. You 'pin' the expected public key or certificate. Even if a rogue CA issues a valid-looking certificate for your bank, your browser rejects it because the pinned key doesn't match. Certificate Transparency (CT) is like a public registry of all keys ever issued by locksmiths. You can check the registry to see if any unauthorized duplicate keys were created. If a locksmith issues a key for your apartment without your knowledge, the log reveals it. CT does not prevent the issuance but ensures it is publicly auditable. Together, pinning provides immediate rejection of unexpected certificates, while CT provides detection of misissuance. In practice, pinning is brittle—if you lose your unique key, you're locked out. CT is more flexible: you monitor the logs for anomalies instead of hardcoding expectations.
What is Certificate Pinning?
Certificate pinning is the process of associating a host or service with an expected certificate or public key. Instead of relying solely on the chain of trust to a CA, the client (e.g., browser, mobile app) stores a copy of the server's certificate or public key hash. During TLS handshake, the client compares the server's presented certificate against the pinned value. If they don't match, the connection is aborted—even if the certificate is otherwise validly signed by a trusted CA.
Pinning can be implemented in two ways: - Hardcoded pinning: The pinned certificate or key is embedded in the application code or configuration. Used by mobile apps and browsers for critical domains. - Dynamic pinning (HPKP): HTTP Public Key Pinning (HPKP) was a header-based mechanism that allowed servers to instruct browsers to pin a public key for a specified period. HPKP is now deprecated because of the risk of permanent lockout if the pin is misconfigured. SY0-701 expects you to know HPKP existed but is not recommended.
How Certificate Pinning Works Mechanically
Step 1: The client (e.g., browser) initiates a TLS connection to a server (e.g., bank.example.com).
Step 2: The server sends its certificate chain. The client validates the chain against its trusted root store.
Step 3: The client extracts the Subject Public Key Info (SPKI) from the server's end-entity certificate. It computes a hash (e.g., SHA-256) of the SPKI.
Step 4: The client compares this hash against a list of pinned hashes for bank.example.com. If a match is found, the connection proceeds. If no match exists, the client rejects the connection with a certificate error.
Example of a pin in Chrome browser source code (preloaded pins):
{
"name": "google.com",
"pins": [
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
]
}Certificate Transparency (CT)
Certificate Transparency is an open framework for monitoring and auditing certificate issuance. It requires CAs to log every SSL/TLS certificate they issue into public, append-only logs. Anyone can inspect these logs to detect misissued or fraudulent certificates.
CT is defined in RFC 6962 (Certificate Transparency). It introduces three components: - Logs: Append-only, cryptographically assured lists of certificates. Each entry has a Signed Certificate Timestamp (SCT) that proves the certificate was submitted to the log. - Monitors: Entities that periodically query logs to check for certificates issued for domains they care about. - Auditors: Entities that verify that logs are behaving correctly (append-only, consistent).
How CT Works Mechanically
Step 1: When a CA issues a certificate for example.com, it submits the certificate to one or more CT logs.
Step 2: The log returns an SCT—a promise that the certificate will be included in the log within a certain time (Maximum Merge Delay, typically 24 hours). The SCT is embedded in the certificate (via an X.509v3 extension) or delivered via TLS extension or OCSP stapling.
Step 3: When a client connects to example.com, the server presents its certificate along with the SCT(s). The client verifies the SCT signatures against known log public keys.
Step 4: If the client requires CT (as modern browsers do for publicly trusted certificates issued after April 2018), it will reject the connection if valid SCTs are missing.
Key Components, Variants, and Standards
Public Key Pinning Extension (HPKP): RFC 7469. Deprecated by Google Chrome in 2017 due to abuse and lockout risks. Not tested in SY0-701 except as a historical note.
Static Pinning: Hardcoded in apps or browsers. Used by Google Chrome for Google domains, and by many mobile apps.
Expect-CT Header: An HTTP header that allows servers to opt into CT enforcement. Now deprecated; CT is enforced by browsers for all publicly trusted certificates.
CT Logs: Operated by Google, Cloudflare, DigiCert, Let's Encrypt, and others. Logs are publicly queryable at URLs like ct.googleapis.com/logs/.
SCT Embedding: The most common method. The CA includes the SCT as an extension in the certificate itself.
How Attackers Exploit or Defenders Deploy
Attackers target the CA trust model by obtaining fraudulent certificates through:
Compromised CA private keys (e.g., DigiNotar breach in 2011)
Rogue CAs (e.g., TrustCor scandal)
Misissuance due to lax validation (e.g., Symantec issued test certificates for google.com)
Defenders deploy:
- Pinning to hardcode expected keys for high-value domains, preventing MITM even with a rogue CA.
- CT monitoring to detect misissuance quickly. Tools like certificate-transparency.org allow domain owners to set up alerts.
Real Command/Tool Examples
Using OpenSSL to extract SPKI hash for pinning:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64Querying a CT log for certificates issued for a domain using ct tool (example):
ct search --log google.com --domain example.comChecking CT compliance of a certificate using openssl:
openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null | grep -A 10 "OCSP response"Identify Critical Domains
The first step in deploying certificate pinning is to identify which domains require pinning. Typically, these are high-value services like banking, email, or authentication portals. For SY0-701, remember that pinning is reserved for services where the risk of CA compromise outweighs the operational overhead. The security team must inventory all certificates and their public keys. They should also consider backup keys (e.g., a second pin) to avoid lockout if the primary key is rotated. This step is often documented in a certificate management policy.
Extract and Pin Public Keys
Using tools like OpenSSL, the team extracts the SPKI hash of the server's certificate. This hash is then hardcoded into the client application or browser configuration. For example, a mobile banking app might embed the hash in its source code. The pin can target the end-entity certificate or an intermediate CA certificate. Pinning to an intermediate allows key rotation without updating the app, as long as the intermediate remains the same. The team must test the pinning in a staging environment to ensure it doesn't break connectivity.
Deploy CT Log Monitoring
The organization subscribes to CT log monitoring services (e.g., Facebook's CT monitor, Google's Certificate Transparency). They configure alerts for any certificate issued for their domains. When a new certificate appears in the logs, the security team receives an email or SIEM alert. They then verify whether the certificate was legitimately requested (e.g., by their own IT team for renewal). If not, they treat it as a potential compromise and initiate incident response. This step is critical for detecting misissuance early.
Handle Pinning Failures
If a pinned certificate does not match, the client will refuse the connection. This can happen due to legitimate key rotation or misconfiguration. The security team must have a process to update pins in client applications. For mobile apps, this requires an app update. For browsers, HPKP allowed a backup pin with a different key. Since HPKP is deprecated, modern pinning relies on preloaded lists (e.g., Chrome's static pins) which are updated via browser releases. The team must ensure they have a recovery plan, such as a grace period where the old pin is still accepted alongside the new one.
Audit and Verify CT Compliance
Regularly, the team audits their certificates for CT compliance. They use tools like `ssllabs.com` or `openssl` to check that SCTs are present and valid. They also verify that their CA is submitting certificates to approved CT logs. If a certificate lacks SCTs, modern browsers will reject it. The team must ensure all certificates issued after the browser enforcement date (April 2018 for Chrome) include SCTs. This step is often part of a quarterly PKI audit.
Scenario 1: Bank Mobile App Pinning A major bank develops a mobile app for customers. To prevent MITM attacks, the app hardcodes the SHA-256 hash of the bank's TLS certificate public key. A user connects to a rogue Wi-Fi hotspot that attempts a SSLstrip+MITM attack using a fraudulent certificate issued by a compromised CA. The app's TLS library compares the server's certificate against the pinned hash. Because the fraudulent certificate has a different public key, the hash doesn't match. The app aborts the connection and displays an error: 'Cannot verify server identity.' The user is protected. A common mistake would be to pin only the root CA certificate, which would still accept any certificate from that CA, defeating the purpose.
Scenario 2: CT Monitoring Detects Misissuance A company 'example.com' uses a CT monitoring service. One day, the service alerts that a certificate for 'login.example.com' was issued by an unknown CA. The security team investigates and finds that an employee's API key for the CA was compromised. The attacker requested a certificate to intercept traffic. The team immediately revokes the certificate with the CA, blocks the issuing CA in their firewall, and rotates all API keys. They also notify the CT log operator to flag the certificate as revoked. Without CT monitoring, the fraudulent certificate would have been valid for 90 days, allowing undetected eavesdropping.
Scenario 3: Pinning Causes Outage A company pins its certificate in a mobile app. The certificate expires, and the IT team renews it with a new key pair. However, the app still has the old pin. Users cannot connect to the service. The company must issue an emergency app update to include the new pin. This highlights the risk of pinning: it is brittle. A better approach would have been to pin the intermediate CA, allowing the end-entity certificate to rotate freely. The exam may test this scenario: the best practice is to pin the intermediate CA or use a backup pin.
What SY0-701 Tests
Objective 4.7 expects you to:
Define certificate pinning and Certificate Transparency.
Explain how each protects against CA compromise and MITM.
Compare static pinning vs. CT (pinning is proactive, CT is detective).
Identify that HPKP is deprecated and not recommended.
Understand that CT requires SCTs in certificates for browser trust.
Recognize that pinning can cause availability issues if not managed carefully.
Common Wrong Answers
1. 'Certificate pinning is the same as certificate validation.' - Wrong: Certificate validation checks the chain of trust to a CA. Pinning bypasses the chain and checks a specific key. Many candidates confuse these.
2. 'CT prevents certificate issuance.' - Wrong: CT does not prevent issuance; it only logs it for auditing. Detection, not prevention.
3. 'HPKP is still recommended for web servers.' - Wrong: HPKP is deprecated. The exam expects you to know it is obsolete.
4. 'Pinning is used to ensure certificate revocation.' - Wrong: Pinning does not check revocation; it checks key match. Revocation is handled via CRL/OCSP.
Specific Terms and Values
SCT (Signed Certificate Timestamp) — proof of log inclusion.
RFC 6962 — Certificate Transparency standard.
Maximum Merge Delay (MMD) — typically 24 hours.
SPKI (Subject Public Key Info) — the data that is pinned.
SHA-256 — common hash algorithm for pins.
Trick Questions
'Which technology ensures that a certificate is publicly logged?' Answer: CT. Not pinning.
'Which technology would prevent a MITM attack using a validly issued fraudulent certificate?' Answer: Pinning (if the pin matches the legitimate certificate's key). CT would detect but not prevent.
'What is the risk of certificate pinning?' Answer: Service outage if the key changes without updating the pin.
Decision Rule
On scenario questions, ask: 'Is the goal to prevent the attack (reject bad cert) or to detect it (log for review)?' If prevent → pinning. If detect → CT. If the scenario mentions 'public log' or 'audit' → CT. If it mentions 'hardcoded key' or 'brittle' → pinning.
Certificate pinning associates a host with a specific public key or certificate, rejecting any other even if CA-valid.
HPKP (RFC 7469) is deprecated; do not use it. Modern pinning uses static preloaded pins in browsers/apps.
Certificate Transparency (RFC 6962) requires CAs to log all certificates into public, append-only logs.
SCT (Signed Certificate Timestamp) proves a certificate was submitted to a CT log.
Maximum Merge Delay (MMD) is typically 24 hours; the SCT is a promise of future inclusion.
CT is detective; pinning is preventive. Both can be used together for defense in depth.
Browsers require CT for publicly trusted certificates issued after April 2018; missing SCTs cause errors.
Pinning to an intermediate CA allows key rotation without updating clients, reducing brittleness.
Common exam scenario: attacker uses rogue CA to issue valid cert → pinning blocks, CT detects.
CT logs can be monitored with tools like Facebook's CT monitor or Google's Certificate Transparency.
These come up on the exam all the time. Here's how to tell them apart.
Certificate Pinning
Proactive: rejects mismatched certificates immediately
Brittle: can cause outages if keys change
Hardcodes expected public key or certificate
Deprecated for web (HPKP); still used in mobile apps
Does not require external infrastructure beyond client
Certificate Transparency
Detective: logs certificates for auditing
Flexible: no hardcoding, logs are public
Requires CAs to submit certificates to logs
Enforced by browsers for public certificates since 2018
Requires log servers and monitoring tools
Mistake
Certificate pinning and Certificate Transparency are the same thing.
Correct
They are complementary but different. Pinning is a proactive control that rejects unexpected certificates. CT is a detective control that logs certificate issuance for auditing. Pinning prevents MITM; CT detects misissuance.
Mistake
CT requires all certificates to be logged before issuance.
Correct
CT logs are append-only but may have a delay (Maximum Merge Delay, usually 24 hours). The SCT is a promise of inclusion, not immediate logging. The certificate can be used before it appears in the log.
Mistake
HPKP is still a recommended security header.
Correct
HPKP (HTTP Public Key Pinning) is deprecated by major browsers due to the risk of permanent lockout. It should not be used. The exam may ask about it as a historical control, but the correct answer is that it is obsolete.
Mistake
Pinning a root CA certificate is as effective as pinning the end-entity certificate.
Correct
Pinning a root CA would still accept any certificate issued by that CA, including fraudulent ones. Effective pinning targets the end-entity or intermediate certificate's public key to restrict to a specific key.
Mistake
CT logs are only for public CAs; private CAs don't need CT.
Correct
CT is primarily for publicly trusted certificates. Private/internal CAs are not required to log, but they can optionally do so for monitoring. However, browsers only enforce CT for publicly trusted certificates.
Certificate validation verifies that a certificate is signed by a trusted CA and is not expired or revoked. Pinning goes further: it checks the certificate against a specific expected key, ignoring the CA trust chain. If the certificate is valid but not pinned, validation passes but pinning fails. For the exam, remember that pinning is an additional constraint beyond standard validation.
HPKP was deprecated because it was too easy to cause a denial of service. If a server operator misconfigured the pin (e.g., pinned a key that was lost), all users would be locked out until the pin expired (which could be months). Also, attackers could use HPKP to 'pin' a victim's browser to a malicious key if they compromised the server. Modern alternatives like preloaded pins and CT are safer.
CT does not directly prevent MITM; it detects misissuance. If a CA issues a fraudulent certificate for your domain, it will appear in a CT log. You can monitor logs and revoke the certificate quickly. However, during the window between issuance and detection, an attacker could use the certificate. For prevention, combine CT with pinning.
Yes, but it is less common because internal CAs are not exposed to the same risks as public CAs. However, if your internal CA is compromised, pinning can prevent MITM. For internal use, pinning is often implemented via Group Policy or mobile device management (MDM) to distribute pins to managed devices.
An SCT (Signed Certificate Timestamp) is a cryptographic proof that a certificate has been submitted to a CT log. It is signed by the log's private key. The client (browser) verifies the SCT against known log public keys. If valid SCTs are present, the browser trusts that the certificate will be logged. Without SCTs, the browser may reject the certificate.
In Android, you can use Network Security Config to pin certificates via XML. In iOS, you can use URLSession delegate methods to evaluate server trust. For both, you embed the expected public key hash (SHA-256) in the app. Example Android XML: <domain-config> <domain includeSubdomains="true">example.com</domain> <pin-set> <pin digest="SHA-256">base64hash==</pin> </pin-set> </domain-config>
If a CT log is compromised, an attacker could issue fake SCTs for fraudulent certificates. However, CT uses multiple independent logs; browsers require SCTs from at least two logs. Compromising multiple logs simultaneously is difficult. Also, logs are auditable: monitors can detect inconsistencies. The system is designed to be resilient to single-log compromise.
You've just covered Certificate Pinning and Transparency — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?