How to Generate an OpenSSL Certificate: A Practical Step-by-Step Reference

Generate OpenSSL Certificate: From Key to Signed Certificate in a Few Commands

Generating an OpenSSL certificate typically means creating a private key, building a certificate signing request (CSR), and then either signing it yourself as a self-signed certificate or submitting it to a certificate authority (CA). The exact steps depend on whether you need a certificate for a production server, a development environment, or a testing setup. Below is the standard path for a self-signed certificate, followed by tips for using a CA workflow and common variations you may encounter.

1. Create the Private Key

Use the openssl genrsa command to generate a new RSA key. For most modern setups, 2048-bit or 4096-bit keys are suitable. Save the key to a file you control tightly, since anyone with access to it can impersonate the server.

openssl genrsa -out server.key 2048

2. Create the CSR

Build a certificate signing request from that key. You can fill in the details interactively or supply them on the command line with the -subj flag to skip prompts. The fields you provide (country, state, organization, common name, etc.) appear in the final certificate and are used by clients to verify identity.

openssl req -new -key server.key -out server.csr -subj "/C=US/ST=California/L=San Francisco/O=My Company/CN=example.com"

3. Sign the Certificate

For a self-signed certificate, use the private key as its own CA. Set a validity period (in days) and specify which extensions you want, such as Subject Alternative Names for modern use cases covering multiple domains or IP addresses.

openssl x509 -req -in server.csr -signkey server.key -out server.crt -days 365 -extfile san.cnf

A minimal san.cnf file might include:

[req] distinguished_name = req_distinguished_name [req_ext] subjectAltName = DNS:example.com, DNS:www.example.com, IP:10.0.区0.1

4. Verify the Result

Check the certificate contents to confirm the fields and dates are correct before deploying it.

openssl x509 -in server.crt -text -noout

5. Using a CA Instead of Self-Signing

If a certificate authority will sign your request, submit server.csr to them and receive back a signed certificate and (often) an intermediate bundle. Concatenate the signed certificate with the CA chain into a single PEM file in the correct order: your certificate first, then the intermediate, then the root if required by your deployment target. Keep the private key separate and protected with file permissions so only the service account can read it.

6. Common Variations

• ECDSA keys — Use openssl ecparam -genkey -name prime256v1 for smaller keys with strong security, common on modern Linux systems and in container environments.
• PKCS#12 export — Bundle the key, certificate, and chain into a .p12 or .pfx file when a GUI or platform expects a single encrypted archive: openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt -certfile chain.crt.
• Engine-based signing — Hardware Security Modules or TPMs may require an engine configuration; check your OpenSSL build and documentation for the required -engine flag and its options.

7. Practical Tips

Keep the private key out of version control and avoid committing it to repositories. Rotate it according to your security policy, which may mandate renewal every 90 to 365 days depending on the use case and key strength. For internal tools, a self-signed certificate is often acceptable; for anything facing external clients, a properly chained certificate from a recognized CA reduces trust errors. When in doubt about which extensions or SAN entries to include, consult the documentation for the services you are securing, and test with openssl s_client to confirm the handshake and certificate chain as seen by a client.