Break Your Own PKI: A Hands-On Lab for Hash Collisions, Weak CSRs and Revocation Failures

TL;DR: You Can Break PKI in an Afternoon With Free Tools

Yes—weak hashing, sloppy CSR flags and ignored revocation checks break real PKI, and you can reproduce all three failure modes in a local, isolated lab using OpenSSL, hashclash and deliberately misconfigured services. This is a hands-on PKI security lab tutorial: no paid tooling, no external targets, and every attack lands against infrastructure you own. If you’ve only ever used certificates, this guide teaches you how they fail.

Public trust stores assume the math and the process hold. History says otherwise. In December 2008, researchers at the Chaos Communication Congress demonstrated a rogue CA certificate signed by a real MD5-issuing CA—instantly undermining the “unforgeable” root of web trust. In 2011, the DigiNotar breach produced fraudulent Google certificates used against Iranian users, collapsing the Dutch CA entirely. Both incidents were preventable. Both are reproducible in miniature on your laptop.

Lab Setup: Your Own CA in a Sandbox

Never point these tools at third-party CAs or domains you don’t own—attack your own PKI in isolated infrastructure. Run everything inside a Docker network or a snapshotted VM. A snapshot before each attack is non-negotiable; you will break your CA, and that’s the point.

Build the hierarchy with OpenSSL’s openssl ca infrastructure:

1. Create a root CA (self-signed, 4096-bit RSA) in /pki/root with its own openssl.cnf.
2. Generate an intermediate CA signed by the root, with basicConstraints = CA:TRUE, pathlen:0.
3. Configure default_md in the intermediate’s config—you’ll flip it to md5 for Attack 1.
4. Stand up a simple TLS server (nginx or openssl s_server) presenting a leaf certificate from your intermediate.
5. Snapshot the VM or commit the Docker image state.

Everything here uses open-source tooling: OpenSSL, Marc Stevens’ hashclash (or the faster fastcoll binary it ships), curl, and Wireshark. Reference the OWASP TLS cheat sheet and CISA guidance as you harden—both map directly to the failures you’re about to build.

Attack 1: MD5 Hash Collisions Against Legacy Certificates

Why are MD5-signed certificates still dangerous? Because MD5 is collision-broken—a chosen-prefix collision lets two different CSRs produce the same signature, and a signature over one is valid for the other. The 2008 Rogue CA attack exploited exactly this: researchers submitted a benign CSR, computed a colliding evil CSR, got the benign one signed, and transferred the signature to the evil certificate—an intermediate CA whose public key they controlled.

In your lab:

1. Set default_md = md5 in your intermediate CA config.
2. Use fastcoll to generate a chosen-prefix collision pair: one prefix produces a normal end-entity CSR, the other sets basicConstraints = CA:TRUE in the embedded extensions.
3. Submit the benign CSR. Your CA signs it happily—MD5 sees two identical digests.
4. Splice the CA’s signature onto the evil certificate body. You now hold a certificate your own root will validate as an issuing CA.

Verify the horror: openssl verify -CAfile root.pem evil-ca.pem returns OK. Public CAs killed MD5 years ago—but enterprise appliances, embedded devices and internal PKI still run legacy hashing. That’s where this lab maps to real risk. Audit your internal issuers; MD5 in a 2025 certificate inventory is an incident waiting for a deadline.

Attack 2: Weak CSR Flags — Missing Basic Constraints and Key Usage

Hash collisions aren’t the only way to get illegitimate CA power. A CSR is a request—and sloppy CA software signs what it’s asked to. The critical question: does your CA enforce basicConstraints = CA:FALSE, or does it copy extensions from the CSR?

Craft the attack:

openssl req -new -key attacker.key -out evil.csr 
  -config <(cat openssl.cnf; echo -e "[v3_ext]nbasicConstraints=critical,CA:TRUEnkeyUsage=keyCertSign,cRLSign")

Point a permissive signing configuration at it—one that uses copy_extensions = copy or omits the x509_extensions directive—and the CA will mint you an end-entity certificate that chains as a CA. You can now sign your own leaf certificates, and any client that trusts your root trusts everything you sign. This is chain abuse without breaking a single hash.

The defensive takeaway is blunt: CAs must strip and re-apply all extensions server-side, enforcing CA:FALSE, constrained keyUsage and extendedKeyUsage. Never trust CSR-supplied extensions.

Attack 3: Revocation Failures — CRL Expiry, OCSP Bypass and Soft-Fail

Why do most clients silently accept revoked certificates? Because revocation is opt-out by default. Clients favor availability over security—”soft-fail” behavior—so a revoked cert with an unreachable revocation infrastructure sails through.

Three failure modes to build in your lab:

• Expired CRL: Sign a CRL with a short nextUpdate window, revoke your server cert, then let the CRL lapse. Watch clients either soft-fail past it or cache the stale list indefinitely.
• Dead OCSP responder: Configure an OCSP URL via authorityInfoAccess, then shut down openssl ocsp. Most clients treat timeout as “probably fine.”
• Soft-fail demonstration: Run curl --cacert root.pem https://revoked.local against a revoked cert with no reachable CRL/OCSP—silent success. Then compare openssl s_client behavior and tools enforcing hard-fail.

The fix stack: OCSP stapling with must-staple (the TLS Feature extension), short certificate lifetimes that make revocation nearly moot, and hard-fail policies for high-assurance environments. Test what your monitoring actually alerts on—most shops discover their CRL distribution points expired months ago, exactly once.

Attack 4: Expired and Misordered Chains

Chain hygiene failures are the quiet killers. In your lab, serve three broken configurations and observe:

• Expired intermediate: Serve an intermediate past its notAfter. Some clients reject; others accept via cached or bundled intermediates—divergence itself is the finding.
• Wrong chain order: Send leaf-then-intermediate instead of leaf-then-intermediate-then-root ordering. Strict parsers fail; lenient ones rebuild the chain. OpenSSL and browsers disagree, predictably.
• Missing intermediates: Serve the leaf alone. Desktop browsers with AIA fetching may recover; curl, Python clients and embedded devices fail hard.

Detect these before attackers do: run periodic openssl s_client -connect host:443 -showcerts sweeps, or use SSL Labs against external endpoints and certigo or scripted OpenSSL internally. Expiring intermediates should page someone ninety days out, not surprise someone during an outage.

Verification: Proving the Attacks With Client Output

Every attack needs evidence. Your verification toolkit:

• openssl s_client -connect host:443 -CAfile root.pem — inspect Verify return code; 0 is success, 23 is revoked, 10 is expired.
• curl -v --cacert root.pem https://target — watch for silent success where failure belongs.
• openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem leaf.pem for offline chain checks.
• Wireshark with the tls.handshake.type == 11 filter to inspect served certificate chains on the wire, including OCSP status in the handshake when stapling is present.

Document both failure and silent success. Silent success is the dangerous outcome—scan reports that show all-green against a broken PKI are the artifact that convinces management.

Hardening Checklist for Blue Teams

• SHA-256 or stronger for every signature—no MD5, no SHA-1, anywhere in the hierarchy.
• Enforce basicConstraints = CA:FALSE, critical keyUsage, and stripped CSR extensions at every issuing CA.
• OCSP stapling plus must-staple on high-value services; monitor responder uptime as production infrastructure.
• Short-lived certificates (90 days or less—automated, like ACME) to shrink revocation blast radius.
• Monitor CRL nextUpdate dates and OCSP responder health with the same rigor as your payment stack.
• Certificate Transparency log monitoring for every domain you own—catch rogue issuance in hours, not months.
• Quarterly chain audits: expiry, order, completeness, algorithm strength.

Mapping the Lab to CTF Challenges and Certifications

These skills transfer directly. Crypto CTF categories regularly feature hash collision primitives and X.509 parsing tricks; this lab gives you the muscle memory. OSCP/OSWE-style enumeration rewards exactly the chain-analysis habits here—reading full chains, spotting expired intermediates, noting missing SANs during recon. And in interviews, “walk me through why soft-fail revocation is a design flaw” separates practitioners from PowerPoint readers. The concepts also chain naturally into broader AI-era trust questions—see our PKI and cryptography tutorials for adjacent material.

Frequently Asked Questions

Is it legal to attack certificate authorities in a lab?

Yes—when done on your own PKI in isolated infrastructure you control. Never test third-party CAs, public trust stores, or domains you don’t own; generating colliding certificates against a real CA isn’t research, it’s a crime in most jurisdictions. Air-gap or Dockerize, snapshot, stay in your sandbox.

Can MD5 collisions still be used against modern PKI?

Public CAs purged MD5 after the 2008 Rogue CA demonstration, but internal, enterprise and embedded PKI still run legacy hashing—VPN appliances, IoT device roots, decade-old internal issuers. That’s precisely where this lab maps to real-world risk.

Why does my client accept a revoked certificate?

Soft-fail revocation checking, expired CRLs, and absent OCSP responders all cause silent acceptance—clients choose availability over security by default. Hard-fail policies, OCSP stapling with must-staple, and short-lived certs fix it.

What’s the difference between a CRL and OCSP?

A CRL is a periodic, signed full list of revoked serials; OCSP is a per-certificate real-time query. CRLs fail by staleness and expiry; OCSP fails by unreachability—each failure mode is worth lab-testing, because clients handle them differently.

Which OpenSSL flags should I check in every CSR and certificate?

basicConstraints (must be CA:FALSE, critical, on leaves), keyUsage, extendedKeyUsage, SANs (never rely on CN), the signature algorithm, and the validity window. Five fields, thirty seconds, most PKI failures caught.