A DevOps Guide to Generate Certificate OpenSSL Commands

In today's cloud-native world, securing every endpoint isn't just a good idea—it's non-negotiable. For any DevOps or platform engineer, knowing how to generate a certificate with OpenSSL has moved from a niche command-line skill to a core competency. It's what stands between you and a secure connection for everything from public-facing web servers to the internal microservices that power your applications. This guide is here to demystify the process, connecting the dots between practical commands and the bigger goals of rock-solid security and operational speed.

Ready to automate your infrastructure and cut down on manual server tasks? Discover how Server Scheduler can streamline your AWS operations and reduce cloud costs by up to 70%.

Why OpenSSL Is a Core DevOps Skill

Mastering OpenSSL is no longer just for security specialists; it has become a daily tool for modern engineering teams. In fast-paced environments, especially within AWS, we constantly spin up new instances, configure load balancers, and deploy applications that all demand encrypted communication. Relying on web UIs to manage certificates is slow, cumbersome, and simply does not scale with the demands of modern infrastructure. This is where proficiency with the OpenSSL command line becomes invaluable, as it enables the scripting and automation of the entire certificate lifecycle, which is crucial for maintaining security and uptime. Whether you are securing a new EC2 instance, an RDS database, or an ElastiCache cluster, the ability to quickly generate keys, Certificate Signing Requests (CSRs), and self-signed certificates is now a fundamental expectation for any DevOps professional.

The push for universal encryption has made OpenSSL more relevant than ever. An incredible 88.08% of all websites now use HTTPS, a significant increase from just 50% in 2016. This trend reflects a broader industry philosophy to encrypt everything, extending beyond public-facing websites to include internal APIs, database connections, and service-to-service communication. For DevOps teams, this means all traffic, not just external, must be secured with TLS. If you are setting up your environment, our guide on how to install software in Linux can assist in getting the necessary tools installed. This industry shift is further detailed in these SSL/TLS trends and statistics. Ultimately, OpenSSL serves as the critical bridge between security requirements and the core DevOps principle of automation. For a deeper dive into building these capabilities, expert DevOps Consulting can provide valuable insights.

Creating Your First Private Key and Self-Signed Certificate

Every journey into SSL/TLS with OpenSSL begins with the creation of a private key. This key is the cornerstone of your secure communications and must be protected diligently. If compromised, it allows unauthorized parties to impersonate your server, making its security paramount. The first step involves generating the key file itself, where you can choose between the reliable RSA algorithm and the more efficient ECDSA. While ECDSA provides equivalent security with smaller keys, RSA remains universally supported and is an excellent starting point. Properly executing these initial steps is fundamental to setting up TLS/SSL, the backbone of how you secure web applications.

To generate a standard 2048-bit RSA key, the command is straightforward: openssl genpkey -algorithm RSA -out private-key.pem -pkeyopt rsa_keygen_bits:2048. This command instructs OpenSSL to create a new private key using the RSA algorithm, with a length of 2048 bits, and save it to a file named private-key.pem.

Callout: A 2048-bit RSA key is the minimum for adequate security today. While 4096-bit keys offer enhanced protection, they introduce a performance overhead that is often unnecessary for internal development or testing environments.

With a private key in hand, you can create a self-signed certificate. This type of certificate is signed by its own private key, making it ideal for development, testing, or internal tools where validation by a public Certificate Authority (CA) is not required. The command openssl req -x509 -new -nodes -key private-key.pem -sha256 -days 365 -out certificate.pem will generate it. OpenSSL will prompt for information to create the Distinguished Name (DN), which identifies the certificate owner. Among these fields, the Common Name (CN) is crucial, as it must match the fully qualified domain name (e.g., dev.example.com) the certificate will secure. If you plan to use this certificate to test your NGINX config, our related guide is a great resource.

Generating a Certificate Signing Request for a CA

When a self-signed certificate is insufficient for a public-facing service, you need a certificate issued by a trusted Certificate Authority (CA). The process begins with a Certificate Signing Request (CSR), a formal, cryptographically signed application containing the necessary information for the CA to issue a publicly trusted certificate for your domain. You generate this request using your private key, but critically, your private key never leaves your server. The CSR is then sent to a CA like Sectigo or Let's Encrypt for signing.

To create a CSR from your private key, you use a command similar to generating a self-signed certificate, but without the -x509 flag. Assuming you have a private-key.pem file, the command is openssl req -new -key private-key.pem -out my-domain.csr. OpenSSL will prompt for the Distinguished Name (DN) information, which the CA will embed into the final certificate. Accuracy is vital here, especially for the Common Name, as any mistake will lead to validation failure.

Before submitting your CSR, it's wise to verify its contents to avoid rejection from the CA. This simple sanity check ensures there are no typos and the request is structured correctly. You can inspect the CSR with the command openssl req -in my-domain.csr -noout -text, which decodes the file and displays its details in a human-readable format. This allows you to confirm that the Common Name and all other information are accurate before proceeding. Understanding how to create a self-signed certificate with OpenSSL provides a solid foundation for these steps.

Securing Multiple Hostnames with Subject Alternative Names

In the past, securing a server involved placing a single domain in the certificate's Common Name (CN) field. This approach is now outdated, as modern applications often serve content from multiple hostnames like www.example.com, api.example.com, and app.example.com from a single IP address. The modern solution for this is a Subject Alternative Name (SAN) certificate. SANs are a standard X.509 extension that allows you to bundle a list of hostnames into a single SSL certificate. This is now an industry standard, as major browsers often ignore the CN field and require SANs to avoid trust errors.

When you need to generate a certificate with OpenSSL that includes SANs, you must use a configuration file. This file specifies the DNS names and IP addresses to include in the request. For example, a file named san.cnf would define the SAN entries under an [alt_names] section. This configuration-driven approach is flexible and essential for automation. If you manage dynamic environments, scripting the creation of these files is a significant advantage. Our guide on how to build a proxy server offers related insights for those managing complex stacks.

With the san.cnf file prepared, you can generate the CSR using the -config flag. The command would be openssl req -new -key private-key.pem -out my-multi-domain.csr -config san.cnf. This instructs OpenSSL to incorporate all settings from the configuration file into the CSR. Using a configuration file makes generating complex certificates a repeatable and version-controlled process, which is far more reliable than interactive prompts, especially within a CI/CD pipeline. Always verify the CSR's contents to ensure the SANs were included correctly before submitting it to a CA.

Essential Conversions and Verification Commands

Engineers frequently need to adapt certificates for different systems, as not all applications use the same certificate formats. Knowing how to convert between formats like PEM and PFX/P12 and verify their contents is a crucial skill for troubleshooting. PEM (Privacy-Enhanced Mail) is a Base64-encoded text format favored by open-source servers like NGINX and Apache. In contrast, PFX (Personal Information Exchange), also known as PKCS#12 or P12, is a binary format that bundles the certificate, private key, and intermediate certificates into a single, password-protected file, commonly used by Windows servers and Java applications.

Being able to perform these conversions from the command line prevents the need for insecure online tools. For example, converting from PEM to PFX is done with openssl pkcs12 -export -out certificate.pfx -inkey private.key -in certificate.crt. The explosive growth of the SSL market, projected to reach $518.4 million by 2032, underscores the importance of these skills as certificate lifespans shorten and automation becomes paramount. Beyond conversion, OpenSSL is a powerful inspection tool. Essential verification commands help debug TLS handshake failures. You can check a certificate's expiration date (openssl x509 -in certificate.pem -noout -enddate) or confirm that a private key and certificate match by comparing their public key hashes. Mastering these commands transforms OpenSSL into a comprehensive management utility. Our Bash scripting cheat sheet can help you automate these crucial checks.

Common OpenSSL Questions Answered

When working with OpenSSL, several common questions often arise. For instance, OpenSSL doesn't "renew" a certificate in the traditional sense. Renewal is a process handled by the Certificate Authority (CA), which issues a new certificate with an updated expiration date. Your role is to generate a new Certificate Signing Request (CSR) using OpenSSL, typically from your existing private key, and submit it to the CA. You are essentially replacing the old certificate, not modifying it.

Another frequent question concerns PEM files. A PEM (Privacy-Enhanced Mail) file is a text file containing Base64 encoded data, typically a private key, a public certificate, or a chain of certificates, enclosed by headers and footers like -----BEGIN CERTIFICATE-----. Its text-based nature makes it highly versatile and the standard for web servers like Apache and NGINX. A single PEM file can contain multiple certificates concatenated together to form a "bundle" or "chain," which is often required by servers to establish a complete chain of trust.

Finally, the error "unable to get local issuer certificate" is a classic issue that usually indicates a missing intermediate certificate. This means the client cannot build a complete trust path back to a trusted root CA. The solution is to ensure your server provides the entire certificate chain, not just the server certificate. This is accomplished by combining your server certificate and the CA's intermediate certificates into a single PEM file and configuring your server to use this bundle.

Related Articles

• How to Create a Self-Signed SSL Certificate with OpenSSL
• A Practical Bash Scripting Cheat Sheet for DevOps
• How to Build a Proxy Server A Step-by-Step Guide

Ready to stop wasting money on idle cloud resources? Server Scheduler gives you a simple, visual way to automate start/stop schedules for your AWS servers, databases, and caches. Start saving in minutes at https://serverscheduler.com.