SSL certificate decoder

Whether the certificate is about to go on a server or has already broken HTTPS, you need the same few answers. If a row above looks wrong, here's the fix:

In the fields underneath, we'd check that the issuer is the CA you expected and the key is the type you asked for. You'll want the serial and fingerprints when you're comparing two copies or quoting one to your CA.

Only the names in the Subject Alternative Name (SAN) list count. The common name looks like the answer, but RFC 9525 says it "MUST NOT be used to identify a service". Wildcards catch people too. One covers exactly one level of subdomain:

Want a site and its subdomains? List both example.com and *.example.com.

A server has to send its own certificate and the intermediates that link it to a root clients already hold. In TLS 1.3 the server certificate must come first, and each one after it should certify the one before.

With Certbot, this comes down to one line of nginx config. Certbot writes the server certificate alone to cert.pem and the full set to fullchain.pem, and nginx's ssl_certificate needs fullchain.pem.

Here's our own site as an example. On Nov 4, 2026, americancloud.com sent three certificates. Paste only the first and the Chain row reads: "One certificate. Its issuer, WE1, isn't here. Serve this on its own and you've left out the intermediate." Paste all three and it reads "3 certificates line up", and notes that the last one's issuer, GlobalSign Root CA, isn't there. That's fine for a root.

Paste the CSR under the certificate. If they share a public key, the certificate came from that CSR or another request using the same key.

Paste a CSR on its own and the Hostname row checks its names, so you can catch a missing one before your CA issues anything. You won't see an issuer or dates yet. Those come from the CA.

The tool won't read a private key, and you shouldn't paste one into any website. Compare it on your own machine: run this and match the result against the Public key SHA-256 row.

Public CAs follow a schedule from the CA/Browser Forum that cuts the longest certificate they can issue from 398 days to 47 by March 2029.

Private CAs aren't on this schedule: Kubernetes control plane certificates last a year by default, for example. For anything a public CA signs, renewing by hand isn't a plan at 47 days, so automate it now.

A certificate isn't encrypted, so there's nothing to decrypt. That block of text is binary data in Base64, and every server hands its certificate to anyone who connects. The secret is the private key, and it isn't in the certificate.

And "SSL" is a leftover name, this page's title included. RFC 7568 says "SSLv3 MUST NOT be used", and today these same certificates secure TLS connections.

The tool takes PEM text and PEM or DER files, not PFX. For a PFX, or if you'd rather stay in your terminal, these commands run on your own machine:

All this decoder knows is what you give it. Along the chain it compares names and key IDs, and it doesn't verify signatures. It doesn't check whether a browser trusts the root or whether the certificate was revoked, and it doesn't connect to your server. So "line up" means the chain reads correctly, not that a browser will accept it.

Next, check what's live. Run the s_client command above and paste all its output in here: now you're checking what your server really sends, not the file you think it's sending.

On an American Cloud VM, HTTPS is Certbot and nginx: our Next.js deploy guide gets a Let's Encrypt certificate, reconfigures nginx for port 443 and turns on automatic renewal. Before you request one, check that your domain points at the server with our DNS lookup. Our load balancers do SSL termination, and we don't charge egress fees on any of it. And if something still looks wrong, ask a person: our support team's median reply time is under 2 minutes.