LFCE 103 🐧 OpenSSL — Self-Signed and CSRs - KandZ

⏱️ Estimated read: 13 min | |

A self-signed certificate is a certificate that is signed by its own private key rather than by a separate Certificate Authority. A Certificate Signing Request (CSR) is the file that carries a public key and identity information to a CA for signing. The previous chapter covered the OpenSSL toolkit; this chapter focuses on these two operations and the practical differences between them. The LFCE exam expects the candidate to configure host-based security, and knowing when to use a self-signed certificate versus when to generate a CSR is a core decision in that configuration.

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 distinction is fundamental. A self-signed certificate provides encryption but not trusted identity. The client can establish a TLS connection, but it cannot verify that the server is who it claims to be unless the client has been manually configured to trust that specific certificate. A CSR, by contrast, is the request for a certificate from a trusted third party. The CA validates the identity and signs the certificate, and the client trusts the CA, which means it trusts the certificate without any manual configuration on the client side.

Key point: A self-signed certificate is created in one step with openssl req -x509. It is suitable for testing, internal services, and environments where the client trust store can be updated manually. A CSR is created with openssl req -new and is sent to a CA for signing. The private key never leaves the server in either case; the CSR contains only the public key and the identity information.

Why the two operations serve different purposes

The trust problem.

A self-signed certificate is not trusted by default because no third party has vouched for it. Browsers and operating systems maintain a list of trusted CA certificates, and a self-signed certificate is not in that list. The client receives a warning and must either bypass it or have the certificate installed in its trust store. For an internal service where the administrator controls the clients, this is acceptable. For a public-facing service, it is not.

The CSR problem.

A CSR is the mechanism that separates the key generation from the certificate signing. The server generates the private key locally, creates the CSR with the public key and the identity information, and sends only the CSR to the CA. The CA signs it and returns the certificate. The private key is never transmitted, which is the security property that makes the PKI model work. The CA validates the identity—by checking domain control, organization documents, or extended validation—and the resulting certificate carries that validation.

The validation problem.

A self-signed certificate can claim any identity. It can claim to be google.com or bank.example.com, and the client has no way to verify the claim except by manually inspecting the certificate and deciding to trust it. A CA-signed certificate carries the CA’s assertion that the identity was validated. The client trusts the CA’s validation process, which is why the CA-signed certificate is accepted without the manual intervention.

a. Creating a self-signed certificate

The self-signed certificate is created with the openssl req -x509 command. It generates the private key and the certificate in one step, or it uses an existing private key.

# Self-signed certificate with a new key
openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt \
  -days 365 -nodes \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

# Self-signed certificate with an existing key
openssl req -x509 -key server.key -out server.crt \
  -days 365 \
  -subj "/CN=example.com"

The -x509 option tells OpenSSL to create a self-signed certificate instead of a CSR. The -newkey rsa:4096 generates a new 4096-bit RSA key along with the certificate. The -nodes option prevents the key from being encrypted with a passphrase, which is necessary for unattended services. The -subj option sets the subject, and the -addext subjectAltName adds the SAN extension, which is required for modern hostname validation.

The -days option sets the validity period. A self-signed certificate for internal use can have a longer validity than a CA-signed certificate because there is no external renewal process. A five-year or ten-year validity is common for internal CAs and testing certificates.

The certificate can be inspected with the openssl x509 command.

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

# Check the subject and the SAN
openssl x509 -in server.crt -noout -subject -ext subjectAltName

The -text option prints the full certificate, and the -ext subjectAltName prints only the SAN extension, which is the mechanism that confirms the certificate covers the intended hostnames.

b. Creating a CSR

The CSR is created with the openssl req -new command. It requires an existing private key, or it can generate one with -newkey.

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

# CSR with a new key generated at the same time
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr \
  -subj "/CN=example.com"

# 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 -new option creates the CSR. The -key option specifies the private key, and the -out option specifies the CSR file. The -subj option sets the Distinguished Name (DN), which includes the Common Name (CN) that must match the hostname. The -addext subjectAltName adds the SAN extension, which is the modern standard for hostname validation.

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

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

The -text option prints the CSR’s subject, public key, and signature. The signature proves that the requester possesses the private key corresponding to the public key in the CSR.

c. Signing a CSR with an internal CA

A CSR can be signed by an internal CA, which is the pattern for an organization that wants to issue its own certificates without a public CA. The CA certificate and key are used to sign the CSR.

# Create the internal CA (one-time)
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt \
  -days 3650 -nodes -subj "/CN=Internal CA"

# 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 openssl x509 -req command signs the CSR. The -CA and -CAkey options specify the CA certificate and key. The -CAcreateserial creates the serial number file, which tracks the issued certificates. The -extfile option adds the SAN extension, which is not copied from the CSR by default; it must be specified at signing time.

The signed certificate can be verified against the CA.

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

The verify command checks that the certificate is signed by the CA and returns OK on success. The client that trusts ca.crt will accept the server certificate without any manual configuration.

Complete Example Session

# ============================================
# PART 1: SELF-SIGNED CERTIFICATE
# ============================================
openssl req -x509 -newkey rsa:4096 -keyout self.key -out self.crt \
  -days 365 -nodes \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

# ============================================
# PART 2: INSPECT THE SELF-SIGNED CERTIFICATE
# ============================================
openssl x509 -in self.crt -noout -subject -ext subjectAltName

# ============================================
# PART 3: GENERATE A KEY FOR THE CSR
# ============================================
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# ============================================
# PART 4: CREATE THE CSR
# ============================================
openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

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

# ============================================
# PART 6: CREATE THE INTERNAL CA
# ============================================
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt \
  -days 3650 -nodes -subj "/CN=Internal CA"

# ============================================
# PART 7: 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 8: VERIFY THE CERTIFICATE
# ============================================
openssl verify -CAfile ca.crt server.crt

# ============================================
# PART 9: INSPECT THE SIGNED CERTIFICATE
# ============================================
openssl x509 -in server.crt -noout -issuer -subject

# ============================================
# PART 10: CHECK THE CHAIN
# ============================================
cat server.crt ca.crt > server-chain.crt

The ten parts demonstrate the two operations: the self-signed certificate in one command, and the CSR followed by the CA signing. The critical distinction is in Part 1 versus Parts 4 and 7: the self-signed certificate is both the key and the certificate in one step, while the CSR is the request that requires a separate signing step.

Quick Reference

Self-Signed vs CSR

Property	Self-Signed	CSR
Command	`openssl req -x509`	`openssl req -new`
Signing	By its own key	By a CA
Trust	Manual (install in trust store)	Automatic (CA in trust store)
Use case	Testing, internal services	Public-facing services
Private key	Generated locally	Generated locally
Identity validation	None	By the CA

Self-Signed Command

Option	Purpose
`-x509`	Create a self-signed certificate
`-newkey rsa:4096`	Generate a new key
`-keyout`	Private key output
`-out`	Certificate output
`-days`	Validity period
`-nodes`	No passphrase on the key
`-subj`	Subject (CN)
`-addext`	Add the SAN extension

CSR Command

Option	Purpose
`-new`	Create a CSR
`-key`	Existing private key
`-out`	CSR output
`-subj`	Subject (CN)
`-addext`	Add the SAN extension

Signing Command

Option	Purpose
`-req`	Sign a CSR
`-CA`	CA certificate
`-CAkey`	CA private key
`-CAcreateserial`	Create the serial file
`-extfile`	Extensions file

Best Practices

✅ Do This:

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

# Inspect the CSR before sending it to the CA
openssl req -in server.csr -text -noout                        # ✅

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

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

# Use the self-signed certificate only for testing or internal use
# Use the CA-signed certificate for public services            # ✅

❌ Don’t Do This:

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

# Share the private key with the CA
# The CA only needs the CSR                                  # ❌

# Use the self-signed certificate on a public website
# The browsers will show the warning                         # ❌

# Forget the -extfile when signing
# The SAN is not copied from the CSR by default              # ❌

# Use the weak key size
-newkey rsa:1024    # Deprecated                             # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
The self-signed certificate is not trusted	No CA signature	Install the certificate in the trust store
The SAN is missing	Not specified	Add the `-addext subjectAltName`
The CSR is rejected	The signature is invalid	Verify the key possession
The signed certificate lacks the SAN	Not passed to the signing	Use the `-extfile` option
The domain mismatch	The CN/SAN does not match	Add the correct SAN

Real-World Examples

1. Self-signed certificate

openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com"

2. Self-signed with an existing key

openssl req -x509 -key server.key -out server.crt -days 365 -subj "/CN=example.com"

3. Create a CSR

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

4. CSR with SAN

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

5. Inspect the CSR

openssl req -in server.csr -text -noout

6. Create the internal CA

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

7. Sign the CSR

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

8. Sign with the SAN

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -extfile <(printf "subjectAltName=DNS:example.com")

9. Verify the certificate

openssl verify -CAfile ca.crt server.crt

10. Check the issuer

openssl x509 -in server.crt -noout -issuer

Visual

The Self-Signed Flow

┌──────────────────────────────────────────────────────────────┐
│  SELF-SIGNED: KEY AND CERTIFICATE IN ONE STEP                │
│                                                              │
│  openssl req -x509                                           │
│       │                                                      │
│       ├── generates the private key                          │
│       ├── creates the certificate                            │
│       └── signs the certificate with the same key            │
│                                                              │
│  Result: server.key + server.crt                             │
│  The certificate is not trusted by default.                  │
└──────────────────────────────────────────────────────────────┘

The CSR Flow

┌──────────────────────────────────────────────────────────────┐
│  CSR: THE REQUEST THAT THE CA SIGNS                          │
│                                                              │
│  Server:                                                     │
│  ├── openssl genpkey → server.key                            │
│  ├── openssl req -new → server.csr                          │
│  └── (the CSR is sent to the CA)                             │
│                                                              │
│  CA:                                                         │
│  ├── validates the identity                                  │
│  ├── signs the CSR                                           │
│  └── returns server.crt                                      │
│                                                              │
│  Result: server.key (local) + server.crt (signed)            │
│  The certificate is trusted because the CA is trusted.       │
└──────────────────────────────────────────────────────────────┘

The Chain of Trust

┌──────────────────────────────────────────────────────────────┐
│  SELF-SIGNED VS CA-SIGNED                                    │
│                                                              │
│  Self-signed:                                                │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ server.crt is signed by server.key                     │  │
│  │ The client does not know the server.key                │  │
│  │ → the certificate is not trusted                       │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  CA-signed:                                                  │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ ca.crt signs server.crt                                │  │
│  │ The client has ca.crt in the trust store               │  │
│  │ → the certificate is trusted                           │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Self-signed command	`openssl req -x509`
CSR command	`openssl req -new`
Sign command	`openssl x509 -req`
SAN extension	`-addext subjectAltName=DNS:...`
Self-signed use	Testing, internal services
CSR use	Public services, CA-signed
Private key	Never transmitted
Verification	`openssl verify -CAfile`
Chain file	`cat server.crt ca.crt`

Key takeaways:

A self-signed certificate is signed by its own key. It provides encryption but not trusted identity. The client must manually trust it or bypass the warning. It is suitable for testing and internal services where the administrator controls the trust store.
A CSR is a request for a CA to sign the certificate. The server generates the private key locally, creates the CSR with the public key and identity information, and sends only the CSR to the CA. The private key never leaves the server.
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 hostname matching.
The -extfile option is required when signing a CSR. The SAN extension is not copied from the CSR by default. The openssl x509 -req command must be given the -extfile option to add the SAN to the signed certificate.
The internal CA is the middle ground. An organization can create its own CA, sign the server certificates with it, and install the CA certificate in the clients’ trust stores. The clients then trust the server certificates without the public CA.
The private key must be protected. The chmod 600 on the key file prevents the unauthorized access. The key is the identity of the server, and its compromise invalidates the certificate.

Remember: OpenSSL provides two paths for the certificates: the self-signed certificate for the testing and the internal use, and the CSR for the CA-signed certificate for the public services. The self-signed certificate is one command, and the CSR is the request that the CA signs. The SAN extension is the modern hostname validation, and the -extfile option is the mechanism that carries the SAN into the signed certificate. The private key never leaves the server, and the trust store is the client’s source of the trusted CAs. The result is the certificate that matches the trust model of the deployment.

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!