🔐 Decoding OpenSSL Commands on Linux with an AI Assistant

Nobody remembers the openssl flags. I’ve been doing this for two decades and I still can’t recall whether it’s -subject or -subj, whether the order of -in and -noout matters, or which incantation prints a full chain. The openssl binary is essential and infuriating in equal measure: it does everything TLS-related on a Linux box, and its interface is a museum of inconsistent flag conventions. What changed my relationship with it was treating an AI assistant as a fast junior engineer who has memorized the man page so I don’t have to. I describe what I want in English, it gives me the exact command, and I — the human still holding the keys — verify and run it. Here’s how that workflow looks in practice.

Inspecting a certificate without guessing flags

The most common task is also the one I always have to look up: print the human-readable details of a cert.

openssl x509 -in server.crt -noout -text
openssl x509 -in server.crt -noout -subject -issuer -dates

The second form gives you the three things you usually care about — who it’s for, who signed it, and when it expires. When I can’t recall the flags, I ask the AI: “openssl command to print only the SAN entries from a PEM cert.” It knows the answer (-ext subjectAltName) faster than I can find it.

Debugging a live TLS handshake

When a service won’t connect, s_client shows you the actual negotiated chain and cipher.

openssl s_client -connect api.internal:443 -servername api.internal -showcerts </dev/null

The -servername flag sends SNI, which matters on shared hosts. The output is dense: a chain of certs, the negotiated protocol, the cipher suite, and a verify return code. Paste that block into an AI chat with a prompt like:

“This is openssl s_client output. The verify return code is 21. Explain what’s failing in plain terms and what to check, but do not give me any commands that modify the server yet.”

It’ll tell you code 21 means “unable to verify the first certificate” — usually a missing intermediate — and explain the difference between a leaf, an intermediate, and a root. That diagnostic translation is the high-value part. I keep these handshake-debug prompts in my prompt workspace so the whole team uses the same vetted wording.

Pro Tip: Pipe s_client output into a file and redact the IP and internal hostnames before sharing it with any AI tool. A handshake dump can leak your internal naming scheme and topology, which is exactly the kind of detail you don’t want pasted into a third-party service.

Checking expiry across a fleet

Expired certs cause more outages than almost anything else. A one-liner per host, generated with AI help, scales the check.

echo | openssl s_client -connect host:443 2>/dev/null \
  | openssl x509 -noout -enddate

Ask the AI to wrap that into a loop over a host list and emit a warning when expiry is under 30 days. It writes the date math (openssl x509 -checkend 2592000) correctly the first time, where I’d fumble the seconds-in-30-days calculation. Always read the generated loop before running it — confirm it only reads and prints, and isn’t quietly piping anything anywhere.

Generating CSRs and keys safely

When you need a new key and signing request, the flags get long.

openssl req -new -newkey rsa:4096 -nodes \
  -keyout app.key -out app.csr \
  -subj "/CN=app.internal/O=Acme"

This is a spot where I lean on AI to build the -subj string and add SANs via a config file, because the -addext "subjectAltName=..." syntax is unforgiving. But generating private keys is also where you draw a hard line: the AI helps you construct the command, you run it locally, and the resulting .key never leaves the host. Never paste a private key into a chat tool, ever, not even to “ask what’s wrong with it.” If a key has touched a clipboard headed for an LLM, treat it as compromised and rotate it.

Converting between formats

PEM, DER, PKCS#12 — every vendor wants a different one. The conversions are pure flag soup.

# PEM to PKCS#12 bundle for a Java/Windows consumer
openssl pkcs12 -export -in fullchain.pem -inkey app.key -out app.p12
# PKCS#12 back to PEM
openssl pkcs12 -in app.p12 -nodes -out app.pem

This is the single best use of an AI copilot for openssl: describe the source and target format in English (“I have a .pfx, I need separate cert and key PEM files”) and get the exact command. It removes an entire category of trial-and-error.

Verifying a chain before you ship it

Before installing a new cert, confirm the chain actually validates against your CA bundle.

openssl verify -CAfile ca-chain.pem server.crt

A clean server.crt: OK is what you want. Anything else, hand the error to the AI for translation — it’s fluent in openssl’s terse failure messages and will tell you whether you’re missing an intermediate, have the chain in the wrong order, or hit a trust-store gap.

Testing cipher suites and protocol versions

Security audits constantly ask “does this endpoint still allow TLS 1.0?” or “is this weak cipher disabled?” openssl answers both, and the flag combinations are exactly where memory fails.

# Does the server still accept the old protocol?
openssl s_client -connect host:443 -tls1_1 </dev/null
# Force a specific cipher to test whether it's allowed
openssl s_client -connect host:443 -cipher 'DES-CBC3-SHA' </dev/null

A handshake that succeeds with -tls1_1 is a finding; one that fails with “no protocols available” is the result you want. This is a strong spot for AI help because the protocol and cipher flags changed between OpenSSL 1.1 and 3.x — -tls1_1 may need -cipher 'DEFAULT@SECLEVEL=0' on a modern build to even attempt the negotiation. Describe your goal (“check whether TLS 1.0 is still accepted on OpenSSL 3.2”) and the model gives you the version-correct invocation rather than the one from a five-year-old Stack Overflow answer.

Pro Tip: When an old protocol test mysteriously fails to even start, it’s usually your client’s security level blocking it, not the server refusing. Ask the AI to add the right @SECLEVEL so you’re actually testing the server and not your own openssl build’s defaults.

Reading a CSR before you submit it

Before you send a signing request to a CA or internal PKI, confirm it actually contains what you think — the right CN, the right SANs, the right key size.

openssl req -in app.csr -noout -text -verify

The -verify checks the CSR’s self-signature, and -text dumps the fields. Paste that output to the AI and ask it to confirm the SAN list matches the hostnames you intend to serve. Catching a missing SAN here saves a full reissue cycle later, and the model reads the dense ASN.1-style output far faster than you’ll scan it by eye.

Conclusion

openssl stopped being a source of dread once I accepted I’d never memorize it and instead pair with an AI that has. The pattern is consistent: I state intent in plain English, the model produces the exact invocation, and I verify and execute as the human in the loop. The non-negotiables are equally consistent — private keys stay on the host, dumps get redacted before sharing, and the AI never gets credentials or runs commands against prod. For more in this vein, browse the Linux admin category, grab reusable prompts from the Linux admin prompt pack, and if you live in the terminal, Warp makes pasting these AI-suggested commands feel native.