How to Decode SSL Certificates and Private Keys Using Base64

Every SSL/TLS certificate, private key, and certificate signing request (CSR) you encounter in DevOps work is Base64-encoded. The familiar PEM format — those files starting with -----BEGIN CERTIFICATE----- — is simply Base64-encoded DER data wrapped in header and footer lines.

Understanding how to read, decode, and inspect certificate data is a practical skill for anyone working with HTTPS servers, Kubernetes TLS secrets, load balancers, or CI/CD pipelines. This guide explains the format, what the Base64 content represents, and how to inspect it without installing OpenSSL.

The PEM Format — What That Base64 Block Actually Is

PEM (Privacy Enhanced Mail) is a container format that uses Base64 to encode binary certificate data. A typical PEM certificate looks like:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIUB6K2cCz...
(many lines of Base64)
-----END CERTIFICATE-----

The content between the header and footer is standard Base64 (with line breaks every 64 characters for readability). The underlying binary format is DER (Distinguished Encoding Rules) — a standardized binary encoding for X.509 certificates.

Other PEM types you will encounter:

• -----BEGIN PRIVATE KEY----- — PKCS#8 private key (unencrypted)
• -----BEGIN RSA PRIVATE KEY----- — PKCS#1 RSA private key
• -----BEGIN CERTIFICATE REQUEST----- — CSR (Certificate Signing Request)
• -----BEGIN PUBLIC KEY----- — Public key only
• -----BEGIN ENCRYPTED PRIVATE KEY----- — Password-protected private key

How Certificates Appear in DevOps Systems

In Kubernetes, TLS certificates stored in secrets are Base64-encoded a second time — PEM data (which is already Base64 DER) gets Base64-encoded again for the YAML format:

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...
  tls.key: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0t...

To get the original PEM certificate from a Kubernetes secret, you Base64-decode the value. You will get a PEM file. If you then strip the header/footer and Base64-decode the inner content, you get the raw binary DER certificate data.

In AWS Certificate Manager, certificates are stored as PEM and can be downloaded as PEM files. In Cloudflare, certificates in the API are returned as PEM strings in JSON fields. In Nginx and Apache configs, you point to PEM files on disk.

Sell Custom Apparel — We Handle Printing & Free Shipping

Inspecting Certificate Content — What You Can Read

If you want to verify what certificate is deployed without using OpenSSL, you can use a browser-based certificate decoder. Strip the header and footer from the PEM, take just the Base64 content (you can paste it into the free decoder to confirm it decodes without error), and then use a dedicated X.509 parser to read the human-readable fields.

What certificate metadata looks like when parsed:

• Subject — the domain or entity the certificate is issued to (e.g., CN=example.com)
• Issuer — the certificate authority (Let's Encrypt, DigiCert, etc.)
• Valid from / Valid to — the certificate's validity period
• Subject Alternative Names (SANs) — additional domains covered
• Public key algorithm — RSA 2048, RSA 4096, EC P-256, etc.
• Serial number — unique identifier assigned by the CA

To check expiry from the command line: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

JKS and PKCS#12 Files — Java Keystores

Java applications typically use JKS (Java KeyStore) or PKCS#12 (.p12 / .pfx) files instead of PEM. These are binary formats that bundle the certificate and private key together, protected by a password. They are not directly Base64-decodable in the same way PEM is.

To work with JKS or PKCS#12 files:

• Convert PKCS#12 to PEM: openssl pkcs12 -in keystore.p12 -out cert.pem -nodes
• List contents of a JKS: keytool -list -keystore keystore.jks
• Export certificate from JKS to PEM: keytool -exportcert -keystore keystore.jks -alias mykey | openssl x509 -inform DER -text

When you encounter a base64 string in an API response or configuration file that represents a JKS or PKCS#12 file, the Base64 decoding just gives you the binary keystore file — you then need the password and appropriate tools to open it.

Quick Reference — Common Certificate Operations

Task	Command or Method
Decode Kubernetes TLS secret	kubectl get secret my-secret -o jsonpath='{.data.tls\.crt}' | base64 -d
View certificate details	openssl x509 -in cert.pem -noout -text
Check expiry date	openssl x509 -in cert.pem -noout -dates
Convert DER to PEM	openssl x509 -inform DER -in cert.der -out cert.pem
Extract cert from PKCS#12	openssl pkcs12 -in bundle.p12 -nokeys -out cert.pem
Verify cert matches private key	Compare modulus: openssl x509 -modulus -noout -in cert.pem | md5sum

Frequently Asked Questions

Can I decode a private key using a Base64 decoder?

You can decode the Base64 content of a PEM private key, but the result will be binary DER data — not human-readable. To inspect a private key in human-readable form, use openssl rsa -in key.pem -text -noout. Never paste private keys into online tools.

Is it safe to paste a certificate (not a private key) into an online decoder?

Public certificates (the ones that start with BEGIN CERTIFICATE) are public by definition — your browser downloads them when visiting any HTTPS site. Pasting a certificate into a decoder is safe. However, never paste private keys into any online tool.

Why does Kubernetes double-encode certificates in Base64?

Kubernetes secret values in YAML must be Base64-encoded so binary data can be safely represented in YAML. Since PEM certificates are already Base64, the result is Base64 encoded twice. kubectl create secret --from-file handles the encoding automatically.