Creating a certificate with OpenSSL generates a digitally signed X.509 certificate using cryptographic keys and configuration files. This process authenticates identity and enables encrypted communication for websites, APIs, and internal services.
OpenSSL is a toolkit for managing cryptographic operations. The openssl req command generates a certificate signing request (CSR), while openssl x509 creates a self-signed certificate from that CSR. These tools are essential for securing TLS/SSL connections without relying on public Certificate Authorities (CAs).
When you run openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365, OpenSSL creates a private key and a self-signed certificate valid for one year. The output files are PEM-encoded, meaning they contain base64 data wrapped in -----BEGIN PRIVATE KEY----- and -----BEGIN CERTIFICATE----- headers.
OpenSSL uses asymmetric cryptography. A private key encrypts data that only the corresponding public key can decrypt. During certificate creation, the private key signs a public key and metadata (subject name, validity period, etc.) to form a certificate.
The process begins with generating a private key using openssl genrsa. This key remains secret and must be protected. Next, openssl req prompts for details like country, organization, and domain name. These values populate the certificate's subject field.
After collecting input, OpenSSL signs the certificate with the private key. The signature ensures anyone verifying the certificate can confirm it hasn't been altered and was issued by the holder of the private key. This chain of trust is fundamental to secure communication.
There are two primary types of certificates generated via OpenSSL: self-signed and CA-signed. Self-signed certificates are valid only for internal testing or local development. They don't verify against public trust stores and trigger browser warnings.
CA-signed certificates come from trusted Certificate Authorities like Let's Encrypt or DigiCert. To obtain one, you generate a CSR with openssl req -new -keyout key.pem -out csr.pem, then submit the CSR to a CA. Once approved, the CA returns a signed certificate.
| Type | Use Case | Validity | Trust Level |
|---|---|---|---|
| Self-signed | Internal apps, testing, dev environments | Configurable (e.g., 365 days) | None (not trusted by browsers) |
| CA-signed | Production websites, public APIs | 90 days (Let's Encrypt), up to 2 years (commercial) | High (trusted by default) |
Configuration files control advanced settings. The default config file is located at /usr/lib/ssl/openssl.cnf on Linux systems. You can override it with -config path/to/custom.cnf.
A custom config file lets you define extensions such as subjectAltName for multiple domains, keyUsage restrictions, or extendedKeyUsage for server/client authentication. Without these, the certificate may fail validation in strict environments.
Many assume that creating a certificate with OpenSSL automatically makes it trusted. That's false. Browsers and operating systems maintain their own root store of trusted CAs. A self-signed certificate won't be accepted unless explicitly added to the trust store.
Another error is omitting the -nodes flag when generating a key. Without it, OpenSSL prompts for a passphrase. If you're scripting or automating, this causes the process to hang waiting for input. Always use -nodes for automated workflows.
Some users confuse req and x509 commands. req creates a CSR; x509 creates a self-signed certificate. Running openssl x509 -req -in csr.pem -signkey key.pem -out cert.pem signs a CSR with a private key, producing a certificate.
One non-obvious fact: OpenSSL defaults to SHA-1 hashing in older versions. SHA-1 is deprecated due to collision vulnerabilities. Modern systems require SHA-256. Always specify -sha256 in your command:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -sha256Suppose you're running a Node.js app on localhost with HTTPS. You need a certificate for https://localhost. Use this sequence:
openssl genrsa -out localhost.key 2048openssl req -new -keyfile localhost.key -out localhost.csropenssl x509 -req -in localhost.csr -signkey localhost.key -out localhost.crt -days 365https.createServer({ key: fs.readFileSync('localhost.key'), cert: fs.readFileSync('localhost.crt') }, app)This setup allows the server to serve content over HTTPS. The browser shows a warning because the certificate isn't from a trusted CA. Manually import localhost.crt into your OS's trust store to remove the warning.
I've used this method to test API endpoints behind mutual TLS authentication. The same workflow applies to internal microservices communicating over HTTPS within a Kubernetes cluster.
Understanding the difference between a CA and a leaf certificate is critical. A CA issues certificates; a leaf certificate secures a service. You can't sign a leaf certificate without a CA's private key.
Always verify your certificate with openssl x509 -in cert.pem -text -noout. This displays the subject, issuer, validity dates, and extensions. Check that Subject Alternative Name includes all required domains.
Use openssl verify -CAfile ca.crt cert.pem to validate a certificate chain. If the output says "OK," the certificate is properly signed and trusted.
Creating a certificate with OpenSSL is a foundational skill for securing networked applications. Whether for development, internal services, or public-facing sites, mastering these commands prevents configuration errors and security gaps.
Follow the steps above to generate a valid certificate using OpenSSL. Ensure you protect private keys, use strong algorithms, and validate outputs before deployment.