(DC) Tongue and Cheek explanation SSL Certificates..

A hopefully non-technical (and mildly humorous) look at what SSL certificates are, what's inside them, and how to tell one from another — without letting the scary word "cryptography" or a pile of techno-jargon live rent-free in your head. Certificates are honestly pretty simple, right up until someone starts throwing acronyms at you.

Certificate Authorities (the folks who vouch for you)

There are a lot of moving gears in the certificate machine. Somewhere north of 100 companies call themselves Certificate Authorities (CAs)¹, but only a handful are the big names you'll actually run into — IdenTrust, DigiCert, Sectigo (formerly Comodo), Let's Encrypt, GoDaddy, GlobalSign. They spend their days playing leap-frog with each other and with the crooks, each trying to stay one step ahead.

Think of a CA as a bouncer with a clipboard. Their whole job is to answer one question for anyone who asks: "Is this site who it claims to be, and can I trust it?" To answer that, they verify their customers up front, then vouch for them later.

There's no single "central" certificate company running the show. Instead, there's a governing committee (the CA/Browser Forum) that CAs must join and play nice with to be considered trustworthy providers of this stuff.

Here at UT Austin, we work with a CA to issue the certificates our services need (web/SSL certs, plus a few other flavors — code signing, user certs, and so on). At the end of the day, a CA is "just" the crew running the servers that take your cryptographic paperwork (a Certificate Signing Request) and hand back a signed certificate. They'll accept that paperwork a dozen different ways — ACME, a web GUI, a REST API, carrier pigeon — but it all does the exact same thing.

What is a certificate?

A certificate is a bundle of fields and information that servers (web, app, mail, whatever) use to prove their identity and set up a secure conversation.

Here's the handshake, minus the intimidating parts:

1. You connect to a server.

2. The server hands you its certificate (the public part) like a business card.

3. Behind the scenes — you almost never see this — your client quietly checks that card against the intermediary and root CAs. ("Hey, is this legit?")

4. The verdict comes back. Either the connection gets dropped like a bad habit, or the site earns its little padlock 🔒 and you're trusted.

5. The client and server then agree on a secret handshake (decoder rings, presumably) and start talking in a code only the two of them can read.

What's inside it? (and its two roommates)

A certificate is really just data inside a file — not the file itself. And it rarely lives alone. It usually shares an apartment with two badge-wearing roommates:

• The Certificate Signing Request (CSR)

• The Private Key

The most common format for all of this is PEM, which stands for the gloriously misleading "Privacy-Enhanced Mail" (yes, it was originally an email thing). You might also hear it called PEMCO — same idea. There are other formats out there, mostly demanded by picky proprietary services: DER, PKCS#7, P7B, PKCS#12, PFX, and friends. If you ever get handed one of those and need PEM instead, there's a conversion guide for that (and hopefully you never have to go the other direction).

The tell-tale text

All of the PEM files are just text files, and the text inside the file is what matters. In PEM format, the very first and very last lines tell you exactly which roommate you're looking at:

Part	First line	Last line

Part	First line	Last line
Certificate Open	-----BEGIN CERTIFICATE-----	-----END CERTIFICATE-----
Certificate Signing Request (CSR) Open	-----BEGIN CERTIFICATE REQUEST-----	-----END CERTIFICATE REQUEST-----
Private Key Open	-----BEGIN PRIVATE KEY-----	-----END PRIVATE KEY-----

Story Time (the art gallery analogy)

Open

Picture a gallery full of wildly abstract paintings — splashes, swirls, shapes. Each painting is like a certificate, a CSR, or a private key. Just by looking at one, there's no way you can tell what it represents (a bowl of fruit? a brooding self-portrait? two blobs that might be dancing?). You need an art expert — a decoder — to read the PEM and tell you the style, period, and artist.

Open

Never trust the label on the wall. In our gallery, the filename and file extension are the label, and the label lies. A certificate could be named xt27sf7sjs.zas or carry a bogus extension like .ccc or .abc. Filenames can be anything and get renamed constantly.

Open

The good news: there are only three types of frames in this gallery — certificate, CSR, and private key. Once you spot the frame (those BEGIN/END lines above), you know which decoder to grab, and then you can ask what the painting actually represents.

Learn how to decode a certificate: (DC) Decoding Certificates / Private Keys

When something goes wrong (who do I blame?)

First rule: figure out exactly where the process is breaking. Then work the list.

1. Verify all three pieces are valid and belong together
   Decode the certificate first. Check that the fields match your FQDN, the expiration date is sane, etc.
   Does the certificate match the private key? Compare their moduli — if the fingerprints match, they're a genuine pair:

   $ openssl x509 -noout -modulus -in certificate_filename.cer | openssl md5 (stdin)= c66d5ade7c316f123ebed344506d35aa $ openssl rsa -noout -modulus -in private_key_filename.key | openssl md5 (stdin)= c66d5ade7c316f123ebed344506d35aa

   Matching output ✅ = the key and certificate can validate each other. They're a pair.
   
   

2. Check the filenames against the service config
   Mismatched filenames masquerade as all kinds of other problems. Make sure what's on disk matches what the service expects.
   
   

3. Was the CSR signed by the right private key?
   Same modulus trick, different pair:

   $ openssl rsa -noout -modulus -in <private_key_filename> | openssl md5 (stdin)= 4506b36ccc9cff2d0f90e5c1f91e1cfd $ openssl req -noout -modulus -in <CSR_filename> | openssl md5 (stdin)= 4506b36ccc9cff2d0f90e5c1f91e1cfd

   Matching output ✅ = the private key signed that CSR.
   
   

4. Valid key and CSR, but still no certificate?
   The issuing process (ACME, web, API, whatever) may have hiccupped. There's usually an error code attached — grab it and hand it to the help desk. The cause could be anything: local problems, network connectivity, CA maintenance, or a service outage.
   
   

5. Got a certificate, but it looks wrong?

• Is it in the wrong format? Can you re-download it as PEM / PEMCO?

• If it's some oddball format your service can't stomach, use the format conversion guide to translate it.

Still stuck?

None of the above helped? Head to Digital Certificates WIKI and the associated (DC) Knowledgebase (KB).

Conclusion (what did we learn?)

Never trust a wolf in sheep's clothing — a.k.a. never let a filename or extension tell you what a file is. Names and extensions can be anything, differ wildly from system to system, and get renamed on a whim. They're at their most useful when they're descriptive and follow the pseudo-standard extensions:

• .cer / .crt — Certificate

• .csr — Certificate Signing Request

• .key / .pk — Private Key

Always dig deeper: open the file, read the first and last lines for the tell-tale BEGIN/END markers, then run it through an online or local decoder to see what it protects and when it expires.

And keep this in mind — modern certificates are less like priceless paintings and more like toilet paper: cheap, disposable, and instantly replaceable. For UT Austin staff they cost nothing, and you can generate, revoke, delete, and regenerate them in minutes. Suspect a certificate is compromised or busted? Just mint a fresh private key and CSR, submit the CSR, and voilà — new certificate.

This matters more than ever now that certificates windows is only getting shorter. Automate your renewals. The tedious, manual work of keeping certificates valid should happen on its own, with little to no babysitting from a sysadmin.

See Digital Certificates WIKI and the (DC) Knowledgebase (KB) for more.