When managing a private CA infrastructure, you'll inevitably encounter OpenSSL's strict default behavior regarding certificate uniqueness. The TXT_DB error number 2 occurs because OpenSSL maintains an index database (index.txt) that by default prevents duplicate entries for the same Distinguished Name (DN).

OpenSSL's CA implementation uses several key files:

index.txt        - Database of issued certificates
serial           - Contains next certificate serial number
certs/           - Directory storing issued certificates
private/         - Contains private keys

The solution lies in the openssl.cnf configuration file. Locate the [ CA_default ] section and modify or add:

[ CA_default ]
unique_subject = no  # Allow duplicate subjects

If you can't modify the config, you can manually edit the database:

# Backup current database
cp index.txt index.txt.bak

# Remove previous entries for the CN
sed -i '/CN=mysite.com/d' index.txt

Here's a complete workflow for reissuing certificates:

# Generate new CSR (same CN)
openssl req -new -key server.key \
  -subj "/CN=mysite.com/O=My Org" \
  -out server_new.csr

# Sign with modified config
openssl ca -config custom_openssl.cnf \
  -in server_new.csr -out server_new.crt \
  -extensions server_cert

Modern browsers handle certificate renewals gracefully provided:

• The new certificate chain is valid
• The certificate keyUsage/extendedKeyUsage matches
• No validation timing issues exist

For production environments, consider:

1. Implementing OCSP stapling
2. Setting appropriate certificate lifetimes
3. Maintaining proper certificate revocation

The same principles apply whether you're using the certificate for web servers, internal services, or client authentication.

The OpenSSL CA database (index.txt) enforces uniqueness constraints on certificate entries. When you attempt to issue multiple certificates with identical Distinguished Names (especially Common Name), OpenSSL throws the "TXT_DB error number 2" because it's trying to prevent duplicate entries in its database.

The solution lies in the intermediate CA's openssl.cnf file. Find and modify the following section:

[ CA_default ]
# Change from 'yes' to 'no' for unique_subject
unique_subject = no

This tells OpenSSL to allow multiple certificates with the same subject to be issued. After making this change, restart your CA operations.

Here's how to properly implement certificate renewal while maintaining the same CN:

# Renewal process for mysite.com certificate
export CN="mysite.com"
export SUBJ="/C=US/ST=California/L=SF/O=Company/OU=IT/CN=$CN"

# Generate new private key (recommended for renewal)
openssl genrsa -out mysite-renewal.key 2048

# Create new CSR with same CN
openssl req -new -key mysite-renewal.key \
    -subj "$SUBJ" \
    -out mysite-renewal.csr

# Sign with modified CA config
openssl ca -config intermediate/openssl.cnf \
    -extensions server_cert \
    -days 365 -notext -md sha256 \
    -in mysite-renewal.csr \
    -out mysite-renewal.crt

After successful issuance, check your intermediate CA's database file:

cat intermediate/index.txt

V 250408124740Z 1001 unknown /C=US/ST=California...CN=mysite.com
V 250408124801Z 1002 unknown /C=US/ST=California...CN=mysite.com

Notice both entries have the same DN but different serial numbers (1001 and 1002) and validity periods.

Modern browsers will accept renewed certificates with identical CNs as long as:

• The certificate chain is valid
• The new certificate has appropriate validity dates
• The previous certificate is properly revoked (if necessary)

For more flexibility, consider using Subject Alternative Names:

openssl req -new -key mysite.key \
    -subj "/CN=mysite.com" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "[SAN]\nsubjectAltName=DNS:mysite.com")) \
    -out mysite-san.csr