# Certificate pinning

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/certificate-pinning

## Quick definition

Certificate pinning is a way to prevent fake websites from tricking your device. Normally, your device trusts any certificate signed by a trusted authority. Pinning says: only trust this one specific certificate, no matter who signed it. This stops attackers from using a valid but fraudulent certificate to intercept your data.

## Simple meaning

Imagine you have a secret pen pal named Alice. You only want to write to Alice and no one else. The postal service checks that letters addressed to you come from a real mailbox, but sometimes a fake mailbox that looks just like the real one can be created. Normally, you would trust any letter that comes with an official stamp from the post office. But with certificate pinning, you decide you will only accept letters that have Alice’s specific handwriting, no matter what stamp is on the envelope. Even if someone else gets an official stamp and writes to you in a different handwriting, you know it’s not Alice and you throw the letter away.

In the digital world, certificates are like official stamps. They are issued by trusted companies called Certificate Authorities (CAs) to prove that a website is who it says it is. Normally, your device trusts any certificate that has a valid stamp from a CA. This works well most of the time. But if an attacker gets a CA to issue a fraudulent certificate for a website they don’t own, they can intercept your connection and steal your information. Certificate pinning solves this by telling your device: ignore all stamps, only trust this exact certificate that I know belongs to the real website.

For example, when you install a banking app on your phone, the app can be programmed to only accept the bank’s specific certificate. If an attacker tries to use a different certificate to impersonate the bank, the app will refuse to connect. This is like telling your phone, “Only talk to the bank if it shows you this exact ID card, and don’t accept any other ID even if it looks official.”

Certificate pinning is especially important for apps and systems that handle sensitive data, like banking, email, or corporate networks. However, it also has a downside. If the website or app needs to update its certificate for a legitimate reason, such as renewal or expiration, the pinned certificate must be updated on every device that uses it. If not updated, the app or system will not be able to connect, even to the real website. This is like changing your lock and forgetting to give the new key to your friend, they can’t get in even though they are supposed to.

## Technical definition

Certificate pinning, also known as public key pinning, is a security mechanism used in Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL). The core purpose of pinning is to associate a host (server) with an expected certificate or public key. This association is enforced by the client, such as a web browser, mobile app, or operating system, which will only establish a secure connection if the server presents a certificate that matches the pinned value. The pinning can be implemented in various ways, including hardcoding the certificate or its public key hash into the application code, using HTTP Public Key Pinning (HPKP) headers, or using Certificate Transparency (CT) logs with Expect-CT headers.

In a standard TLS handshake, the client verifies the server’s certificate by checking that it is signed by a trusted Certificate Authority (CA). This trust model is hierarchical and relies on a list of root CAs stored in the client’s trust store. The vulnerability in this model is that any CA can issue a certificate for any domain, and if a CA is compromised or coerced, it may issue fraudulent certificates. Certificate pinning addresses this by bypassing the CA trust chain for a specific server. Instead, the client directly checks that the server’s certificate matches a pre-configured pin.

There are two primary methods of pinning: certificate pinning and public key pinning. Certificate pinning involves pinning the entire certificate, including its serial number, issuer, and validity period. This is very strict because if the certificate is renewed, the pin must be updated. Public key pinning, on the other hand, pins only the public key contained within the certificate. Since a public key can remain the same across certificate renewals, this method is more flexible. The public key is hashed using a cryptographic hash function like SHA-256, and the resulting hash is stored as the pin.

HTTP Public Key Pinning (HPKP) was a standard defined in RFC 7469 that allowed web servers to instruct browsers to pin their public key for a certain period. The server would send an HPKP header in its response, containing one or more base64-encoded SHA-256 hashes of public keys. The browser would then enforce that future connections to the domain use a certificate whose public key matches one of the pinned hashes. However, HPKP was deprecated by major browsers due to the risk of permanent denial of service if a site administrator lost control of the private key or failed to update pins before certificate expiration. The deprecated status does not mean the concept is dead; it is still widely used in mobile apps and internal enterprise systems.

Modern alternatives to HPKP include Certificate Transparency (CT) and Expect-CT headers, which audit certificate issuance rather than pinning specific certificates. Also, browsers now implement a form of pinning for their own root programs, such as Chrome’s static pinning for Google domains and Firefox’s pinning for Mozilla services. In mobile app development, pinning is typically implemented in the application code using frameworks like OkHttp for Android, NSURLSession for iOS, or by embedding the server’s certificate or public key hash directly in the app’s resources.

In corporate environments, certificate pinning is often used with internal Certificate Authorities (CAs). For example, an enterprise may deploy its own CA to issue certificates for internal services. Client devices can be configured to pin the root CA certificate or the intermediate CA certificate, ensuring that only certificates from that specific CA are trusted. This provides a defense against rogue certificates issued by external CAs for internal domain names.

The implementation of pinning requires careful planning. Pins must be backed up and must have a mechanism for update. Many implementations use backup pins, which are pins for a second key pair that is stored securely offline. If the primary key is compromised or the certificate expires, the backup pin can be used to allow a seamless transition. Client applications also must handle pin validation failures gracefully, offering clear error messages and fallback mechanisms if possible.

From a security perspective, certificate pinning is a strong defense against man-in-the-middle (MITM) attacks and CA compromise. However, it introduces operational complexity. A single misconfiguration can break connectivity for all users until the app is updated. Therefore, it is most appropriate for high-security environments where the risk of a CA breach is considered unacceptable, and the organization has mature certificate lifecycle management processes.

## Real-life example

Imagine you are the manager of a very exclusive nightclub. The club has a strict rule: only people whose names are on the VIP list can enter. The door security guard has a clipboard with the names of all the VIPs. When someone shows up and claims to be a VIP, the guard checks their ID. Normally, the guard would trust any ID that looks official, a driver’s license, a passport, or a club membership card. But you are worried that someone might forge an ID using a real government template. So you take extra precautions: you tell the guard to only trust IDs that have a specific hologram that only your club’s printer can make, and to also check that the person’s face matches the photo exactly, regardless of how official the ID looks.

Now, the club has a problem. One day, the VIP list needs to be updated because a new member joins. The guard’s clipboard must be updated, but the update process is slow. While waiting, a legitimate VIP with a valid ID is turned away because the guard’s list hasn’t been updated yet. This is exactly what happens when a certificate pin is not updated on a client device. The device refuses to connect to a legitimate server because the server’s new certificate does not match the old pin.

In another scenario, a rival club owner tries to get into your club using a fake ID that looks exactly like a real one, but the hologram is slightly off. Because you have pinned the hologram, the guard catches the fake immediately. This is like a CA issuing a fraudulent certificate for a bank’s domain. Without pinning, the browser would trust the fake certificate because it was signed by a legitimate CA. With pinning, the browser rejects the fake because the certificate’s public key hash doesn’t match the pinned value.

The real world of IT is similar. A typical user’s browser trusts hundreds of root CAs. If any one of them is tricked into issuing a certificate for a high-value site like a bank, the user’s connection can be intercepted. Pinning removes the need to trust all those CAs for that one site. Instead, the user’s device trusts only the specific certificate that the bank deliberately installed. This greatly reduces the attack surface, but it also creates a dependency: every time the bank’s certificate is renewed, every user’s app must be updated, or the bank must use a pin that allows for key rotation.

## Why it matters

Certificate pinning matters because it addresses a fundamental weakness in the TLS trust model. The public key infrastructure (PKI) relies on Certificate Authorities to validate identities, but CAs can be compromised, coerced, or make mistakes. There have been well-documented incidents, such as the DigiNotar breach in 2011, where a Dutch CA was hacked and issued fraudulent certificates for Google, Yahoo, and other domains. Without pinning, those fraudulent certificates would have been trusted by all major browsers, allowing the attackers to eavesdrop on encrypted traffic.

For IT professionals and security architects, pinning provides a way to enforce a security boundary that is independent of the CA ecosystem. In enterprise environments, an organization may not fully trust every CA in the browser’s root store. By pinning internal services to a specific internal CA or to the specific certificate of the server, the organization ensures that only its own infrastructure can be used to authenticate its services. This is critical for preventing man-in-the-middle attacks from within the network, such as those performed by malicious devices on the same Wi-Fi network.

Pinning also matters for mobile app security. Mobile apps often communicate with backend APIs over HTTPS. If a user installs a rogue certificate on their device to intercept traffic, the app would normally still connect because the rogue certificate is trusted. With pinning, the app verifies that the server’s certificate matches the hardcoded pin, even if the device’s trust store has been modified. This is especially important for apps that handle financial transactions, healthcare data, or corporate credentials.

On the flip side, pinning can be a liability if not managed well. It can lead to service outages if certificates are rotated without updating pins. It also complicates the development and deployment process because any change to the server’s certificate requires an app update. This operational overhead means that pinning is not always the right choice. For many applications, relying on Certificate Transparency and strict CA validation is sufficient and more maintainable.

Ultimately, pinning is a tool in a larger security strategy. It is not a silver bullet, but it is a powerful defense when applied correctly to high-value targets. Understanding when and how to use pinning is a key skill for security professionals, system administrators, and developers.

## Why it matters in exams

Certificate pinning appears across multiple IT certification exams, especially those focused on security and cloud architecture. For the CompTIA Security+ exam, pinning is a topic under the “Secure Network Architecture” and “Identity and Access Management” domains. You may be asked to identify the purpose of pinning in a scenario where an organization wants to prevent man-in-the-middle attacks using a rogue CA. The question might describe an environment where an internal CA is used, and you need to choose the best technique to ensure that only certificates from that specific CA are trusted. Pinning is often contrasted with certificate revocation lists (CRLs) and OCSP stapling.

For the CISSP exam (ISC2 domain 3: Security Architecture and Engineering), pinning is discussed in the context of PKI and cryptographic controls. You may see questions that ask about the difference between certificate pinning and public key pinning, or the risks associated with HPKP. The CISSP exam expects you to understand the operational trade-offs: pinning increases security but reduces flexibility. You might be given a scenario where a system uses pinning and the certificate expires, causing an outage, and asked to identify the best mitigation.

For AWS Solutions Architect Associate (SAA-C03), pinning comes up in the context of API Gateway, CloudFront, and mobile app security. The exam may ask how to ensure that an API endpoint is only accessed by a legitimate mobile app, and one of the answers could involve using certificate pinning with client certificates. You need to know that AWS Certificate Manager (ACM) handles certificate rotation, and if you pin a certificate, you must update your app whenever the certificate is renewed. AWS recommends using public key pinning instead of certificate pinning for this reason.

In Microsoft exams like AZ-104 (Azure Administrator) and MS-102, pinning is less direct but appears in questions about Azure Application Gateway, Web Application Firewall (WAF), and Azure Front Door. You might need to configure end-to-end TLS with pinning for internal services. The exam could ask about scenarios where a customer wants to ensure that clients only trust the specific certificate from the organization’s internal PKI.

For CySA+ (CompTIA Cybersecurity Analyst), you may encounter questions about detecting and preventing certificate-based attacks, including man-in-the-middle attacks that use forged certificates. Pinning is one of the defensive measures you should know, along with HSTS and certificate transparency. The exam may ask which technique would most effectively prevent an attacker from using a fraudulent certificate from a compromised CA.

For SC-900 (Microsoft Security, Compliance, and Identity Fundamentals), pinning is a minor topic but may appear in questions about defense-in-depth strategies. You should understand basic concepts like how pinning prevents MITM attacks, even if you don’t need to know the technical implementation details.

In general, exam questions about certificate pinning are scenario-based. You are given a situation where an organization wants to protect a high-value connection, such as a mobile banking app or a sensitive internal API. The correct answer will involve pinning the server’s certificate or public key. Distractors might include using a wildcard certificate, enabling HSTS, or implementing OCSP. The key differentiator is that pinning removes trust in all CAs except the pinned one.

## How it appears in exam questions

Certificate pinning questions in IT certification exams typically fall into three categories: scenario-based selection, configuration choices, and troubleshooting. In scenario-based questions, the exam presents a situation where a company uses a third-party API or a mobile app that connects to a backend server. They want to ensure that even if the user’s device has a compromised certificate store, the connection remains secure. The question will ask: “Which of the following should the developer implement to ensure the app only trusts the company’s server?” The correct answer is often “Implement certificate pinning in the mobile app.”

Configuration questions might appear in Azure or AWS exams. For example, in AWS, you might be asked: “A company uses AWS API Gateway with a custom domain name. They want to ensure that client applications only trust the API Gateway certificate. What should they do?” The answer could involve using a client certificate pinned to the API stage, or configuring a custom authorizer that validates the client certificate. In Azure, a question might ask: “You have an Azure Application Gateway that terminates TLS. You need to ensure that backend servers only accept connections from the gateway. What should you configure?” The answer might be to configure certificate pinning on the backend server to only trust the Application Gateway’s certificate.

Troubleshooting questions are also common. For instance, a user reports that a mobile banking app stopped connecting to the server after an update. The server’s certificate was renewed, but the app was not updated. The question asks: “What is the most likely cause of the connection failure?” The answer is that the app has certificate pinning and the pinned certificate no longer matches the server’s new certificate. A follow-up question might ask for the solution, which would be to update the app with the new pinned certificate or implement public key pinning instead.

In Security+ and CySA+ exams, you may see questions about HPKP specifically. Even though HPKP is deprecated, it is still covered for historical understanding. A question might ask: “An organization implemented HPKP for its public website. After a major infrastructure change, users cannot access the site. What is the most likely cause?” The answer is that the new server certificate does not match the pinned public key, and the HPKP header is still active.

Another common pattern is a scenario where a company wants to allow only certain internal clients to access a sensitive service. The question might ask: “Which method should be used to ensure that only clients with a specific certificate can connect?“ This is client certificate authentication, not pinning, but the two are often confused. Pinning is about the client verifying the server; client certificates are about the server verifying the client. Exam questions will test your ability to distinguish between these concepts.

Finally, you may encounter questions that compare certificate pinning with other security controls like HSTS, TLS, and OCSP. For example, “A security analyst recommends implementing a control that prevents the use of a fraudulent certificate issued by a compromised CA. Which control would be most effective?” The answer is certificate pinning, because it does not rely on the CA hierarchy to validate the certificate.

## Example scenario

A medium-sized healthcare company, MedSecure Inc., develops a mobile app for patients to access their medical records. The app communicates with a backend API at https://api.medsecure.com. The company wants to ensure that even if a patient’s phone has a malicious root certificate installed (perhaps through a phishing attack), the app will never connect to a fake server that impersonates the real API.

The development team decides to implement certificate pinning. They obtain the SHA-256 hash of the public key from the server’s certificate for api.medsecure.com. They hardcode this hash into the mobile app’s configuration file. When the app starts a TLS connection to the server, it performs the standard certificate validation, but then it also computes the hash of the server’s public key and compares it to the hardcoded pin. If the hashes do not match, the app immediately terminates the connection and shows an error message to the user: “Unable to connect. Please contact support.”

One month later, a security researcher discovers that a small Certificate Authority used by MedSecure’s hosting provider has been compromised. The attacker obtains a valid certificate for api.medsecure.com from that CA. They set up a fake server and try to intercept patient traffic on a public Wi-Fi network. Without pinning, the patients’ devices would accept the fraudulent certificate because it is signed by a trusted CA. However, because the app has pinned the real server’s public key, the fraudulent certificate’s public key hash does not match. The app refuses to connect, and the attacker’s attempt fails.

Six months later, MedSecure renews its TLS certificate for api.medsecure.com. The new certificate uses a different key pair. The app, which still has the old public key hash, now fails to connect to the legitimate server. The company realizes its mistake: they did not implement a backup pin or a mechanism for updating the pin without a full app update. They push a critical app update with the new hash, and also decide to switch to public key pinning with a backup key for future rotations.

This scenario illustrates both the strength and the operational challenge of certificate pinning. The company successfully prevented a sophisticated MITM attack, but they also caused a temporary outage when the certificate was renewed without updating the app. In an exam, you might be asked to identify the vulnerability in this scenario or to recommend a better approach, such as using public key pinning with a backup key.

## Common mistakes

- **Mistake:** Thinking certificate pinning is the same as using a self-signed certificate.
  - Why it is wrong: A self-signed certificate is not trusted by any CA and is used to encrypt traffic without identity verification. Pinning is a technique used on top of a valid CA-issued certificate to ensure only that specific certificate is trusted. They serve different purposes.
  - Fix: Use a CA-issued certificate for your server, then pin that certificate’s public key in your client to enforce trust.
- **Mistake:** Believing that certificate pinning makes certificate revocation unnecessary.
  - Why it is wrong: Pinning does not replace revocation. A pinned certificate can still be compromised. If the private key of a pinned certificate is stolen, the attacker can use it until the pin is updated. CRL and OCSP are still needed to check revocation status.
  - Fix: Implement certificate revocation checking (OCSP stapling) even when using pinning, and have a plan to rotate pinned keys quickly.
- **Mistake:** Setting pins for every domain in an application, including less sensitive ones.
  - Why it is wrong: Pinning increases operational complexity and risk of connectivity issues. It should only be used for high-value domains. Over-pinning can lead to frequent outages and maintenance headaches.
  - Fix: Only pin certificates for critical services such as authentication endpoints, payment gateways, and APIs handling sensitive data.
- **Mistake:** Hardcoding a single certificate pin without a backup pin.
  - Why it is wrong: If the primary certificate expires or its private key is lost, the service becomes unreachable until the entire application is updated. This can cause a denial of service.
  - Fix: Always include a backup pin for an offline key pair that can be used to issue a new certificate without breaking connectivity.
- **Mistake:** Confusing certificate pinning with client certificate authentication.
  - Why it is wrong: Pinning is the client verifying the server’s certificate. Client certificate authentication is the server verifying the client’s certificate. They address different parts of the TLS handshake.
  - Fix: Use pinning for server verification. Use client certificates for mutual TLS when both sides need to authenticate.
- **Mistake:** Assuming that pinning protects against all man-in-the-middle attacks.
  - Why it is wrong: Pinning protects against MITM attacks that use fraudulent certificates from CAs. However, it does not protect against attacks that compromise the pinned server itself, nor against DNS spoofing that redirects traffic to a different server with a different certificate that may still be pinned (if the attacker controls the pinning logic).
  - Fix: Combine pinning with other controls like HSTS, DNSSEC, and strict transport security to reduce overall attack surface.

## Exam trap

{"trap":"The exam asks: “A security engineer wants to prevent an attacker from using a fraudulent certificate from a compromised CA. Which mechanism should they implement?” The options include Certificate Pinning, HSTS, OCSP Stapling, and DNSSEC. Learners often choose OCSP Stapling because it checks revocation, but the question is about preventing the use of a fraudulent certificate from a compromised CA, not revoking a known bad one.","why_learners_choose_it":"Learners think OCSP stapling checks if a certificate is revoked, and a fraudulent certificate from a compromised CA would be revoked. However, revocation is a reactive measure and relies on the CA to publish revocation info promptly. The CA may not even know it has been compromised until later, so OCSP may not catch it in time.","how_to_avoid_it":"Understand that pinning is a preventive measure that does not rely on the CA’s honesty. It trusts only the specific pinned certificate regardless of CA status. When the question asks for prevention of fraudulent certificates from a compromised CA, the proactive solution is pinning, not reactive revocation checking."}

## Commonly confused with

- **Certificate pinning vs Certificate revocation (CRL/OCSP):** Certificate revocation is a mechanism for invalidating a certificate before its expiration. Pinning is for forcing trust in only a specific certificate or public key. Revocation is reactive; pinning is proactive. They can be used together. (Example: Revocation is like a store putting a sign that says “Stop accepting this ID.” Pinning is like a bouncer who only lets in people with a specific VIP pass, ignoring all other IDs.)
- **Certificate pinning vs HSTS (HTTP Strict Transport Security):** HSTS tells browsers to only connect to a domain over HTTPS, preventing downgrade attacks. It does not verify the certificate’s identity beyond standard validation. Pinning actually validates the certificate content itself. HSTS ensures the connection is encrypted, but it does not prevent a fraudulent certificate from being used. (Example: HSTS is like a sign saying “Use the front door only.” Pinning is like checking the person’s fingerprint before letting them in.)
- **Certificate pinning vs Client certificate authentication:** Client certificate authentication is when the server asks the client to present a certificate to prove the client’s identity. Pinning is the opposite: the client checks the server’s certificate. They serve different authentication directions. (Example: Client certs are like showing your ID at the entrance; pinning is like the entrance checking the building manager’s ID to make sure you are at the right place.)
- **Certificate pinning vs Certificate Transparency (CT):** Certificate Transparency is a framework for logging all certificates issued by CAs, so that any suspicious issuance can be detected by domain owners. It does not prevent the use of a fraudulent certificate; it only makes it more likely to be discovered. Pinning actively stops the fraudulent certificate from being accepted. (Example: CT is like a public registry of all IDs issued; if a fake ID is made, you can check the registry. Pinning is like your security guard already having the only ID they will accept.)
- **Certificate pinning vs Self-signed certificates:** A self-signed certificate is not signed by any CA and is typically used for internal testing or where trust is established out-of-band. Pinning is often applied to CA-signed certificates to add an extra layer of trust. The two concepts are independent. (Example: A self-signed certificate is like a handwritten note; pinning is like verifying that note matches the only note you expect to see, even if it’s handwritten.)

## Step-by-step breakdown

1. **Client initiates TLS handshake** — The client (app or browser) sends a ClientHello message to the server, indicating it wants to establish a secure connection. The server responds with its certificate chain, which includes the server’s certificate and possibly intermediate CA certificates.
2. **Standard certificate validation** — The client performs standard TLS validation: it checks that the certificate is not expired, matches the domain name, and is signed by a trusted Certificate Authority in its trust store. If any of these checks fail, the connection is terminated. This is the baseline security check.
3. **Pinned hash extraction** — If certificate pinning is implemented, the client now extracts the pinned information from its local configuration or code. This can be a hash of the certificate’s public key, or the entire certificate itself. The client has a list of one or more pins for the target server.
4. **Compute hash from server’s certificate** — The client computes the SHA-256 hash of the server’s certificate’s public key (or the certificate itself, depending on the implementation). The same hashing algorithm used when the pin was created must be used. For example, it takes the SubjectPublicKeyInfo field of the server’s certificate and hashes it.
5. **Compare computed hash to pinned hash** — The client compares the hash computed in the previous step with the pinned value stored locally. If there is a match, the server is considered authenticated. If there is no match, the client checks if there is a backup pin. If none of the pins match, the connection is aborted.
6. **Handle pin validation failure** — If the pin does not match, the client must handle the failure. In a mobile app, this usually means the app throws a security exception and possibly logs the event. The user may see an error message like “Connection not secure.” The client should not attempt to fall back to standard validation, as that would defeat the purpose of pinning.
7. **Establish encrypted session** — If the pin matches, the TLS handshake continues. The client and server perform key exchange using ephemeral Diffie-Hellman (ECDHE) to generate session keys. All subsequent data is encrypted with those session keys. The client’s confidence is high because both the CA trust and the pin match.
8. **Maintain and update pins** — Over time, the server’s certificate will expire and be renewed. The client’s pins must be updated accordingly. For applications, this often requires an app update. For browsers using HPKP, the header directed the browser to enforce pins for a specified period (max-age). This step is critical for operational continuity.

## Practical mini-lesson

Certificate pinning in practice requires careful planning and a well-defined lifecycle. As a security professional, you need to decide when to use pinning, which method to use, and how to manage pins over time. The first decision is the scope: pinning is best suited for high-security applications where the consequence of a man-in-the-middle attack is catastrophic, such as banking, healthcare, or internal corporate communications. For general public-facing websites, the operational overhead often outweighs the benefit, and other mechanisms like HSTS and Certificate Transparency are sufficient.

Once you decide to implement pinning, you must choose between certificate pinning and public key pinning. Public key pinning is preferred because it allows the certificate to be renewed without changing the public key. If you use the same key pair, you can obtain a new certificate with the same public key, and the pin remains valid. This is easier than certificate pinning, where the entire certificate must match, including the serial number and validity period. To change the public key, you can use a backup pin: you generate a second key pair and store it securely offline. You then pin both the primary and backup public keys. When it is time to rotate, you issue a new certificate with the backup key, update the pins in your client application, and deprecate the old key.

In mobile app development, pinning is implemented at the network layer. For Android apps using OkHttp, you can use the CertificatePinner class. For iOS apps using NSURLSession, you can implement URLSessionDelegate methods to evaluate the server trust and compare the certificate’s public key hash. Both platforms allow you to embed the hash in the app’s configuration. You should never hardcode pins in plain text that can be easily decompiled; instead, obfuscate or encrypt them. Also, test your pinning implementation thoroughly: a common mistake is to implement pinning in a debug build but leave it disabled in production.

Another practical consideration is the fallback behavior. If the pin check fails, the app should not silently connect. It should provide a clear error and log the event. However, you must also consider the user experience: if the error is due to a legitimate certificate rotation that the app has not yet been updated to support, users will be locked out. To avoid this, some organizations implement a “pinning grace period” where the app checks the pin but still allows the connection if it fails, combined with a remote kill switch that can be updated via a server-side configuration. This is risky but can prevent mass outages.

For web applications, HPKP is deprecated, but you can still implement pinning using a service worker or by embedding pins in the application JavaScript. However, this is less reliable than native app pinning. Most modern browsers now rely on static pinning for their own trusted sites and on Certificate Transparency for the rest. As an IT professional, you should stay current with browser security policies because they evolve.

Finally, always monitor your pinned endpoints. Use logging and alerting to detect when a pin validation fails. This could be a sign of an attack or a misconfiguration. In enterprise environments, use a centralized PKI management tool to track certificate expiration and ensure that pins are updated before the certificate expires. Automated certificate management with tools like cert-manager in Kubernetes can help, but the pin updates still require a client update unless you use public key pinning with a stable key pair.

pinning is a powerful but demanding security control. It requires rigorous planning, backup procedures, and regular maintenance. When done correctly, it provides a strong defense against CA compromise and MITM attacks. When done poorly, it can cause widespread outages and user frustration.

## Commands

```
openssl s_client -connect example.com:443 -showcerts 2>&1 | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | head -n 30
```
Retrieves the certificate chain from a server for pinning; used to extract the public key or certificate to embed in a client application.

*Exam note: Tests understanding of how to obtain certificates for pinning, especially in CISSP and Security+ exam scenarios.*

```
openssl x509 -in cert.pem -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | base64
```
Generates the Subject Public Key Information (SPKI) fingerprint in Base64 format for pinning in mobile apps or web clients.

*Exam note: Commonly tested in CySA+ and AWS-SAA exams as the standard method to produce a pinning hash for certificate or public key pinning.*

```
certutil -store -user My 2>&1 | findstr /C:"SSL"
```
Windows command to list user certificate store entries for SSL; used to identify pinned certificates for applications like MD-102 or MS-102 managed endpoints.

*Exam note: Appears in MD-102 and MS-102 exams for managing certificate pinning in enterprise environments with Intune.*

```
netsh http add sslcert ipport=0.0.0.0:443 certhash=abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890 appid={12345678-1234-1234-1234-123456789abc}
```
Pins an SSL certificate to a specific port and application on Windows Server, used for IIS or custom server binding.

*Exam note: Tested in AZ-104 and MS-102 exams for securing Azure VMs or on-premises servers with certificate pinning in load balancer scenarios.*

```
curl --pinnedpubkey 'sha256//AbCdEfGhIjKlMnOpQrStUvWxYz1234567890AbCdEfGhIjKlMnOpQrStUvWxYz' https://example.com
```
Uses curl with a pinned public key hash to validate the server certificate against the expected key, failing if mismatch occurs.

*Exam note: Appears in AWS-SAA and Security+ exams as a client-side method to enforce certificate pinning in CI/CD or automated testing.*

```
okhttp3.CertificatePinner certificatePinner = new okhttp3.CertificatePinner.Builder() .add("example.com", "sha256/AbCdEfGhIjKlMnOpQrStUvWxYz1234567890AbCdEfGhIjKlMnOpQrStUvWxYz==") .build();
```
Android/Java code snippet to configure certificate pinning in an OkHttp client for mobile or backend applications.

*Exam note: Frequently referenced in CySA+ and CISSP exams for mobile security controls and developer implementation of certificate pinning.*

```
openssl s_client -connect example.com:443 -servername example.com 2>&1 | openssl x509 -noout -fingerprint -sha256
```
Retrieves the SHA-256 fingerprint of the server certificate, useful for comparing against a pinned fingerprint in configuration files.

*Exam note: Exams like Security+ and SC-900 test this command as a troubleshooting step for mismatched certificate pins.*

## Troubleshooting clues

- **Certificate pinning fails after server certificate renewal** — symptom: Application or client fails to connect to server with SSL/TLS errors, even though certificate is valid and trusted by root CA.. The pinned certificate hash or public key in the client code matches the old certificate; after renewal, the new certificate has a different public key or hash, causing pin validation to fail. (Exam clue: Exam questions often describe a scenario where a security update breaks connectivity due to certificate pinning, testing the need to update pinned hashes in client configurations.)
- **Misconfigured intermediate CA certificate pinning** — symptom: Client connects to some servers but not others using the same domain; error 'certificate pinning failure' only on specific endpoints.. Intermediate certificates may differ between load-balanced servers or CDN nodes; pinning to an intermediate that is not consistent across all endpoints causes intermittent failures. (Exam clue: Tested in AWS-SAA and AZ-104 exams where multiple backend servers or TLS termination points (e.g., ELB, Application Gateway) use different intermediate CAs.)
- **Pinning to leaf certificate instead of public key** — symptom: After certificate renewal, all clients fail to connect with 'pinning mismatch' errors immediately.. Leaf certificate changes on renewal (even with same key) can break pinning if the fingerprint includes the entire certificate; pinning to the public key avoids this if the key remains unchanged. (Exam clue: CISSP and Security+ exams emphasize the difference between certificate pinning (fragile) and public key pinning (more robust).)
- **HPKP (HTTP Public Key Pinning) header not honored by modern browsers** — symptom: Legacy HPKP headers are ignored; clients connect without error despite mismatched pins.. HPKP was deprecated by major browsers (Chrome, Firefox) starting 2018-2020; modern security ignores the header, so pinning via HPKP is ineffective. (Exam clue: CySA+ and SC-900 exams test awareness of deprecated security mechanisms and recommend modern alternatives like Expect-CT or certificate pinning at the application layer.)
- **Certificate pinning in mobile app fails after app update** — symptom: Old version of mobile app works; updated version fails to connect to backend even though backend certificate is unchanged.. Developers changed the pinned hash or added a new pinning rule in the app update, but the backend certificate does not match the new hash, often due to a mis-synchronized rollout. (Exam clue: Common scenario in MS-102 and MD-102 exams for Intune-managed app deployments where certificate pinning policies must be tested pre-release.)
- **Pinning to an expired certificate** — symptom: Client shows 'certificate expired' error even though the server presents a valid, unexpired certificate.. The pinning configuration includes a hash of an older, expired certificate, and the client checks both the pin and certificate validity; the server's valid certificate does not match the expired pin hash. (Exam clue: Security+ and CISSP exams test the importance of updating pinned hashes alongside certificate lifecycle management.)
- **Pinning fails due to SNI (Server Name Indication) mismatch** — symptom: Client connecting to a domain with multiple virtual hosts gets a certificate pinning error, but domain resolves correctly.. The server may present a default certificate (not matching the requested SNI hostname) causing the pinning check to fail; the client's pin is for the expected hostname's certificate. (Exam clue: Appears in AZ-104 and AWS-SAA exams for multi-tenant or shared hosting environments where SNI configuration affects certificate validation.)
- **Large pin set causing performance degradation** — symptom: Application startup or connection establishment is significantly slower after implementing certificate pinning.. Pinning multiple backup keys (e.g., 10+ hashes) increases memory and computation per connection; mobile devices may experience lag during SSL handshake. (Exam clue: CySA+ and SC-900 exams test best practices for limiting the number of pinned keys to reduce attack surface and performance overhead.)

## Memory tip

Remember “Pinning = Prevents Pseudo-PKI.” Pinning stops someone from using a fake certificate from a fraudulent CA, because you trust only the real key, not the entire CA system.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/certificate-pinning