Cheatsheet: OpenSSL

A private key (genrsa/ecparam output) is the secret you generate and keep -- never send it anywhere. A CSR (Certificate Signing Request, req -new) is a public request containing your public key plus identity info (common name, org, SANs), signed with your private key to prove you hold it -- you send the CSR to a CA. A certificate (x509) is what the CA (or you, for a self-signed cert) issues back: your public key plus identity info, now signed by the CA's key instead of your own, which is what lets others verify it against a trusted root. The private key never appears inside the CSR or the certificate -- only the corresponding public key does.

openssl x509 -in cert.pem -noout -text dumps a full human-readable certificate (issuer, subject, validity dates, Subject Alternative Names, public key, signature algorithm). Narrow it down with -noout plus a specific flag: -dates for notBefore/notAfter, -subject for just the subject line, -issuer for the issuer, or -ext subjectAltName for just the SANs. The same -text/-noout pattern works on a CSR with openssl req -in request.csr -noout -text instead of x509.

PEM is the common Base64-wrapped text format with -----BEGIN ...----- headers -- most Unix/Linux tools (Nginx, Apache, curl) expect this. DER is the raw binary encoding of the same X.509 structure with no headers -- some Windows/Java tooling expects this instead. PKCS#12 (.p12/.pfx) is a binary container bundling a private key together with its certificate (and optionally the CA chain) in one password-protected file -- common for importing into Windows cert stores, browsers, or Java keystores. openssl x509 -inform der/pem and openssl pkcs12 -export/-in handle the conversions between them.

openssl s_client -connect host:443 -servername host opens a real TLS connection and dumps the negotiated protocol version, cipher, and the full certificate chain the server sent -- essential when a browser's padlock doesn't tell you enough, or you're debugging a server behind a load balancer/CDN. -servername is required for virtual-hosted TLS (SNI) setups, otherwise you may get the wrong certificate. Pipe through openssl x509 -noout -dates to just check the expiry, or add -showcerts to see the entire chain the server sent, not just the leaf.

No -- self-signed just means the certificate's issuer and subject are the same entity (it signed itself instead of a CA signing it), which is cryptographically valid and works fine for internal tools, local dev, or anywhere you can manually distribute and trust the specific cert. It's flagged by browsers/clients only because nothing in the public trust store vouches for it, so a client has no automated way to know whether to trust it -- that's a trust-chain problem, not a cryptographic weakness in the certificate itself.