Technical Guide to Decoding ASN.1, DER, and PKCS Formats
In the world of security and cryptography, data is rarely stored in human-readable formats like JSON or XML. Instead, it is packed into dense, binary structures following standards established decades ago. If you've ever encountered a .der, .p12, or .csr file and wondered what's inside, you've met the ASN.1 family.
This guide explains how these binary formats work and how to decode them.
1. What is ASN.1?
ASN.1 (Abstract Syntax Notation One) is a standard interface description language for defining data structures that can be serialized and deserialized in a cross-platform way. It is the "source code" for security data.
DER Encoding
While ASN.1 defines the structure, DER (Distinguished Encoding Rules) defines how that structure is turned into binary. DER is a tag-length-value (TLV) encoding, meaning every piece of data starts with a byte identifying its type (tag), followed by its length, and then the actual data.
2. Decoding Common Binary Formats
CSR (Certificate Signing Request) Decoder
A CSR contains your public key and identity information. It is usually encoded in Base64 (PEM format), but underneath, it is a DER-encoded ASN.1 structure.
- How to decode: You can use OpenSSL (
openssl req -in request.csr -noout -text) or an online CSR decoder to see the Subject, Organization, and Public Key.
PKCS#7 (P7B) Decoder
PKCS#7 is often used to distribute a chain of certificates. It usually contains the certificate and any intermediate certificates required to verify it.
- How to decode: Unlike a simple certificate, a PKCS#7 file can contain multiple objects. Decoding it reveals the "bag" of certificates inside.
PKCS#12 (P12/PFX) Decoder
PKCS#12 is a password-protected archive that can store a private key and its corresponding certificate.
- How to decode: Because it is encrypted, you must have the password. Decoding it allows you to extract the private key and certificate into separate PEM files.
3. ASN.1 and DER: The "Tree" View
When you decode a raw DER file (like an X.509 certificate), you get a tree-like structure:
- SEQUENCE: A list of items.
- OBJECT IDENTIFIER (OID): A series of numbers (like
2.5.4.3) that represent a specific field (e.g., "Common Name"). - BIT STRING / OCTET STRING: Raw binary data, often containing the public key or signature.
4. PGP and GPG Key Viewing
While PGP (Pretty Good Privacy) uses its own packet-based format (RFC 4880), it shares the same goal as X.509: binding an identity to a public key.
- PGP Key Viewer: Inspecting a PGP key reveals the user IDs, creation dates, and the subkeys used for signing and encryption.
Summary of Decoder Tools
| Format | Extension | Content Type | How to "See" Inside |
|---|---|---|---|
| X.509 | .der, .crt |
Public Cert | openssl x509 -inform der -text |
| CSR | .csr |
Signing Req | openssl req -text -noout |
| PKCS#12 | .p12, .pfx |
Cert + Private Key | openssl pkcs12 -info |
| PGP | .asc, .gpg |
PGP Key/Message | gpg --list-packets |
Conclusion
Decoding binary security formats is like solving a puzzle. Once you understand that almost everything in modern PKI is built on the foundation of ASN.1 and DER, the "random" bytes start to make sense. Whether you are using command-line tools like OpenSSL or web-based decoders, being able to inspect the raw structure of a certificate or request is an essential skill for any security-conscious developer.
Looking for a way to verify file integrity? Use our Hash Generator to compute checksums for your security files.