Mastering Certificate Inspection: A Deep Dive into Using OpenSSL to Show Certificate Details

In the intricate world of digital security, SSL/TLS certificates are the cornerstones of trust and privacy on the internet. They authenticate servers (and sometimes clients), enable encrypted communication channels, and ensure data integrity. Whether you’re a system administrator troubleshooting a connection issue, a developer integrating secure communication, a security professional conducting an audit, or simply a curious user wanting to understand the digital identities you interact with, the ability to inspect the contents of these certificates is crucial.

Enter OpenSSL – the versatile, open-source cryptography toolkit. Often referred to as the “Swiss Army knife” of cryptography, OpenSSL provides a rich set of command-line tools for generating keys, managing Certificate Signing Requests (CSRs), signing certificates, performing encryption/decryption, and, importantly for this discussion, examining certificate details.

This comprehensive guide will delve deep into using the OpenSSL command-line interface (CLI) to parse, display, and understand the wealth of information embedded within an X.509 digital certificate. We’ll cover how to obtain certificates from files or live servers and explore the various OpenSSL commands and options available for dissecting their contents, from basic subject and issuer information to complex X.509v3 extensions.

Why Inspect Certificate Details?

Before diving into the commands, let’s briefly consider why inspecting certificate details is so important:

Verification: Confirming that a certificate belongs to the entity (e.g., website domain) it claims to represent. Does the Common Name (CN) or Subject Alternative Name (SAN) match the domain you’re connecting to?
Troubleshooting: Diagnosing connection errors. Is the certificate expired? Is it issued by a trusted Certificate Authority (CA)? Does it have the correct Key Usage or Extended Key Usage attributes? Is the certificate chain complete or valid?
Security Auditing: Checking certificate properties like key length, signature algorithm (e.g., avoiding SHA-1), and the presence of necessary security extensions.
Understanding Trust: Identifying the issuing CA and potentially examining the entire certificate chain to understand the path of trust back to a root CA.
Learning: Gaining a deeper understanding of Public Key Infrastructure (PKI) and the X.509 standard by examining real-world examples.
Automation: Extracting specific certificate details for use in scripts or monitoring systems (e.g., checking expiry dates automatically).

Prerequisites: Getting OpenSSL

OpenSSL is pre-installed on most Linux and macOS systems. You can verify its installation and version by opening a terminal or command prompt and running:

bash openssl version

If it’s not installed, you can typically install it using your system’s package manager:

Debian/Ubuntu: sudo apt-get update && sudo apt-get install openssl
Fedora/CentOS/RHEL: sudo dnf install openssl or sudo yum install openssl
macOS (using Homebrew): brew install openssl (Note: macOS comes with LibreSSL, but Homebrew’s OpenSSL is often preferred for newer features. You might need to adjust your PATH or use the specific path provided by Homebrew).
Windows: OpenSSL is not included by default. You can download pre-compiled binaries from various sources (like Shining Light Productions or via package managers like Chocolatey: choco install openssl). Ensure the openssl.exe location is added to your system’s PATH environment variable.

Understanding Certificate Formats: PEM and DER

OpenSSL primarily works with two common certificate encoding formats:

PEM (Privacy-Enhanced Mail): This is the most common format. It’s a Base64 encoded representation of the binary certificate data, enclosed between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers. It’s text-based, making it easy to copy and paste or include in text files (often with .pem, .crt, .cer, or .key extensions, though the extension isn’t strictly enforced). PEM files can also contain multiple certificates (e.g., a server certificate followed by its intermediate chain) or even private keys.
DER (Distinguished Encoding Rules): This is a binary format based on ASN.1 (Abstract Syntax Notation One). It’s a more compact representation but not human-readable directly. Files typically have .der or .cer extensions.

OpenSSL commands often require you to specify the input format if it’s not the default (which is usually PEM).

The Core Command: `openssl x509`

The primary subcommand within OpenSSL for dealing specifically with X.509 certificates is x509. It can be used to display certificate information, convert between formats, sign certificates (acting as a CA), and more. For inspection, its most powerful feature is the ability to parse and print the certificate details in a human-readable format.

Basic Syntax for Displaying Details:

The most common invocation for displaying all details of a certificate stored in a PEM file is:

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

Let’s break down these options:

openssl x509: Specifies that we want to use the X.509 certificate utility.
-in certificate.pem: Specifies the input filename containing the certificate. Replace certificate.pem with the actual path to your certificate file.
-text: This is the key option. It tells OpenSSL to print out the certificate contents in a human-readable text format, decoding all the fields and extensions.
-noout: This option prevents OpenSSL from outputting the encoded (PEM or DER) version of the certificate itself. When combined with -text, it ensures only the human-readable details are printed, which is usually what you want for inspection.

If your certificate is in DER format, you need to tell OpenSSL:

bash openssl x509 -in certificate.der -inform DER -text -noout

-inform DER: Specifies that the input file (certificate.der) is DER encoded.

Obtaining Certificates for Inspection

Before you can inspect a certificate, you need to have it. Here are the common ways:

1. From a File:
If you already have the certificate saved in a file (e.g., .pem, .crt, .cer), you can directly use the openssl x509 command as shown above.

2. From a Live SSL/TLS Server:
Often, you want to inspect the certificate currently being used by a live web server, email server, or other TLS-enabled service. The openssl s_client command is used for this. It acts as a generic SSL/TLS client, initiating a connection to a server.

bash openssl s_client -connect example.com:443

This command connects to example.com on the standard HTTPS port 443. The output will include a lot of information about the SSL/TLS session negotiation, and it will print the server’s certificate in PEM format.

However, the output can be verbose. To only get the certificate and then analyze it, you can pipe the output of s_client directly into openssl x509:

bash openssl s_client -connect example.com:443 </dev/null | openssl x509 -text -noout

-connect host:port: Specifies the server hostname/IP address and port number.
</dev/null: Prevents s_client from waiting for standard input, making it exit cleanly after the handshake. On Windows, you might omit this or use alternative methods if it causes issues, though often simply closing the connection (Ctrl+C after seeing the certificate) works for interactive use before piping. A common Windows alternative is to use echo | openssl ... but this might send a newline character. The key is to get s_client to perform the handshake and output the cert.
|: The pipe symbol sends the standard output of s_client (which includes the PEM certificate) to the standard input of openssl x509.
openssl x509 -text -noout: Parses the certificate received from s_client.

Important Consideration: Server Name Indication (SNI)

Many web servers host multiple websites (and thus multiple certificates) on the same IP address. Server Name Indication (SNI) is a TLS extension that allows the client to specify the hostname it’s trying to connect to during the handshake. This allows the server to present the correct certificate.

If you don’t use SNI when connecting to such a server, you might receive a default certificate or an error. To specify the hostname for SNI using s_client, use the -servername option:

bash openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -text -noout

-servername example.com: Tells the server you are specifically requesting the certificate for example.com. Always use this when inspecting certificates on shared hosting environments or servers using SNI.

Getting the Full Certificate Chain:

Servers usually send not just their own certificate (the “end-entity” or “leaf” certificate) but also the intermediate CA certificate(s) needed to link it back to a trusted root CA. The root CA certificate itself is typically not sent by the server, as clients are expected to have it in their trust store already.

To view the entire chain sent by the server, use the -showcerts option with s_client:

bash openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

This will output all certificates presented by the server, typically starting with the end-entity certificate and followed by intermediates, each in PEM format.

To analyze a specific certificate from the chain (e.g., the intermediate), you would need to copy and paste that specific -----BEGIN CERTIFICATE-----…-----END CERTIFICATE----- block into a file or use text processing tools (awk, sed) to isolate it before piping to openssl x509 -text -noout.

For example, to view the second certificate in the chain (often the first intermediate):

bash openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null | \ awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){n++}; if(n==2){print} }' | \ openssl x509 -text -noout

This uses awk to find and print only the block belonging to the second certificate (n==2).

Decoding the Certificate Details: A Field-by-Field Breakdown

Now, let’s dive into the output generated by openssl x509 -text -noout. The structure and fields are defined by the X.509 standard.

Certificate: Data: Version: 3 (0x2) # (1) Serial Number: # (2) 0a:1b:2c:3d:4e:5f:6a:7b:8c:9d:0e:1f:2a:3b:4c:5d Signature Algorithm: sha256WithRSAEncryption # (3) Issuer: C=US, O=Let's Encrypt, CN=R3 # (4) Validity # (5) Not Before: Jan 1 00:00:00 2023 GMT Not After : Mar 31 23:59:59 2023 GMT Subject: CN=example.com # (6) Subject Public Key Info: # (7) Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:aa:bb:cc:...:xx:yy:zz Exponent: 65537 (0x10001) X509v3 extensions: # (8) X509v3 Key Usage: critical # (8a) Digital Signature, Key Encipherment X509v3 Extended Key Usage: # (8b) TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical # (8c) CA:FALSE X509v3 Subject Key Identifier: # (8d) AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01 X509v3 Authority Key Identifier: # (8e) keyid:1A:2B:3C:4D:5E:6F:7A:8B:9C:0D:1E:2F:3A:4B:5C:6D:7E:8F:9A:0B Authority Information Access: # (8f) OCSP - URI:http://r3.o.lencr.org CA Issuers - URI:http://r3.i.lencr.org/ X509v3 Subject Alternative Name: # (8g) DNS:example.com, DNS:www.example.com X509v3 Certificate Policies: # (8h) Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.44947.1.1.1 CPS: http://cps.letsencrypt.org CT Precertificate SCTs: # (8i) ... (Certificate Transparency information) ... Signature Algorithm: sha256WithRSAEncryption # (9) a1:b2:...:y8:z9 # (10) -----BEGIN CERTIFICATE----- # (Optional: Suppressed by -noout) MIIF... -----END CERTIFICATE-----

Let’s examine these fields:

Version: Indicates the X.509 version. Version 3 (0x2) is the most common, as it supports extensions (Section 8), which are critical for modern PKI. Version 1 is legacy and lacks extensions. Version 2 added issuer/subject unique identifiers but is rarely used.
Serial Number: A unique positive integer assigned by the issuing CA to this specific certificate. It’s unique within the scope of the issuing CA. Used for identification and revocation checking (e.g., in Certificate Revocation Lists – CRLs). Displayed as a hexadecimal string.
Signature Algorithm (Inner): Specifies the algorithm used by the CA to sign this certificate (e.g., sha256WithRSAEncryption, ecdsa-with-SHA256). This confirms the integrity and authenticity of the certificate’s contents, linking it to the issuer’s private key. Important for security – older algorithms like MD5 or SHA-1 are deprecated and insecure.
Issuer: Identifies the Certificate Authority (CA) that issued and signed the certificate. It’s represented as a Distinguished Name (DN), typically composed of several Relative Distinguished Names (RDNs):
- C: Country Name (2-letter code, e.g., US)
- ST: State or Province Name (e.g., California)
- L: Locality Name (e.g., City, like San Francisco)
- O: Organization Name (e.g., Let’s Encrypt, Google LLC)
- OU: Organizational Unit Name (e.g., IT Department, Engineering)
- CN: Common Name (e.g., R3, Go Daddy Secure Certificate Authority – G2) – For CA certificates, this is often the name of the CA itself.
Validity: Defines the time period during which the certificate is considered valid.
- Not Before: The date and time when the certificate becomes valid. Connections attempted before this time should fail validation.
- Not After: The date and time when the certificate expires. Connections attempted after this time must fail validation. Crucial for security – ensures keys are rotated and identities re-verified periodically. Time zone is usually GMT/UTC. System clocks must be reasonably accurate for validation.
Subject: Identifies the entity to whom the certificate is issued (the “owner” or “subject” of the certificate). Also represented as a DN, using the same RDN types as the Issuer (C, O, OU, CN, etc.).
- For server certificates (SSL/TLS), the CN historically held the primary domain name (e.g., example.com). However, the Subject Alternative Name (SAN) extension (8g) is now the standard place to list domain names and IP addresses. Browsers primarily check the SAN field. If SAN is present, the CN might be ignored or used as a fallback. Best practice is to have the primary domain in the CN and repeated in the SAN.
Subject Public Key Info: Contains the subject’s public key and the algorithm it uses.
- Public Key Algorithm: Specifies the algorithm (e.g., rsaEncryption, id-ecPublicKey for Elliptic Curve).
- RSA Public-Key / EC Public-Key: Details about the key:
  - For RSA: Key size (e.g., 2048 bit, 4096 bit) – larger is generally stronger but slower. The Modulus (the large number n in RSA) and the Public Exponent (often 65537 / 0x10001) are shown.
  - For ECC: The specific curve used (e.g., prime256v1, secp384r1) and the public point coordinates (pub).
- The actual public key data is displayed in hexadecimal format. This public key corresponds to the private key held securely by the subject.
X.509v3 Extensions: This is a critical section in v3 certificates, allowing for additional attributes and constraints. OpenSSL decodes many standard extensions. Some common and important ones include:
- (a) Key Usage (X509v3 Key Usage): Defines the cryptographic operations the public key in this certificate is permitted to perform. Often marked critical, meaning applications must understand and enforce these constraints. Examples:
  - Digital Signature: For signing data (but not certificates or CRLs).
  - Non Repudiation / Content Commitment: Similar to Digital Signature, often used for document signing.
  - Key Encipherment: For encrypting symmetric keys (e.g., during TLS key exchange with RSA).
  - Data Encipherment: For directly encrypting user data (less common in TLS).
  - Key Agreement: For key exchange protocols like Diffie-Hellman (including ECDH). Used with DH or ECC keys.
  - Certificate Sign: For signing other certificates (implies this is a CA certificate).
  - CRL Sign: For signing Certificate Revocation Lists.
  - Encipher Only, Decipher Only: Used with Key Agreement.
- (b) Extended Key Usage (X509v3 Extended Key Usage): Specifies application-specific purposes for the public key, going beyond the general cryptographic operations in Key Usage. Usually not critical. Identified by Object Identifiers (OIDs). OpenSSL often translates common OIDs into descriptive text:
  - TLS Web Server Authentication (OID: 1.3.6.1.5.5.7.3.1): The certificate can be used to authenticate a web server. Essential for HTTPS.
  - TLS Web Client Authentication (OID: 1.3.6.1.5.5.7.3.2): The certificate can be used to authenticate a client to a server (mutual TLS).
  - Code Signing (OID: 1.3.6.1.5.5.7.3.3): For signing executable code.
  - Email Protection (OID: 1.3.6.1.5.5.7.3.4): For S/MIME email security (signing, encryption).
  - Time Stamping (OID: 1.3.6.1.5.5.7.3.8): For binding a hash to a time from a trusted Time Stamping Authority.
  - OCSP Signing (OID: 1.3.6.1.5.5.7.3.9): For signing OCSP responses.
- (c) Basic Constraints (X509v3 Basic Constraints): Indicates if the certificate subject is a CA and, optionally, the maximum depth of the certification path (pathlen) that can follow this certificate. Crucial for establishing trust boundaries. Almost always marked critical.
  - CA:TRUE: This certificate belongs to a CA and can be used to issue other certificates.
  - CA:FALSE: This certificate belongs to an end-entity (like a web server) and cannot issue other certificates.
  - pathlen:N: If CA:TRUE, this limits how many non-self-issued intermediate CA certificates can be below this one in the chain. pathlen:0 means it can only sign end-entity certificates, not other CAs.
- (d) Subject Key Identifier (X509v3 Subject Key Identifier – SKI): Contains a unique identifier (usually a hash) derived from the subject’s public key. Helps distinguish between different certificates that might contain the same public key (e.g., during key rollover) and is used by the Authority Key Identifier (AKI) in certificates issued by this subject.
- (e) Authority Key Identifier (X509v3 Authority Key Identifier – AKI): Helps link a certificate to its issuer. It typically contains the Subject Key Identifier (SKI) of the issuer’s certificate. This allows clients to easily find the issuer certificate in their local store or during chain building, especially when multiple certificates might share the same Issuer DN. It may also contain the issuer’s serial number and full DN.
- (f) Authority Information Access (Authority Information Access – AIA): Provides information about how to access services related to the CA that issued the certificate. Commonly includes:
  - OCSP - URI: Specifies the URL of the Online Certificate Status Protocol responder for checking the revocation status of this certificate in real-time.
  - CA Issuers - URI: Specifies a URL where the issuer’s certificate can be downloaded. Useful for clients building the certificate chain if they don’t have the intermediate certificate locally.
- (g) Subject Alternative Name (X509v3 Subject Alternative Name – SAN): This is arguably one of the most important extensions for TLS certificates today. It allows multiple identities (domain names, IP addresses, email addresses, etc.) to be associated with a single certificate. Browsers and other TLS clients check the SAN field for identity matching. If this extension is present, the Subject CN is often ignored or used only as a fallback. Always check this field to verify all required hostnames and IPs are listed.
  - DNS:example.com, DNS:www.example.com, DNS:*.example.net (wildcard)
  - IP Address:192.168.1.1
  - email:[email protected]
  - Other types exist (URI, Directory Name, etc.).
- (h) Certificate Policies (X509v3 Certificate Policies): Specifies the policy or policies under which the certificate was issued and how it should be used. Identified by OIDs. May include pointers (CPS URIs) to a human-readable Certificate Practice Statement (CPS) document describing the CA’s issuance practices. Relevant for high-assurance certificates or specific compliance requirements.
- (i) Certificate Transparency (CT Precertificate SCTs): Contains Signed Certificate Timestamps (SCTs) from public Certificate Transparency logs. This is a mechanism to publicly log all issued TLS certificates, making it possible to detect fraudulently or mistakenly issued certificates. Browsers like Chrome often require valid SCTs for a certificate to be trusted.
- Other Extensions: Many other extensions exist (e.g., CRL Distribution Points (CDP) specifying where to download CRLs, Name Constraints, Policy Constraints, Freshest CRL, etc.). OpenSSL will attempt to decode and display any it recognizes.
Signature Algorithm (Outer): Repeats the algorithm used by the CA to sign the certificate (same as field #3). This appears just before the actual signature value.
Signature Value: The actual digital signature created by the CA’s private key over the certificate’s Data section (from Version down to Extensions). This is a block of hexadecimal data. A relying party (like your browser) uses the CA’s public key (obtained from the CA’s certificate) to verify this signature. If the verification succeeds, it confirms that the certificate hasn’t been tampered with and was genuinely issued by that CA.

Extracting Specific Information

While openssl x509 -text -noout provides a comprehensive view, sometimes you need just one specific piece of information, perhaps for scripting. openssl x509 provides options for this:

Subject: -subject
bash openssl x509 -in certificate.pem -noout -subject # Output: subject=C = US, O = Let's Encrypt, CN = R3
Issuer: -issuer
bash openssl x509 -in certificate.pem -noout -issuer # Output: issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
Serial Number: -serial
bash openssl x509 -in certificate.pem -noout -serial # Output: serial=0A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D
Validity Dates: -dates
bash openssl x509 -in certificate.pem -noout -dates # Output: # notBefore=Jan 1 00:00:00 2023 GMT # notAfter=Mar 31 23:59:59 2023 GMT
Start Date: -startdate
End Date: -enddate
bash openssl x509 -in certificate.pem -noout -enddate # Output: notAfter=Mar 31 23:59:59 2023 GMT
Subject Hash (for directory lookup): -subject_hash (useful for finding certs in OpenSSL’s cert store format)
bash openssl x509 -in certificate.pem -noout -subject_hash # Output: 1a2b3c4d (example hash)
Issuer Hash: -issuer_hash
Fingerprint (Thumbprint): -fingerprint (Defaults to SHA-1 – use SHA-256!)
bash openssl x509 -in certificate.pem -noout -fingerprint -sha256 # Output: SHA256 Fingerprint=AA:BB:CC:...:XX:YY:ZZ # You can specify other digests like -md5, -sha1, etc. SHA-256 is recommended.
A fingerprint is a short, unique hash of the entire DER-encoded certificate. Useful for quickly comparing or identifying certificates.
Email Address (from Subject): -email (Extracts the email address field if present in the Subject DN)
Purpose: -purpose (Checks certificate extensions against various purposes and reports usability)
bash openssl x509 -in server_cert.pem -noout -purpose # Output: # Certificate purposes: # SSL client : Yes # SSL client CA : No # SSL server : Yes # SSL server CA : No # Netscape SSL server : Yes # Netscape SSL server CA : No # S/MIME signing : No # S/MIME signing CA : No # S/MIME encryption : Yes # S/MIME encryption CA : No # CRL signing : No # CRL signing CA : No # Any Purpose : Yes # Any Purpose CA : Yes # OCSP helper : Yes # OCSP helper CA : No # Time Stamp signing : No # Time Stamp signing CA : No
This output interprets the Key Usage and Extended Key Usage extensions.
Public Key: -pubkey (Extracts the public key in PEM format)
bash openssl x509 -in certificate.pem -noout -pubkey # Output: # -----BEGIN PUBLIC KEY----- # MIIB... # -----END PUBLIC KEY-----

You can combine these flags, but often -text provides the most context. For scripting, the specific flags are invaluable.

Working with Certificate Chains

As mentioned, servers often provide a chain of certificates. Using openssl s_client -showcerts gives you a file containing multiple PEM-encoded certificates concatenated together. You can save this output to a file (e.g., chain.pem).

bash openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null > chain.pem

Now chain.pem might look like:

-----BEGIN CERTIFICATE----- (End-entity / Server Certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate CA Certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Optional: Another Intermediate CA Certificate) -----END CERTIFICATE-----

You can view details for all certificates in the chain file using a loop or by manually splitting the file. A simple way to view them all sequentially using openssl x509 (though formatting might be basic without splitting):

“`bash
openssl x509 -in chain.pem -text -noout

This might only process the first certificate depending on the OpenSSL version and context.

A safer approach often involves splitting or using tools that understand multi-cert PEMs.

“`

A more robust method is often to split the file into individual certificates (cert1.pem, cert2.pem, etc.) and then run openssl x509 -text -noout on each one. Tools like csplit on Linux or simple scripting can achieve this.

Alternatively, for verification purposes, the openssl verify command is designed to handle chains:

“`bash

Assuming you have root CA certs in /etc/ssl/certs or specified via -CApath / -CAfile

And chain.pem contains server cert + intermediate(s)

openssl verify -CApath /etc/ssl/certs chain.pem

Or, if you have the intermediate(s) in one file and the server cert in another:

openssl verify -CAfile root.pem -untrusted intermediate.pem server.pem
“`

While verify doesn’t show the details like x509 -text, understanding the chain structure is crucial when interpreting the Issuer and Authority Key Identifier fields you see with x509 -text. The Issuer of one certificate should match the Subject of the next certificate up the chain, and the AKI should match the SKI of the issuer.

Practical Examples and Use Cases

Let’s solidify this with some practical scenarios:

Scenario 1: Checking if a website’s certificate matches the domain and hasn’t expired.

“`bash

Get the cert from www.example.com

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
“`

-subject: Check the Common Name (fallback).
-dates: Check notAfter.
-ext subjectAltName: Directly print the SAN extension, which is the primary place to check domain names.

You would then manually inspect the output:
* Does the notAfter date indicate it’s still valid?
* Does the Subject Alternative Name section list DNS:www.example.com (and potentially DNS:example.com)?

Scenario 2: Finding the issuing CA of a certificate.

“`bash
openssl x509 -in mycert.pem -noout -issuer

Or for a live server:

openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null | openssl x509 -noout -issuer
“`

This quickly tells you who signed the certificate (e.g., CN=R3, O=Let's Encrypt, C=US).

Scenario 3: Verifying the key strength and signature algorithm.

bash openssl s_client -connect secure.example.com:443 -servername secure.example.com </dev/null | openssl x509 -text -noout | grep -E "Signature Algorithm:|Public-Key:"

Use openssl x509 -text -noout to get all details.
Pipe to grep to filter for specific lines.
Look for Signature Algorithm: (check it’s SHA-256 based, not MD5 or SHA-1).
Look for Public-Key: (check the bit size, e.g., (2048 bit) or (4096 bit) for RSA, or the curve name for ECC).

Scenario 4: Checking if a certificate is intended for server authentication.

“`bash
openssl x509 -in server.crt -noout -purpose | grep “SSL server”

Or examine the full text output:

openssl x509 -in server.crt -text -noout

And look for:

X509v3 Extended Key Usage:

TLS Web Server Authentication

“`

Scenario 5: Extracting the public key from a certificate.

bash openssl x509 -in client_cert.pem -noout -pubkey > client_pubkey.pem
This saves the public key portion into a separate file, which might be needed for certain configurations or cryptographic operations.

Conclusion

OpenSSL provides an indispensable suite of tools for interacting with SSL/TLS certificates, and the openssl x509 command is central to inspecting their contents. By mastering options like -text, -noout, -in, -inform, and the various specific field extractors (-subject, -issuer, -dates, -fingerprint, -purpose, etc.), combined with the ability to retrieve certificates from live servers using openssl s_client (paying attention to -servername and -showcerts), you gain powerful visibility into the digital identities that underpin secure communication.

Understanding the meaning of fields like Issuer, Subject, Validity, and especially the nuances of X.509v3 extensions such as Subject Alternative Name, Key Usage, Extended Key Usage, and Authority Key Identifier, transforms the cryptic output into actionable information. Whether you are debugging a failed TLS handshake, auditing security compliance, or simply satisfying your curiosity about the PKI ecosystem, OpenSSL offers the keys to unlock the rich details held within every digital certificate. It remains an essential skill for anyone working seriously with network security and encrypted communications.