DevOps Journal

Today, I will walk through the process of creating a new Certificate Authority (CA) using a 4096-bit RSA key and SHA-512 as the signature hash algorithm. I will also store the private key securely on a PKCS #11–compatible smart card, and then create a subordinate (sub) CA using the root CA. Throughout this guide, I will use recommended security controls that you should follow to protect your keys and certificates.

Why Use a Smart Card (PKCS #11)?

Storing your private key on a smart card (or Hardware Security Module, HSM) significantly enhances security by:

• Preventing key extraction: Private keys generated on or imported into smart cards cannot be easily exported in plain text.
• Hardware-based security: Many smart cards implement protections against physical tampering and side-channel attacks.
• Secure key usage: Sign and decrypt operations occur on the card, which reduces exposure of the private key.

Recommended Security Controls

Before diving into commands, keep these best practices in mind:

1. Offline Root CA:
   • Maintain your root CA offline (on a laptop or computer not connected to any network).
   • Only bring it online in a secure environment when issuing or renewing certificates.
2. Physical Security:
   • Store the smart card containing the root CA key in a locked safe or a secure location.
   • Use tamper-evident bags or containers for added protection.
3. Strong Passphrase/PIN:
   • Use a complex PIN/passphrase for the smart card (or HSM).
   • Never store the PIN/passphrase on the same device or in the same physical location as the smart card.
4. Dedicated Machine for CA Operations:
   • Limit software installed on the CA machine to the bare minimum (e.g., OpenSSL, PKCS #11 drivers).
   • Keep the system fully patched and hardened.
5. Regular Audits and Logging:
   • Maintain logs of issuance, revocation, and key usage.
   • Periodically review who has access to the CA environment.
6. Multi-factor Authentication (MFA):
   • If possible, layer an additional form of authentication (e.g., a separate password or token) to access CA resources.

With these controls in place, let’s move on to the technical steps.

Step-by-Step: Creating a Root CA (SHA-512, 4096-bit) on a Smart Card

3.1 Install Required Packages

On most Linux systems, you will need:

sudo apt-get update
sudo apt-get install opensc openssl libengine-pkcs11-openssl pkcs11-tools

• OpenSSL: Core cryptographic toolkit.
• OpenSC: Contains drivers and utilities for several PKCS #11 smart cards.
• pkcs11-tools: Utility set for managing PKCS #11 tokens.
• libengine-pkcs11-openssl: Engine plugin allowing OpenSSL to communicate with PKCS #11–compatible devices.

3.2 Initialize and Prepare Your Smart Card

1. Insert the smart card into your reader.
2. Initialize the card (careful—this may erase existing keys!). For example, with pkcs15-init from OpenSC:

pkcs15-init --create-pkcs15 --profile pkcs15+onepin --pin 123456 --puk 654321

• --pin 123456 – sets your user PIN (example value; use a stronger PIN in reality).
• --puk 654321 – sets an unblock code if the PIN is entered incorrectly too many times.

Alternatively, you can use pkcs11-tool commands depending on your card’s vendor and management software.

3.3 Generate or Import the Root CA Key onto the Smart Card

There are two main approaches to get the key onto the card:

• Generate directly on the card (best practice, more secure).
• Generate externally and import (some cards may not support this, or you might prefer external generation).

3.3.1 Generating the Key on the Card

pkcs11-tool --module /usr/lib/opensc-pkcs11.so \
            --login \
            --keypairgen \
            --key-type RSA:4096 \
            --label "RootCA-Key" \
            --id 01 \
            --pin 123456

• --module points to your PKCS #11 driver (path may differ by system).
• --keypairgen performs the on-card key generation.
• --label "RootCA-Key" helps identify the key.
• --id 01 sets a hex identifier for the key, which you can reference later.

3.3.2 Creating the Root CA Certificate Request

1. Create a configuration file for OpenSSL (let’s call it root-ca.conf) specifying default settings, like so:

[ req ]
default_bits       = 4096
default_keyfile    = rootCA.key
distinguished_name = req_distinguished_name
req_extensions     = v3_req
prompt             = no

[ req_distinguished_name ]
C  = US
ST = YourState
L  = YourCity
O  = YourOrganization
OU = Root CA
CN = vkafed.com Root CA

[ v3_req ]
keyUsage = critical, keyCertSign, cRLSign
basicConstraints = critical, CA:true

Use OpenSSL’s PKCS #11 engine to create a certificate request that references the on-card key

openssl req -new -engine pkcs11 \
    -keyform engine \
    -key "pkcs11:object=RootCA-Key;type=private;pin-value=123456" \
    -config root-ca.conf \
    -sha512 \
    -out rootCA.csr

3.3.3 Self-Sign the Root CA Certificate

Because this is a root CA, we are self-signing:

openssl x509 -req -in rootCA.csr -sha512 \
    -extensions v3_req \
    -signkey "pkcs11:object=RootCA-Key;type=private;pin-value=123456" \
    -days 3650 \
    -out rootCA.crt

• -days 3650 (10 years) is an example. Adjust it if needed.
• The resulting file rootCA.crt is your self-signed root CA certificate.

Store rootCA.crt in a secure offline location (and keep backups!).

4. Creating a Subordinate CA (SubCA)

Next, we create a subordinate CA signed by the root CA.

4.1 Generate SubCA Keys and CSR

You may generate this subordinate CA key in software or on another smart card, depending on your security policies. Below is a software-based example:

1. Generate the key pair:

openssl genrsa -out subCA.key 4096

2. Create a configuration file for the SubCA (e.g., sub-ca.conf):

[ req ]
default_bits       = 4096
default_keyfile    = subCA.key
distinguished_name = req_distinguished_name
req_extensions     = v3_req
prompt             = no

[ req_distinguished_name ]
C  = US
ST = YourState
L  = YourCity
O  = YourOrganization
OU = Sub CA
CN = vkafed.com Sub CA

[ v3_req ]
keyUsage = critical, keyCertSign, cRLSign
basicConstraints = critical, CA:true, pathlen=0

3. Generate the CSR:

openssl req -new -sha512 -key subCA.key -config sub-ca.conf -out subCA.csr

4.2 Sign the SubCA CSR Using the Offline Root CA

On your offline root CA machine (where rootCA.crt and root CA smart card are stored), sign the SubCA CSR:

openssl x509 -req -in subCA.csr \
    -CA rootCA.crt \
    -CAkey "pkcs11:object=RootCA-Key;type=private;pin-value=123456" \
    -CAcreateserial \
    -days 1825 \
    -sha512 \
    -extensions v3_req \
    -extfile sub-ca.conf \
    -out subCA.crt

• -CAcreateserial will create a file rootCA.srl that tracks certificate serial numbers.
• -days 1825 sets the SubCA certificate to be valid for 5 years (example; adjust if needed).

5. Final Security Considerations

Secure Storage:

• Keep the root CA’s smart card physically secured and offline.
• Maintain secure backups (preferably in another physical location).

Revocation Mechanisms:

• Publish a Certificate Revocation List (CRL) or use Online Certificate Status Protocol (OCSP) so end-users can check certificate status.
• Host the CRL or OCSP service in a reliable location.

Certificate Policies:

• Draft a Certificate Policy (CP) and a Certification Practice Statement (CPS) if this CA will be used for a production or public trust environment.

Regular Renewal and Key Rollover:

• Plan certificate renewal schedules and ensure that sub CA and end-entity certificates are renewed before they expire.
• Periodically rotate (reissue) keys to reduce long-term exposure.

Logging and Monitoring:

• Log all CA operations (issuance, revocation, etc.).
• Monitor your environment for unauthorized issuance attempts or suspicious access.