1. Executive Summary: What is a Certificate Signing Request (CSR)?
A Certificate Signing Request (CSR) is a block of encoded text sent to a Certificate Authority (CA) to apply for an SSL/TLS digital certificate. It contains your organization's verified domain names, public key, and identity information, signed using your corresponding private key.
Under modern CA/Browser Forum baselines and NIST guidelines, all CSRs must use minimum RSA 2048-bit (or ECDSA P-256/P-384) keys and must explicitly include domain names in the Subject Alternative Name (SAN) extension.
2. Generating CSR & Private Key via OpenSSL CLI
A. Recommended: Single-Command CSR Generation with SAN (RSA 2048/4096)
This command generates both the private key and CSR in a single non-interactive step, embedding multiple SAN domains:
B. Modern Elliptic Curve (ECDSA P-256) Generation
3. Inspecting & Decoding CSR Metadata
Before submitting a CSR to DigiCert, Sectigo, or Let's Encrypt, verify that the attributes, public key size, and signature are intact:
Critical Pre-Deployment Check: Private Key Matching
A common deployment failure is having a CSR that does not match the private key on the server. Verify that the cryptographic moduli match:
4. CSR Audit & Compliance Checklist
| Audit Check | Standard Requirement | Pass Criteria |
|---|---|---|
| Key Length | RSA ≥ 2048 bits or ECDSA ≥ 256 bits | Zero 1024-bit RSA keys generated |
| SAN Presence | All active domains explicitly enumerated in subjectAltName |
Both apex and www subdomains covered |
| Signature Algorithm | SHA-256 or SHA-384 signature hash | Zero MD5 / SHA-1 digest algorithms used |
| Private Key Security | Permissions set to 600 (read/write only by root/owner) |
Private key never transmitted across unencrypted email or tickets |
WebOTG Standards Directorate
WebOTG provides benchmark reference documentation, automated matrix evaluators, and security test harnesses for government digital platforms, WQMS architectures, and STQC compliance frameworks.