A Certificate Signing Request (CSR) is a formally structured message sent to a Certificate Authority (CA) to request the issuance of a digital certificate. Defined by the PKCS#10 standard (RFC 2986), a CSR contains the applicant's public key, identifying information (the subject distinguished name), and a digital signature created with the applicant's private key. This self-signature proves that the requester possesses the private key corresponding to the public key in the request, a critical security property that prevents attackers from requesting certificates for keys they do not control.

The public key cryptography underlying CSR generation relies on asymmetric encryption, where mathematically related key pairs are generated such that data encrypted with one key can only be decrypted with the other. RSA (Rivest-Shamir-Adleman), introduced in 1977, derives its security from the computational difficulty of factoring the product of two large prime numbers. RSA key sizes of 2048 bits are currently considered secure for most applications, providing approximately 112 bits of security strength. The 4096-bit option doubles the key length for higher security margins but increases computational cost during TLS handshakes. ECDSA (Elliptic Curve Digital Signature Algorithm) achieves equivalent security with much shorter keys: a 256-bit ECDSA key provides comparable security to a 3072-bit RSA key, resulting in faster handshakes and smaller certificates.

The CA workflow upon receiving a CSR depends on the validation level requested. Domain Validation (DV) certificates require only proof that the applicant controls the domain, typically verified through an email to the domain registrant, a DNS TXT record, or an HTTP challenge file. Organization Validation (OV) certificates additionally verify the legal existence and identity of the requesting organization through business registration databases and phone callbacks. Extended Validation (EV) certificates require the most thorough verification, including legal identity confirmation, physical address verification, and operational existence checks, historically resulting in a green address bar indicator in browsers.

The subject distinguished name in a CSR follows the X.500 naming convention, with fields for Common Name (CN, traditionally the domain name), Organization (O), Organizational Unit (OU), Locality (L, city), State (ST), and Country (C, two-letter ISO code). Modern certificates rely primarily on the Subject Alternative Names (SAN) extension rather than the Common Name for domain identification, as RFC 6125 deprecated CN matching in favor of SAN. This means that while the CN field remains conventionally populated, the SAN extension is what browsers actually check when validating that a certificate matches the requested domain. Multiple domains can be included in a single certificate through SAN entries, and wildcard certificates (*.example.com) cover all first-level subdomains of a domain.