When working with OpenSSL to generate self-signed certificates, many developers encounter the puzzling behavior where the -days parameter seems to be ignored in certain scenarios. Let's dive into why this happens and how to properly control certificate validity periods.

The key observation here is that your script involves three distinct operations:

# Root CA creation (uses -days successfully)
openssl req -x509 -days 358000 -newkey rsa:2048 -keyout ca.key -out ca.crt

# CSR generation (days parameter here is irrelevant)
openssl req -newkey rsa:2048 -days 358000 -keyout server.key -out server.csr

# Certificate signing (missing critical -days parameter)
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt

The -days parameter in CSR generation has no effect because:

• CSR files don't contain expiration information - they're just requests
• The actual expiration is set during signing (x509 command)
• The default expiration is 30 days when not specified during signing

To properly set the expiration period, you must include -days in the signing command:

# Correct way to sign with custom expiration
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 358000

Always verify your certificates after creation:

openssl x509 -in server.crt -noout -dates

Here's a corrected version of your script:

#!/bin/bash

# Generate root CA valid for ~100 years
openssl req -nodes -x509 -days 358000 -newkey rsa:2048 \
  -keyout ca.key -out ca.crt \
  -subj "/C=IR/ST=TEH/L=Torento/O=CTO/OU=root/CN=es.example.com"

# Generate server CSR (days parameter not needed here)
openssl req -nodes -newkey rsa:2048 \
  -keyout server.key -out server.csr \
  -subj "/C=IR/ST=TEH/L=Torento/O=CTO/OU=server/CN=es.example.com"

# Sign server cert with proper expiration
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 358000

# Verify expiration
openssl x509 -in server.crt -noout -enddate

• For production systems, consider using a proper CA hierarchy
• Modern systems may reject extremely long validity periods
• Always include proper SAN (Subject Alternative Name) extensions

When creating self-signed certificates through OpenSSL, many developers encounter an unexpected behavior where the -days parameter specified during CSR generation doesn't carry through to the final signed certificate. Instead, OpenSSL defaults to a 30-day validity period.

# What you expect (358000 days):
openssl req -nodes -newkey rsa:2048 -days 358000 ...

# What you actually get:
openssl x509 -enddate -noout -in client.pem
notAfter=Aug 10 12:32:07 2018 GMT

The critical misunderstanding lies in the two-stage process of certificate creation. The -days parameter in openssl req only affects the CSR itself, not the final certificate. The actual validity period is determined during the signing operation (openssl x509 -req).

Here's the corrected version of your script with proper expiration control:

#!/bin/bash

# Generate CA with 10-year validity
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout ca.key -out ca.crt \
  -subj "/C=IR/ST=TEH/L=Torento/O=CTO/OU=root/CN=es.example.com"

# Generate server CSR (days parameter here is irrelevant for expiry)
openssl req -nodes -newkey rsa:2048 \
  -keyout server.key -out server.csr \
  -subj "/C=IR/ST=TEH/L=Torento/O=CTO/OU=server/CN=es.example.com"

# Sign server cert with explicit 10-year validity
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 3650

# Verify the actual expiry
openssl x509 -enddate -noout -in server.crt

For simpler use cases, you can combine the steps:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout combined.pem -out combined.pem \
  -subj "/CN=example.com"

The 30-day default comes from OpenSSL's security-first philosophy for certificate signing operations. Unlike CA certificates (created with openssl req -x509), signed certificates require explicit validity specification during the signing phase.