Skip to main content
This lesson explains what SSL/TLS certificates do, how they’re used, and how to create and inspect them on Linux using OpenSSL. It preserves the original sequence of diagrams and examples while improving readability and SEO relevance for terms like TLS, X.509, CSR, OpenSSL, and self-signed certificates. First, a clarification: what people historically called “SSL” is today actually TLS. The old name stuck in many tools and documentation, but TLS is the modern, secure protocol that replaced SSL.
SSL (Secure Sockets Layer) is the historical name. TLS (Transport Layer Security) is the modern protocol that fixes many of SSL’s security problems. Many tools still use “SSL” in their names (for example, OpenSSL), but they work with TLS certificates and TLS connections.
A slide titled "Clarification: What we Call SSL Nowadays is Actually TLS" that defines SSL as "secure sockets layer" and TLS as "transport layer security." It also shows a diagram of a yellow SSL stack being "upgraded" (dashed arrow) to a larger teal TLS stack.

​
What do certificates do?

TLS/X.509 certificates address two fundamental problems when sending sensitive data (passwords, credit cards) to a website:
  • Authentication — prove the website is the legitimate site (for example, kodekloud.com) and not an impostor.
  • Encryption — ensure the connection between client and server is private and all data in transit is encrypted.
In short: certificates authenticate a server’s identity and enable encrypted traffic between client and server.
A slide titled "What are SSL Certificates?" showing a user, a shield/lock between the user and a website labeled "Encrypt," and a certificate scroll with a gavel labeled "Authenticate," illustrating that SSL provides encryption and authentication for websites.

​
Tools on Linux: OpenSSL

OpenSSL is the de facto cryptography toolkit used on Linux for generating and inspecting TLS/X.509 certificates, private keys, and certificate signing requests (CSRs). Despite its name referencing “SSL”, OpenSSL fully supports modern TLS and X.509 certificates.
A presentation slide titled "How to Create TLS/SSL Certificates on Linux" listing what OpenSSL can be used for. It shows bullet points like creation/management of private and public keys, generation of X.509 certificates/CSRs, message digests, encryption/decryption, SSL/TLS testing, S/MIME handling, and timestamp requests.
To see OpenSSL’s top-level help:
OpenSSL organizes functionality into subcommands such as req (request, for CSRs), x509 (for certificates), rsa, genpkey, pkcs12, and many more. For subcommand-specific help, read the corresponding man page:
You can also run openssl <subcommand> -help for quick usage information.

​
When to use a CSR vs. a self-signed certificate

  • CSR (Certificate Signing Request): generate a key + CSR and submit the CSR to a Certificate Authority (CA) to obtain a publicly trusted certificate.
  • Self-signed certificate: create and sign the certificate yourself. Useful for development, testing, or closed environments where you control client trust stores.

​
Typical workflow at a glance

​
Working with certificate signing requests (CSRs)

When you want a publicly trusted certificate, you generate a CSR and send it to a CA. The CA validates your identity and signs the CSR, producing a certificate that browsers will trust.
A slide titled "What is a Certificate Signing Request (CSR)?" showing icons for a private key, a certificate signing request, and a user. A Google logo at the top suggests the certificate authority in the diagram.
Generate a private key and CSR in one step:
Options explained:
  • -newkey rsa:2048 — create a new RSA key (2048 bits) and a CSR.
  • -keyout key.pem — save the private key to key.pem.
  • -out req.pem — save the CSR to req.pem.
By default OpenSSL will prompt for a passphrase to encrypt the private key (omit encryption with -nodes) and then prompt for Distinguished Name (DN) fields (Country, State, Locality, Organization, Common Name, etc.). Historically the Common Name (CN) indicated the hostname, but modern clients rely on the Subject Alternative Name (SAN) extension for hostname verification. Ensure the website hostname appears in SAN (and/or CN for compatibility), e.g., www.kodekloud.com. A CSR file (PEM format) looks like this:
In practice, you send req.pem to your chosen CA; they will verify and return a signed certificate.

​
Generating a self-signed certificate

For internal or development use, create a self-signed X.509 certificate and (optionally) an unencrypted private key in one command:
Options:
  • -x509 — create a self-signed X.509 certificate instead of a CSR.
  • -newkey rsa:4096 — generate a new RSA key with 4096 bits.
  • -nodes — do not encrypt the private key (no passphrase).
  • -days 365 — certificate validity length in days.
  • -keyout / -out — file names for the private key and certificate.
When executed, OpenSSL prompts for DN fields. You can accept defaults or enter custom values. Example DN prompts:

​
Inspecting certificates (X.509)

Certificates in PEM form are base64 with header/footer and are not human-friendly to read directly. Use openssl x509 to view certificate details:
Sample (truncated) output:
Useful openssl x509 printing options: (See openssl x509 -help for complete option list.)

​
Quick mental model

  • Use openssl req to generate a new private key and CSR or to create a self-signed certificate (-x509).
  • Use openssl x509 to inspect or manipulate existing X.509 certificate files.

​
Common commands you’ll reuse

Also consult the manual pages regularly:
If you need certificates trusted by public browsers, generate a CSR (openssl req -new ...) and submit it to a Certificate Authority. For internal/testing scenarios you can self-sign (openssl req -x509 ...) and add that certificate to your clients’ trust stores.
We hope this guide helps you generate and inspect TLS (formerly “SSL”) certificates using OpenSSL. Use the man pages (man openssl-req, man openssl-x509) and the -help flag for each subcommand to explore additional options and examples.

Watch Video