What a certificate signing request contains
A CSR is a PKCS#10 structure, defined in RFC 2986. It carries a subject name, your public key and a set of attributes, all signed with your private key. That signature proves you hold the key matching the public half. The CA validates the names, copies them and the public key into a certificate, and signs it with its own key. Your private key never goes to the CA.
The request this tool writes has a subject such as C=GB, ST=England, L=London, O=Example Ltd, CN=www.example.com and one attribute: an extension request holding the Subject Alternative Name list. It is output as PEM between -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines, the form that CA order pages ask you to paste.
Filling in the subject and names
Common Name must be a hostname, a wildcard such as *.example.com, or an IP address; anything else stops with a message that the common name must be a domain name. Each additional name gets the same check, and the ones that fail are listed. A wildcard covers one label, so *.example.com matches www.example.com but not example.com itself. Add the bare domain as an additional name if you want both.
For a domain-validated certificate the CA checks control of the hostnames and ignores the rest, so the organisation fields can stay empty. Organisation-validated and extended-validation certificates are different: the CA compares Organization, City, State and Country with official records. Country must be the two-letter ISO code, for example US, GB or IN. Email is optional and is added to the subject as an emailAddress attribute.
RSA or ECDSA, and which size
RSA 2048 is the default because every server, client and CA accepts it, and 2048 bits is the minimum publicly trusted CAs allow. RSA 3072 and 4096 give a larger margin at the cost of bigger certificates and slower signing in each TLS handshake. ECDSA P-256 keys are far smaller and sign faster. P-384 is the stronger curve. Some old clients and appliances lack ECDSA support, so check before you switch.
The request is signed with SHA-256 for all three RSA sizes and for P-256, and with SHA-384 for P-384. That choice affects only the signature on the CSR itself. The CA decides which algorithm signs the certificate it issues to you.
Looking after the private key
The key is exported as unencrypted PKCS#8 PEM, the block that starts -----BEGIN PRIVATE KEY-----. Nginx, Apache and most other servers read it directly. Unencrypted means anyone who can read the file can impersonate your site, so the file's location and permissions are its protection.
If the key is lost, the certificate issued for it is useless, and nothing in the CSR or the certificate can rebuild it. Generate a new pair and ask the CA to reissue. Where policy forbids keys on workstations, run the OpenSSL command printed under the form on the server itself.
- Download the .key file before leaving the page; it is not stored
- Move it to the server and restrict access, for example chmod 600
- Never email it, paste it into a ticket or send it to the CA
- To add a passphrase: openssl pkey -in private.key -aes256 -out private.enc.key
From request to installed certificate
Before ordering, check the domain's CAA record with the DNS lookup: if CAA records exist and none names your CA, the CA must refuse to issue. After validation the CA returns the certificate, usually with its intermediates. Paste it into the certificate decoder to confirm the names and key type, and use the certificate converter if it arrived as a .p7b and your server wants PEM.
The generator has limits. It always creates a new key and cannot build a request for a key you already have. It adds no extension other than Subject Alternative Name, sets no passphrase, and offers neither Ed25519 nor RSA below 2048 bits. For any of those, adapt the OpenSSL command.