The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →OpenSSL is the command-line toolkit used to create private keys, generate PKCS#10 certificate signing requests (CSRs), inspect X.509 certificates and package them for servers and clients. The dependable workflow is to create a key, produce a CSR with the correct names, obtain a certificate from a certificate authority (CA) or self-sign for a controlled test, verify the certificate and chain, then deploy the required format while keeping the private key secret.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
This guide covers the practical commands, version-sensitive defaults, file conversions and validation failures that matter when working with OpenSSL 1.1.1 and 3.x.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsWhat OpenSSL, a private key, a CSR and a certificate each do
OpenSSL implements SSL/TLS protocols and the cryptographic standards around them, including X.509 certificates, CSRs and certificate revocation lists. These objects have different jobs:
- Private key: The secret half of a key pair. A server uses it to prove possession of the public key in its certificate. Anyone who obtains it may be able to impersonate the service.
- Public key: The shareable half of the pair. It is placed in a CSR and, later, in the issued certificate.
- CSR: A PKCS#10 request containing the public key, a subject and requested extensions. It does not contain the private key. A CA signs a certificate using the information it accepts from the request and its own validation policy.
- Certificate: An X.509 statement signed by an issuer. It binds a public key to names such as
www.example.com, and carries validity dates, issuer data and extensions. - Chain: The certificate plus any intermediate certificates needed to reach a trusted root. A certificate can parse correctly while still failing trust or hostname validation.
For public HTTPS, use a certificate that chains to a CA trusted by the clients. A self-signed certificate is appropriate for a lab, an internal trust domain where you distribute your own root, or an isolated test—not for ordinary public browser trust.
Check the OpenSSL release before relying on defaults
Record the binary and its build details before creating production material:
openssl version -aOpenSSL releases differ in defaults and option names. Since OpenSSL 3.2, certificates generated by req are X.509 version 3 unless you explicitly request -x509v1; key-identifier extensions are included by default. Since OpenSSL 3.3, a failed req -verify check returns exit status 1, which makes shell automation safer. The current option for generating an unencrypted private key is -noenc; -nodes is deprecated in OpenSSL 3.0, although older installations may still accept it. Keep the version, command line and configuration file with your renewal records.
Generate a private key and CSR
One command for a new RSA key and CSR
The req command is OpenSSL’s “PKCS#10 certificate request and certificate generating command.” This workflow creates a 2048-bit RSA key and a CSR:
openssl req -newkey rsa:2048 -keyout private.key -out request.csrOn versions that support the modern behavior, OpenSSL asks for a passphrase and writes an encrypted private key. Enter the requested subject fields carefully, but do not assume the Common Name alone covers every hostname. When a CA accepts the request, the certificate will be issued according to its validation rules, not merely whatever text was entered at the prompt.
Create a CSR from an existing key
Use this when a key has already been generated and must remain the same during a renewal:
openssl req -new -key private.key -out request.csrOpenSSL prompts for the subject unless you provide a configuration file or other explicit options. The private key stays local; send the resulting request.csr to the CA, never the key.
Leave a generated key unencrypted only when the service requires it
Some unattended services cannot unlock an encrypted key at boot. With current OpenSSL releases, explicitly request an unencrypted output:
Rank #2
- 8 1/2 x 11 Teacher Record Book with Teacher's daily schedule
- Special duties
- Supplementary data sheets
- Grade recording sheets for 40 weeks with shading every other two lines
- Perforated grade recording sheets - write the class list only once
openssl req -newkey rsa:2048 -noenc -keyout private.key -out request.csrAn unencrypted key must have stronger filesystem and secret-management controls because possession of the file is enough to use it. If you see older instructions using -nodes, treat that spelling as deprecated in OpenSSL 3.0 and check the installed release.
Put Subject Alternative Names in the request
Modern hostname validation uses the certificate’s Subject Alternative Name (SAN) extension. Use a configuration file so every requested DNS name is explicit and reproducible:
[ req ]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
C = US
ST = California
L = San Francisco
O = Example Organization
CN = www.example.com
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = www.example.com
DNS.2 = example.comSave it as openssl.cnf, then run:
openssl req -new -key private.key -out request.csr -config openssl.cnfInclude only names you control and actually need. The CA may remove or alter requested extensions, so inspect the issued certificate rather than assuming the CSR was copied verbatim.
Inspect and verify a CSR before submitting it
Check that the request can be parsed and that its signature verifies:
openssl req -in request.csr -text -verify -nooutRead the displayed public-key algorithm, subject, requested SANs and other extensions. A successful parse proves the file is structurally valid and the CSR was signed by its corresponding private key; it does not prove that a CA will validate the organization or names.
Confirm that the request contains no private material before transferring it. A normal PEM CSR begins with -----BEGIN CERTIFICATE REQUEST----- (or the longer “NEW CERTIFICATE REQUEST” label) and can be shared with the CA. A private key begins with a private-key label and must remain restricted.
Create a self-signed certificate for testing
For a temporary test endpoint, generate a key and self-sign in one step:
Rank #3
- Includes (one)Heavy Duty, levant-grain, imitation leather binder . Available in Black or Burgundy
- 10 Standard Wording stock Certificates. (Wording will reflect entity type)
- 7 position Index Tabs
- Stock Transfer Ledger or Membership Roll Sheets.
- If you want us to customize a kit for you, just search for our new "Corpkit Customized" kit!
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pemThis command normally encrypts the generated key and asks for a validity period and subject information. Add -days when you need a defined test lifetime; do not treat a long test lifetime as a production security policy. A self-signed certificate’s issuer and subject are the same, so clients that do not already trust that certificate (or its private root) will show an untrusted-issuer error. Installing it in a test client’s trust store is a deliberate trust decision, not a way to obtain public HTTPS trust.
For a self-signed certificate with SANs, use a configuration file containing the req_extensions and subjectAltName sections shown above, and add the certificate-extension option supported by your release when invoking req -x509. Verify the result afterward; option availability differs between older 1.1.1 builds and 3.x.
Read an X.509 certificate with openssl x509
Display every encoded field, including extensions and the public key:
openssl x509 -in cert.pem -text -nooutFor a compact deployment check, print the dates, issuer and subject:
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallopenssl x509 -in cert.pem -dates -issuer -subject -nooutCheck whether the certificate will expire within 30 days (2592000 seconds):
openssl x509 -in cert.pem -checkend 2592000 -nooutThe command exits successfully when the certificate remains valid for that interval and fails when it does not, making it useful in renewal scripts. It does not check whether a client trusts the issuer or whether a hostname matches.
Review intended uses such as server authentication and key-encipherment with:
openssl x509 -in cert.pem -purpose -nooutPay particular attention to:
- Not Before and Not After times, interpreted with the system clock and the certificate’s time zone convention.
- Subject Alternative Names, including every production DNS name and IP address that clients use.
- Issuer and Authority Key Identifier, which help identify the issuing chain.
- Key Usage and Extended Key Usage, which must permit the operation (for example, server authentication).
- Public-key type and size, signature algorithm, serial number and fingerprints.
Distinguish parsing from trust, chain and hostname verification
openssl x509 -text only decodes the certificate. To validate a chain, supply trust anchors and any required intermediates to openssl verify:
openssl verify -CAfile trusted-root.pem -untrusted intermediate.pem cert.pemUse the CA bundle appropriate to the client environment. A successful result means the chain can be built to the supplied trust material under that verifier’s rules; it does not guarantee that every operating system has the same roots.
When the OpenSSL build supports hostname verification, test the actual name used by the client:
openssl verify -CAfile trusted-root.pem -untrusted intermediate.pem -verify_hostname www.example.com cert.pemFor a service-specific test, also connect with a TLS client that sends the correct SNI name, because a server may present different certificates for different virtual hosts. A certificate can be valid in isolation yet fail when the server omits an intermediate, sends the wrong SNI certificate or uses a private root unknown to the client.
Convert common certificate and key formats
PEM is Base64 text with boundary lines and is common in Unix server configurations. DER is the binary encoding of the same ASN.1 structures. PKCS#12 (usually .p12 or .pfx) is a password-protected bundle that can contain a private key, certificate and chain. PKCS#7 (often .p7b) commonly carries certificates and a chain but does not carry a private key.
Recommended Free Tools
| Task | Command | Result and caution |
|---|---|---|
| PEM certificate to DER | openssl x509 -in cert.pem -outform der -out cert.der |
Binary certificate; the key is not included. |
| DER certificate to PEM | openssl x509 -inform der -in cert.der -outform pem -out cert.pem |
Text PEM certificate. |
| Export a PKCS#12 bundle | openssl pkcs12 -export -inkey private.key -in cert.pem -certfile chain.pem -out bundle.p12 |
Prompts for a bundle password; include the intermediate chain needed by the target. |
| Extract a private key from PKCS#12 | openssl pkcs12 -in bundle.p12 -nocerts -out key.pem |
Prompts for the bundle password and may write an encrypted PEM key. |
| Extract the end-entity certificate | openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out cert.pem |
Writes the client/server certificate without private key material. |
| Extract certificates from PKCS#7 | openssl pkcs7 -in bundle.p7b -print_certs -out certs.pem |
PKCS#7 contains certificates, not the private key. |
| Read binary PKCS#7 | openssl pkcs7 -inform der -in bundle.p7b -print_certs -out certs.pem |
Use -inform der only when the input is binary. |
After every conversion, inspect the output and confirm which certificate is the leaf and which files are intermediates. Do not overwrite the only copy of a key during a format change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Match the private key to the certificate
A frequent deployment error is pairing a new certificate with an old key. Compare their public keys without exposing the private key:
openssl x509 -in cert.pem -pubkey -noout > cert-public.pem
openssl pkey -in private.key -pubout > key-public.pem
diff cert-public.pem key-public.pemNo differences indicate that the public key in the certificate matches the private key. If the files differ, locate the original key used for the CSR or request a replacement certificate for the key you intend to deploy.
Diagnose certificate validation failures
Hostname mismatch
The requested DNS name is absent from SAN, misspelled, or the client is connecting by an alias not covered by the certificate. Issue a certificate containing every required SAN and test the exact hostname, including the SNI name.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Expired or not-yet-valid certificate
Compare Not Before and Not After with the client and server clocks. Correct clock synchronization, then replace a certificate outside its validity window.
Untrusted issuer or incomplete chain
The client does not trust the root, or the server sent only the leaf certificate. Install the appropriate private root in controlled environments or configure the server with the leaf followed by the required intermediate certificates. Never substitute an unrelated root certificate.
Wrong key, usage or algorithm
A certificate may be paired with the wrong private key, lack server-authentication usage, or use an algorithm rejected by the client policy. Compare public keys, inspect Key Usage and Extended Key Usage, and check the client’s supported algorithms.
Format and password errors
A binary DER file passed as PEM, a PKCS#12 password entered incorrectly, or an encrypted key supplied to a service that cannot prompt will all prevent loading. Identify the format, convert explicitly with -inform/-outform, and arrange secure noninteractive key unlocking where required.
Free tools Windows power users keep installed
One-click scans. No signup required.
Revocation and policy failures
Expiration and chain checks do not prove that a certificate has not been revoked. Clients may apply CRL, OCSP, algorithm, name-constraints or enterprise policy checks. Follow the client or CA’s revocation and policy diagnostics rather than treating a successful local parse as final approval.
Operational checklist before deployment
- Run
openssl version -aand record the release. - Generate or select the private key; protect it with restrictive permissions and approved secret storage.
- Create a CSR with explicit SANs and retain the exact command and configuration.
- Inspect the CSR and verify its signature before sending it to the CA.
- When the certificate arrives, inspect dates, SANs, issuer, key usage, public key and chain.
- Verify the chain with the intended trust bundle and test the real hostname.
- Confirm that the certificate’s public key matches the deployed private key.
- Convert to the server’s required PEM, DER, PKCS#12 or PKCS#7 packaging without distributing the private key unnecessarily.
- Set an expiry alert before the validity window becomes critical, and retain a documented renewal procedure.
The safest OpenSSL practice is reproducibility: keep the version, configuration, SAN list, file formats, trust bundle and command options alongside the certificate inventory, while treating every private key as a secret throughout its entire lifecycle.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
