Night Class | A TLS journey - part 2
Night Class is a comic series that provides research, to a technical audience, in a fun way.
A TLS journey is a narrative driven exploration of how TLS works using the styling of a 1960’s sci-fi comic book.
This is part 2 of A TLS Journey; in which we explore how TLS certificates work.
Space is vast, beautiful, and full of signals claiming to be your friend. That pirate satellite with the skull-and-crossbones? It's pretending to be a server that it's not. You can never be 100% certain whom you've contacted in the void...but you can ask for ID.
That's where the Department of Multi-planetary Vehicles comes in. They're our public certificate authority, the folks who create cryptographic credentials we use to separate legitimate spacecraft from imposters. Think of them as the cosmic DMV, except instead of license plates, they issue mathematical proof of identity.
The DMV creates root certificates—the ultimate anchor point for everything we trust.
These certificates come with a private cryptographic key that can sign other certificates, creating a digital signature that proves "yes, the DMV vouches for this." Your ship's operating system came pre-loaded with these root certificates because the DMV has spent decades building that reputation.
Here's the thing: we trust the root because we trust the authority. It's tautological, but it works. Every device in the galaxy has the same set of trusted roots baked into their trust bundle; creating a shared foundation for verifying identities. .
The DMV doesn't sign every single certificate in the galaxy—that would be chaos. Instead, they delegate. They sign an intermediate certificate for Ziggy, Inc., the largest vehicle manufacturer ever. Ziggy gets their own signing key, deputized to create more certificates. Ziggy then signs an intermediate for manufacturing plant 42 on planet Beldar. Plant 42 signs one for vehicle MDT7779311. The vehicle creates certificates for every factory-compliant device onboard.
This creates a certificate chain: leaf device → vehicle → plant → manufacturer → DMV root. Each link vouches for the one below it. The chain represents cascading trust, with clear lines of accountability. If Plant 42's key gets compromised, you revoke just that intermediate, not the entire manufacturing division.
When my escape pod's correspondence unit connects to another ship’s correspondence unit, it doesn't just trust blindly. The other ship’s unit presents its certificate (cu-7874.MDT7779311.plant-beldar-42.ziggy.mfg.igdmv.org) along with every intermediate certificate back to the DMV root. My systems then perform cryptographic signature verification—mathematical proof that each certificate was genuinely signed by the one above it.
The validation walks up the chain: verify the device certificate with the vehicle's public key, verify the vehicle with Plant 42's public key, verify Plant 42 with Ziggy's, verify Ziggy with the DMV root that's already in my trust store. Each signature check confirms authenticity and detects tampering. No signature verification, no connection. It's mathematics enforcing trust.
When I hit the distress beacon, intergalactic roadside assistance didn't just show up and hope for the best. Roadside assistance connected to my escape pod which presented its certificate chain proving it was a legitimate Ziggy-manufactured, DMV-registered craft. They verified the chain, confirmed my identity, and cross-referenced it against their service database.
That verification unlocked two things: authentication (yes, you're really pod XK-2771) and authorization (yes, your service plan covers towing from this sector). One process proved who I was. The other determined what I could access. Both relied on that unbroken chain of cryptographic trust going back to the DMV.
Cryptographic private keys are the single point of failure for everything. If an attacker steals the DMV's root key, they can forge certificates for anyone, anywhere. If Ziggy's intermediate key leaks, thousands of ships become untrustworthy overnight. That's why keys live in Hardware Security Modules—tamper-resistant fortresses where keys never leave, operations happen inside, and only results come out.
The DMV doesn't even use their root key directly—too risky. They sign intermediates instead, keeping the root offline in a vault that requires multiple executives to access simultaneously. Ziggy does the same down the chain. Modern practice demands keys rotate regularly, certificate lifespans stay short, and every signing operation gets logged. One weak link destroys trust. Defense means assuming every layer could be compromised and building accordingly.
The pirates have tricks. They steal intermediate keys and issue fraudulent certificates that look legitimate until you check revocation status. They compromise certificate authorities and forge credentials for man-in-the-middle attacks. They exploit incomplete certificate chains—servers that forget to send the full path of intermediates, breaking validation on certain clients while working on others.
Some pirates force protocol downgrades, pushing connections to ancient SSL 3.0 where known vulnerabilities like POODLE let them decrypt traffic. Others exploit timing attacks, race conditions, or buffer overflows in TLS implementations to leak private keys from memory. The most sophisticated don't even attack the cryptography—they target the operational gaps, the expired certificates, the misconfigured trust stores, the revocation checking that soft-fails instead of hard-fails. Mathematics is perfect. Implementation is where they strike.
Can't fake the funk, can't forge the signature.
