LFCE 102 🐧 OpenSSL — Certificates and Keys - KandZ

⏱️ Estimated read: 13 min | |

OpenSSL is the cryptographic toolkit that implements the TLS protocol and the X.509 certificate handling on Linux. The previous chapter covered the TLS concepts: the handshake, the certificate, and the cipher suite. This chapter covers the commands that create the keys, generate the certificate requests, sign the certificates, and inspect the results. The LFCE exam expects the candidate to configure the host-based and user-based security for a service, and OpenSSL is the tool that produces and verifies the certificates that the services use.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The toolkit has two roles. The openssl command is the command-line utility that performs the individual operations: the key generation, the certificate request, the signing, the verification, and the conversion between the formats. The openssl s_client is the diagnostic tool that connects to a remote service and prints the certificate chain, the negotiated protocol, and the cipher suite. The two roles are the production and the inspection sides of the same toolkit, and the administrator uses both to set up the TLS and to troubleshoot it.

Key point: The certificate request (CSR) is the file that the server sends to the CA to request the signature. The CSR contains the server’s public key and the identity information, and it is signed with the server’s private key to prove the possession. The CA signs the CSR and returns the certificate. The private key never leaves the server; the CSR and the certificate are the only files that travel. The openssl req command creates the CSR, and the openssl x509 command signs it or inspects it.

Why OpenSSL requires the key and the CSR

The private-key problem.

The private key is the identity of the server. It is used to decrypt the session key in the TLS handshake (in the RSA key exchange) and to sign the handshake messages (in the ECDHE key exchange). The key must be generated on the server, and it must never be shared or transmitted. The openssl genpkey or the openssl genrsa command creates the private key, and the file must be protected with the restrictive permissions.

The CSR problem.

The CA does not need the private key to sign the certificate. It needs the public key and the identity information, and the CSR is the container that carries them. The CSR is signed with the private key, which proves that the requester possesses the key. The CA verifies the signature, checks the identity, and signs the certificate. The openssl req -new command creates the CSR from the private key and the subject information.

The certificate problem.

The certificate is the signed public key. It is the file that the server presents in the handshake, and the client verifies it against the CA’s certificate. The openssl x509 command can sign a CSR with a CA’s private key, which is the mechanism for the self-signed CA and the internal PKI. The command also inspects the certificate’s content, the subject, the issuer, and the validity.

a. The key generation and the certificate request

The private key is generated with the openssl genpkey or the openssl genrsa command. The genpkey is the modern command, and the genrsa is the legacy one.

# Generate a 2048-bit RSA private key
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# Generate an ECDSA private key (P-256)
openssl genpkey -algorithm EC -out server.key -pkeyopt ec_paramgen_curve:P-256

# Protect the key with a passphrase
openssl genpkey -algorithm RSA -out server.key -aes256

The genpkey -algorithm RSA creates the RSA key, and the -pkeyopt rsa_keygen_bits:2048 sets the key size. The -aes256 option encrypts the key with a passphrase, which is the mechanism for the at-rest protection. The unencrypted key is required for the unattended services, but it must be protected with the file permissions.

The CSR is generated with the openssl req -new command.

# Generate a CSR with the subject information
openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=example.com"

# Generate a CSR with the SAN extension
openssl req -new -key server.key -out server.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

The -key server.key specifies the private key, and the -out server.csr specifies the output file. The -subj option sets the subject information, including the Common Name (CN), which must match the hostname. The -addext subjectAltName option adds the Subject Alternative Name (SAN) extension, which is the modern mechanism for the hostname validation; the CN alone is deprecated for the hostname matching.

The CSR can be inspected before it is sent to the CA.

# Inspect the CSR
openssl req -in server.csr -text -noout

The openssl req -text command prints the CSR’s subject, the public key, and the signature. The inspection is the mechanism that confirms the CSR contains the correct information before the CA signs it.

b. The certificate signing and the self-signed CA

The openssl x509 command signs the CSR with the CA’s private key, which is the mechanism for the internal PKI and the self-signed certificates.

# Create a self-signed CA certificate
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt \
  -days 3650 -subj "/CN=My Internal CA" -nodes

# Sign the server CSR with the CA
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365 \
  -extfile <(printf "subjectAltName=DNS:example.com,DNS:www.example.com")

The -x509 option creates the self-signed certificate, which is the CA certificate. The -newkey rsa:4096 generates the new key, and the -nodes option prevents the key encryption. The -days 3650 sets the validity to 10 years, which is the common practice for the internal CA.

The openssl x509 -req command signs the CSR. The -CA ca.crt and the -CAkey ca.key specify the CA’s certificate and key, and the -CAcreateserial creates the serial number file. The -out server.crt is the signed certificate, and the -days 365 is the validity. The -extfile option adds the SAN extension, which is the mechanism that makes the certificate valid for the multiple hostnames.

The certificate chain is the CA certificate and the server certificate. The server should send the full chain in the handshake.

# Create the full chain file
cat server.crt ca.crt > server-chain.crt

The cat server.crt ca.crt concatenates the server certificate and the CA certificate, and the result is the file that the server presents in the handshake. The order matters: the server certificate first, then the CA certificate.

c. The inspection and the verification

The openssl x509 command inspects the certificate, and the openssl verify command verifies it against the CA.

# Inspect the certificate
openssl x509 -in server.crt -text -noout

# Check the subject and the issuer
openssl x509 -in server.crt -noout -subject -issuer

# Check the validity
openssl x509 -in server.crt -noout -dates

# Verify the certificate against the CA
openssl verify -CAfile ca.crt server.crt

The -text option prints the full certificate content, including the subject, the issuer, the validity, the public key, and the extensions. The -subject and the -issuer options show the identity of the certificate’s owner and the CA that signed it. The -dates option shows the notBefore and notAfter dates. The verify -CAfile ca.crt server.crt command verifies that the server certificate is signed by the CA, and it returns the OK on success.

The openssl s_client is the diagnostic tool that connects to the remote service.

# Connect to the remote service and print the certificate
openssl s_client -connect example.com:443 -showcerts

# Check the negotiated protocol and the cipher
openssl s_client -connect example.com:443 | grep -E "Protocol|Cipher"

# Test the specific TLS version
openssl s_client -connect example.com:443 -tls1_3

The -connect option specifies the host and the port. The -showcerts option prints the full chain, which is the mechanism for the missing intermediate troubleshooting. The -tls1_3 option tests the specific version. The s_client output includes the certificate chain, the protocol, the cipher, and the verification result.

Complete Example Session

# ============================================
# PART 1: GENERATE THE CA KEY AND CERT
# ============================================
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt \
  -days 3650 -subj "/CN=My Internal CA" -nodes

# ============================================
# PART 2: GENERATE THE SERVER KEY
# ============================================
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# ============================================
# PART 3: GENERATE THE CSR
# ============================================
openssl req -new -key server.key -out server.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

# ============================================
# PART 4: INSPECT THE CSR
# ============================================
openssl req -in server.csr -text -noout

# ============================================
# PART 5: SIGN THE CSR
# ============================================
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365 \
  -extfile <(printf "subjectAltName=DNS:example.com,DNS:www.example.com")

# ============================================
# PART 6: INSPECT THE CERTIFICATE
# ============================================
openssl x509 -in server.crt -text -noout

# ============================================
# PART 7: VERIFY THE CERTIFICATE
# ============================================
openssl verify -CAfile ca.crt server.crt

# ============================================
# PART 8: CREATE THE FULL CHAIN
# ============================================
cat server.crt ca.crt > server-chain.crt

# ============================================
# PART 9: TEST THE REMOTE SERVICE
# ============================================
openssl s_client -connect example.com:443 -showcerts

# ============================================
# PART 10: CHECK THE PROTOCOL AND CIPHER
# ============================================
openssl s_client -connect example.com:443 | grep -E "Protocol|Cipher"

The ten parts demonstrate the OpenSSL certificate workflow: the CA key and certificate, the server key, the CSR, the CSR inspection, the signing, the certificate inspection, the verification, the chain, the remote test, and the protocol check. The critical distinction is between Parts 3 and 5: the CSR is generated with the server’s private key, and the certificate is signed with the CA’s private key.

Quick Reference

Key Generation

Command	Purpose
`openssl genpkey -algorithm RSA`	Generate the RSA key
`openssl genpkey -algorithm EC`	Generate the ECDSA key
`openssl genrsa`	Legacy RSA key generation
`openssl rsa -in key -pubout`	Extract the public key

Certificate Operations

Command	Purpose
`openssl req -new -key`	Generate the CSR
`openssl req -x509`	Self-signed certificate
`openssl x509 -req -CA`	Sign the CSR
`openssl x509 -in -text`	Inspect the certificate
`openssl verify -CAfile`	Verify the certificate

Inspection

Command	Purpose
`openssl x509 -noout -subject`	View the subject
`openssl x509 -noout -issuer`	View the issuer
`openssl x509 -noout -dates`	View the validity
`openssl req -in -text`	View the CSR
`openssl s_client -connect -showcerts`	View the remote chain

Format Conversion

Command	Purpose
`openssl pkcs12 -in file.p12`	Extract from the PKCS#12
`openssl x509 -in cert -outform DER`	Convert the PEM to DER
`openssl rsa -in key -outform DER`	Convert the key to DER

Best Practices

✅ Do This:

# Generate the key with the strong size
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048   # ✅

# Use the SAN extension for the hostname
-addext "subjectAltName=DNS:example.com"                       # ✅

# Verify the certificate after the signing
openssl verify -CAfile ca.crt server.crt                       # ✅

# Inspect the CSR before the signing
openssl req -in server.csr -text -noout                        # ✅

# Protect the private key
chmod 600 server.key                                           # ✅

# Use the full chain in the server
cat server.crt ca.crt > server-chain.crt                       # ✅

❌ Don’t Do This:

# Share the private key
# The key is the identity; never transmit it                  # ❌

# Use the CN only for the hostname
-subj "/CN=example.com"    # The SAN is the modern standard  # ❌

# Use the weak key size
openssl genrsa 1024    # The 1024-bit RSA is deprecated     # ❌

# Skip the verification
# The certificate may not be signed by the CA                 # ❌

# Use the self-signed certificate in production
# The clients do not trust it without the CA installation    # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
The certificate is not trusted	The CA is not in the trust store	Install the CA
The domain mismatch	The CN/SAN does not match	Add the SAN
The CSR is rejected	The signature is invalid	Verify the key possession
The chain is incomplete	The intermediate is missing	Include the full chain
The key is unreadable	Wrong permissions	`chmod 600`

Real-World Examples

1. Generate the key

openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

2. Generate the CSR

openssl req -new -key server.key -out server.csr -subj "/CN=example.com"

3. CSR with SAN

openssl req -new -key server.key -out server.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com"

4. Self-signed CA

openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 3650 -subj "/CN=My CA" -nodes

5. Sign the CSR

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365

6. Inspect the certificate

openssl x509 -in server.crt -text -noout

7. Check the dates

openssl x509 -in server.crt -noout -dates

8. Verify the certificate

openssl verify -CAfile ca.crt server.crt

9. Create the chain

cat server.crt ca.crt > server-chain.crt

10. Test the remote

openssl s_client -connect example.com:443 -showcerts

Visual

The Certificate Workflow

┌──────────────────────────────────────────────────────────────┐
│  KEY → CSR → CA → CERTIFICATE                                │
│                                                              │
│  Server:                                                     │
│  ├── openssl genpkey → server.key                            │
│  ├── openssl req -new → server.csr                          │
│  └── (the CSR is sent to the CA)                             │
│                                                              │
│  CA:                                                         │
│  ├── openssl x509 -req -CA ca.crt -CAkey ca.key             │
│  └── → server.crt (signed)                                   │
│                                                              │
│  Server:                                                     │
│  ├── cat server.crt ca.crt → server-chain.crt               │
│  └── the chain is presented in the handshake                 │
└──────────────────────────────────────────────────────────────┘

The Chain of Trust

┌──────────────────────────────────────────────────────────────┐
│  THE ROOT CA SIGNS THE SERVER                                │
│                                                              │
│  ca.crt (self-signed)                                        │
│       │ signs                                                │
│       ▼                                                      │
│  server.crt (signed by the CA)                               │
│                                                              │
│  The client trusts the ca.crt in its trust store,            │
│  and verifies the server.crt against it.                     │
└──────────────────────────────────────────────────────────────┘

The s_client Output

┌──────────────────────────────────────────────────────────────┐
│  openssl s_client -connect SHOWS THE HANDSHAKE               │
│                                                              │
│  CONNECTED (00000003)                                        │
│  depth=1 C=US, O=Example, CN=Example CA                      │
│  depth=0 CN=example.com                                      │
│  ---                                                         │
│  Certificate chain                                           │
│   0 s:CN=example.com                                         │
│   1 i:CN=Example CA                                          │
│  ---                                                         │
│  SSL-Session:                                                │
│      Protocol: TLSv1.3                                       │
│      Cipher: TLS_AES_256_GCM_SHA384                          │
│      Verify return code: 0 (ok)                              │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Key generation	`openssl genpkey`
CSR generation	`openssl req -new`
Self-signed CA	`openssl req -x509`
Sign the CSR	`openssl x509 -req -CA`
Inspect the cert	`openssl x509 -text`
Verify the cert	`openssl verify -CAfile`
Remote test	`openssl s_client -connect`
SAN extension	`-addext subjectAltName`
Private key permission	`chmod 600`
Full chain	`cat server.crt ca.crt`

Key takeaways:

The private key is generated on the server and never leaves it. The openssl genpkey command creates the key, and the file must be protected with the chmod 600. The key is used to sign the CSR and to prove the possession in the handshake.
The CSR carries the public key and the identity, and it is signed with the private key. The openssl req -new command creates the CSR from the key and the subject information. The CA verifies the signature and signs the certificate.
The CA signs the CSR with its private key. The openssl x509 -req -CA command produces the certificate. The CA’s private key must be protected, because its compromise invalidates the entire PKI.
The SAN extension is the modern hostname validation. The -addext subjectAltName option adds the hostnames that the certificate is valid for. The CN alone is deprecated for the hostname matching.
The openssl verify command checks the certificate against the CA. The -CAfile ca.crt option specifies the trusted CA, and the OK result confirms the signature.
The openssl s_client is the remote diagnostic. The -showcerts option prints the full chain, and the -tls1_3 option tests the specific version. The output includes the protocol, the cipher, and the verification result.

Remember: OpenSSL is the toolkit that produces and verifies the certificates. The private key is generated on the server, the CSR is created from the key and the subject, and the CA signs the CSR to produce the certificate. The SAN extension is the modern hostname validation, and the full chain is the file that the server presents. The openssl x509 and the openssl req inspect the certificates, and the openssl s_client tests the remote service. The result is the PKI that the TLS handshake depends on.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!