OpenSSL cheat sheet

Key generation

openssl genpkey -algorithm ed25519 -out privkey.pem
openssl genpkey -algorithm rsa -pkeyopt bits:4096 -out privkey.pem
(Old-style) openssl genrsa -out privkey.pem 4096

Note on key parts

The "public" and the "private" key files do not form a relationship of reciprocally needed parts. The private key file always contains the public portion too. The public key file can always be regenerated from the private key file, like so:

Generate some RSA key:
openssl genpkey -algorithm rsa -pkeyopt bits:512 -out privkey.pem
Show components/parameters inside a "private" key file:
openssl pkey -in privkey.pem -text
RSA has lots of parameters in contrast to X25519 or Ed25519.
Show components/parameters inside a "public" key file:
openssl pkey -in privkey.pem -pubout | openssl pkey -pubin -text

25519 who?

Curve25519 is a Montgomery curve.
X25519 is an Elliptic-Curve Diffie-Hellman (ECDH) key exchange protocol that uses the x coordinate of Curve25519. (For key exchange, x is sufficient.)
Ed25519 is an Edwards Digital Signature Algorithm using the (twisted) Edwards form of Curve25519 that is birationally equivalent to Curve25519. Both x and y coordinates are used (as required by signing).

(Thanks StackExchange)

Possible extensions values

Possible values for nsCertType: client, server, email, objsign, sslCA, emailCA, objCA
Possible values for keyUsage: digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly
Possible values for extendedKeyUsage (EKU): serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, OCSPSigning, msCodeInd, msCodeCom, mcCTLSign, msEFS
Root CAs / Intermediate CAs should not have any EKUs specified (thanks SO). They should have keyCertSign. End-entity certs should not have CA extensions. The basicConstraints field's CA subfield should always be present with a value (either as CA:true or CA:false).

Generation of S/MIME certificates

Generation of a self-signed certificate:
openssl req -x509 -out cert.pem -key privkey.pem -days 365 -subj "/CN=my@address.de" -addext subjectAltName="email:my@address.de" -addext basicConstraints="critical,CA:FALSE" -addext keyUsage="critical,digitalSignature,keyEncipherment" -addext extendedKeyUsage="clientAuth,emailProtection"
(For making CA + CA-based end-user certificate, see further below.)
Generating a PKCS#12 formatted container of a certificate (either self-signed or CA-based):
openssl pkcs12 -export -out cert.pfx -in cert.pem -inkey privkey.pem -name "Descriptive Name (my@address.de)"
Windows/Outlook notes on dealing with these self-generated certificates:
- Start the certificate manager: certmgr.exe currentUser
- Importing an Ed25519 certificate into the Trust Center is possible, but Windows does not know what to do with the item.
- Self-signed certificates such as that one need to be copied to the Trust CA Root
- While arbitrary-keyed PFX files can be imported, only certificates with EKU "emailProtection" can be selected when trying to activate certificate use in Outlook.
Grommunio notes:
- Importing an Ed25519 certificate into g-web settings is possible, but utilizing the certificate runs into problems (messages so signed/encrypted are empty as of g-web-3.9).

A case against using `openssl ca`

With the default openssl.cnf, openssl ca expects a certain directory structure (./demoCA/newcerts etc.) as it will auto-track serial number generation and indices. Below, we will look at manually managing absolutely every aspect without requiring any particular path. For absolutely quick-and-dirty CAs, all of the indexing can be ignored.

One-step generation of CA/self-signed certificate

openssl req -x509 -nodes -newkey ed25519 -out myca.pem -keyout myca.key -days 365 -subj /O=CA -addext basicConstraints="critical,CA:TRUE" -addext nsCertType="sslCA,emailCA" -addext keyUsage=keyCertSign,cRLSign

Multi-step generation of CA/self-signed certificate

Use genpkey from above for making myca.key.
openssl req -nodes -out myca.req -newkey ed25519 -subj /O=CA -addext basicConstraints=critical,CA:true -addext nsCertType=sslCA,emailCA -addext keyUsage=keyCertSign,cRLSign
openssl x509 -req -in myca.req -signkey myca.key -days 365 -copy_extensions copy -set_serial 1 -out myca.pem

Curious looking invocations

openssl req -x509: Asking the "req" subprogram to directly proceed to generation of an X.509 certificate. Normally, "req" would generate a Certificate Signing Request (CSR).
openssl x509 -req: Telling the "x509" subprogram that the -in input file is a CSR. Normally, "x509" expects the input file to be an X.509 certificate.

Generation of a CA-capable server certificate from Root CA

Assuming the server will be reached with https://127.0.0.2/ or e.g. mysql -h 127.0.0.2 …:
openssl req -nodes -newkey ed25519 -out mysrv.req -keyout mysrv.key -subj /CN=127.0.0.2 -addext basicConstraints=critical,CA:true -addext nsCertType=sslCA,emailCA,server,email -addext keyUsage=digitalSignature,keyEncipherment,dataEncipherment,keyAgreement,keyCertSign,cRLSign
openssl x509 -CA myca.pem -CAkey myca.key -req -in mysrv.req -days 365 -copy_extensions copy -set_serial 2 -out mysrv.pem
Servers should emit the entire certificate chain to TLS clients when something connects, so generate one:
cat mysrv.pem myca.pem >mysrv.bnd

Generation of a client certificate tied to the server

openssl req -nodes -newkey ed25519 -out mycl.req -keyout mycl.key -subj /CN=someusername -addext basicConstraints=CA:false -addext nsCertType=client,email -addext keyUsage=digitalSignature,keyEncipherment,dataEncipherment,keyAgreement -addext extendedKeyUsage=serverAuth,clientAuth
openssl x509 -CA mysrv.pem -CAkey mysrv.key -req -in mycl.req -days 365 -copy_extensions copy -set_serial 3 -out mycl.pem
Clients may want to verify their own certificate standalone (without context to a connected server), so the chain should be available:
cat mycl.pem mysrv.pem myca.pem >mycl.bnd

System placement

On SUSE and/or where the ca-certificates package is installed, certificate files that should be globally available are to be copied into /etc/pki/trust/anchors (running update-ca-certificates seems optional, at least for processes that are purely libopenssl-based).