Configuring Certificate Authority With Openssl

Configuring Certificate Authority with OpenSSL

Overview

A Certificate Authority (CA) is the trust anchor in a PKI hierarchy, responsible for issuing, signing, and revoking digital certificates. This skill covers building a two-tier CA hierarchy (Root CA + Intermediate CA) using OpenSSL and the Python cryptography library, including CRL distribution, OCSP responder configuration, and certificate policy management.

When to Use

Trigger phrases:

• "configuring certificate authority with openssl"

• "A Certificate Authority (CA) is the trust anchor in a PKI hierarchy, responsible"

• When deploying or configuring configuring certificate authority with openssl capabilities in your environment

• When establishing security controls aligned to compliance requirements

• When building or improving security architecture for this domain

• When conducting security assessments that require this implementation

Prerequisites

• Familiarity with cryptography concepts and tools
• Access to a test or lab environment for safe execution
• Python 3.8+ with required dependencies installed
• Appropriate authorization for any testing activities

Objectives

• Create a Root CA with self-signed certificate
• Create an Intermediate CA signed by the Root CA
• Issue server and client certificates from the Intermediate CA
• Configure Certificate Revocation Lists (CRLs)
• Implement certificate policies and constraints
• Build a complete PKI hierarchy programmatically

Key Concepts

This section covers key concepts for configuring certificate authority with openssl.

• Ensure all prerequisites are met before proceeding
• Follow the documented workflow steps in sequence
• Record results and any anomalies encountered during this phase

CA Hierarchy

Root CA (offline, air-gapped)
  |
  +-- Intermediate CA (online, operational)
        |
        +-- Server Certificates
        +-- Client Certificates
        +-- Code Signing Certificates

Certificate Extensions

Security Considerations

• Root CA private key must be stored offline (air-gapped HSM)
• Use minimum 4096-bit RSA or P-384 ECDSA for CA keys
• Set path length constraints on intermediate CAs
• Implement certificate policies (OIDs)
• Enable CRL and OCSP for revocation checking
• Audit all certificate issuance operations

Validation Criteria

• Root CA self-signed certificate is valid
• Intermediate CA certificate chains to Root CA
• Issued certificates chain to Intermediate -> Root
• Path length constraints are enforced
• CRL is generated and accessible
• Revoked certificates appear in CRL
• Certificate policies are correctly embedded

When NOT to Use

• You need to implement from scratch (use implementing-* skills)
• Task is about testing the configuration (use performing-* skills)
• You need to analyze misconfigurations (use analyzing-* skills)
• Task is about building automation (use building-* skills)
• You don't have admin access to the system
• Task requires vendor professional services

Red Flags

• Performing actions without explicit written authorization from the asset owner
• Testing against production systems without a defined scope and rules of engagement
• Sharing sensitive findings or credentials in unencrypted communications
• Failing to properly scope and contain the assessment before starting

Verification

• All steps executed successfully against a test environment before production use
• Output documented with screenshots or logs demonstrating expected behavior
• Results validated against known-good baselines or reference implementations
• Documentation complete enough for another analyst to reproduce findings

Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality

Anti-Rationalization Table