CER File Documentation

Summary

A security certificate (.cer) is an X.509 digital certificate: it binds an identity — a website, server, person or software publisher — to a public key, and is signed by a Certificate Authority so software can verify it is genuine. It is the kind of certificate behind the HTTPS padlock. On Windows, double-click it to open the certificate viewer and see the issuer, validity dates and purpose. A .cer holds a public key only (safe to share), not a private key, and may be stored as binary DER or Base64 text. Its MIME type is application/x-x509-ca-cert.

Technical details

FeatureValue
Full nameX.509 public-key certificate
File extension.cer
MIME typeapplication/x-x509-ca-cert (also application/pkix-cert)
Format typeX.509 certificate — binary DER or Base64 PEM encoding
EncodingDER (binary) or PEM (Base64 text) — the extension does not say which
Data structureASN.1, DER-encoded
StandardITU-T X.509; IETF RFC 5280 (PKIX profile)
First publishedX.509, 1988
DeveloperITU-T / IETF; .cer convention common on Windows
Open standardYes
Magic number (DER)30 82 (ASN.1 SEQUENCE tag + length)
Magic text (PEM)-----BEGIN CERTIFICATE-----
ContainsSubject, issuer, public key, validity period, CA signature
Public key algorithmsRSA, ECDSA, DSA, EdDSA
Signature algorithmsSHA-256/384/512 with RSA or ECDSA
Contains private keyNo — public certificate only (unlike .pfx/.p12)
Typical usesSSL/TLS, code signing, S/MIME email, CA/root trust
RevocationCheckable via CRL or OCSP
Opens inWindows certificate viewer, macOS Keychain, OpenSSL, text editor (PEM)
Related extensions.crt, .pem, .der, .p7b, .pfx, .p12, .key
Specificationdatatracker.ietf.org/doc/html/rfc5280
File signature (magic bytes)
30 82  /  2D 2D 2D 2D 2D 42 45 47 49 4E

A .cer holds an X.509 certificate in one of two encodings, and the extension does not tell you which. DER (binary) begins at offset 0 with the ASN.1 SEQUENCE tag 30 followed by a long-form length, almost always 82 (two length bytes) — so most DER certificates start 30 82. PEM (text) begins with the ASCII line -----BEGIN CERTIFICATE----- (hex 2D…42 45 47 49 4E) followed by Base64. Open the file as text to tell them apart: PEM is readable, DER is binary. The same certificate may carry .cer, .crt, .der or .pem.

What is a CER file?

A .cer file is a public-key certificate in the X.509 standard, the backbone of trust on the internet (the Public Key Infrastructure, or PKI). A certificate binds an identity — a website domain, a server, a person, or a code-signing publisher — to a public key, and is digitally signed by a Certificate Authority (CA) so that software can verify it is genuine. When your browser shows a padlock for an HTTPS site, it has validated that site’s X.509 certificate against a set of trusted CAs. X.509 was first published by the ITU-T in 1988; the profile the internet actually uses is defined by the IETF in RFC 5280.

A .cer normally contains only the public certificate, which is safe to share, together with the CA’s signature over it. It is not a private key and not a document. This matters: a .pfx or .p12 bundles the matching private key and must be protected, but a lone .cer is public by design. The rest of this page is about what is actually inside the file and how its two encodings differ.

The X.509 certificate: three ASN.1 fields

An X.509 certificate is defined in ASN.1 (Abstract Syntax Notation One) and is, at the top level, a single SEQUENCE of exactly three parts:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,      -- the "to-be-signed" body
    signatureAlgorithm   AlgorithmIdentifier, -- how the CA signed it
    signatureValue       BIT STRING           -- the CA's signature
}

The tbsCertificate (“to be signed”) holds every meaningful field. The signatureAlgorithm names the algorithm the CA used, and signatureValue is the signature itself — computed over the DER encoding of the tbsCertificate. That last point is the whole trick of a certificate: the signature covers the body byte-for-byte, so changing any field (say, swapping in a different public key) invalidates the signature. The signatureAlgorithm field must repeat the same algorithm named inside the body, a redundancy that stops an attacker substituting a weaker algorithm.

The tbsCertificate body, field by field

The TBSCertificate is itself a SEQUENCE whose ordered fields are what the Windows or macOS certificate viewer shows you:

FieldWhat it holds
versionX.509 version; v3 (value 2) for modern certificates with extensions
serialNumberA unique integer the issuing CA assigns to this certificate
signatureThe signing algorithm identifier (must match signatureAlgorithm)
issuerThe distinguished name of the CA that signed it
validityThe notBefore and notAfter dates — the certificate’s lifetime
subjectThe identity the certificate is for (e.g. CN=example.com)
subjectPublicKeyInfoThe public key plus its algorithm (RSA, ECDSA, etc.)
extensionsv3 extensions: Subject Alternative Names, key usage, CRL/OCSP URLs

The v3 extensions carry most of the practical policy. Subject Alternative Names (SANs) list every domain the certificate covers — modern TLS validation reads the SAN list, not the legacy Common Name. Key-usage extensions restrict what the key may do (signing a TLS handshake, signing other certificates, signing email), and the Authority Information Access and CRL Distribution Point extensions carry the OCSP responder and CRL URLs a client uses to check whether the certificate has been revoked.

DER versus PEM: the same certificate, two encodings

The one real subtlety of a .cer is that the extension does not tell you how the certificate is encoded. There are two encodings, and .cer, .crt, .der and .pem are largely interchangeable labels for “a certificate” whose real difference is binary versus text.

DER (Distinguished Encoding Rules) is the strict binary serialisation of the ASN.1 structure. DER guarantees exactly one valid byte sequence for a given certificate, which is essential because the CA’s signature is computed over those exact bytes. A DER .cer starts at offset 0 with the SEQUENCE tag 0x30 and a length, so nearly all begin 30 82, and it is unreadable in a text editor.

PEM is that same DER, Base64-encoded and wrapped between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. PEM is human-readable text, easy to paste into a config file or email, and a single PEM file can hold a whole chain by concatenating several such blocks. The quickest way to tell which you have is to open the .cer in a text editor: if you see the BEGIN CERTIFICATE header it is PEM; if you see binary noise it is DER.

# inspect a certificate regardless of encoding
openssl x509 -in cert.cer -inform der  -text -noout   # binary DER
openssl x509 -in cert.cer -inform pem  -text -noout   # Base64 PEM

# convert binary DER to Base64 PEM (common for Linux web servers)
openssl x509 -inform der -in cert.cer -out cert.pem -outform pem

How a CA signature is verified

Verifying a certificate is not a matter of the file “saying” it is trustworthy; it is a chain of signatures. Your system carries a store of trusted root CA certificates. When a server presents its certificate, the client checks that the certificate’s signatureValue was produced by the private key of the issuer named in the issuer field, using the issuer’s public key. That issuer is usually an intermediate CA, whose own certificate is signed by another CA, up to a root the system already trusts. The client walks this chain, checking each signature and each validity window, and confirms the leaf certificate’s subject (via its SANs) matches the domain being visited. If any link fails to verify, is expired, or is revoked (per the CRL/OCSP data in its extensions), the connection is rejected.

This is also why a certificate can be checked and shared without secrets: everything a verifier needs is public. The private key that produced the signature stays with the CA and the server; the .cer exposes none of it.

Viewing, converting and installing a CER

On Windows, double-click a .cer to open the certificate viewer, which shows the issuer, validity dates, purpose and the full field list; Install Certificate adds it to a certificate store, and certmgr.msc manages the stores. On macOS, double-click to view and import it into Keychain Access. On Linux and everywhere else, OpenSSL is the universal tool for inspecting and converting certificates.

The common conversions all keep the same certificate and change its packaging. Converting to PEM produces the Base64 text form Apache and Nginx expect. Bundling into a PFX/PKCS#12 combines the certificate with its private key (which you must already have) into a password-protected file for Windows/IIS or Java — a .cer alone, being public-only, cannot produce a usable .pfx. Wrapping a chain without any key gives a .p7b (PKCS#7). Browsers and Adobe Acrobat also consume certificates — a browser to trust an internal CA, Acrobat to validate a signed PDF — but neither is the general way to “open” a .cer; the OS viewer and OpenSSL are.

References