OpenSSL asn1parse: How to Decode and Troubleshoot ASN.1 Data

Overview

Certificates, certificate signing requests, private keys, CRLs, and many other PKI objects are built from ASN.1 data structures. Most system administrators do not need to inspect those structures byte by byte during normal certificate management.

That changes when a certificate or request:

• opens successfully on one system but fails on another;
• produces an ASN.1 decoding error;
• contains an unfamiliar object identifier;
• has an extension that a normal certificate viewer cannot decode;
• appears to have been converted incorrectly between PEM and DER;
• is rejected by an appliance, Java application, load balancer, or security scanner;
• contains nested data that must be extracted for closer inspection.

The openssl asn1parse command is a diagnostic utility for examining the underlying ASN.1 structure of encoded data. It shows how objects are nested, where each object begins, how long it is, and which ASN.1 data type it contains.

This guide uses a practical system-administration scenario: an internal application rejects a TLS certificate with an ASN.1 parsing error even though the certificate appears normal when viewed with openssl x509.

You will use openssl asn1parse to:

1. confirm whether the file is PEM or DER;
2. parse the complete certificate structure;
3. understand the command output;
4. locate certificate extensions;
5. inspect nested extension data;
6. extract an ASN.1 object by offset;
7. identify malformed, unexpected, or proprietary data.

What is ASN.1?

ASN.1 stands for Abstract Syntax Notation One. It is a language for describing structured data independently of a particular programming language, operating system, or network protocol.

In PKI, ASN.1 is used to define structures such as:

• X.509 certificates;
• PKCS#10 certificate signing requests;
• certificate revocation lists;
• public and private keys;
• PKCS#7 and CMS messages;
• PKCS#8 private-key containers;
• PKCS#12 files;
• OCSP requests and responses.

ASN.1 describes the logical structure. Encoding rules determine how that structure is represented as bytes.

Certificates and many other PKI objects commonly use DER, or Distinguished Encoding Rules. A PEM certificate usually contains the same DER data encoded as Base64 and surrounded by header and footer lines.

For example:

-----BEGIN CERTIFICATE-----
Base64-encoded DER data
-----END CERTIFICATE-----

For a broader explanation of certificate fields and extensions, see Understanding X.509 Certificates.

What does openssl asn1parse do?

The basic syntax is:

openssl asn1parse -in file.pem

The command does not provide the same human-friendly certificate summary as:

openssl x509 -in certificate.pem -text -noout

Instead, it displays the encoded ASN.1 hierarchy.

A simplified result might resemble:

0:d=0  hl=4 l=1024 cons: SEQUENCE
4:d=1  hl=4 l= 740 cons:  SEQUENCE
8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
10:d=3 hl=2 l=   1 prim:    INTEGER           :02
13:d=2 hl=2 l=  16 prim:   INTEGER
31:d=2 hl=2 l=  13 cons:   SEQUENCE
33:d=3 hl=2 l=   9 prim:    OBJECT            :sha256WithRSAEncryption

This output is useful when you need to understand the actual encoded object rather than only its interpreted certificate fields.

The official OpenSSL asn1parse documentation describes the command as a diagnostic tool that parses ASN.1 structures and can extract data from ASN.1-formatted input.

OpenSSL version compatibility

This article covers:

• OpenSSL 3.0;
• OpenSSL 3.1;
• OpenSSL 3.2;
• OpenSSL 3.3;
• OpenSSL 3.4;
• OpenSSL 3.5 LTS;
• OpenSSL 4.0.

The principal workflow is consistent across these versions:

openssl asn1parse -in file.pem
openssl asn1parse -inform DER -in file.der
openssl asn1parse -in file.pem -i
openssl asn1parse -in file.pem -dump
openssl asn1parse -in file.pem -strparse OFFSET

There is one input-format difference worth noting.

For the greatest compatibility across OpenSSL 3.0 through 4.0, use PEM or DER explicitly.

Check your version:

openssl version

Display detailed build information:

openssl version -a

When should administrators use asn1parse?

Use openssl asn1parse when a higher-level OpenSSL command does not provide enough information.

For normal certificate inspection, start with:

openssl x509 \
  -in certificate.pem \
  -text \
  -noout

For a CSR, use:

openssl req \
  -in request.csr \
  -text \
  -noout \
  -verify

Use asn1parse when you need to:

• investigate an ASN.1 decoding error;
• find the byte offset of a specific object;
• inspect unsupported certificate extensions;
• examine the object identifiers present in a file;
• extract data from an OCTET STRING or BIT STRING;
• determine whether a file contains a valid ASN.1 sequence;
• compare the internal structure of two certificates;
• inspect an object whose exact PKI format is unknown.

The asn1parse command is normally a second-level troubleshooting tool, not the first command to run against every certificate.

Real-world troubleshooting scenario

Assume an administrator receives a certificate named:

application-server.pem

The certificate appears readable:

openssl x509 \
  -in application-server.pem \
  -subject \
  -issuer \
  -dates \
  -noout

However, an application refuses to import it and reports an error similar to:

Unable to decode ASN.1 object

Possible causes include:

• the file is not actually a certificate;
• text or binary data was added before or after the PEM object;
• the file was damaged during transfer;
• the certificate is DER but was treated as PEM;
• multiple objects were combined incorrectly;
• a certificate extension contains data the application cannot decode;
• the application does not understand a private or proprietary OID;
• the certificate uses a structure unsupported by the application.

The goal is not merely to display the certificate. The goal is to determine whether its underlying ASN.1 structure is valid and identify the object that may be causing the incompatibility.

Step 1: Identify the file type

Start by inspecting the beginning of the file:

head -n 3 application-server.pem

A PEM certificate should begin with:

-----BEGIN CERTIFICATE-----

And end with:

-----END CERTIFICATE-----

Check the end:

tail -n 3 application-server.pem

The Linux file command may provide an additional clue:

file application-server.pem

Do not rely on the filename extension alone. A file ending in .cer, .crt, or .pem may contain PEM or DER data depending on how it was created.

For more help identifying and converting certificate formats, see Convert PEM to Other Formats.

Step 2: Confirm that OpenSSL recognizes the certificate

Try the certificate-specific parser first:

openssl x509 \
  -in application-server.pem \
  -noout \
  -subject \
  -issuer \
  -serial \
  -dates

If the command succeeds, OpenSSL recognizes the file as an X.509 certificate.

To view its normal interpreted fields, run:

openssl x509 \
  -in application-server.pem \
  -text \
  -noout

The openssl x509 command is better than asn1parse for routine inspection of:

• subject and issuer;
• serial number;
• validity dates;
• public key;
• signature algorithm;
• Subject Alternative Names;
• key usage;
• extended key usage;
• basic constraints.

See How to View a Certificate with OpenSSL for a complete certificate-inspection walkthrough.

If openssl x509 fails, continue with asn1parse to determine whether the input is valid ASN.1 data but not an X.509 certificate.

Step 3: Parse the PEM certificate

Run:

openssl asn1parse \
  -in application-server.pem

The default input format is PEM.

For easier-to-read indentation, add -i:

openssl asn1parse \
  -in application-server.pem \
  -i

The output will begin with a top-level sequence similar to:

0:d=0  hl=4 l=1280 cons: SEQUENCE

An X.509 certificate is represented by a top-level ASN.1 SEQUENCE. Inside it are three major components:

Certificate
├── tbsCertificate
├── signatureAlgorithm
└── signatureValue

The tbsCertificate portion contains the certificate data that was signed, including:

• version;
• serial number;
• issuer;
• validity period;
• subject;
• subject public key;
• extensions.

If the parse operation reaches the end without an ASN.1 error, the outer encoding is at least structurally readable by OpenSSL.

Step 4: Understand asn1parse output

A typical line looks like this:

410:d=4  hl=2 l=112 cons: SEQUENCE

Each field has a specific meaning.

Offset

The first number is the object’s decimal byte offset.

For example:

410:

This is important because options such as -offset and -strparse operate on offsets.

Do not copy an offset from an online example and assume it applies to your certificate. Offsets depend on the exact contents and length of the file being inspected.

Depth

The depth appears as:

d=4

A larger number indicates deeper nesting.

The -i option visually indents the output according to this depth:

openssl asn1parse \
  -in application-server.pem \
  -i

Header length

The header length appears as:

hl=2

ASN.1 DER objects contain a tag and a length before their content. The header length tells you how many bytes were used for that metadata.

Content length

The content length appears as:

l=112

This is the length of the object’s content, not necessarily the total number of bytes occupied by the object.

The total encoded size is generally:

header length + content length

Constructed versus primitive

A constructed object is marked:

cons:

Examples include:

• SEQUENCE;
• SET;
• context-specific containers.

A primitive object is marked:

prim:

Examples include:

• INTEGER;
• OBJECT;
• UTF8STRING;
• PRINTABLESTRING;
• OCTET STRING;
• BIT STRING;
• UTCTIME;
• GENERALIZEDTIME.

Step 5: Locate the certificate serial number

Near the beginning of an X.509 certificate, you will normally find an INTEGER representing the certificate version followed by another INTEGER containing the serial number.

A simplified parse may resemble:

8:d=2  hl=2 l=3 cons:   cont [ 0 ]
10:d=3 hl=2 l=1 prim:    INTEGER           :02
13:d=2 hl=2 l=16 prim:   INTEGER           :4A1B2C3D...

The context-specific [0] object contains the X.509 version. The value 02 corresponds to version 3 because ASN.1 certificate versions are zero-based:

Compare the serial number with the higher-level command:

openssl x509 \
  -in application-server.pem \
  -serial \
  -noout

Using both commands helps map the human-readable certificate fields to their ASN.1 representation.

Step 6: Find object identifiers

ASN.1 object identifiers are displayed as OBJECT entries.

Search the parsed output:

openssl asn1parse \
  -in application-server.pem \
  -i |
grep OBJECT

Example output may include:

OBJECT :sha256WithRSAEncryption
OBJECT :countryName
OBJECT :organizationName
OBJECT :commonName
OBJECT :rsaEncryption
OBJECT :X509v3 Subject Alternative Name
OBJECT :X509v3 Key Usage
OBJECT :X509v3 Extended Key Usage

An OID identifies an algorithm, certificate attribute, extension, policy, or another defined object.

Common certificate OIDs include:

OpenSSL normally displays a friendly name for known OIDs. An unknown object may appear numerically:

OBJECT :1.3.6.1.4.1.55555.1.1

The 1.3.6.1.4.1 arc is commonly used for private enterprise OIDs. A private extension is not automatically invalid, but the consuming application may not recognize it.

Step 7: Identify an unknown certificate extension

Suppose the application vendor reports that it cannot process an extension.

Search the normal certificate output first:

openssl x509 \
  -in application-server.pem \
  -text \
  -noout

An unsupported extension may be displayed using its numerical OID:

1.3.6.1.4.1.55555.1.1:
    ...

Now search for the same OID in the ASN.1 parse:

openssl asn1parse \
  -in application-server.pem \
  -i |
grep -n -A 3 -B 2 '1.3.6.1.4.1.55555.1.1'

You may see a structure similar to:

cons: SEQUENCE
 prim:  OBJECT            :1.3.6.1.4.1.55555.1.1
 prim:  BOOLEAN           :255
 prim:  OCTET STRING

This tells you:

• which OID identifies the extension;
• whether the extension is marked critical;
• where the extension value is stored;
• the offset of its OCTET STRING.

A critical unknown extension is particularly important. An implementation performing certificate validation is generally expected to reject a certificate when it does not understand a critical extension.

Step 8: Display raw data with -dump

The -dump option displays unknown or opaque data in hexadecimal form:

openssl asn1parse \
  -in application-server.pem \
  -i \
  -dump

This can produce a large amount of output.

To limit the amount shown for each object, use -dlimit:

openssl asn1parse \
  -in application-server.pem \
  -i \
  -dlimit 32

This displays only the first 32 bytes of dumpable data.

Use -dlimit when you need enough information to identify an object but do not want hundreds or thousands of bytes printed to the terminal.

Be careful when parsing private keys or credential containers. Dumped data may expose sensitive key material or other secrets.

Step 9: Drill into an OCTET STRING with -strparse

X.509 extension values are commonly wrapped in an ASN.1 OCTET STRING. The content of that string may itself contain another encoded ASN.1 structure.

Assume the parse output shows:

612:d=5  hl=2 l=3  prim: OBJECT       :X509v3 Subject Alternative Name
617:d=5  hl=2 l=24 prim: OCTET STRING [HEX DUMP]:301682...

The exact offset will differ for every certificate.

To parse the ASN.1 data contained inside the OCTET STRING, use its offset:

openssl asn1parse \
  -in application-server.pem \
  -strparse 617 \
  -i

The nested result may resemble:

0:d=0  hl=2 l=22 cons: SEQUENCE
2:d=1  hl=2 l=20 prim:  cont [ 2 ]

Context-specific tag [2] is used for a DNS name in the GeneralName structure used by Subject Alternative Name.

To see the encoded content:

openssl asn1parse \
  -in application-server.pem \
  -strparse 617 \
  -i \
  -dump

The official documentation describes -strparse as a way to parse the content octets of an ASN.1 object at a specified offset. The option may be repeated to drill through multiple nested layers.

Step 10: Extract a nested object

The -out option writes DER-encoded data to a file and is particularly useful with -strparse.

Using the discovered offset:

openssl asn1parse \
  -in application-server.pem \
  -strparse 617 \
  -out extension.der \
  -noout

Inspect the extracted file:

file extension.der

Parse it independently:

openssl asn1parse \
  -inform DER \
  -in extension.der \
  -i \
  -dump

This is useful when you need to:

• send only the problematic extension to a vendor;
• compare the extension between two certificates;
• analyze nested data separately;
• preserve a binary sample for application testing.

Remember that extracted certificate data may still contain internal names, identifiers, account values, or other sensitive information. Review it before sharing externally.

Step 11: Parse a DER certificate

If the certificate is DER-encoded, specify the input format:

openssl asn1parse \
  -inform DER \
  -in application-server.der \
  -i

If you omit -inform DER, OpenSSL assumes PEM by default and may produce an error.

You can confirm that the DER object is an X.509 certificate with:

openssl x509 \
  -inform DER \
  -in application-server.der \
  -text \
  -noout

Convert it to PEM:

openssl x509 \
  -inform DER \
  -in application-server.der \
  -outform PEM \
  -out application-server.pem

Then verify the converted certificate:

openssl x509 \
  -in application-server.pem \
  -subject \
  -issuer \
  -serial \
  -noout

Step 12: Distinguish PEM, Base64, and DER

These formats are related but not identical.

DER

DER is binary ASN.1 data.

Parse it with:

openssl asn1parse \
  -inform DER \
  -in object.der

PEM

PEM contains Base64-encoded DER data with identifying boundaries:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Parse it with:

openssl asn1parse \
  -inform PEM \
  -in object.pem

Because PEM is the default, this is equivalent:

openssl asn1parse \
  -in object.pem

Bare Base64

A bare Base64 file contains encoded data without PEM boundaries.

OpenSSL 3.5 and OpenSSL 4.0 document B64 as an accepted -inform value:

openssl asn1parse \
  -inform B64 \
  -in object.b64

For compatibility with OpenSSL 3.0, decode the Base64 to DER first:

openssl base64 \
  -d \
  -in object.b64 \
  -out object.der

Then parse it:

openssl asn1parse \
  -inform DER \
  -in object.der

Step 13: Use -strictpem for files with extra text

By default, asn1parse may process Base64-formatted data even when normal PEM boundaries are absent.

Use -strictpem when you want OpenSSL to require and honor the PEM BEGIN and END markers:

openssl asn1parse \
  -strictpem \
  -in application-server.pem \
  -i

With -strictpem, OpenSSL ignores data before the beginning marker and after the ending marker.

This is useful when a certificate was copied from:

• an email;
• a support ticket;
• a configuration file;
• an application export;
• a diagnostic bundle containing surrounding text.

It can also help determine whether stray text around an otherwise valid PEM certificate is contributing to an import problem.

Step 14: Parse only part of a file

Use -offset to begin parsing at a particular byte offset:

openssl asn1parse \
  -inform DER \
  -in object.der \
  -offset 128

Use -length to limit the number of bytes parsed:

openssl asn1parse \
  -inform DER \
  -in object.der \
  -offset 128 \
  -length 256

These options are most helpful when:

• a file contains multiple concatenated ASN.1 objects;
• a protocol capture includes ASN.1 data after a non-ASN.1 header;
• you know where the relevant object begins;
• you want to isolate a specific binary region.

An incorrect offset may produce errors because OpenSSL begins in the middle of an object rather than at a valid ASN.1 tag.

Step 15: Compare two certificates structurally

Assume an older certificate imports successfully, but its replacement does not.

Create parse files:

openssl asn1parse \
  -in working-certificate.pem \
  -i \
  > working-asn1.txt

openssl asn1parse \
  -in rejected-certificate.pem \
  -i \
  > rejected-asn1.txt

Compare them:

diff -u \
  working-asn1.txt \
  rejected-asn1.txt

Because the certificates contain different serial numbers, dates, keys, signatures, and lengths, the output will not match exactly.

Focus on structural differences such as:

• a new extension OID;
• an extension becoming critical;
• a different public-key algorithm;
• a different signature algorithm;
• a changed string type;
• additional policy objects;
• unexpected context-specific fields.

Also compare their normal decoded output:

openssl x509 \
  -in working-certificate.pem \
  -text \
  -noout \
  > working-x509.txt

openssl x509 \
  -in rejected-certificate.pem \
  -text \
  -noout \
  > rejected-x509.txt

diff -u \
  working-x509.txt \
  rejected-x509.txt

Use openssl x509 to understand semantic certificate differences and asn1parse to investigate encoding or nesting differences.

Step 16: Add names for private OIDs

OpenSSL displays unknown OIDs numerically:

OBJECT :1.3.6.1.4.1.55555.1.1

You can provide a file that maps an OID to a short and long name.

Create:

cat > custom-oids.txt <<'EOF'
1.3.6.1.4.1.55555.1.1 appRole Internal Application Role
EOF

Then parse with:

openssl asn1parse \
  -in application-server.pem \
  -i \
  -oid custom-oids.txt

The file contains three fields:

numeric-OID shortName Long descriptive name

This does not teach OpenSSL how to decode the extension’s internal value. It only gives the OID a readable name in the parser output.

Use generic or documentation-approved values in public examples. Do not publish a private enterprise OID if its disclosure could reveal internal system or organizational information.

Step 17: Parse a CSR

A PKCS#10 CSR is also encoded with ASN.1.

Parse a PEM CSR:

openssl asn1parse \
  -in application-server.csr \
  -i

For routine CSR inspection, use:

openssl req \
  -in application-server.csr \
  -text \
  -noout \
  -verify

The higher-level command displays the subject, public key, requested extensions, and signature verification result.

Use asn1parse when you need to inspect:

• the raw subject structure;
• attribute encoding;
• extension-request attributes;
• unfamiliar requested OIDs;
• malformed or unsupported CSR data.

For CSR creation and inspection examples, see What Is a Certificate Signing Request?.

Step 18: Parse a private key safely

Private keys are also commonly encoded with ASN.1, but they require additional care.

An unencrypted PKCS#8 private key may use:

-----BEGIN PRIVATE KEY-----

A traditional RSA private key may use:

-----BEGIN RSA PRIVATE KEY-----

You can inspect the ASN.1 structure:

openssl asn1parse \
  -in private-key.pem \
  -i

However, avoid using -dump against private keys in:

• shared terminals;
• captured shell sessions;
• support tickets;
• documentation screenshots;
• centralized command logging;
• CI/CD logs.

Use the purpose-specific key command for normal validation:

openssl pkey \
  -in private-key.pem \
  -check \
  -noout

The asn1parse output may expose private key integers or other sensitive material. Never publish real private-key output.

Step 19: Generate test ASN.1 data

The -genstr option can generate a simple ASN.1 object for testing.

Create and display a UTF8 string:

openssl asn1parse \
  -genstr 'UTF8:Test value'

Write the encoded object to a DER file:

openssl asn1parse \
  -genstr 'UTF8:Test value' \
  -noout \
  -out test-value.der

Parse it again:

openssl asn1parse \
  -inform DER \
  -in test-value.der \
  -i

This feature is useful for:

• learning ASN.1 encoding;
• creating small parser test cases;
• reproducing an application issue;
• testing custom software;
• generating controlled sample objects.

For more complex generated structures, -genconf accepts an ASN.1 generation configuration file.

Create:

cat > asn1-test.cnf <<'EOF'
asn1 = SEQUENCE:test_sequence

[test_sequence]

enabled = BOOLEAN:TRUE name = UTF8:Test application number = INTEGER:42 EOF

Generate DER output:

openssl asn1parse \
  -genconf asn1-test.cnf \
  -noout \
  -out asn1-test.der

Inspect it:

openssl asn1parse \
  -inform DER \
  -in asn1-test.der \
  -i

Generated ASN.1 test objects should not be confused with complete certificates or production PKI objects.

Important asn1parse options

Common OpenSSL asn1parse errors

Error: offset out of range

Example:

Error: offset out of range

The value supplied to -offset or -strparse is beyond the available input.

Re-run the initial parse and confirm the object’s first-column offset:

openssl asn1parse \
  -in application-server.pem \
  -i

Offsets must come from the exact file being analyzed.

Error: too long

An error containing:

asn1 encoding routines
too long

can indicate:

• malformed ASN.1 length data;
• an incorrect input format;
• a damaged file;
• parsing from the wrong offset;
• attempting to parse non-ASN.1 input.

Confirm whether the file is PEM or DER and retry with the correct -inform value.

Error: header too long

This may mean OpenSSL does not see a valid ASN.1 header where parsing began.

Check:

• the input format;
• the file contents;
• the selected offset;
• whether the object is Base64, PEM, or binary DER;
• whether unrelated data precedes the ASN.1 object.

Error loading PEM file

Confirm that the file contains valid boundaries:

grep -- '-----BEGIN' application-server.pem
grep -- '-----END' application-server.pem

Use:

openssl asn1parse \
  -strictpem \
  -in application-server.pem

If the object is DER, use:

openssl asn1parse \
  -inform DER \
  -in application-server.der

The file parses but the application rejects it

A successful ASN.1 parse does not prove that:

• the object is semantically valid;
• the certificate signature is valid;
• the chain is trusted;
• the certificate is within its validity period;
• the hostname matches;
• every extension is appropriate;
• the application supports every included algorithm or extension.

Continue with certificate-specific checks:

openssl x509 \
  -in application-server.pem \
  -text \
  -noout

openssl verify \
  -CAfile ca-chain.pem \
  application-server.pem

For chain-validation examples, see OpenSSL Verify Certificate and Certificate Chain.

asn1parse versus other OpenSSL commands

Choose the command designed for the object whenever possible.

asn1parse shows the encoded structure. It generally does not explain whether a certificate is trusted, valid for a hostname, approved for server authentication, or correctly installed.

Practical troubleshooting workflow

For a rejected certificate, use this order:

1. Identify the file

file application-server.pem
head -n 2 application-server.pem

2. Use the purpose-specific parser

openssl x509 \
  -in application-server.pem \
  -text \
  -noout

3. Verify the certificate

openssl verify \
  -CAfile ca-chain.pem \
  application-server.pem

4. Parse the ASN.1 hierarchy

openssl asn1parse \
  -in application-server.pem \
  -i

5. Find extensions and algorithms

openssl asn1parse \
  -in application-server.pem \
  -i |
grep OBJECT

6. Limit opaque data output

openssl asn1parse \
  -in application-server.pem \
  -i \
  -dlimit 32

7. Drill into the suspected object

openssl asn1parse \
  -in application-server.pem \
  -strparse OFFSET \
  -i \
  -dump

8. Compare with a known working certificate

diff -u working-asn1.txt rejected-asn1.txt

This workflow moves from simple, human-readable checks to lower-level binary analysis.

Security and privacy considerations

ASN.1 output can disclose more than expected.

Before posting command output publicly, remove or replace:

• real domain names;
• internal hostnames;
• usernames;
• email addresses;
• organization names;
• internal IP addresses;
• private OIDs;
• account identifiers;
• certificate policy identifiers;
• proprietary extension values;
• serial numbers when sensitive;
• private-key material.

Use placeholders such as:

application.example.internal
Example Organization
192.0.2.10
1.3.6.1.4.1.55555.1.1

The address ranges and names used in public documentation should be examples rather than real infrastructure values.

Never publish output created by dumping an actual private key.

Frequently asked questions

What does openssl asn1parse do?

openssl asn1parse displays the structure of ASN.1-encoded data. It identifies nested sequences, object types, OIDs, lengths, and byte offsets. It can also extract and parse data contained inside another ASN.1 object.

How do I parse a certificate with openssl asn1parse?

For a PEM certificate:

openssl asn1parse \
  -in certificate.pem \
  -i

For a DER certificate:

openssl asn1parse \
  -inform DER \
  -in certificate.der \
  -i

What does d mean in asn1parse output?

The d value represents nesting depth. For example, d=3 means the object is nested three levels below the outer structure.

What does hl mean in asn1parse output?

The hl value is the ASN.1 header length. It includes the encoded tag and length information that appear before the object’s content.

What does l mean in asn1parse output?

The l value is the number of content bytes in the object. It does not include the ASN.1 header bytes.

What is the difference between -offset and -strparse?

-offset begins parsing at a selected position in the input file. -strparse parses the content stored inside the ASN.1 object located at the selected offset.

Use -strparse for nested DER data contained in objects such as OCTET STRINGs or BIT STRINGs.

Can asn1parse verify a certificate?

No. It can show the encoded structure, but it does not establish trust or perform complete certificate-path validation.

Use:

openssl verify \
  -CAfile ca-chain.pem \
  certificate.pem

Can asn1parse decode certificate extensions?

It can identify extension OIDs and expose their encoded values. The -strparse option can parse nested ASN.1 extension data. However, purpose-specific commands such as openssl x509 -text usually provide a more readable interpretation of standard extensions.

Does asn1parse work with OpenSSL 4.0?

Yes. The core command and principal options remain available in OpenSSL 4.0. Scripts intended to run across OpenSSL 3.0 through 4.0 should prefer PEM and DER because bare B64 input is not documented in the OpenSSL 3.0 command syntax.

Related OpenSSL guides

• Start with the complete OpenSSL Commands Guide.
• Learn how to view an X.509 certificate with OpenSSL.
• Understand the fields found in X.509 certificates.
• Generate and inspect a certificate signing request.
• Troubleshoot trust paths with openssl verify.
• Learn the differences between certificate formats in Convert PEM to Other Formats.
• Inspect certificates and requests with the online Mister PKI SSL Tools.

External references

• OpenSSL 3.5 asn1parse documentation
• OpenSSL 3.0 asn1parse documentation
• OpenSSL 4.0 asn1parse documentation
• OpenSSL x509 documentation
• OpenSSL req documentation

Conclusion

The openssl asn1parse command is a low-level diagnostic tool for administrators who need to look beneath the normal certificate display.

It is most valuable when:

• a certificate or CSR produces an ASN.1 error;
• an application rejects an otherwise readable certificate;
• a file’s encoding is uncertain;
• an extension contains an unfamiliar OID;
• nested ASN.1 data must be extracted;
• two certificates must be compared structurally.

Begin with a purpose-specific command such as openssl x509, openssl req, or openssl pkey. Move to openssl asn1parse when those commands do not explain the encoding, nesting, or extension-level problem.

The most useful troubleshooting sequence is:

Identify the file format
Use the object-specific OpenSSL command
Parse the full ASN.1 hierarchy
Locate the suspicious object
Drill into it with -strparse
Extract it when necessary
Compare it with a working object

That approach makes asn1parse more than an abstract ASN.1 viewer. It becomes a practical tool for diagnosing real certificate and PKI interoperability problems.