Working with OpenSSL

This article provides a guide to working with OpenSSL, including generating RSA keys, creating and signing CSR requests, configuring certificate extensions (SAN, Key Usage), and validating certificates. It covers certificate storage formats (PEM, DER, PKCS#12), their conversion and exchange, as well as configuring trusted stores.

Generating an RSA Private Key

Generating an RSA private key is the first step in certificate generation. RSA (Rivest-Shamir-Adleman) is one of the most common asymmetric encryption algorithms used for data protection and authentication.

The private key must be kept strictly confidential, as it is used to decrypt information encrypted with the corresponding public key.

To generate a private key in OpenSSL, use the following command, where you can specify the key length to ensure the required security level.

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048

Note

The minimum key length is 2048 bits. For enhanced security, consider using 3072 or 4096-bit keys.

Creating a Certificate Signing Request (CSR)

CSR (Certificate Signing Request) is a file containing information about the certificate owner and their public key. A CSR is not a valid certificate itself. To obtain a full-fledged certificate, the CSR must be signed by a Certificate Authority (CA).

Use the following command to generate a CSR:

openssl req -new -key private_key.pem -out request.csr -sha256

During the process, you will need to provide subject details:

• Country Name — 2-letter country code, e.g., AE

• State or Province Name — state or region, e.g., Dubai

• Locality Name — city, e.g., Dubai

• Organization Name — organization name

• Organizational Unit Name — department name

• Common Name — fully qualified domain name of the certificate subject

• Email Address — email address

When creating a certificate signing request, you can also specify additional attributes, including:

• Challenge password — verification password

• Optional company name — optional company name

Important!

Entering a . character will leave the field blank.

Important!

Each component's host certificate (Logstash, OpenSearch, etc.) must include the following required extensions:

• Subject Alternative Name (SAN), containing all IP addresses and DNS names of the corresponding Search Anywhere Framework component

• Key Usage: critical Digital Signature, Key Encipherment

• Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication

Subject Alternative Name (SAN)

One of the key aspects when working with certificates is the ability to specify alternative names for which the certificate will be valid.

Subject Alternative Name (SAN) is an extension that allows defining additional domains and IP addresses that will be considered valid for this certificate during verification.

Adding alternative names to a certificate is possible during CSR creation. To do this, you need to create a configuration file (e.g., san.cnf). This file should include the following parameters:

• basic information (Common Name, Organization, etc.)

• SAN list (additional domains and IPs)

Below is an example configuration file:

[req]
default_bits = 2048
prompt = no
distinguished_name = req_distinguished_name
req_extensions = v3_req


[req_distinguished_name]
countryName = AE
stateOrProvinceName = Dubai
localityName = Dubai
organizationName = My Company
organizationalUnitName = IT
commonName = example.com
emailAddress = example@mail.com

[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alt_section

[alt_section]
DNS.1 = example.com         # Primary domain (can duplicate CN)
DNS.2 = www.example.com     # Subdomain
DNS.3 = api.example.com     # Another subdomain
DNS.4 = test.example.org    # External domain

Important!

Including local addresses (127.0.0.1, 192.168.x.x) in a certificate's SAN creates security risks as it allows attackers to impersonate local services. Public Certificate Authorities (CAs) typically refuse to sign such certificates.

Next, generate the CSR while specifying SAN:

openssl req -new -key private_key.pem -out request.csr -config san.cnf -sha256

Verify that the SAN field was successfully added:

openssl req -in request.csr -noout -text | grep -A1 "Subject Alternative Name"

Certificate Formats and Conversion

Certificates and keys can be stored in different formats, each designed for specific tasks and systems.

Main Certificate Formats

• PEM - text format (Base64), standard for Linux/OpenSSL

• DER - binary format, used in Java/Windows

• PKCS#12 (.p12/.pfx) - contains certificate + password-protected key

• PKCS#7 (.p7b) - certificate chain only

Key Conversion Commands

PEM ↔ DER

openssl x509 -in cert.pem -outform der -out cert.der
openssl x509 -inform der -in cert.der -out cert.pem

PEM → PKCS#12 (with key)

openssl pkcs12 -export -in cert.pem -inkey key.pem -out bundle.p12 

PKCS#12 → PEM (certificate + key)

openssl pkcs12 -in bundle.p12 -out cert.pem -nodes 

Extracting only private key from PKCS#12

openssl pkcs12 -in bundle.p12 -nocerts -nodes -out private.key

Viewing and Validating Certificates

For certificates in PEM format, complete information can be displayed with the following command:

openssl x509 -in cert.pem -noout -text

he command shows:

• basic data (version, serial number, signature algorithm)
• validity period
• issuer and Subject (owner)
• public key
• extended fields (SAN, Key Usage)
• certificate signature

For working with other formats, use these commands:

• DER:

openssl x509 -in cert.der -inform der -noout -text

• PKCS#12:

openssl pkcs12 -in bundle.p12 -nodes -info -nokeys

Important!

Avoid specifying passwords in plain text in the command line as such commands remain in command history. Example of insecure usage with exposed password:

openssl pkcs12 -in bundle.p12 -nodes -info -nokeys -password pass:"123"

• PKCS#7:

openssl pkcs7 -in chain.p7b -print_certs -inform der

Important!

Some formats (like PKCS#12 and PKCS#7) don't contain complete certificate information. For detailed analysis, convert them to PEM format and use openssl x509.

Validating Certificates and Keys

Before using a certificate, it's crucial to verify its correctness, validity period, and match with the private key.

Note

Commands for viewing certificate contents in various formats are listed in the Viewing and Validating Certificates section.

Validation commands:

• verify key and certificate match (hashes must match)

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

• for PKCS#8 formatted keys:

openssl pkey -noout -modulus -in private.key | openssl md5

• verify key and certificate match in PFX file:

openssl pkcs12 -in bundle.pfx -nocerts -nodes | openssl rsa -noout -modulus | openssl md5

• check certificate expiration:

openssl x509 -in certificate.crt -noout -dates

• validate PEM file structure (errors will appear if format is invalid):

openssl x509 -in certificate.crt -noout

Important!

Certificate signature verification and trust chain validation using root and intermediate CAs are described in the Signature and Trust Chain Verification section.

Certificate Signing

Digital signature is the result of cryptographic processing of certificate data (including subject information, public key, and validity period) using the private key of a Certificate Authority (CA). The signature allows verification that the certificate:

• was issued by a trusted Certificate Authority (CA)
• has not been forged or altered
• belongs to a specific public key

The digital signature is recorded in the Signature field of the certificate. Signature verification is performed using the CA's public key, making falsification impossible without access to the private key.

Certificate Signing Methods

There are two main types of signed certificates:

• Self-signed - signed with its own private key
• Externally CA-signed - signed by a Certificate Authority whose private key is not accessible

Important!

Self-signed certificates are not trusted by browsers and other clients by default. To establish trust, they must be added to the local trusted certificate store.

Creating Your Own CA Certificate

To sign a CSR, you need to have a CA private key and certificate. If an external Certificate Authority is not used, you can generate your own CA certificate.

Creating a root CA certificate involves two steps:

• creating a private key:

openssl req -x509 -new -key private.key -out cert.crt -days 365 -sha256

• creating a self-signed certificate:

openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt

Note

This certificate will be used to sign other certificates.

Signing CSR with a Self-Signed CA

After generating the certificate request file request.csr, the next step is to sign it with the CA certificate to obtain a valid, functional certificate.

If certificate extensions (such as SAN or Extended Key Usage) are required, use an OpenSSL configuration file (openssl_ca.cnf) and the openssl ca command:

openssl ca -config openssl_ca.cnf -in request.csr -out server.crt \
-days 825 -extensions v3_req -batch -notext -md sha256

Explanation of parameters used in the openssl ca command:

• -config - path to the configuration file (openssl_ca.cnf)
• -in - path to the CSR file
• -out - output path for the signed certificate
• -extensions v3_req - section name in the config file containing required extensions
• -batch - disable interactive prompts
• -notext - don't add human-readable text to the certificate
• -sha256 - use SHA256 hashing algorithm

The command execution will create a signed certificate server.crt based on the request.csr, signed with the CA certificate files ca.crt and ca.key.

Signature and Trust Chain Verification

To verify that a certificate was signed by a specific CA, use the following command:

openssl verify -CAfile ca.crt server.crt

Upon successful verification, the output will show: server.crt: OK.

When using an intermediate CA, a full trust chain verification must be performed.

Before adding a certificate to the trusted list, the following checks should be completed:

• signature authenticity (trust chain verification)
• certificate validity period
• absence from revocation lists

This command:

openssl verify -CAfile root_ca.crt -untrusted intermediate.crt server.crt

performs verification using the following certificates:

• root_ca.crt - root (trusted) Certificate Authority (CA) certificate
• intermediate.crt - intermediate certificate issued by the root CA
• server.crt - end-entity certificate being verified

To verify a PEM certificate with CA chain, use:

openssl verify -CAfile ca_bundle.pem certificate.pem

Certificate Exchange

Configuring Trusted Certificates

Java applications use special truststores to manage trusted certificates. To add a CA certificate to a truststore, use:

$JAVA_HOME/bin/keytool -import -trustcacerts -alias ca_cert -file ca_cert.der -keystore truststore.jks -storepass password

Important!

This command requires Java installation and properly configured JAVA_HOME environment variable. Ensure Java is installed and keytool is accessible via $JAVA_HOME/bin/keytool. If JAVA_HOME is not set, use the full path manually, for example:

/usr/lib/jvm/java-17-openjdk-amd64/bin/keytool -import -trustcacerts -alias ca_cert -file ca_cert.der -keystore truststore.jks -storepass password

Parameter explanations:

• -trustcacerts - indicates the imported certificate is a trusted CA certificate
• -alias ca_cert - alias for the imported certificate, used for identification within the store
• -file ca_cert.der - path to the certificate file to import (DER format)
• -keystore truststore.jks - truststore filename where the certificate will be added
• -storepass password - truststore access password

Retrieving Remote Host Certificates

For configuring inter-server communication, you often need to obtain a remote host's certificate. This can be done with:

openssl s_client -connect remote-host:9200 -showcerts </dev/null 2>/dev/null | openssl x509 -out remote_cert.pem

Important!

Information about certificate validation, including trust chain and signature verification, can be found in the Signature and Trust Chain Verification section.