Public Key Infrastructure (PKI) forms the foundation of modern web security, enabling encrypted, authenticated communication between web browsers, API clients, and cloud servers via TLS/SSL certificates. A Certificate Signing Request (CSR) is an encoded block of text in PEM/DER format containing a server's public key and organizational identification details. A system administrator submits the CSR to a trusted Certificate Authority (CA) (such as Let's Encrypt, DigiCert, Sectigo, GlobalSign, or AWS Certificate Manager) to receive a digitally signed X.509 SSL/TLS certificate.

When requesting an SSL/TLS certificate, two cryptographic files are created as a matched keypair:

• Private Key (`.key`): Kept strictly secret on your origin server, load balancer, or HSM (Hardware Security Module). It decrypts incoming TLS sessions and generates digital signatures. It must NEVER be shared or transmitted across unencrypted networks.
• Public Key & CSR (`.csr`): Sent to the CA. The CSR contains the server's Public Key, Subject Distinguished Name (DN) attributes, and requested extension attributes—most importantly Subject Alternative Names (SANs).

The OpenSSL command-line tool utilizes configuration files (.conf or .cnf) to automate key and CSR generation. Using an explicit configuration file is the enterprise industry standard because it allows version controlling your CSR settings and prevents typos during manual interactive CLI prompts.

• `distinguished_name = req_distinguished_name`: Tells OpenSSL which configuration block defines the organization's identity credentials.
• `req_extensions = v3_req`: Directs OpenSSL to include X.509 version 3 extensions (such as subjectAltName and keyUsage) directly inside the generated CSR.
• `prompt = no`: Critical for DevOps Automation. Setting prompt = no instructs OpenSSL to read all values strictly from the configuration file rather than prompting the user on the command line. This allows seamless integration into CI/CD pipelines (e.g. Azure DevOps, GitHub Actions, Ansible, Terraform, Jenkins).

• `C = IN` (Country): Two-letter ISO 3166-1 alpha-2 country code (e.g., IN for India, US for United States, GB for United Kingdom).
• `ST = PY` (State/Province): Full or abbreviated state/province name (e.g., PY or Pudhucherry, California, London).
• `L = Pudhucherry` (Locality): City or municipality where the organization is legally registered.
• `O = KOSOFT IT SOLUTIONS PVT LTD` (Organization): Registered legal corporate name.
• `OU = IT` (Organizational Unit): Internal division or engineering team (e.g., IT, DevOps, Cloud Infrastructure).
• `CN = demo.com` (Common Name): The primary domain name. For direct hostname certificates, use demo.com or app.demo.com. For wildcard certificates, use *.demo.com or demo.com.

• `keyUsage = keyEncipherment, dataEncipherment`: Declares that the generated public key will be used for asymmetric key exchange and data encryption.
• `extendedKeyUsage = serverAuth`: Specifies that the certificate is authorized for TLS Web Server Authentication.
• `subjectAltName = @alt_names`: Points to the list of hostnames under [alt_names]. Modern web browsers (Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge) enforce SAN validation and ignore the legacy `CN` field.
• DNS.1 = demo.com & DNS.2 = *.demo.com**: Lists explicit domain names. Combining demo.com and *.demo.com ensures that both the root domain and all first-level subdomains are covered by a single certificate.

A Wildcard SSL Certificate utilizes an asterisk wildcard character (*) in the host portion of the domain name (e.g. *.demo.com) to secure an unlimited number of first-level subdomains under the same parent domain using a single SSL certificate and private key pair.

• Multi-Tenant SaaS Architectures: Multi-tenant SaaS platforms dynamically assign custom subdomains to new organization accounts (e.g. acme.demo.com, globex.demo.com). Using a wildcard certificate allows spinning up new tenant subdomains dynamically without requesting a new certificate from a CA.
• Cloud Load Balancers & Kubernetes Ingress: Deploying a single wildcard certificate on an AWS Application Load Balancer (ALB), Nginx Ingress Controller, or HAProxy simplifies SSL termination across dozens of microservices.
• Simplified Renewal & Lifecycle Management: Instead of managing 50 individual SSL certificates with varying expiration dates, system administrators manage a single wildcard certificate renewal cycle.

• RSA 2048-bit: The baseline security standard. Provides widespread compatibility with legacy operating systems, older Android devices, and legacy embedded hardware.
• RSA 4096-bit: Provides high cryptographic resilience for long-term data security, but increases CPU overhead during TLS handshake cryptographic computations by ~5x.

• ECDSA P-256 (prime256v1 / secp256r1): The modern recommended standard for cloud applications. A 256-bit EC key provides security equivalent to a 3072-bit RSA key while executing TLS handshakes substantially faster with smaller packet sizes.
• ECDSA P-384 (secp384r1): High-grade elliptic curve cryptography used in military, financial, and compliance-critical environments.

Create a file named req.conf in your terminal workspace containing your identity and SAN definitions.

• -new: Instructs OpenSSL to generate a new Certificate Signing Request.
• -newkey rsa:2048: Generates a new 2048-bit RSA private key simultaneously.
• -nodes: ("No DES") Keeps the private key unencrypted on disk (required for automatic web server restarts without prompting for a password).
• -keyout demo.com.key: Specifies the output filename for the private key.
• -out demo.com.csr: Specifies the output filename for the CSR.
• -config req.conf: Supplies the configuration file containing identity and SAN rules.

Before submitting the CSR to your CA, inspect the encoded X.509 fields:

Ensure that the CSR public key matches the private key modulus:

*(If both MD5 hash outputs match exactly, the private key and CSR are validly paired.)*

• Strict Permissions (`chmod 600`): Secure the private key file immediately after creation:

chmod 600 /etc/ssl/private/demo.com.key

• Zero Expose Policy: Private keys must never leave your secure server infrastructure. Never upload private keys to public online converters or commit them to Git repositories.
• Passphrase Protection for Off-site Backups: Encrypt private key backups with AES-256 before storing them off-site:

openssl rsa -in demo.com.key -aes256 -out demo.com.secure.key

• Routine Key Rotation: Rotate keys at least once annually or automatically every 90 days using ACME protocols (Let's Encrypt / certbot).