Generate and Verify a CSR on Linux or Plan Windows Enrollment

A certificate signing request (CSR) asks an issuer to certify a public key and requested names. It is not an issued certificate, and a valid request signature does not establish website trust. Keep its matching private key secure and submit only the request to the issuer.

Plan the request

List every required hostname and follow the issuer’s key/identity requirements. Use subject alternative names rather than assuming Common Name alone covers the site. A wildcard does not automatically include the bare domain or deeper subdomain levels. Do not create a second independent key after issuance and expect the certificate to match it.

Linux: OpenSSL 3.x example

This Bash example creates synthetic example.com material in a new private temporary directory, avoiding overwriting existing key files. Use an installed, maintained OpenSSL package from your supported operating system:

umask 077
workdir="$(mktemp -d "${TMPDIR:-/tmp}/csr-example.XXXXXX")" || exit 1
cd "$workdir" || exit 1
openssl req -new -newkey rsa:2048 -noenc -sha256 \
  -keyout example.com.key -out example.com.csr -subj '/CN=example.com' \
  -addext 'subjectAltName=DNS:example.com,DNS:www.example.com'

-noenc writes an unencrypted private key; directory/file permissions protect it, not a password. Choose an encrypted-key workflow when required by your deployment. The request’s optional challenge attribute is not the private-key encryption password. Do not print the key just to inspect the request.

openssl req -in example.com.csr -noout -text -verify

Inspect names and requested extensions, then submit the CSR through the issuer’s trusted workflow. An issuer may require additional validation and can apply its own extension policy. Do not self-sign the request and call that a publicly trusted issued certificate.

Windows: use the destination service’s enrollment workflow

For IIS, use the server’s Server Certificates request workflow where supported, then complete the issued request on the machine retaining the matching key and assign the HTTPS binding. If multiple SANs, provider choices or enterprise templates are needed, use an appropriate administrator-reviewed Windows certificate-enrollment/certreq configuration.

The old mixed IIS/MMC instructions forced a legacy key provider without establishing a requirement. Do not select a provider, make a key exportable or submit to an enterprise CA merely to reproduce those screenshots. Protect the machine key store and follow the issuer/service requirements for your Windows version.

References: OpenSSL CSR options; IIS HTTPS binding context; Windows certreq enrollment.

Reviewed October 15, 2026. Linux generation, SANs and request/key matching tested locally; Windows enrollment and public-CA issuance were not tested.