OPENSSL(1)

πŸ“¦
version 4.4.0 Β· 2 versions
, in arch rolling

πŸ’– NAME πŸ’–

Ok so this is OPENSSL(1) from the General Commands Manual β€” aka the page for openssl, the OpenSSL command line tool. πŸ’…


✨ SYNOPSIS ✨

openssl command [command_opt ...] [command_arg ...]

openssl list-standard-commands | list-message-digest-commands |
        list-cipher-commands | list-cipher-algorithms |
        list-message-digest-algorithms | list-public-key-algorithms

openssl no-command

🌸 DESCRIPTION 🌸

Bestie. OpenSSL is a cryptography toolkit implementing the Transport Layer Security (TLS) network protocol, as well as related cryptography standards. πŸ”

The openssl program is a command line tool for using the various cryptography functions of openssl's crypto library from the shell.

The pseudo-commands list-standard-commands, list-message-digest-commands, and list-cipher-commands output a list (one entry per line) of the names of all standard commands, message digest commands, or cipher commands, respectively, that are available in the present openssl utility.

The pseudo-commands list-cipher-algorithms and list-message-digest-algorithms list all cipher and message digest names, one entry per line. Aliases are listed as:

from => to

The pseudo-command list-public-key-algorithms lists all supported public key algorithms.

The pseudo-command no-command tests whether a command of the specified name is available. If command does not exist, it returns 0 and prints no-command; otherwise it returns 1 and prints command. In both cases, the output goes to stdout and nothing is printed to stderr. Additional command line arguments are always ignored. Since for each cipher there is a command of the same name, this provides an easy way for shell scripts to test for the availability of ciphers in the openssl program.

Note: no-command is not able to detect pseudo-commands such as quit, list-...-commands, or no-command itself. 😭

πŸ¦‹ ASN1PARSE πŸ¦‹

openssl asn1parse  [-i] [-dlimit number] [-dump] [-genconf file]
                   [-genstr str] [-in file] [-inform der | pem | txt]
                   [-length number] [-noout] [-offset number]
                   [-oid file] [-out file] [-strparse offset]

The asn1parse command is a diagnostic utility that can parse ASN.1 structures. It can also be used to extract data from ASN.1 formatted data. 🧚

The options are as follows:

  • -dlimit number β€” Dump the first number bytes of unknown data in hex form.
  • -dump β€” Dump unknown data in hex form.
  • -genconf file, -genstr str β€” Generate encoded data based on string str, file file, or both, using the format described in ASN1_generate_nconf(3). If only file is present then the string is obtained from the default section using the name β€œasn1”. The encoded data is passed through the ASN.1 parser and printed out as though it came from a file; the contents can thus be examined and written to a file using the -out option.
  • -i β€” Indent the output according to the "depth" of the structures.
  • -in file β€” The input file to read from, or standard input if not specified.
  • -inform der | pem | txt β€” The input format.
  • -length number β€” Number of bytes to parse; the default is until end of file.
  • -noout β€” Do not output the parsed version of the input file.
  • -offset number β€” Starting offset to begin parsing; the default is start of file.
  • -oid file β€” A file containing additional object identifiers (OIDs). If an OID (object identifier) is not part of openssl's internal table, it will be represented in numerical form (for example 1.2.3.4).

Each line consists of three columns: the first column is the OID in numerical format and should be followed by whitespace. The second column is the "short name", which is a single word followed by whitespace. The final column is the rest of the line and is the "long name". asn1parse displays the long name. πŸ‘‘

  • -out file β€” The DER-encoded output file; the default is no encoded output (useful when combined with -strparse).
  • -strparse offset β€” Parse the content octets of the ASN.1 object starting at offset. This option can be used multiple times to "drill down" into a nested structure.

πŸ‘‘ CA πŸ‘‘

openssl ca  [-batch] [-cert file] [-config file] [-create_serial]
            [-crl_CA_compromise time] [-crl_compromise time]
            [-crl_hold instruction] [-crl_reason reason] [-crldays days]
            [-crlexts section] [-crlhours hours] [-crlsec seconds]
            [-days arg] [-enddate date] [-extensions section]
            [-extfile file] [-gencrl] [-in file] [-infiles]
            [-key password] [-keyfile file] [-keyform pem | der]
            [-md alg] [-multivalue-rdn] [-name section] [-noemailDN]
            [-notext] [-out file] [-outdir directory] [-passin arg]
            [-policy arg] [-preserveDN] [-revoke file] [-selfsign]
            [-sigopt nm:v] [-ss_cert file] [-startdate date]
            [-status serial] [-subj arg] [-updatedb] [-utf8] [-verbose]

The ca command is a minimal certificate authority (CA) application. It can be used to sign certificate requests in a variety of forms and generate certificate revocation lists (CRLs). It also maintains a text database of issued certificates and their status. πŸŽ€

The options relevant to CAs are as follows:

  • -batch β€” Batch mode. In this mode no questions will be asked and all certificates will be certified automatically.
  • -cert file β€” The CA certificate file.
  • -config file β€” Specify an alternative configuration file.
  • -create_serial β€” If reading the serial from the text file as specified in the configuration fails, create a new random serial to be used as the next serial number.
  • -days arg β€” The number of days to certify the certificate for.
  • -enddate date β€” Set the expiry date. The format of the date is [YY]YYMMDDHHMMSSZ, with all four year digits required for dates from 2050 onwards.
  • -extensions section β€” The section of the configuration file containing certificate extensions to be added when a certificate is issued (defaults to x509_extensions unless the -extfile option is used). If no extension section is present, a V1 certificate is created. If the extension section is present (even if it is empty), then a V3 certificate is created. See the x509v3.cnf(5) manual page for details of the extension section format.
  • -extfile file β€” An additional configuration file to read certificate extensions from (using the default section unless the -extensions option is also used).
  • -in file β€” An input file containing a single certificate request to be signed by the CA.
  • -infiles β€” If present, this should be the last option; all subsequent arguments are assumed to be the names of files containing certificate requests.
  • -key password β€” The password used to encrypt the private key. Since on some systems the command line arguments are visible, this option should be used with caution. ⚠️
  • -keyfile file β€” The private key to sign requests with.
  • -keyform pem | der β€” Private key file format. The default is pem.
  • -md alg β€” The message digest to use. Possible values include md5 and sha1. This option also applies to CRLs.
  • -multivalue-rdn β€” This option causes the -subj argument to be interpreted with full support for multivalued RDNs, for example "/DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe". If -multivalue-rdn is not used, the UID value is set to "123456+CN=John Doe".
  • -name section β€” Specifies the configuration file section to use (overrides default_ca in the ca section).
  • -noemailDN β€” The DN of a certificate can contain the EMAIL field if present in the request DN, however it is good policy just having the email set into the altName extension of the certificate. When this option is set, the EMAIL field is removed from the certificate's subject and set only in the, eventually present, extensions. The email_in_dn keyword can be used in the configuration file to enable this behaviour.
  • -notext β€” Don't output the text form of a certificate to the output file.
  • -out file β€” The output file to output certificates to. The default is standard output. The certificate details will also be printed out to this file in PEM format.
  • -outdir directory β€” The directory to output certificates to. The certificate will be written to a file consisting of the serial number in hex with ".pem" appended.
  • -passin arg β€” The key password source.
  • -policy arg β€” Define the CA "policy" to use. The policy section in the configuration file consists of a set of variables corresponding to certificate DN fields. The values may be one of "match" (the value must match the same field in the CA certificate), "supplied" (the value must be present), or "optional" (the value may be present). Any fields not mentioned in the policy section are silently deleted, unless the -preserveDN option is set, but this can be regarded more of a quirk than intended behaviour. πŸ™ˆ
  • -preserveDN β€” Normally, the DN order of a certificate is the same as the order of the fields in the relevant policy section. When this option is set, the order is the same as the request. This is largely for compatibility with the older IE enrollment control which would only accept certificates if their DNs matched the order of the request. This is not needed for Xenroll.
  • -selfsign β€” Indicates the issued certificates are to be signed with the key the certificate requests were signed with, given with -keyfile. Certificate requests signed with a different key are ignored. If -gencrl or -ss_cert are given, -selfsign is ignored.

A consequence of using -selfsign is that the self-signed certificate appears among the entries in the certificate database (see the configuration option database) and uses the same serial number counter as all other certificates signed with the self-signed certificate.

  • -sigopt nm:v β€” Pass options to the signature algorithm during sign or certify operations. The names and values of these options are algorithm-specific.
  • -ss_cert file β€” A single self-signed certificate to be signed by the CA.
  • -startdate date β€” sets the start date ✨ the format is [YY]YYMMDDHHMMSSZ, and heads up: all four year digits are required for dates from 2050 onwards, so no cutting corners there bestie.
  • -subj arg β€” supersedes the subject name given in the request. The arg has to be formatted like /type0=value0/type1=value1/type2=...; characters can be escaped with \ (backslash), and no spaces are skipped. Slippery little format, so pay attention πŸ’…
  • -utf8 β€” interprets field values read from a terminal, or grabbed from a configuration file, as UTF-8 strings. By default they're interpreted as ASCII, which is giving "grandma's default settings" energy.
  • -verbose β€” prints extra details about the operations being performed. For the nosy girlies (affectionate) πŸ”

Okay so now the CRL girlies get their own little corner β€” the options relevant to CRLs are as follows:

  • -crl_CA_compromise time β€” literally the same as -crl_compromise, except the revocation reason is set to CACompromise πŸ’€
  • -crl_compromise time β€” sets the revocation reason to keyCompromise and the compromise time to time. time should be in GeneralizedTime format, i.e. YYYYMMDDHHMMSSZ.
  • -crl_hold instruction β€” sets the CRL revocation reason code to certificateHold and the hold instruction to instruction, which must be an OID. Although any OID can be used, only holdInstructionNone (the use of which is discouraged by RFC 2459), holdInstructionCallIssuer or holdInstructionReject will normally be used. iykyk.
  • -crl_reason reason β€” revocation reason, where reason is one of: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold or removeFromCRL. The matching of reason is case insensitive 🫢 Setting any revocation reason will make the CRL v2. In practice, removeFromCRL is not particularly useful because it is only used in delta CRLs which are not currently implemented β€” so like, don't come for it.
  • -crldays days β€” the number of days before the next CRL is due. This is the days from now to place in the CRL nextUpdate field.
  • -crlexts section β€” the section of the configuration file containing CRL extensions to include. If no CRL extension section is present then a V1 CRL is created; if the CRL extension section is present (even if it's empty!) then a V2 CRL is created. The CRL extensions specified are CRL extensions and not CRL entry extensions. It should be noted that some software can't handle V2 CRLs πŸ’€ See the x509v3.cnf(5) manual page for details of the extension section format.
  • -crlhours hours β€” the number of hours before the next CRL is due.
  • -crlsec seconds β€” the number of seconds before the next CRL is due. Yes we went all the way down to seconds, the precision is impeccable πŸ’…
  • -gencrl β€” generate a CRL based on information in the index file.
  • -revoke file β€” a file containing a certificate to revoke. Rip bozo πŸͺ¦
  • -status serial β€” show the status of the certificate with serial number serial.
  • -updatedb β€” update the database index to purge expired certificates. Spring cleaning era 🌸

Many of the options can be set in the ca section of the configuration file (or in the default section of the configuration file), specified using default_ca or -name. The preserve option is read directly from the ca section.

Many of the configuration file options are identical to command line options. Where the option is present in the configuration file and the command line, the command line value is used. Where an option is described as mandatory, then it must be present in the configuration file or the command line equivalent (if any) used. No skipping the mandatory ones, bestie, it's giving non-negotiable βœ‹

  • certificate β€” the same as -cert. It gives the file containing the CA certificate. Mandatory.
  • copy_extensions β€” decides how extensions in certificate requests should be handled πŸ‘€
    • if set to none, or this option is not present, then extensions are ignored and not copied to the certificate.
    • if set to copy, then any extensions present in the request that are not already present are copied to the certificate.
    • if set to copyall, then all extensions in the request are copied to the certificate: if the extension is already present in the certificate it is deleted first.
⚠️ the copy_extensions option should be used with caution. If care is not taken, it can be a security risk. For example, if a certificate request contains a basicConstraints extension with CA:TRUE and the copy_extensions value is set to copyall and the user does not spot this when the certificate is displayed, then this will hand the requester a valid CA certificate. Like, actual yikes 😭
This situation can be avoided by setting copy_extensions to copy and including basicConstraints with CA:FALSE in the configuration file. Then if the request contains a basicConstraints extension, it will be ignored. Slay, problem solved πŸ’…

The main use of this option is to allow a certificate request to supply values for certain extensions such as subjectAltName.

  • crl_extensions β€” the same as -crlexts.
  • crlnumber β€” a text file containing the next CRL number to use in hex. The CRL number will be inserted in the CRLs only if this file exists. If this file is present, it must contain a valid CRL number. No fake numbers allowed, it's giving strict πŸŽ€
  • database β€” the text database file to use. Mandatory. This file must be present, though initially it will be empty. Empty is fine, absent is not.
  • default_crl_hours, default_crl_days β€” the same as the -crlhours and -crldays options. These will only be used if neither command line option is present. At least one of these must be present to generate a CRL.
  • default_days β€” the same as the -days option. The number of days to certify a certificate for.
  • default_enddate β€” the same as the -enddate option. Either this option or default_days (or the command line equivalents) must be present.
  • default_md β€” the same as the -md option. The message digest to use. Mandatory.
  • default_startdate β€” the same as the -startdate option. The start date to certify a certificate for. If not set, the current time is used.
  • email_in_dn β€” the same as -noemailDN. If the EMAIL field is to be removed from the DN of the certificate, simply set this to "no". If not present, the default is to allow for the EMAIL field in the certificate's DN.
  • name_opt, cert_opt β€” these options allow the format used to display the certificate details when asking the user to confirm signing. All the options supported by the x509 utilities' -nameopt and -certopt switches can be used here, except that no_signame and no_sigdump are permanently set and cannot be disabled (this is because the certificate signature cannot be displayed because the certificate has not been signed at this point β€” timeline issues, truly). For convenience, the value ca_default is accepted by both to produce a reasonable output. If neither option is present, the format used in earlier versions of openssl is used. Use of the old format is strongly discouraged because it only displays fields mentioned in the policy section, mishandles multicharacter string types and does not display extensions. Old format is NOT the moment, don't do it πŸ™ˆ
  • new_certs_dir β€” the same as the -outdir command line option. It specifies the directory where new certificates will be placed. Mandatory.
  • oid_file β€” this specifies a file containing additional object identifiers. Each line of the file should consist of the numerical form of the object identifier followed by whitespace, then the short name followed by whitespace and finally the long name. Order matters, bestie, don't freestyle it ✨
  • oid_section β€” this specifies a section in the configuration file containing extra object identifiers. Each line should consist of the short name of the object identifier followed by = and the numerical form. The short and long names are the same when this option is used.
  • policy β€” the same as -policy. Mandatory.
  • preserve β€” the same as -preserveDN.
  • private_key β€” same as the -keyfile option. The file containing the CA private key. Mandatory.
  • serial β€” a text file containing the next serial number to use in hex. Mandatory. This file must be present and contain a valid serial number. No vibes-based serials πŸ’€
  • unique_subject β€” if the value yes is given, the valid certificate entries in the database must have unique subjects. If the value no is given, several valid certificate entries may have the exact same subject. The default value is yes. Note that it is valid in some circumstances for certificates to be created without any subject. In cases where there are multiple certificates without subjects this does not count as a duplicate 🫢
  • x509_extensions β€” the same as -extensions.

πŸ”— CERTHASH

openssl certhash  [-nv] dir ...

The certhash command calculates a hash value of ".pem" file in the specified directory list and creates symbolic links for each file, where the name of the link is the hash value. See the SSL_CTX_load_verify_locations(3) manual page for how hash links are used.

The links created are of the form "HHHHHHHH.D", where each H is a hexadecimal character and D is a single decimal digit. The hashes for CRLs look similar, except the letter r appears after the period, like this: "HHHHHHHH.rD". When processing a directory, certhash will first remove all links that have a name in that syntax and invalid reference.

Multiple objects may have the same hash; they will be indicated by incrementing the D value. Duplicates are found by comparing the full SHA256 fingerprint. A warning will be displayed if a duplicate is found πŸ””

A warning will also be displayed if there are files that cannot be parsed as either a certificate or a CRL. Not everything is a cert, and that's okay πŸ¦‹

The options are as follows:

  • -n β€” perform a dry-run, and do not make any changes. Look but don't touch πŸ’…
  • -v β€” print extra details about the processing.
  • dir ... β€” specify the directories to process.

✨ CIPHERS ✨

openssl ciphers [-hsVv] [-tls1_2] [-tls1_3] [control]

Okay so real talk, ciphers is the glow-up machine for cipher lists πŸ’… It takes that control string (the format is documented over in SSL_CTX_set_cipher_list(3), go read it, iykyk) and turns it into an ordered SSL cipher suite preference list. No control string given? Then you just get the DEFAULT list printed out. Cute, simple, slay.

The options are as follows, bestie:

  • -h, -? β€” Print a brief usage message. A little help never hurt nobody 🫢
  • -s β€” Only list ciphers that are supported by the TLS method. No flops allowed ✨
  • -tls1_2 | -tls1_3 β€” Team up with the -s option and this lists the ciphers which could be used if the specified protocol version were negotiated. Version-specific vibe check πŸ”₯
  • -V β€” Verbose mode, the main character option. Lists ciphers with cipher suite code in hex format, cipher name, and a complete description of protocol version, key exchange, authentication, encryption, and mac algorithms. It's giving full lore dump πŸ“–
  • -v β€” Like -V, but without cipher suite codes. Same energy, less hex πŸŽ€

🌸 CMS 🌸

openssl cms  [-aes128 | -aes192 | -aes256 | -camellia128 |
             -camellia192 | -camellia256 | -des | -des3 |
             -rc2-40 | -rc2-64 | -rc2-128] [-CAfile file]
             [-CApath directory] [-CRLfile file] [-binary]
             [-certfile file] [-certsout file] [-cmsout] [-content file]
             [-crlfeol] [-data_create] [-data_out] [-debug_decrypt]
             [-decrypt] [-digest_create] [-digest_verify]
             [-econtent_type type] [-encrypt] [-EncryptedData_decrypt]
             [-EncryptedData_encrypt] [-from addr] [-in file]
             [-inform der | pem | smime] [-inkey file]
             [-keyform der | pem] [-keyid] [-keyopt nm:v] [-md digest]
             [-no_attr_verify] [-no_content_verify]
             [-no_signer_cert_verify] [-noattr] [-nocerts] [-nodetach]
             [-nointern] [-nooldmime] [-noout] [-nosigs] [-nosmimecap]
             [-noverify] [-out file] [-outform der | pem | smime]
             [-passin src] [-print] [-pwri_password arg]
             [-rctform der | pem | smime]
             [-receipt_request_all | -receipt_request_first]
             [-receipt_request_from addr] [-receipt_request_print]
             [-receipt_request_to addr] [-recip file] [-resign]
             [-secretkey key] [-secretkeyid id] [-sign] [-sign_receipt]
             [-signer file] [-stream | -indef | -noindef] [-subject s]
             [-text] [-to addr] [-verify] [-verify_receipt file]
             [-verify_retcode] [cert.pem ...]

So cms handles S/MIME v3.1 mail πŸ’Œ It can encrypt, decrypt, sign and verify S/MIME messages. The full package, periodt.

Now listen, because this trips people up: the MIME message must be sent without any blank lines between the headers and the output. Some mail programs will automatically add a blank line β€” rude of them, honestly πŸ™ˆ Piping the mail directly to sendmail is one way to achieve the correct format. And the supplied message to be signed or encrypted must include the necessary MIME headers or many S/MIME clients won't display it properly (if at all). You can use the -text option to automatically add plain text headers. Ty for that one, king πŸ‘‘

A "signed and encrypted" message is one where a signed message is then encrypted πŸ” This can be produced by encrypting an already signed message. Stacking the layers like an iconic little outfit.

There are various operation options that set the type of operation to be performed. The meaning of the other options varies according to the operation type. So pick your operation first, then everything else reads differently. Vibe check accordingly ⭐

  • -encrypt β€” Encrypt mail for the given recipient certificates. Input file is the message to be encrypted. Output file is the encrypted mail in MIME format. The actual CMS type is EnvelopedData. ⚠️ Note that no revocation check is done for the recipient cert, so if that key has been compromised, others may be able to decrypt the text. That's not a vibe, that's a warning, take it seriously πŸ’€
  • -decrypt β€” Decrypt mail using the supplied certificate and private key. Expects an encrypted mail message in MIME format for the input file. The decrypted mail is written to the output file. Unwrapping the gift 🎁
  • -sign β€” Sign mail using the supplied certificate and private key. Input file is the message to be signed. The signed message in MIME format is written to the output file. Signing your work, as you should ✍️
  • -verify β€” Verify signed mail. Expects a signed mail message on input and outputs the signed data. Both clear text and opaque signing are supported. Trust but verify, bestie πŸ•΅οΈ
  • -cmsout β€” Take an input message and write out a PEM encoded CMS structure. Structural, literally.
  • -resign β€” Resign a message. Take an existing message and one or more new signers. This operation uses an existing message digest when adding a new signer β€” which means attributes must be present in at least one existing signer using the same message digest or this operation will fail. No attributes, no dice 🚫
  • -data_create β€” Create a CMS Data type.
  • -data_out β€” Output a content from the input CMS Data type.
  • -digest_create β€” Create a CMS DigestedData type.
  • -digest_verify β€” Verify a CMS DigestedData type and output the content.
  • -EncryptedData_encrypt β€” Encrypt a content using supplied symmetric key and algorithm using a CMS EncryptedData type.
  • -EncryptedData_decrypt β€” Decrypt a CMS EncryptedData type using supplied symmetric key.
  • -sign_receipt β€” Generate and output a signed receipt for the supplied message. The input message must contain a signed receipt request. Functionality is otherwise similar to the -sign operation. Receipt szn 🧾
  • -verify_receipt file β€” Verify a signed receipt in file. The input message must contain the original receipt request. Functionality is otherwise similar to the -verify operation.

The remaining options are as follows:

  • -aes128 | -aes192 | -aes256 | -camellia128 | -camellia192 | -camellia256 | -des | -des3 | -rc2-40 | -rc2-64 | -rc2-128 β€” The encryption algorithm to use. That's 128-, 192-, or 256-bit AES; 128-, 192-, or 256-bit CAMELLIA; DES (56 bits); triple DES (168 bits); or 40-, 64-, or 128-bit RC2, respectively. If not specified, 256-bit AES is used. Only used with the -encrypt and -EncryptedData_encrypt commands. Choose your fighter 🌈
  • -binary β€” Normally the input message is converted to "canonical" format, which is effectively using CR/LF as end of line, as required by the S/MIME specification. When this option is present, no translation occurs. Useful when handling binary data which may not be in MIME format. Leave it raw, no notes πŸ¦‹
  • -CAfile file β€” A file containing trusted CA certificates, used with -verify and -verify_receipt.
  • -CApath directory β€” A directory containing trusted CA certificates, used with -verify and -verify_receipt. This directory must be a standard certificate directory: that is, a hash of each subject name (using x509 -hash) should be linked to each certificate. Folder discipline, bestie πŸ“
  • -CRLfile file β€” Allows additional certificate revocation lists to be specified for verification. The CRLs should be in PEM format.
  • cert.pem ... β€” One or more certificates of message recipients, used when encrypting a message.
  • -certfile file β€” Allows additional certificates to be specified. When signing, these will be included with the message. When verifying, these will be searched for the signer's certificates. The certificates should be in PEM format.
  • -certsout file β€” A file that any certificates contained in the message are written to.
  • -check_ss_sig, -crl_check, -crl_check_all, -extended_crl, -ignore_critical, -issuer_checks, -policy, -policy_check, -purpose, -x509_strict β€” Set various certificate chain validation options. See the verify command for details. The whole validation crew, assembled πŸ‘‘
  • -content file β€” A file containing the detached content. This is only useful with the -verify command, and only usable if the CMS structure is using the detached signature form where the content is not included. This option will override any content if the input format is S/MIME and it uses the multipart/signed MIME content type.
  • -crlfeol β€” Output an S/MIME message with CR/LF end of line.
  • -debug_decrypt β€” Set the CMS_DEBUG_DECRYPT flag when decrypting. ⚠️ This option should be used with caution, since this can be used to disable the MMA attack protection and return an error if no recipient can be found. See the CMS_decrypt(3) manual page for details of the flag. Debug responsibly, please πŸ™
  • -from addr, -subject s, -to addr β€” The relevant mail headers. These are included outside the signed portion of a message, so they may be included manually. If signing, then many S/MIME mail clients check that the signer's certificate's email address matches that specified in the From: address. Header drama, but make it cryptographic βœ‰οΈ
  • -econtent_type type β€” Set the encapsulated content type, used with -sign. If not supplied, the Data type is used. The type argument can be any valid OID name in either text or numerical format.
  • -in file β€” The input message to be encrypted or signed, or the message to be decrypted or verified.
  • -inform der | pem | smime β€” The input format for the CMS structure. The default is smime, which reads an S/MIME format message. pem and der change this to expect PEM and DER format CMS structures instead. This currently only affects the input format of the CMS structure; if no CMS structure is being input (for example with -encrypt or -sign) this option has no effect. Just so you don't sit there confused πŸ’…
  • -inkey file β€” The private key to use when signing or decrypting. This must match the corresponding certificate. If this option is not specified then the private key must be included in the certificate file specified with the -recip or -signer file. When signing, this option can be used multiple times to specify successive keys. Key rotation era πŸ”‘
  • -keyform der | pem β€” Input private key format. The default is pem.
  • -keyid β€” Use subject key identifier to identify certificates instead of issuer name and serial number. The supplied certificate must include a subject key identifier extension. Supported by -sign and -encrypt operations.
  • -keyopt nm:v β€” Set customised parameters for the preceding key or certificate for encryption and signing. It can currently be used to set RSA-PSS for signing, RSA-OAEP for encryption, or to modify default parameters for ECDH. This option can be used multiple times. Tune it how you like πŸŽ›οΈ
  • -md digest β€” The digest algorithm to use when signing or resigning. If not present then the default digest algorithm for the signing key will be used (usually SHA1).
  • -no_attr_verify β€” Do not verify the signer's attribute of a signature.
  • -no_content_verify β€” Do not verify the content of a signed message.
  • -no_signer_cert_verify β€” skips verifying the signer's certificate on a signed message. like, trust falls but nobody's catching you 🫢
  • -noattr β€” don't include attributes. normally when you sign something, a whole little bundle of attributes comes along (the signing time, the supported symmetric algorithms, all that). this option ✨ yeets ✨ them.
  • -nocerts β€” don't include the signer's certificate. it makes the signed message smol πŸ’… but the verifier has to already have a copy of that certificate locally (like, passed in with the -certfile option, for example), otherwise it's giving "who dis."
  • -nodetach β€” when signing, use opaque signing. this form is more resistant to getting mangled by mail relays, but mail agents that don't support S/MIME can't read it. without this option you get cleartext signing with the MIME type multipart/signed.
  • -nointern β€” only the certs you listed in -certfile get used. normally when verifying, the certificates included in the message (if there are any) get searched for the signing certificate. but fr, the supplied certs can still be used as untrusted CAs.
  • -nooldmime β€” outputs an old S/MIME content type, like "application/x-pkcs7-". retro vibes πŸŽ€
  • -noout β€” don't output the parsed CMS structure for the -cmsout operation. super useful when you pair it with -print, or when you're just checking whether the CMS structure's syntax is even valid.
  • -nosigs β€” do not attempt to verify the signatures on the message. we're skipping that part bestie 😭
  • -nosmimecap β€” excludes the list of supported algorithms from the signed attributes. other stuff, like signing time and content type, still gets included.
  • -noverify β€” do not verify the signer's certificate of a signed message.
  • -out file β€” the message text that's been decrypted or verified, or the output MIME format message that's been signed or verified. ✨
  • -outform der | pem | smime β€” specifies the output format for the CMS structure. default is smime, which writes an S/MIME format message. pem and der change that to write PEM and DER format CMS structures instead. heads up: this currently only affects the output format of the CMS structure β€” if no CMS structure is being output (like with -verify or -decrypt), this option does literally nothing. πŸ’€
  • -passin src β€” the private key password source. πŸ—οΈ
  • -print β€” prints out all fields of the CMS structure for the -cmsout operation. mainly a testing thing, ngl.
  • -pwri_password arg β€” specify the PasswordRecipientInfo (PWRI) password to use. supported by the -encrypt and -decrypt operations.
  • -rctform der | pem | smime β€” specifies the format for a signed receipt, for use with the -receipt_verify operation. default is smime.
  • -receipt_request_all | -receipt_request_first β€” says receipts should be provided by all recipients, or by first tier recipients only (meaning the ones mailed directly, not the ones coming from a mailing list), for the -sign operation to include a signed receipt request. ignored if -receipt_request_from is included.
  • -receipt_request_from addr β€” adds an explicit email address where receipts should be supplied. πŸ“¬
  • -receipt_request_print β€” prints out the contents of any signed receipt requests, for the -verify operation.
  • -receipt_request_to addr β€” adds an explicit email address where signed receipts should be sent. this option must be supplied if a signed receipt is requested β€” no address, no receipt, periodt.
  • -recip file β€” when decrypting a message, this specifies the recipient's certificate. it has to match one of the message's recipients or you get an error. when encrypting, you can use this option multiple times to specify each recipient. you gotta use this form if you need customised parameters (for example, specifying RSA-OAEP). only certificates carrying RSA, Diffie-Hellman or EC keys are supported by this option.
  • -secretkey key β€” specify the symmetric key to use. it must be supplied in hex format and be consistent with the algorithm being used. supported by the -EncryptedData_encrypt, -EncryptedData_decrypt, -encrypt and -decrypt operations. when used with -encrypt or -decrypt, the supplied key wraps or unwraps the content encryption key using an AES key in the KEKRecipientInfo type.
  • -secretkeyid id β€” the key identifier for the supplied symmetric key, for the KEKRecipientInfo type. this option must be present if -secretkey is used with -encrypt. with -decrypt, the id is used to locate the relevant key; if it's not supplied, an attempt is made to decrypt any KEKRecipientInfo structures.
  • -signer file β€” a signing certificate, for when you're signing or resigning a message. can be used multiple times if you need more than one signer, because sometimes one icon just isn't enough πŸ‘‘. if a message is being verified, the signers' certificates get written to this file if the verification was successful.
  • -stream | -indef | -noindef β€” -stream and -indef are equivalent and enable streaming I/O for encoding operations. this permits single pass processing of data without holding the entire contents in memory, so it can potentially support very large files. streaming is automatically set for S/MIME signing with detached data if the output format is smime; it's currently off by default for all other operations. -noindef disables streaming I/O where it would produce an indefinite length constructed encoding β€” note that this option currently has no effect. πŸ™ˆ
  • -text β€” adds plain text (text/plain) MIME headers to the supplied message if you're encrypting or signing. if you're decrypting or verifying, it strips off the text headers β€” and if the decrypted or verified message isn't of MIME type text/plain, you get an error. vibe check failed πŸ’€
  • -verify_retcode β€” sets the verification error code as the exit code, so you can tell what verification error occurred. supported by the -verify operation only. exit code value minus 32 shows the verification error code. see verify command for the list of verification error codes.

The exit codes for cms are as follows:

  0     The operation was completely successful.
  1     An error occurred parsing the command options.
  2     One of the input files could not be read.
  3     An error occurred creating the CMS file or when reading the
        MIME message.
  4     An error occurred decrypting or verifying the message.
  5     The message was verified correctly but an error occurred
        writing out the signer's certificates.
  6     An error occurred writing the output file.
  32+   A verify error occurred while -verify_retcode is specified.

πŸ’œ CRL πŸ’œ

okay so here's the vibe:

openssl crl  [-CAfile file] [-CApath dir] [-crlnumber] [-fingerprint]
             [-hash] [-hash_old] [-in file] [-inform der | pem]
             [-issuer] [-lastupdate] [-nameopt option] [-nextupdate]
             [-noout] [-out file] [-outform der | pem] [-text] [-verify]

the crl command processes CRL files in DER or PEM format. yes that's the whole job and it does it beautifully ✨

The options are as follows:

  • -CAfile file β€” verify the signature on a CRL by looking up the issuing certificate in file.
  • -CApath directory β€” verify the signature on a CRL by looking up the issuing certificate in dir. this directory has to be a standard certificate directory, i.e. a hash of each subject name (using x509 -hash) should be linked to each certificate. iykyk πŸŽ€
  • -crlnumber β€” print the CRL number.
  • -fingerprint β€” print the CRL fingerprint.
  • -hash β€” output a hash of the issuer name. you can use it to look up CRLs in a directory by issuer name.
  • -hash_old β€” output an old-style (MD5) hash of the issuer name. vintage, lowkey πŸ’…
  • -in file β€” the input file to read from, or standard input if not specified.
  • -inform der | pem β€” the input format.
  • -issuer β€” output the issuer name.
  • -lastupdate β€” output the thisUpdate field. this option is misnamed for historical reasons, so don't come for me, blame the archives 😭
  • -nameopt option β€” specify certificate name options.
  • -nextupdate β€” output the nextUpdate field.
  • -noout β€” do not output the encoded version of the CRL.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -outform der | pem β€” the output format.
  • -text β€” print the CRL in plain text. so you can actually read it, iconic 🫢
  • -verify β€” verify the signature on the CRL. trust but verify, bestie.

πŸ¦‹ CRL2PKCS7 πŸ¦‹

the synopsis, serving:

openssl crl2pkcs7  [-certfile file] [-in file] [-inform der | pem]
                   [-nocrl] [-out file] [-outform der | pem]

the crl2pkcs7 command takes an optional CRL plus one or more certificates and converts them into a PKCS#7 degenerate "certificates only" structure. it's giving a little bundled package of certs πŸ“¦βœ¨

The options are as follows:

  • -certfile file β€” add the certificates in the PEM file to the PKCS#7 structure. you can use this option more than once to read certificates from multiple files, so go off πŸŽ€
  • -in file β€” read the CRL from file, or standard input if not specified.
  • -inform der | pem β€” the input format.
  • -nocrl β€” normally a CRL is included in the output file. with this option, no CRL gets included in the output file, and a CRL isn't read from the input file either. bye bye CRL πŸ‘‹
  • -out file β€” write the PKCS#7 structure to file, or standard output if not specified.
  • -outform der | pem β€” the output format.

✨ DGST ✨

Okay bestie, so the digest commands are giving ✨checksum realness✨ β€” they spit out the message digest of the file(s) you hand them, in hexadecimal. But they're not just cute little checksums, no ma'am β€” they can also do digital signing and verification, which is highkey important. πŸ‘‘

openssl dgst  [-cdr] [-binary] [-digest] [-hex] [-hmac key]
              [-keyform pem] [-mac algorithm] [-macopt nm:v] [-out file]
              [-passin arg] [-prverify file] [-sign file]
              [-signature file] [-sigopt nm:v] [-verify file] [file ...]

The digest functions output the message digest of a supplied file or files in hexadecimal form. They can also be used for digital signing and verification.

Let's get into the options, shall we? πŸŽ€

  • -binary β€” Output the digest or signature in binary form. Raw bytes energy. πŸ’…
  • -c β€” Print the digest in two-digit groups separated by colons. It's giving organized. 🫢
  • -d β€” Print BIO debugging information. For when you need the inside scoop. πŸ”
  • -digest β€” Use the specified message digest. The default is SHA256. You can see all the digests available with openssl list-message-digest-commands. And PSA: these two are literally the same thing: openssl dgst -sha256 and openssl sha256.
  • -hex β€” Digest is to be output as a hex dump. This is the default case for a "normal" digest as opposed to a digital signature.
  • -hmac key β€” Create a hashed MAC using key.
  • -keyform pem β€” Specifies the key format to sign the digest with.
  • -mac algorithm β€” Create a keyed Message Authentication Code (MAC). The most popular MAC algorithm is HMAC (hash-based MAC), but there are other MAC algorithms which are not based on hash. MAC keys and other options should be set via the -macopt parameter. πŸ“
  • -macopt nm:v β€” Passes options to the MAC algorithm, specified by -mac. HMAC supports the following:
    • key:string β€” Specifies the MAC key as an alphanumeric string (use if the key contains printable characters only). String length must conform to any restrictions of the MAC algorithm.
    • hexkey:string β€” Specifies the MAC key in hexadecimal form (two hex digits per byte). Key length must conform to any restrictions of the MAC algorithm.
  • -out file β€” The output file to write to, or standard output if not specified.
  • -passin arg β€” The key password source.
  • -prverify file β€” Verify the signature using the private key in file. The output is either "Verification OK" or "Verification Failure". Iconic binary outcome, we love to see it. ✨
  • -r β€” Print the digest in coreutils format.
  • -sign file β€” Digitally sign the digest using the private key in file.
  • -signature file β€” The actual signature to verify.
  • -sigopt nm:v β€” Pass options to the signature algorithm during sign or verify operations. The names and values of these options are algorithm-specific.
  • -verify file β€” Verify the signature using the public key in file. The output is either "Verification OK" or "Verification Failure". Again with the two-outcome life. 😭
  • file ... β€” File or files to digest. If no files are specified then standard input is used.

🌸 DHPARAM 🌸

Okay so dhparam is your girl for manipulating DH parameter files. But heads up β€” only the older PKCS#3 DH is supported, not the newer X9.42 DH. No cap, that's just how it is. πŸ’€

openssl dhparam  [-2 | -5] [-check] [-dsaparam] [-in file]
                 [-inform der | pem] [-noout] [-out file]
                 [-outform der | pem] [-text] [numbits]

The dhparam command is used to manipulate DH parameter files. Only the older PKCS#3 DH is supported, not the newer X9.42 DH.

Here's the lineup: πŸŽ€

  • -2, -5 β€” The generator to use; 2 is the default. If present, the input file is ignored and parameters are generated instead.
  • -check β€” Check the DH parameters. Vibe check but for math. πŸ¦‹
  • -dsaparam β€” Read or create DSA parameters, converted to DH format on output. Otherwise, "strong" primes (such that (p-1)/2 is also prime) will be used for DH parameter generation.

DH parameter generation with the -dsaparam option is much faster, and the recommended exponent length is shorter, which makes DH key exchange more efficient. Beware that with such DSA-style DH parameters, a fresh DH key should be created for each use to avoid small-subgroup attacks that may be possible otherwise. ⚠️ Like, actually beware, bestie.

  • -in file β€” The input file to read from, or standard input if not specified.
  • -inform der | pem β€” The input format.
  • -noout β€” Do not output the encoded version of the parameters.
  • -out file β€” The output file to write to, or standard output if not specified.
  • -outform der | pem β€” The output format.
  • -text β€” Print the DH parameters in plain text.
  • numbits β€” Generate a parameter set of size numbits. It must be the last option. If not present, a value of 2048 is used. If this value is present, the input file is ignored and parameters are generated instead. Last option or it doesn't count, periodt. πŸ’…

πŸ’œ DSA πŸ’œ

The dsa command is all about processing DSA keys β€” converting them between various forms and printing out their components. Glow-up for your keys, basically. ✨

openssl dsa  [-aes128 | -aes192 | -aes256 | -des | -des3] [-in file]
             [-inform der | pem | pvk] [-modulus] [-noout] [-out file]
             [-outform der | pem | pvk] [-passin arg] [-passout arg]
             [-pubin] [-pubout] [-pvk-none | -pvk-strong | -pvk-weak]
             [-text]

The dsa command processes DSA keys. They can be converted between various forms and their components printed out.

Note: This command uses the traditional SSLeay compatible format for private key encryption: newer applications should use the more secure PKCS#8 format using the pkcs8 command. Old school vs new school, and new school is the move. πŸ‘‘

The options go like this:

  • -aes128 | -aes192 | -aes256 | -des | -des3 β€” Encrypt the private key with the AES, DES, or the triple DES ciphers, respectively, before outputting it. A pass phrase is prompted for. If none of these options are specified, the key is written in plain text.

This means that using the dsa utility to read an encrypted key with no encryption option can be used to remove the pass phrase from a key, or by setting the encryption options it can be used to add or change the pass phrase. These options can only be used with PEM format output files. πŸ”

  • -in file β€” The input file to read from, or standard input if not specified. If the key is encrypted, a pass phrase will be prompted for.
  • -inform der | pem | pvk β€” The input format.
  • -modulus β€” Print the value of the public key component of the key.
  • -noout β€” Do not output the encoded version of the key.
  • -out file β€” The output file to write to, or standard output if not specified. If any encryption options are set then a pass phrase will be prompted for.
  • -outform der | pem | pvk β€” The output format.
  • -passin arg β€” The key password source.
  • -passout arg β€” The output file password source.
  • -pubin β€” Read in a public key, not a private key.
  • -pubout β€” Output a public key, not a private key. Automatically set if the input is a public key.
  • -pvk-none | -pvk-strong | -pvk-weak β€” Enable or disable PVK encoding. The default is -pvk-strong.
  • -text β€” Print the public/private key in plain text.

🧚 DSAPARAM 🧚

And finally, dsaparam β€” your go-to for manipulating or generating DSA parameter files. Parameter file queen behavior. πŸ‘‘

openssl dsaparam  [-genkey] [-in file] [-inform der | pem] [-noout]
                  [-out file] [-outform der | pem] [-text] [numbits]

The dsaparam command is used to manipulate or generate DSA parameter files.

The options, bestie:

  • -genkey β€” Generate a DSA key either using the specified or generated parameters.
  • -in file β€” The input file to read from, or standard input if not specified. If the numbits parameter is included, then this option is ignored.
  • -inform der | pem β€” The input format.
  • -noout β€” Do not output the encoded version of the parameters.
  • -out file β€” The output file to write to, or standard output if not specified.
  • -outform der | pem β€” The output format.
  • -text β€” Print the DSA parameters in plain text.
  • numbits β€” Generate a parameter set of size numbits. If this option is included, the input file is ignored. πŸ’«
openssl ec  [-conv_form arg] [-des] [-des3] [-in file]
            [-inform der | pem] [-noout] [-out file]
            [-outform der | pem] [-param_enc arg] [-param_out]
            [-passin arg] [-passout arg] [-pubin] [-pubout] [-text]

Okay so ec is your EC key glow-up machine πŸ’« β€” it takes elliptic curve keys and converts them between all the different forms, plus prints out their components if you're nosy (we love a nosy queen).

Fun fact: openssl uses the private key format from "SEC 1: Elliptic Curve Cryptography" (https://www.secg.org/). And if you ever need to turn an EC private key into PKCS#8 private key format, that's a whole different vibe β€” take it to the pkcs8 command, bestie.

Here's the options, no gatekeeping:

  • -conv_form arg β€” tells OpenSSL how points on the elliptic curve get converted into octet strings. Your choices are compressed, uncompressed (the default, she's the standard), and hybrid. Want the lore? Check the X9.62 standard.
  • -des | -des3 β€” encrypt the private key with DES, triple DES, or literally any other cipher openssl supports. You'll get prompted for a pass phrase. If you specify none of these, the key is written in plain text β€” which, real talk, means you can use ec to read in an encrypted key with no encryption option and strip the pass phrase off it, or set the encryption options to add/change the pass phrase. These options only work with PEM format output files though. πŸŽ€
  • -in file β€” the input file to read a key from, or standard input if you don't specify one. If the key is encrypted, expect a pass phrase prompt.
  • -inform der | pem β€” the input format.
  • -noout β€” don't output the encoded version of the key.
  • -out file β€” the output filename to write to, or standard output if you don't specify one. If any encryption options are set, you'll be prompted for a pass phrase.
  • -outform der | pem β€” the output format.
  • -param_enc arg β€” how the elliptic curve parameters get encoded. Possible values: named_curve, where the EC parameters are specified by an OID, or explicit, where the EC parameters are explicitly given (see RFC 3279 for the definition of the EC parameter structures). Default is named_curve. Heads up ⚠️ the implicitlyCA alternative, as specified in RFC 3279, is currently not implemented.
  • -param_out β€” print the elliptic curve parameters.
  • -passin arg β€” the key password source.
  • -passout arg β€” the output file password source.
  • -pubin β€” read in a public key, not a private key.
  • -pubout β€” output a public key, not a private key. Automatically set if the input is a public key.
  • -text β€” print the public/private key in plain text.

🌸 ECPARAM 🌸

openssl ecparam  [-check] [-conv_form arg] [-genkey] [-in file]
                 [-inform der | pem] [-list_curves] [-name arg]
                 [-no_seed] [-noout] [-out file] [-outform der | pem]
                 [-param_enc arg] [-text]

ecparam is here to manipulate or generate EC parameter files ✨. Sad news though: openssl can't generate new groups, so ecparam can only create EC parameters from known (named) curves. That's just the situation, iykyk.

The options, coming right up:

  • -check β€” validate the elliptic curve parameters.
  • -conv_form arg β€” same deal as before: how points on the elliptic curve get converted into octet strings. Values are compressed, uncompressed (the default), and hybrid. More info on point conversion forms lives in the X9.62 standard.
  • -genkey β€” generate an EC private key using the specified parameters.
  • -in file β€” the input file to read from, or standard input if not specified.
  • -inform der | pem β€” the input format.
  • -list_curves β€” print a list of all currently implemented EC parameter names and dip out. πŸ‘‹
  • -name arg β€” use the EC parameters with the specified "short" name.
  • -no_seed β€” don't include the seed for parameter generation in the ECParameters structure (see RFC 3279).
  • -noout β€” don't output the encoded version of the parameters.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -outform der | pem β€” the output format.
  • -param_enc arg β€” how the elliptic curve parameters get encoded. Possible values: named_curve (parameters specified by an OID) or explicit (parameters explicitly given β€” see RFC 3279 for the EC parameter structure definitions). Default is named_curve. Note πŸ“Œ the implicitlyCA alternative from RFC 3279 is currently not implemented.
  • -text β€” print the EC parameters in plain text.

πŸ”₯ ENC πŸ”₯

openssl enc  -ciphername [-AadePpv] [-base64] [-bufsize number] [-debug]
             [-in file] [-iter iterations] [-iv IV] [-K key]
             [-k password] [-kfile file] [-md digest] [-none] [-nopad]
             [-nosalt] [-out file] [-pass arg] [-pbkdf2] [-S salt]
             [-salt]

The symmetric cipher commands let you encrypt or decrypt data using various block and stream ciphers, with keys based on passwords or ones you hand over explicitly. Base64 encoding or decoding can also happen β€” either on its own or stacked on top of the encryption/decryption. Obsessed with the flexibility tbh. You can call the program either as openssl ciphername or as openssl enc -ciphername.

Now, real talk on safety ⚠️: some of the ciphers don't have large keys, and others have security implications if you don't use them correctly. All the block ciphers normally use PKCS#5 padding, also known as standard block padding. If you disable padding, your input data must be a multiple of the cipher block length. No exceptions, bestie.

The options:

  • -A β€” if the -a option is set, then base64 process the data on one line.
  • -a, -base64 β€” base64 process the data. Meaning: if encryption is happening, the data gets base64-encoded after encryption. If decryption is set, the input data gets base64-decoded before being decrypted.
  • -bufsize number β€” set the buffer size for I/O.
  • -d β€” decrypt the input data.
  • -debug β€” debug the BIOs used for I/O.
  • -e β€” encrypt the input data. This is the default.
  • -in file β€” the input file to read from, or standard input if not specified.
  • -iter iterations β€” use the pbkdf2 key derivation function, with iterations as the number of iterations.
  • -iv IV β€” the actual IV (initialisation vector) to use. It must be a string made up of only hex digits. If only the key is specified with -K, the IV must be explicitly defined. When a password is being specified using one of the other options, the IV is generated from that password.
  • -K key β€” the actual key to use, and it must be a string made up of only hex digits. If only the key is specified, the IV must also be specified with -iv. When both a key and a password are specified, the key from -K wins and the IV generated from the password gets taken. Lowkey it probably doesn't make much sense to specify both key and password.
  • -k password β€” the password to derive the key from. Superseded by the -pass option.
  • -kfile file β€” read the password to derive the key from the first line of file. Superseded by the -pass option.
  • -md digest β€” use digest to create a key from a pass phrase. Currently the default value is sha256.
  • -none β€” use NULL cipher (no encryption or decryption of input).
  • -nopad β€” disable standard block padding.
  • -nosalt β€” don't use a salt in the key derivation routines. 🚨 Genuinely: this option should never be used, since it makes efficient dictionary attacks on the password possible and lets attackers go after stream cipher encrypted data. Just don't.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -P β€” print out the salt, key, and IV used, then immediately exit; no encryption or decryption at all.
  • -p β€” print out the salt, key, and IV used.
  • -pass arg β€” the password source.
  • -pbkdf2 β€” use the pbkdf2 key derivation function, with the default of 10000 iterations.
  • -S salt β€” the actual salt to use, as a string of only hex digits.
  • -salt β€” use a salt in the key derivation routines (this is the default). When salt is used, the first eight bytes of the encrypted data are reserved for it: randomly generated when encrypting a file, and read from the encrypted file when it's decrypted.
  • -v β€” print extra details about the processing.

πŸ¦‹ ERRSTR πŸ¦‹

openssl errstr errno ...

errstr does error number β†’ error string conversion, generating a human-readable string representing the error code errno. The string comes from the ERR_error_string_n(3) function and has this format:

error:[error code]:[library name]:[function name]:[reason string]

[error code] is an 8-digit hexadecimal number. The remaining fields β€” [library name], [function name], and [reason string] β€” are all ASCII text. Cute and informative, we stan. πŸ’…


πŸ‘‘ GENDSA πŸ‘‘

openssl gendsa  [-aes128 | -aes192 | -aes256 | -camellia128 |
                 -camellia192 | -camellia256 | -des | -des3 | -idea]
                 [-out file] [-passout arg] paramfile

gendsa generates a DSA private key from a DSA parameter file (typically one generated by the openssl dsaparam command). And here's the tea: DSA key generation is little more than random number generation, so it's way quicker than, say, RSA key generation. Speed demon energy ⚑

The options:

  • -aes128 | -aes192 | -aes256 | -camellia128 | -camellia192 | -camellia256 | -des | -des3 | -idea β€” encrypt the private key with the AES, CAMELLIA, DES, triple DES or the IDEA ciphers, respectively, before outputting it. You'll be prompted for a pass phrase. If none of these options are specified, no encryption is used.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -passout arg β€” the output file password source.
  • paramfile β€” specify the DSA parameter file to use. The parameters in this file determine the size of the private key.

✨ GENPKEY ✨

🌸 SYNOPSIS 🌸

openssl genpkey  [-algorithm alg] [cipher] [-genparam] [-out file]
                 [-outform der | pem] [-paramfile file] [-pass arg]
                 [-pkeyopt opt:value] [-text]

πŸ’– DESCRIPTION πŸ’–

Okay so genpkey generates private keys, bestie. It's highkey encouraged over the algorithm-specific utilities because you get to use additional algorithm options. The way that's a glow-up? Immaculate. ✨

✨ OPTIONS ✨

  • -algorithm alg β€” the public key algorithm to use, like RSA, DSA, or DH. This option must come before any -pkeyopt options. Also, -paramfile and -algorithm are mutually exclusive, so pick one.
  • cipher β€” encrypt the private key with the supplied cipher. Any algorithm name accepted by EVP_get_cipherbyname(3) is acceptable.
  • -genparam β€” generate a set of parameters instead of a private key. This option must precede any -algorithm, -paramfile, or -pkeyopt options.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -outform der | pem β€” the output format.
  • -paramfile file β€” some public key algorithms generate a private key based on a set of parameters, and you can supply those with this option. If you use this, the public key algorithm used is determined by the parameters. This option must precede any -pkeyopt options. The options -paramfile and -algorithm are mutually exclusive.
  • -pass arg β€” the output file password source.
  • -pkeyopt opt:value β€” set the public key algorithm option opt to value, like this:
    • rsa_keygen_bits:numbits β€” (RSA) the number of bits in the generated key. The default is 2048.
    • rsa_keygen_pubexp:value β€” (RSA) the RSA public exponent value. This can be a large decimal or hexadecimal value if preceded by 0x. The default is 65537.
    • dsa_paramgen_bits:numbits β€” (DSA) the number of bits in the generated parameters. The default is 1024.
    • dh_paramgen_prime_len:numbits β€” (DH) the number of bits in the prime parameter p.
    • dh_paramgen_generator:value β€” (DH) the value to use for the generator g.
    • ec_paramgen_curve:curve β€” (EC) the elliptic curve to use.
  • -text β€” print the private/public key in plain text.

πŸ”₯ GENRSA πŸ”₯

🌸 SYNOPSIS 🌸

openssl genrsa  [-3 | -f4] [-aes128 | -aes192 | -aes256 | -camellia128 |
                -camellia192 | -camellia256 | -des | -des3 | -idea]
                [-out file] [-passout arg] [numbits]

πŸ’– DESCRIPTION πŸ’–

The genrsa command generates an RSA private key, which essentially involves the generation of two prime numbers. When generating the key, various symbols will be output to indicate the progress of the generation. No cap, this is a whole vibe check made of punctuation:

  • '.' represents each number which has passed an initial sieve test.
  • '+' means a number has passed a single round of the Miller-Rabin primality test.
  • '*' means the number has failed primality testing and needs to be generated afresh.
  • A newline means that the number has passed all the prime tests (the actual number depends on the key size).

✨ OPTIONS ✨

  • -3 | -f4 β€” the public exponent to use, either 3 or 65537. The default is 65537.
  • -aes128 | -aes192 | -aes256 | -camellia128 | -camellia192 | -camellia256 | -des | -des3 | -idea β€” encrypt the private key with the AES, CAMELLIA, DES, triple DES or the IDEA ciphers, respectively, before outputting it. If none of these options are specified, no encryption is used. If encryption is used, a pass phrase is prompted for, if it is not supplied via the -passout option.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -passout arg β€” the output file password source.
  • numbits β€” the size of the private key to generate in bits. This must be the last option specified. The default is 2048.

πŸ¦‹ OCSP πŸ¦‹

🌸 SYNOPSIS 🌸

openssl ocsp  [-CA file] [-CAfile file] [-CApath directory] [-cert file]
              [-dgst alg] [-header name value] [-host hostname:port]
              [-ignore_err] [-index indexfile] [-issuer file]
              [-ndays days] [-nmin minutes] [-no_cert_checks]
              [-no_cert_verify] [-no_certs] [-no_chain] [-no_explicit]
              [-no_intern] [-no_nonce] [-no_signature_verify] [-nonce]
              [-noverify] [-nrequest number] [-out file] [-path path]
              [-port portnum] [-req_text] [-reqin file] [-reqout file]
              [-resp_key_id] [-resp_no_certs] [-resp_text]
              [-respin file] [-respout file] [-rkey file] [-rother file]
              [-rsigner file] [-serial num] [-sign_other file]
              [-signer file] [-signkey file] [-status_age age] [-text]
              [-timeout seconds] [-trust_other] [-url responder_url]
              [-VAfile file] [-validity_period nsec]
              [-verify_other file]

πŸ’– DESCRIPTION πŸ’–

The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate (RFC 2560). Icons only.

The ocsp command performs many common OCSP tasks. It can be used to print out requests and responses, create requests and send queries to an OCSP responder, and behave like a mini OCSP server itself. Main character energy, honestly. πŸ’…

✨ OPTIONS ✨

⚠️ Heads up, bestie: some of these options are testing-only or debugging-only and should not be treated like production vibes. I'll flag them as we go. No cap.

🌟 described options 🌟

  • -CAfile file, -CApath directory β€” a file or path containing trusted CA certificates, used to verify the signature on the OCSP response.
  • -cert file β€” add the certificate file to the request. The issuer certificate is taken from the previous -issuer option, or an error occurs if no issuer certificate is specified.
  • -dgst alg β€” use the digest algorithm alg for certificate identification in the OCSP request. By default SHA1 is used.
  • -host hostname:port, -path path β€” send the OCSP request to hostname on port. -path specifies the HTTP path name to use, or / by default.
  • -header name value β€” add the header name with the specified value to the OCSP request that is sent to the responder. This may be repeated.
  • -issuer file β€” the current issuer certificate, in PEM format. Can be used multiple times and must come before any -cert options.
  • -no_cert_checks β€” don't perform any additional checks on the OCSP response signer's certificate. That is, do not make any checks to see if the signer's certificate is authorised to provide the necessary status information: as a result this option should only be used for testing purposes. Testing only, fr fr.
  • -no_cert_verify β€” don't verify the OCSP response signer's certificate at all. Since this option allows the OCSP response to be signed by any certificate, it should only be used for testing purposes. 😭 Testing only.
  • -no_certs β€” don't include any certificates in the signed request.
  • -no_chain β€” do not use certificates in the response as additional untrusted CA certificates.
  • -no_explicit β€” don't check the explicit trust for OCSP signing in the root CA certificate.
  • -no_intern β€” ignore certificates contained in the OCSP response when searching for the signer's certificate. The signer's certificate must be specified with either the -verify_other or -VAfile options.
  • -no_signature_verify β€” don't check the signature on the OCSP response. Since this option tolerates invalid signatures on OCSP responses, it will normally only be used for testing purposes. Testing only, bestie.
  • -nonce, -no_nonce β€” add an OCSP nonce extension to a request, or disable an OCSP nonce addition. Normally, if an OCSP request is input using the -respin option no nonce is added: using the -nonce option will force the addition of a nonce. If an OCSP request is being created (using the -cert and -serial options), a nonce is automatically added; specifying -no_nonce overrides this.
  • -noverify β€” don't attempt to verify the OCSP response signature or the nonce values. This is normally only used for debugging since it disables all verification of the responder's certificate. Debugging only.
  • -out file β€” specify the output file to write to, or standard output if not specified.
  • -req_text, -resp_text, -text β€” print out the text form of the OCSP request, response, or both, respectively.
  • -reqin file, -respin file β€” read an OCSP request or response file from file. These options are ignored if an OCSP request or response creation is implied by other options (for example with the -serial, -cert, and -host options).
  • -reqout file, -respout file β€” write out the DER-encoded certificate request or response to file.
  • -serial num β€” same as the -cert option except the certificate with serial number num is added to the request. The serial number is interpreted as a decimal integer unless preceded by 0x. Negative integers can also be specified by preceding the value with a minus sign.
  • -sign_other file β€” additional certificates to include in the signed request.
  • -signer file, -signkey file β€” sign the OCSP request using the certificate specified in the -signer option and the private key specified by the -signkey option. If the -signkey option is not present, then the private key is read from the same file as the certificate. If neither option is specified, the OCSP request is not signed.
  • -timeout seconds β€” connection timeout to the OCSP responder in seconds.
  • -trust_other β€” the certificates specified by the -verify_other option should be explicitly trusted and no additional checks will be performed on them. This is useful when the complete responder certificate chain is not available or trusting a root CA is not appropriate.
  • -url responder_url β€” specify the responder URL. Both HTTP and HTTPS (SSL/TLS) URLs can be specified.
  • -VAfile file β€” a file containing explicitly trusted responder certificates. Equivalent to the -verify_other and -trust_other options.

🫢 synopsis-only options 🫢

These show up in the synopsis, but the page doesn't give them their own separate descriptions. I'm not gonna invent behavior, bestie β€” iykyk.

  • -CA file β€” synopsis only; no separate description on this page.
  • -ignore_err β€” synopsis only; no separate description on this page.
  • -index indexfile β€” synopsis only; no separate description on this page.
  • -ndays days β€” synopsis only; no separate description on this page.
  • -nmin minutes β€” synopsis only; no separate description on this page.
  • -nrequest number β€” synopsis only; no separate description on this page.
  • -port portnum β€” synopsis only; no separate description on this page.
  • -resp_key_id β€” synopsis only; no separate description on this page.
  • -resp_no_certs β€” synopsis only; no separate description on this page.
  • -rkey file β€” synopsis only; no separate description on this page.
  • -rother file β€” synopsis only; no separate description on this page.
  • -rsigner file β€” synopsis only; no separate description on this page.
  • -status_age age β€” synopsis only; no separate description on this page.
  • -validity_period nsec β€” synopsis only; no separate description on this page.
  • -verify_other file β€” synopsis only; no separate description on this page. It is referenced by -no_intern, -trust_other, and -VAfile.
  • -validity_period nsec, -status_age age β€” the lil tolerated-time window, in seconds, for an OCSP response πŸ’… every cert status response carries a notBefore time and an optional notAfter time, and your current time is supposed to fall between the two β€” but bestie, that gap might literally be a couple of seconds 😭 and in real life the responder's clock and the clients' clocks are not precisely synced, so that check can just... fail. That's why -validity_period exists: give it an acceptable error range in seconds, and the default is 5 minutes ✨

Now if notAfter is omitted from a response, that means fresh status info is immediately available. In that case the age of the notBefore field gets checked, to make sure it isn't older than age seconds. Heads up though β€” by default this additional check is not performed πŸ™ˆ

  • -verify_other file β€” a file of extra certificates to go hunting through when it's trying to locate the certificate that signed the OCSP response πŸ” some responders are out here omitting the actual signer's certificate from the response (rude), so this is how you hand over the certificate it needs.

The options for the OCSP server are as follows πŸ‘‘:

  • -CA file β€” the CA certificate that corresponds to the revocation information in indexfile.
  • -ignore_err β€” ignore the invalid response. yeah. just. ignore it πŸ’€
  • -index indexfile β€” indexfile is a text index file in ca format holding certificate revocation information.

If this option is specified, ocsp is in responder mode; otherwise it's in client mode. The requests the responder processes can be:

  • specified right on the command line (with the -issuer and -serial options),
  • supplied in a file (with the -respin option),
  • or come in from external OCSP clients (if port or url is specified).

If this option is present, then -CA and -rsigner must also be present ⚠️

  • -nmin minutes, -ndays days β€” how many minutes or days the fresh revocation information is available: this goes in the nextUpdate field. If neither option is there, the nextUpdate field is omitted entirely, which means fresh revocation information is immediately available πŸŽ€
  • -nrequest number β€” bail out after receiving number requests (default is unlimited, iykyk).
  • -port portnum β€” the port to listen for OCSP requests on. Can also be specified with the -url option.
  • -resp_key_id β€” identify the signer certificate using the key ID; the default is to use the subject name.
  • -resp_no_certs β€” don't include any certificates in the OCSP response. none. zero. πŸ™…
  • -rkey file β€” the private key to sign OCSP responses with; if it's not present, the file named in the -rsigner option is used.
  • -rother file β€” additional certificates to include in the OCSP response.
  • -rsigner file β€” the certificate to sign OCSP responses with.

okay so here's how the verify flow actually goes, and it's giving ✨process✨ 🌸

Initially the OCSP responder certificate is located, and the signature on the OCSP request is checked using the responder certificate's public key. Then a normal certificate verify is performed on the OCSP responder certificate, building up a certificate chain in the process. Where are the trusted certificates used to build that chain found? You can point at them with the -CAfile and -CApath options, or they'll be looked for in the standard openssl certificates directory πŸ“‚

If that initial verify fails, the OCSP verify process halts with an error πŸ›‘

Otherwise, the issuing CA certificate in the request is compared against the OCSP responder certificate: if there's a match, then the OCSP verify succeeds βœ…

Otherwise β€” the OCSP responder certificate's CA is checked against the issuing CA certificate in the request. If there's a match and the OCSPSigning extended key usage is present in the OCSP responder certificate, then the OCSP verify succeeds ✨

Otherwise β€” the root CA of the OCSP responder's CA is checked to see if it's trusted for OCSP signing. If it is, then the OCSP verify succeeds πŸ‘‘

If none of these checks succeed, the OCSP verify fails. What all of that effectively means is: if the OCSP responder certificate is authorised directly by the CA it's issuing revocation information about (and it's correctly configured), then verification will succeed 🫢

If the OCSP responder is a global responder β€” one that can give details about multiple CAs and has its own separate certificate chain β€” then its root CA can be trusted for OCSP signing. Alternatively, the responder certificate itself can be explicitly trusted with the -VAfile option πŸ’–

🌸 PASSWD 🌸

openssl passwd  [-1 | -apr1 | -crypt] [-in file] [-noverify] [-quiet]
                [-reverse] [-salt string] [-stdin] [-table] [password]

The passwd command computes the hash of a password. that's it. that's the whole gig πŸ”₯

The options are as follows:

  • -1 β€” use the MD5 based BSD password algorithm "1".
  • -apr1 β€” use the "apr1" algorithm (Apache variant of the BSD algorithm).
  • -crypt β€” use the "crypt" algorithm (this is the default πŸ‘‘).
  • -in file β€” read passwords from file.
  • -noverify β€” don't verify when reading a password from the terminal.
  • -quiet β€” don't output warnings when passwords given on the command line are truncated 🀫
  • -reverse β€” switch the table columns. This only makes sense in conjunction with the -table option, ngl.
  • -salt string β€” use the salt specified by string. When reading a password from the terminal, this implies -noverify.
  • -stdin β€” read passwords from standard input.
  • -table β€” in the output list, prepend the cleartext password and a TAB character to each password hash ✨

πŸŽ€ PKCS7 πŸŽ€

openssl pkcs7  [-in file] [-inform der | pem] [-noout] [-out file]
               [-outform der | pem] [-print] [-print_certs] [-text]

The pkcs7 command processes PKCS#7 files in DER or PEM format. Quick reality check: the PKCS#7 routines only understand PKCS#7 v 1.5 as specified in RFC 2315 πŸ’…

The options are as follows:

  • -in file β€” the input file to read from, or standard input if not specified.
  • -inform der | pem β€” the input format.
  • -noout β€” don't output the encoded version of the PKCS#7 structure (or certificates, if -print_certs is set).
  • -out file β€” the output to write to, or standard output if not specified.
  • -outform der | pem β€” the output format.
  • -print β€” print the ASN.1 representation of the PKCS#7 structure.
  • -print_certs β€” print any certificates or CRLs contained in the file, preceded by their subject and issuer names in a one-line format πŸ“œ
  • -text β€” print certificate details in full rather than just subject and issuer names. the whole thing. all the tea β˜•

πŸ¦‹ PKCS8 πŸ¦‹

openssl pkcs8  [-in file] [-inform der | pem] [-nocrypt] [-noiter]
               [-out file] [-outform der | pem] [-passin arg]
               [-passout arg] [-topk8] [-v1 alg] [-v2 alg]

The pkcs8 command processes private keys (both encrypted and unencrypted) in PKCS#8 format, with a whole little buffet of PKCS#5 (v1.5 and v2.0) and PKCS#12 algorithms πŸ“

The options are as follows:

  • -in file β€” the input file to read from, or standard input if not specified. If the key is encrypted, a pass phrase will be prompted for πŸ”‘
  • -inform der | pem β€” the input format.
  • -nocrypt β€” generate an unencrypted PrivateKeyInfo structure. ⚠️ this option does not encrypt private keys at all and should only be used when absolutely necessary. like, absolutely. fr fr.
  • -noiter β€” use an iteration count of 1. See the β€œPKCS12” section below for a detailed explanation of this option.
  • -out file β€” the output file to write to, or standard output if none is specified. If any encryption options are set, a pass phrase will be prompted for.
  • -outform der | pem β€” the output format.
  • -passin arg β€” the key password source.
  • -passout arg β€” the output file password source.
  • -topk8 β€” read a traditional format private key and write a PKCS#8 format key πŸ”„
  • -v1 alg β€” specify a PKCS#5 v1.5 or PKCS#12 algorithm to use.
    • PBE-MD5-DES β€” 56-bit DES.
    • PBE-SHA1-RC2-64 | PBE-MD5-RC2-64 | PBE-SHA1-DES β€” 64-bit RC2 or 56-bit DES.
    • PBE-SHA1-RC4-128 | PBE-SHA1-RC4-40 | PBE-SHA1-3DES | PBE-SHA1-2DES | PBE-SHA1-RC2-128 | PBE-SHA1-RC2-40 β€” PKCS#12 password-based encryption algorithm, which allow strong encryption algorithms like triple DES or 128-bit RC2 πŸ’ͺ
  • -v2 alg β€” use PKCS#5 v2.0 algorithms. These are block ciphers used in CBC mode. The default is AES-256-CBC. ⚠️ With the exception of AES, the choices available in RFC 8018 are considered decrepit πŸ’€ They can be enabled with des, des3, and rc2 (rc5 is no longer supported).

πŸŽ€ PKCS12 πŸŽ€

openssl pkcs12  [-aes128 | -aes192 | -aes256 | -camellia128 |
                -camellia192 | -camellia256 | -des | -des3 | -idea]
                [-cacerts] [-CAfile file] [-caname name]
                [-CApath directory] [-certfile file] [-certpbe alg]
                [-chain] [-clcerts] [-descert] [-export] [-in file]
                [-info] [-inkey file] [-keyex] [-keypbe alg] [-keysig]
                [-macalg alg] [-maciter] [-name name] [-nocerts]
                [-nodes] [-noiter] [-nokeys] [-nomac] [-nomaciter]
                [-nomacver] [-noout] [-out file] [-passin arg]
                [-passout arg] [-password arg] [-twopass]

okay so the pkcs12 command is your bestie for making and reading PKCS#12 files (some people call them PFX files, iykyk) πŸ’– By default it parses one β€” if you wanna create one you gotta say -export. That's the whole vibe.


✨ the parsing options (reading mode) ✨

  • -aes128 | -aes192 | -aes256 | -camellia128 | -camellia192 | -camellia256 | -des | -des3 | -idea β€” encrypt your private keys with AES, CAMELLIA, DES, triple DES or IDEA respectively. the default is triple DES, no cap πŸ’…
  • -cacerts β€” only spit out CA certificates. no client certs, sorry bestie.
  • -clcerts β€” the opposite vibe: only client certificates, no CA certs.
  • -in file β€” the input file to read from, or standard input if you don't specify one.
  • -info β€” print extra tea about the PKCS#12 file structure, which algorithms got used, and the iteration counts πŸ‘€
  • -nocerts β€” do not output certificates.
  • -nodes β€” do not encrypt private keys. literally bare, no encryption at all.
  • -nokeys β€” do not output private keys.
  • -nomacver β€” do not even try to verify the integrity MAC before reading the file. bold of you.
  • -noout β€” do not output the keys and certificates to the output file version of the PKCS#12 file.
  • -out file β€” the output file to write to, or standard output if you don't specify one.
  • -passin arg β€” the key password source.
  • -passout arg β€” the output file password source.
  • -twopass β€” prompt for separate integrity and encryption passwords. most software just assumes these are the same, so this option will literally render such PKCS#12 files unreadable by them 😭 chaotic but iconic.

🌸 the creation options (make mode) 🌸

  • -CAfile file β€” CA storage as a file.
  • -CApath directory β€” CA storage as a directory. heads up: the directory has to be a standard certificate directory β€” that means a hash of each subject name (using x509 -hash) should be linked to each certificate.
  • -caname name β€” pick the "friendly name" for other certificates. you can use it multiple times to name all the certificates in the order they appear 🫢
  • -certfile file β€” a file to read additional certificates from.
  • -certpbe alg, -keypbe alg β€” specify the algorithm used to encrypt the private key and certificates to be selected. any PKCS#5 v1.5 or PKCS#12 PBE algorithm name works. if you hand it a cipher name (as output by the list-cipher-algorithms command) it gets used with PKCS#5 v2.0. for interoperability reasons it's advisable to only use PKCS#12 algorithms β€” fr fr, take the advice.
  • -chain β€” include the entire certificate chain of the user certificate. the standard CA store is used for this search. if the search fails, that's a fatal error, no chill.
  • -descert β€” encrypt the certificate using triple DES. this may render the PKCS#12 file unreadable by some "export grade" software πŸ™ˆ by default the private key is encrypted using triple DES and the certificate using 40-bit RC2.
  • -export β€” create a PKCS#12 file (instead of parsing one). this is the whole switch, bestie.
  • -in file β€” the input file to read from, or standard input if you don't specify one. the order doesn't matter, but one private key and its corresponding certificate should be present. if additional certificates are present, they get included in the PKCS#12 file too πŸ’–
  • -inkey file β€” file to read a private key from. if it's not there, a private key must be present in the input file.
  • -keyex | -keysig β€” say whether the private key is for key exchange or just signing. normally "export grade" software will only allow 512-bit RSA keys for encryption purposes, but arbitrary length keys for signing. -keysig marks the key for signing only. signing-only keys can be used for S/MIME signing, authenticode (ActiveX control signing) and SSL client authentication ✨
  • -macalg alg β€” specify the MAC digest algorithm. default is SHA1.
  • -maciter β€” included for compatibility only 🫠 it used to be needed to use MAC iteration counts, but they're used by default now.
  • -name name β€” specify the "friendly name" for the certificate and private key. this name usually shows up in list boxes when software imports the file.
  • -nomac β€” don't attempt to provide the MAC integrity at all.
  • -nomaciter, -noiter β€” these affect the iteration counts on the MAC and key algorithms.

so here's the lore: to discourage attacks using big dictionaries of common passwords, the algorithm that derives keys from passwords can have an iteration count applied β€” that makes a certain part of the algorithm repeat and slows it down. the MAC checks file integrity, but since it'll normally have the same password as the keys and certificates, it could get attacked too. by default both the MAC and encryption iteration counts are set to 2048; with these options the MAC and encryption iteration counts can be set to 1. since that reduces file security you should NOT use these unless you really have to 😬 most software supports both MAC and key iteration counts.

  • -out file β€” the output file to write to, or standard output if you don't specify one.
  • -passin arg β€” the key password source.
  • -passout arg β€” the output file password source.
  • -password arg β€” with -export, -password is equivalent to -passout. otherwise, -password is equivalent to -passin. see what they did there πŸ’…

πŸ¦‹ PKEY πŸ¦‹

openssl pkey  [cipher] [-in file] [-inform der | pem] [-noout]
              [-out file] [-outform der | pem] [-passin arg]
              [-passout arg] [-pubin] [-pubout] [-text] [-text_pub]

the pkey command processes public or private keys. you can convert them between various forms and print their components out. it's giving key glow-up ✨

the options are as follows:

  • cipher β€” encrypt the private key with the specified cipher. any algorithm name accepted by EVP_get_cipherbyname(3) works, like des3.
  • -in file β€” the input file to read from, or standard input if you don't specify one. if the key is encrypted, you'll get prompted for a pass phrase.
  • -inform der | pem β€” the input format.
  • -noout β€” do not output the encoded version of the key.
  • -out file β€” the output file to write to, or standard output if you don't specify one. if any encryption options are set then you'll be prompted for a pass phrase.
  • -outform der | pem β€” the output format.
  • -passin arg β€” the key password source.
  • -passout arg β€” the output file password source.
  • -pubin β€” read in a public key, not a private key.
  • -pubout β€” output a public key, not a private key. set automatically if the input is a public key, convenient much?
  • -text β€” print the public/private key in plain text.
  • -text_pub β€” print out only public key components, even if a private key is what's being processed πŸ‘‘

🧚 PKEYPARAM 🧚

openssl pkeyparam [-in file] [-noout] [-out file] [-text]

the pkeyparam command processes public or private keys. the key type is determined by the PEM headers, so it just knows πŸ’«

the options are as follows:

  • -in file β€” the input file to read from, or standard input if you don't specify one.
  • -noout β€” do not output the encoded version of the parameters.
  • -out file β€” the output file to write to, or standard output if you don't specify one.
  • -text β€” print the parameters in plain text.

πŸ’… PKEYUTL πŸ’…

openssl pkeyutl  [-asn1parse] [-certin] [-decrypt] [-derive] [-encrypt]
                 [-hexdump] [-in file] [-inkey file]
                 [-keyform der | pem] [-out file] [-passin arg]
                 [-peerform der | pem] [-peerkey file]
                 [-pkeyopt opt:value] [-pubin] [-rev] [-sigfile file]
                 [-sign] [-verify] [-verifyrecover]

Okay so pkeyutl is your lil go-to bestie for doing public key operations with literally any supported algorithm πŸ¦‹. Like, any algorithm, one tool, one vibe. It's giving versatility.

The options are as follows, bestie:

  • -asn1parse β€” ASN.1 parses the output data ✨. Super useful when you pair it with the -verifyrecover option and an ASN.1 structure happens to be what got signed.
  • -certin β€” the input is a certificate containing a public key πŸŽ€.
  • -decrypt β€” decrypt the input data using a private key πŸ”.
  • -derive β€” derive a shared secret using the peer key 🀝.
  • -encrypt β€” encrypt the input data using a public key πŸ”’.
  • -hexdump β€” hex dump the output data, for when you wanna look at the bytes πŸ’….
  • -in file β€” the input file to read from, or standard input if you don't specify one.
  • -inkey file β€” the input key file. By default it should be a private key.
  • -keyform der | pem β€” the key format.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -passin arg β€” the key password source.
  • -peerform der | pem β€” the peer key format.
  • -peerkey file β€” the peer key file, used by key derivation (agreement) operations.
  • -pkeyopt opt:value β€” set the public key algorithm option opt to value. Unless it says otherwise somewhere, all algorithms support the format digest:alg, which tells it which digest to use for sign, verify, and verifyrecover operations 🌸. The value alg should be a digest name like the ones used in the EVP_get_digestbyname(3) function.

The RSA algorithm supports the encrypt, decrypt, sign, verify, and verifyrecover operations in general β€” but ngl, some padding modes only support some of those operations. πŸ‘€

  • rsa_padding_mode:mode β€” this sets the RSA padding mode. Acceptable values for mode are pkcs1 for PKCS#1 padding; none for no padding; oaep for OAEP mode; x931 for X9.31 mode; and pss for PSS.

In PKCS#1 padding, if the message digest is not set, then the supplied data is signed or verified directly instead of using a DigestInfo structure πŸ’€. If a digest is set, then a DigestInfo structure is used and its length must correspond to the digest type. For oeap mode only encryption and decryption is supported. For x931, if the digest type is set it's used to format the block data; otherwise the first byte is used to specify the X9.31 digest ID. sign, verify, and verifyrecover can be performed in this mode. For pss mode only sign and verify are supported and the digest type must be specified ⚠️.

  • rsa_pss_saltlen:len β€” for pss mode only, this option specifies the salt length πŸ§‚. Two special values are supported: -1 sets the salt length to the digest length. When signing, -2 sets the salt length to the maximum permissible value. When verifying, -2 causes the salt length to be automatically determined based on the PSS block structure. Iconic behaviour honestly.

The DSA algorithm supports the sign and verify operations. Currently there are no additional options other than digest. Only the SHA1 digest can be used and this digest is assumed by default.

The DH algorithm supports the derive operation and no additional options 🫢.

The EC algorithm supports the sign, verify, and derive operations. The sign and verify operations use ECDSA and derive uses ECDH. Currently there are no additional options other than digest. Only the SHA1 digest can be used and this digest is assumed by default.

  • -pubin β€” the input file is a public key.
  • -rev β€” reverse the order of the input buffer πŸ”„.
  • -sigfile file β€” signature file (verify operation only).
  • -sign β€” sign the input data and output the signed result. This requires a private key πŸ”‘.
  • -verify β€” verify the input data against the signature file and indicate whether the verification succeeded or failed βœ…βŒ.
  • -verifyrecover β€” verify the input data and output the recovered data.

πŸ”₯ PRIME πŸ”₯

openssl prime [-bits n] [-checks n] [-generate] [-hex] [-safe] p

The prime command is used to generate prime numbers, or to check numbers for primality πŸ‘‘. Results are probabilistic: they have an exceedingly high likelihood of being correct, but they are not guaranteed. So like… bestie, it's basically certain, but not a promise. Noted πŸ’€.

The options are as follows:

  • -bits n β€” specify the number of bits in the generated prime number. Must be used in conjunction with -generate ⚠️.
  • -checks n β€” perform a Miller-Rabin probabilistic primality test with n iterations. The default is 20.
  • -generate β€” generate a pseudo-random prime number. Must be used in conjunction with -bits ⚠️.
  • -hex β€” output in hex format.
  • -safe β€” generate only "safe" prime numbers (i.e. a prime p so that (p-1)/2 is also prime) πŸ›‘οΈ.
  • p β€” test if number p is prime.

🎲 RAND 🎲

openssl rand  [-base64] [-hex] [-out file] num

The rand command outputs num pseudo-random bytes ✨. That's it, that's the whole job, and it ate.

The options are as follows:

  • -base64 β€” perform base64 encoding on the output πŸŽ€.
  • -hex β€” specify hexadecimal output.
  • -out file β€” the output file to write to, or standard output if not specified.

🧚 REQ 🧚

openssl req  [-addext ext] [-batch] [-config file] [-days n]
             [-extensions section] [-in file] [-inform der | pem]
             [-key keyfile] [-keyform der | pem] [-keyout file]
             [-md4 | -md5 | -sha1] [-modulus] [-multivalue-rdn]
             [-nameopt option] [-new] [-newhdr] [-newkey arg] [-nodes]
             [-noout] [-out file] [-outform der | pem] [-passin arg]
             [-passout arg] [-pkeyopt opt:value] [-pubkey]
             [-reqexts section] [-reqopt option] [-set_serial n]
             [-sigopt nm:v] [-subj arg] [-subject] [-text] [-utf8]
             [-verbose] [-verify] [-x509]

The req command primarily creates and processes certificate requests in PKCS#10 format πŸŽ€. It can additionally create self-signed certificates, for use as root CAs, for example πŸ‘‘. She contains multitudes.

✨ The Options ✨

  • -addext ext β€” add a specific extension to the certificate (if the -x509 option is present) or certificate request 🌸. The argument must have the form of a key=value pair as it would appear in a config file. This option can be given multiple times, so go off.
  • -batch β€” non-interactive mode. No prompts, just vibes 😌.
  • -config file β€” specify an alternative configuration file.
  • -days n β€” specify the number of days to certify the certificate for. The default is 30 days. Used with the -x509 option πŸ“….
  • -extensions section, -reqexts section β€” specify alternative sections to include certificate extensions (with -x509) or certificate request extensions, allowing several different sections to be used in the same configuration file πŸ—‚οΈ.
  • -in file β€” the input file to read a request from, or standard input if not specified. A request is only read if the creation options -new and -newkey are not specified ⚠️.
  • -inform der | pem β€” the input format.
  • -key keyfile β€” the file to read the private key from. It also accepts PKCS#8 format private keys for PEM format files πŸ”‘.
  • -keyform der | pem β€” the format of the private key file specified in the -key argument. The default is pem.
  • -keyout file β€” the file to write the newly created private key to. If this option is not specified, the filename present in the configuration file is used.
  • -md5 | -sha1 | -sha256 β€” the message digest to sign the request with. This overrides the digest algorithm specified in the configuration file πŸ’….

Some public key algorithms may override this choice. For instance, DSA signatures always use SHA1. Rude but okay.

  • -modulus β€” print the value of the modulus of the public key contained in the request.
  • -multivalue-rdn β€” this option causes the -subj argument to be interpreted with full support for multivalued RDNs, for example "/DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe" 🌈. If -multivalue-rdn is not used, the UID value is set to "123456+CN=John Doe". Sneaky difference, honestly.
  • -nameopt option, -reqopt option β€” determine how the subject or issuer names are displayed πŸ‘€. option can be a single option or multiple options separated by commas. Alternatively, these options may be used more than once to set multiple options. See the β€œX509” section below for details.
  • -new β€” generate a new certificate request. The user is prompted for the relevant field values. The actual fields prompted for and their maximum and minimum sizes are specified in the configuration file and any requested extensions πŸ“.

If the -key option is not used, it will generate a new RSA private key using information specified in the configuration file.

  • -newhdr β€” add the word NEW to the PEM file header and footer lines on the outputted request. Some software and CAs need this πŸŽ€.
  • -newkey arg β€” create a new certificate request and a new private key. The argument takes one of several forms πŸ‘‘

rsa:nbits generates an RSA key nbits in size. If nbits is omitted, the default key size is used.

dsa:file generates a DSA key using the parameters in file.

param:file generates a key using the parameters or certificate in file.

All other algorithms support the form algorithm:file, where file may be an algorithm parameter file, created by the genpkey -genparam command or an X.509 certificate for a key with appropriate algorithm. file can be omitted, in which case any parameters can be specified via the -pkeyopt option.

  • -nodes β€” do not encrypt the private key πŸ™ˆ.
  • -noout β€” do not output the encoded version of the request.
  • -out file β€” the output file to write to, or standard output if not specified.
  • -outform der | pem β€” what format the output comes in. that's it, that's the whole vibe check πŸ’…
  • -passin arg β€” where the key password comes from, bestie πŸ”‘
  • -passout arg β€” same deal but for the output file's password.
  • -pkeyopt opt:value β€” sets the public key algorithm option opt to value. little key-value slay ✨
  • -pubkey β€” output the public key. just the public half, respectfully 🫢
  • -reqopt option β€” customises the output format that -text uses. option can be a single option, or several separated by commas. (also: go look at the discussion of -certopt in the x509 command, it's the same energy)
  • -set_serial n β€” the serial number to use when you're outputting a self-signed certificate. you can write it as a decimal value, or as hex if you put 0x in front. yes you can use negative serial numbers, but pls don't, it's not recommended πŸ™ˆ
  • -sigopt nm:v β€” passes options to the signature algorithm while signing. the names and values are algorithm-specific, so like, iykyk.
  • -subj arg β€” replaces the subject field of an input request with the data you give it, and outputs the modified request. arg has to be formatted like /type0=value0/type1=value1/type2=...; you can escape characters with \ (backslash); and heads up, no spaces are skipped. none. zero. 😭
  • -subject β€” prints the request subject (or the certificate subject if you also passed -x509).
  • -text β€” prints the certificate request in plain text. unglamorous but iconic.
  • -utf8 β€” interprets field values as UTF8 strings instead of ASCII.
  • -verbose β€” prints extra details about what's being done. she's chatty, we love her πŸ’¬
  • -verify β€” verifies the signature on the request. trust but verify fr fr
  • -x509 β€” outputs a self-signed certificate instead of a certificate request. typically used to generate a test certificate or a self-signed root CA. the extensions added to the certificate (if any) come from the configuration file. and unless you set it with -set_serial, the serial number is 0.

🌸 the config file options (req section) 🌸

the configuration options live in the "req" section of the configuration file, and here's what you can put in there:

  • attributes β€” the section containing any request attributes; its format is the same as distinguished_name. typically these might contain challengePassword or unstructuredName types. right now they're ignored by the openssl request signing utilities, but some CAs might want them. not us though πŸ’€
  • default_bits β€” the default key size, in bits. the default is 2048. it gets used if the -new option is used, and you can override it with the -newkey option.
  • default_keyfile β€” the default file to write a private key to, or standard output if it's not specified. can be overridden by the -keyout option.
  • default_md β€” the digest algorithm to use. possible values include md5, sha1 and sha256 (which is the default). can be overridden on the command line, main character behaviour honestly πŸ‘‘
  • distinguished_name β€” the section containing the distinguished name fields to prompt for when generating a certificate or certificate request. the format is described below, keep scrolling bestie.
  • encrypt_key β€” if set to "no" and a private key is generated, it is not encrypted. it's equivalent to the -nodes option. for compatibility, encrypt_rsa_key is an equivalent option.
  • input_password | output_password β€” the passwords for the input private key file (if present) and the output private key file (if one will be created). the command line options -passin and -passout override the config file values.
  • oid_file β€” a file containing additional OBJECT IDENTIFIERS. every line should be the numerical form of the object identifier, then whitespace, then the short name, then whitespace, then the long name. order matters, don't be chaotic πŸŽ€
  • oid_section β€” specifies a section in the configuration file containing extra object identifiers. every line should be the short name of the object identifier followed by = and the numerical form. when you use this option, the short and long names are the same.
  • prompt β€” if set to "no", it disables prompting for certificate fields and just takes values from the config file directly. it also changes the expected format of the distinguished_name and attributes sections. sneakily important.
  • req_extensions β€” the configuration file section containing a list of extensions to add to the certificate request. overridden by the -reqexts option.
  • string_mask β€” limits the string types used for encoding certain fields. here are the values you can use, each one limiting strings to the types shown:
    • utf8only β€” UTF8String. this is the default, as recommended by PKIX in RFC 2459.
    • default β€” PrintableString, IA5String, T61String, BMPString, UTF8String.
    • pkix β€” PrintableString, IA5String, BMPString, UTF8String. inspired by the PKIX recommendation in RFC 2459 for certificates generated before 2004, but it differs by also permitting IA5String.
    • nombstr β€” PrintableString, IA5String, T61String, UniversalString. a workaround for some ancient software that had problems with the variable-sized BMPString and UTF8String types. boomer software smh πŸ’€
    • MASK:number β€” an explicit bitmask of permitted types, where number is a C-style hex, decimal, or octal number that's a bit-wise OR of B_ASN1_* values from <openssl/asn1.h>.
  • utf8 β€” if set to "yes", field values are interpreted as UTF8 strings.
  • x509_extensions β€” the configuration file section containing a list of extensions to add to a certificate generated when the -x509 switch is used. overridden by the -extensions command line switch.

so there are two separate formats for the distinguished name and attribute sections, and which one you get depends on -prompt:

  • if the -prompt option is set to "no", these sections just consist of field names and values. simple, clean, minimal.
  • if -prompt is absent, or not set to "no", then the file contains field prompting information of this exact shape:
fieldName="prompt"
fieldName_default="default field value"
fieldName_min= 2
fieldName_max= 4

"fieldName" is the field name being used, for example commonName (or CN). the "prompt" string is what gets used to ask the user to enter the relevant details. if the user enters nothing, the default value is used; and if there's no default value present, the field is omitted. a field can still be omitted even when a default value is present β€” if the user just enters the . character. periodt.

the number of characters entered has to be between the fieldName_min and fieldName_max limits. and there may be extra restrictions based on the field being used β€” for example countryName can only ever be two characters long and must fit in a PrintableString. two. that's the whole budget. πŸ“

some fields (like organizationName) can be used more than once in a DN, which is a whole problem because config files will not recognize the same name occurring twice. to get around it: if the fieldName contains some characters followed by a full stop, those characters get ignored. so for example, a second organizationName can be input by calling it "1.organizationName". hack of the century honestly ✨

the actual permitted field names are any object identifier short or long names. these are compiled into openssl and include the usual values such as commonName, countryName, localityName, organizationName, organizationalUnitName, stateOrProvinceName. additionally, emailAddress is included, plus name, surname, givenName, initials and dnQualifier.

and you can define additional object identifiers with the oid_file or oid_section options in the configuration file. any additional fields get treated as though they were a DirectoryString. πŸ¦‹


πŸ”₯ RSA πŸ”₯

openssl rsa  [-aes128 | -aes192 | -aes256 | -des | -des3] [-check]
             [-in file] [-inform der | net | pem | pvk] [-modulus]
             [-noout] [-out file] [-outform der | net | pem | pvk]
             [-passin arg] [-passout arg] [-pubin] [-pubout]
             [-pvk-none | -pvk-strong | -pvk-weak] [-RSAPublicKey_in]
             [-RSAPublicKey_out] [-text]

okay so the rsa command processes RSA keys. they can be converted between various forms, and their components printed out. rsa uses the traditional SSLeay compatible format for private key encryption β€” but newer applications should use the more secure PKCS#8 format via the pkcs8 utility, okurrr πŸ’…

the options are as follows:

  • -aes128 | -aes192 | -aes256 | -des | -des3 β€” encrypt the private key with the AES, DES, or triple DES ciphers respectively, before outputting it. a pass phrase is prompted for. if none of these options are specified, the key is written in plain text. which means: using the rsa utility to read in an encrypted key with no encryption option can remove the pass phrase from a key β€” or, by setting the encryption options, it can add or change the pass phrase. these options can only be used with PEM format output files. ⚠️ like, only PEM, don't try it elsewhere.
  • -check β€” check the consistency of an RSA private key. vibe check for keys πŸ”
  • -in file β€” the input file to read from, or standard input if it's not specified. if the key is encrypted, a pass phrase will be prompted for.
  • -inform der | net | pem | pvk β€” the input format.
  • -noout β€” do not output the encoded version of the key.
  • -modulus β€” print the value of the modulus of the key.
  • -out file β€” the output file to write to, or standard output if it's not specified.
  • -outform der | net | pem | pvk β€” the output format.
  • -passin arg β€” the key password source.
  • -passout arg β€” the output file password source.
  • -pubin β€” read in a public key, not a private key.
  • -pubout β€” output a public key, not a private key. automatically set if the input is a public key.
  • -pvk-none | -pvk-strong | -pvk-weak β€” enable or disable PVK encoding. the default is -pvk-strong.
  • -RSAPublicKey_in, -RSAPublicKey_out β€” same as -pubin and -pubout except the RSAPublicKey format is used instead. πŸŽ€
  • -text β€” print the public/private key components in plain text. all the little components, out in the open, no cap πŸ’œ

πŸ’… RSAUTL πŸ’…

Okay bestie, so rsautl is your go-to for all things RSA β€” signing, verifying, encrypting, decrypting. One tool, four moods. Periodt. πŸ”₯

openssl rsautl  [-asn1parse] [-certin] [-decrypt] [-encrypt] [-hexdump]
                [-in file] [-inkey file] [-keyform der | pem]
                [-oaep | -pkcs | -raw | -x931] [-out file] [-passin arg]
                [-pubin] [-rev] [-sign] [-verify]

The rsautl command can be used to sign, verify, encrypt and decrypt data using the RSA algorithm. That's it, that's the whole vibe check. πŸ’–

✨ OPTIONS ✨

The options are as follows:

  • -asn1parse β€” Does an asn1parse on the output data. Lowkey a slay when you pair it with -verify, just saying. πŸ‘€
  • -certin β€” The input is a certificate containing an RSA public key. Like, a whole cert, not just the key.
  • -decrypt β€” Decrypt the input data using an RSA private key. Secrets unlocked. πŸ”“
  • -encrypt β€” Encrypt the input data using an RSA public key. Lock it down. πŸ”’
  • -hexdump β€” Hex dump the output data. For when you want to see the actual bytes, no cap.
  • -in file β€” The input to read from, or standard input if not specified.
  • -inkey file β€” The input key file. By default it's assumed to be an RSA private key.
  • -keyform der | pem β€” The private key format. The default is pem.
  • -oaep, -pkcs, -raw, -x931 β€” Picks the padding. In order: PKCS#1 OAEP, PKCS#1 v1.5 (the default), no padding, or ANSI X9.31. For signatures though, only -pkcs and -raw can be used β€” the other two simply do not apply, bestie. πŸ™ˆ
  • -out file β€” The output file to write to, or standard output if not specified.
  • -passin arg β€” The key password source.
  • -pubin β€” The input file is an RSA public key. Heads up so it doesn't try to read it as private. ✨
  • -rev β€” Reverse the order of the input buffer. Backwards but make it fashion. πŸ¦‹
  • -sign β€” Sign the input data and output the signed result. This one requires an RSA private key β€” no exceptions.
  • -verify β€” Verify the input data and output the recovered data. The truth-teller of the group chat. ⭐

πŸŽ€ S_CLIENT πŸŽ€

This is the big one, bestie β€” the generic SSL/TLS client that connects to a remote host over SSL/TLS. Buckle in, it's giving main character energy and a lot of flags. πŸ‘‘

openssl s_client  [-4 | -6] [-alpn protocols] [-bugs] [-CAfile file]
                  [-CApath directory] [-cert file] [-certform der | pem]
                  [-check_ss_sig] [-cipher cipherlist]
                  [-connect host[:port]] [-crl_check] [-crl_check_all]
                  [-crlf] [-debug] [-dtls] [-dtls1_2] [-extended_crl]
                  [-groups list] [-host host] [-ign_eof]
                  [-ignore_critical] [-issuer_checks] [-key keyfile]
                  [-keyform der | pem] [-keymatexport label]
                  [-keymatexportlen len] [-legacy_server_connect] [-msg]
                  [-mtu mtu] [-nbio] [-nbio_test] [-no_comp]
                  [-no_ign_eof] [-no_legacy_server_connect] [-no_ticket]
                  [-no_tls1_2] [-no_tls1_3] [-pass arg] [-policy_check]
                  [-port port] [-prexit] [-proxy host:port] [-quiet]
                  [-reconnect] [-servername name] [-serverpref]
                  [-sess_in file] [-sess_out file] [-showcerts]
                  [-starttls protocol] [-state] [-status] [-timeout]
                  [-tls1_2] [-tls1_3] [-tlsextdebug]
                  [-use_srtp profiles] [-verify depth]
                  [-verify_return_error] [-x509_strict] [-xmpphost host]

The s_client command implements a generic SSL/TLS client which connects to a remote host using SSL/TLS. Like a little handshake with the server, but make it cryptography. 🀝

So here's how it behaves: if a connection is established with an SSL server, any data received from the server is displayed and any key presses will be sent to the server. When used interactively (which means neither -quiet nor -ign_eof have been given), the session will be renegotiated if the line begins with an R; if the line begins with a Q or if end of file is reached, the connection will be closed down. Cute little control scheme, ngl. πŸ’…

🌸 OPTIONS 🌸

The options are as follows:

  • -4 β€” Attempt connections using IPv4 only. Old reliable. 🧚
  • -6 β€” Attempt connections using IPv6 only.
  • -alpn protocols β€” Enable the Application-Layer Protocol Negotiation. protocols is a comma-separated list of protocol names that the client should advertise support for. Flex your capabilities. ✨
  • -bugs β€” Enable various workarounds for buggy implementations. We're being nice to the messy servers today. 😭
  • -CAfile file β€” A file containing trusted certificates to use during server authentication and to use when attempting to build the client certificate chain.
  • -CApath directory β€” The directory to use for server certificate verification. This directory must be in "hash format" β€” see -verify for more information. These are also used when building the client certificate chain.
  • -cert file β€” The certificate to use, if one is requested by the server. The default is not to use a certificate. Don't hand it out unless asked.
  • -certform der | pem β€” The certificate format. The default is pem.
  • -check_ss_sig, -crl_check, -crl_check_all, -extended_crl, -ignore_critical, -issuer_checks, -policy_check, -x509_strict β€” Set various certificate chain validation options. See the verify command for details β€” that's where the lore lives. πŸ“œ
  • -cipher cipherlist β€” Modify the cipher list sent by the client. Although the server determines which cipher suite is used, it should take the first supported cipher in the list sent by the client. See the ciphers command for more information.
  • -connect host[:port] β€” The host and port to connect to. If not specified, an attempt is made to connect to the local host on port 4433. Alternatively, the host and port pair may be separated using a forward-slash character, which is useful for numeric IPv6 addresses. Slash instead of colon, iconic. πŸ¦‹
  • -crlf β€” Translate a line feed from the terminal into CR+LF, as required by some servers. Old-school servers need their little line endings, bless. πŸŽ€
  • -debug β€” Print extensive debugging information, including a hex dump of all traffic. Everything. All of it. The whole tea. β˜•
  • -dtls β€” Permit any version of DTLS.
  • -dtls1_2 β€” Permit only DTLS1.2. Exclusive, much? πŸ’…
  • -groups list β€” Set the supported elliptic curve groups to the colon separated list of group NIDs or names as documented in SSL_CTX_set1_groups_list(3).
  • -host host β€” The host to connect to. The default is localhost.
  • -ign_eof β€” Inhibit shutting down the connection when end of file is reached in the input. Stay in the chat, bestie. πŸ’–
  • -key keyfile β€” The private key to use. If not specified, the certificate file will be used.
  • -keyform der | pem β€” The private key format. The default is pem.
  • -keymatexport label β€” Export keying material using label.
  • -keymatexportlen len β€” Export len bytes of keying material (default 20).
  • -legacy_server_connect, -no_legacy_server_connect β€” Allow or disallow initial connection to servers that don't support RI. Yes, it's a switch-flip situation. πŸ”
  • -msg β€” Show all protocol messages with hex dump. Receipts for every message. 🧾
  • -mtu mtu β€” Set the link layer MTU.
  • -nbio β€” Turn on non-blocking I/O.
  • -nbio_test β€” Test non-blocking I/O. Just vibes and testing, together.
  • -no_ign_eof β€” Shut down the connection when end of file is reached in the input. Can be used to override the implicit -ign_eof after -quiet. Love an override. 😌
  • -no_tls1_2 | -no_tls1_3 β€” Disable the use of TLS1.2 and 1.3, respectively. Tell those versions they're not invited. πŸ’€
  • -no_ticket β€” Disable RFC 4507 session ticket support.
  • -pass arg β€” The private key password source.
  • -port port β€” The port to connect to. The default is 4433.
  • -prexit β€” Print session information when the program exits. This will always attempt to print out information even if the connection fails. Normally, information will only be printed out once if the connection succeeds. This option is useful because the cipher in use may be renegotiated or the connection may fail because a client certificate is required or is requested only after an attempt is made to access a certain URL. Note that the output produced by this option is not always accurate because a connection might never have been established. So like, take it with a grain of salt, bestie. πŸ™ˆ
  • -proxy host:port β€” Use the HTTP proxy at host and port. The connection to the proxy is done in cleartext and the -connect argument is given to the proxy. If not specified, localhost is used as final destination. After that, switch the connection through the proxy to the destination to TLS. Cleartext first, then glow-up to TLS. ✨
  • -quiet β€” Inhibit printing of session and certificate information. This implicitly turns on -ign_eof as well. Peace and quiet, finally. 🀫
  • -reconnect β€” Reconnect to the same server 5 times using the same session ID; this can be used as a test that session caching is working. Five taps to make sure the cache remembers you. πŸ”₯
  • -servername name β€” Include the TLS Server Name Indication (SNI) extension in the ClientHello message, using the specified server name.
  • -showcerts β€” Display the whole server certificate chain: normally only the server certificate itself is displayed. The full family tree, not just the one cert. πŸ‘‘
  • -serverpref β€” Use the server's cipher preferences. Let them choose, it's their house.
  • -sess_in file β€” Load TLS session from file. The client will attempt to resume a connection from this session. Reusing sessions, sustainable queen. 🌈
  • -sess_out file β€” Output TLS session to file.
  • -starttls protocol β€” Send the protocol-specific messages to switch to TLS for communication. protocol is a keyword for the intended protocol. Currently, the supported keywords are "ftp", "imap", "sieve", "smtp", "pop3", and "xmpp". Pick your fighter. πŸ₯Š
  • -state β€” Print the SSL session states. Watch the whole storyline unfold. πŸ“–
  • -status β€” Send a certificate status request to the server (OCSP stapling). The server response (if any) is printed out.
  • -timeout β€” Enable send/receive timeout on DTLS connections.
  • -tls1_2 | -tls1_3 β€” Permit only TLS1.2 or 1.3 respectively.
  • -tlsextdebug β€” Print a hex dump of any TLS extensions received from the server. Extension receipts, printed. 🧾
  • -use_srtp profiles β€” Offer SRTP key management with a colon-separated profile list.
  • -verify depth β€” Turn on server certificate verification, with a maximum length of depth. Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure. Yeah, it's a little messy, but that's how it works. 😭
  • -verify_return_error β€” Return verification error. Unlike the above, this one will actually complain. πŸ’€
  • -xmpphost hostname β€” When used with -starttls xmpp, specify the host for the "to" attribute of the stream element. If this option is not specified then the host specified with -connect will be used.

πŸ’… S_SERVER πŸ’…

okay bestie, before we do literally anything else, here's the synopsis in all its glory β€” every flag, exactly as it's written, no cap:

openssl s_server  [-accept port] [-alpn protocols] [-bugs]
                  [-CAfile file] [-CApath directory] [-cert file]
                  [-cert2 file] [-certform der | pem]
                  [-cipher cipherlist] [-context id] [-crl_check]
                  [-crl_check_all] [-crlf] [-dcert file]
                  [-dcertform der | pem] [-debug] [-dhparam file]
                  [-dkey file] [-dkeyform der | pem] [-dpass arg]
                  [-dtls] [-dtls1] [-dtls1_2] [-groups list] [-HTTP]
                  [-id_prefix arg] [-key keyfile] [-key2 keyfile]
                  [-keyform der | pem] [-keymatexport label]
                  [-keymatexportlen len] [-msg] [-mtu mtu]
                  [-naccept num] [-named_curve arg] [-nbio] [-nbio_test]
                  [-no_cache] [-no_dhe] [-no_ecdhe] [-no_ticket]
                  [-no_tls1_2] [-no_tls1_3] [-no_tmp_rsa] [-nocert]
                  [-pass arg] [-quiet] [-servername name]
                  [-servername_fatal] [-serverpref] [-state] [-status]
                  [-status_timeout nsec] [-status_url url]
                  [-status_verbose] [-timeout] [-tls1_2] [-tls1_3]
                  [-tlsextdebug] [-use_srtp profiles] [-Verify depth]
                  [-verify depth] [-verify_return_error] [-WWW] [-www]

So here's the vibe: s_server is the generic SSL/TLS server, and what it does is literally just sit there and listen for connections on a port using SSL/TLS. That's the whole job description. 🎧


🫢 the interactive bits (iykyk)

If a connection request gets established with a client and you did not use -www or -WWW, then everything is very cute and hands-on: any data received from the client gets displayed, and any key you press gets sent to the client. It's giving ✨live chat✨.

Certain single letter commands do special operations:

  • P β€” Send plain text, which should cause the client to disconnect.
  • Q β€” End the current SSL connection and exit.
  • q β€” End the current SSL connection, but still accept new connections.
  • R β€” Renegotiate the SSL session and request a client certificate.
  • r β€” Renegotiate the SSL session.
  • S β€” Print out some session cache status information.

✨ OPTIONS ✨

The options are as follows, bestie β€” buckle up, there's a lot:

  • -accept port β€” Listen on TCP port for connections. The default is port 4433. πŸ’–
  • -alpn protocols β€” Turns on the Application-Layer Protocol Negotiation. protocols is a comma-separated list of supported protocol names.
  • -bugs β€” Enables various workarounds for buggy implementations. (yes it's literally called bugs, we love a self-aware icon)
  • -CAfile file β€” A file containing trusted certificates, used during client authentication and used when trying to build the server certificate chain. That same list also gets used in the list of acceptable client CAs that's passed to the client when a certificate is requested. multitasking queen πŸ‘‘
  • -CApath directory β€” The directory to use for client certificate verification. This directory must be in "hash format"; peep -verify for more information. These are also used when building the server certificate chain.
  • -cert file β€” The certificate to use. Most server's cipher suites require the use of a certificate, and some require a certificate with a certain public key type. For example, the DSS cipher suites require a certificate containing a DSS (DSA) key. If you don't specify it, the file server.pem will be used.
  • -cert2 file β€” The certificate to use for servername.
  • -certform der | pem β€” The certificate format. The default is pem.
  • -cipher cipherlist β€” Modify the cipher list used by the server. This allows the cipher list used by the server to be modified. When the client sends a list of supported ciphers, the first client cipher that's also included in the server list is used. Because the client specifies the preference order, the order of the server cipherlist is irrelevant (lowkey iconic of her). See the ciphers command for more information.
  • -context id β€” Set the SSL context ID. It can be given any string value. any. go feral. πŸŽ€
  • -crl_check, -crl_check_all β€” Check that the peer certificate has not been revoked by its CA. The CRLs are appended to the certificate file. -crl_check_all checks all CRLs of all CAs in the chain.
  • -crlf β€” Translate a line feed from the terminal into CR+LF.
  • -dcert file, -dkey file β€” Specify an additional certificate and private key; these behave in the same manner as the -cert and -key options except there is no default if they are not specified (so no additional certificate or key is used). By using RSA and DSS certificates and keys, a server can support clients which only support RSA or DSS cipher suites by using an appropriate certificate. teamwork fr fr 🫢
  • -dcertform der | pem, -dkeyform der | pem, -dpass arg β€” Additional certificate and private key format, and private key password source, respectively.
  • -debug β€” Print extensive debugging information, including a hex dump of all traffic. the way she dumps hex... 😭
  • -dhparam file β€” The DH parameter file to use. The ephemeral DH cipher suites generate keys using a set of DH parameters. If not specified, an attempt is made to load the parameters from the server certificate file. If that fails, a static set of parameters hard coded into the s_server program will be used.
  • -dtls β€” Permit any version of DTLS.
  • -dtls1_2 β€” Permit only DTLS1.2.
  • -groups list β€” Set the supported elliptic curve groups to the colon separated list of group NIDs or names as documented in SSL_CTX_set1_groups_list(3).
  • -HTTP β€” Emulate a simple web server. Pages are resolved relative to the current directory. For example if the URL https://myhost/page.html is requested, the file ./page.html will be loaded. The files loaded are assumed to contain a complete and correct HTTP response (lines that are part of the HTTP response line and headers must end with CRLF). ⚠️ that last bit is load-bearing, don't skip it.
  • -id_prefix arg β€” Generate SSL/TLS session IDs prefixed by arg. This is mostly useful for testing any SSL/TLS code that wish to deal with multiple servers, when each of which might be generating a unique range of session IDs.
  • -key keyfile β€” The private key to use. If not specified, the certificate file will be used.
  • -key2 keyfile β€” The private key to use for servername.
  • -keyform der | pem β€” The private key format. The default is pem.
  • -keymatexport label β€” Export keying material using label.
  • -keymatexportlen len β€” Export len bytes of keying material (default 20).
  • -msg β€” Show all protocol messages with hex dump.
  • -mtu mtu β€” Set the link layer MTU.
  • -naccept num β€” Terminate the server after num connections.
  • -named_curve arg β€” Specify the elliptic curve name to use for ephemeral ECDH keys. > This option is deprecated; use -groups instead. (she's retired, let her rest πŸ’€)
  • -nbio β€” Turn on non-blocking I/O.
  • -nbio_test β€” Test non-blocking I/O.
  • -no_cache β€” Disable session caching.
  • -no_dhe β€” Disable ephemeral DH cipher suites.
  • -no_ecdhe β€” Disable ephemeral ECDH cipher suites.
  • -no_ticket β€” Disable RFC 4507 session ticket support.
  • -no_tls1_2 | -no_tls1_3 β€” Disable the use of TLS1.2 and 1.3, respectively.
  • -no_tmp_rsa β€” Disable temporary RSA key generation.
  • -nocert β€” Do not use a certificate. This restricts the cipher suites available to the anonymous ones (currently just anonymous DH). no cert, no problem πŸ¦‹
  • -pass arg β€” The private key password source.
  • -quiet β€” Inhibit printing of session and certificate information. shhh 🀫
  • -servername name β€” Set the TLS Server Name Indication (SNI) extension with name.
  • -servername_fatal β€” Send a fatal alert if servername does not match. The default is a warning alert.
  • -serverpref β€” Use server's cipher preferences.
  • -state β€” Print the SSL session states.
  • -status β€” Enables certificate status request support (OCSP stapling).
  • -status_timeout nsec β€” Sets the timeout for OCSP response in seconds.
  • -status_url url β€” Sets a fallback responder URL to use if no responder URL is present in the server certificate. Without this option, an error is returned if the server certificate does not contain a responder address.
  • -status_verbose β€” Enables certificate status request support (OCSP stapling) and gives a verbose printout of the OCSP response.
  • -timeout β€” Enable send/receive timeout on DTLS connections.
  • -tls1_2 | -tls1_3 β€” Permit only TLS1.2, or 1.3, respectively.
  • -tlsextdebug β€” Print a hex dump of any TLS extensions received from the server.
  • -use_srtp profiles β€” Offer SRTP key management with a colon-separated profile list.
  • -verify_return_error β€” Return verification error.
  • -WWW β€” Emulate a simple web server. Pages are resolved relative to the current directory. For example if the URL https://myhost/page.html is requested, the file ./page.html will be loaded.
  • -www β€” Send a status message to the client when it connects, including information about the ciphers used and various session parameters. The output is in HTML format, so this option will normally be used with a web browser. 🌈
  • -Verify depth, -verify depth β€” Request a certificate chain from the client, with a maximum length of depth. With -Verify, the client must supply a certificate or an error occurs; with -verify, a certificate is requested but the client does not have to send one. note the capital V, it's giving strict vs chill πŸ’…

⏱️ S_TIME πŸ’…

okay so s_time is literally a generic SSL/TLS client that connects to a remote host using SSL/TLS. It can request a page from the server and includes the time to transfer the payload data in its timing measurements. It measures the number of connections within a given timeframe, the amount of data transferred (if any), and calculates the average time spent for one connection. Benchmark goblin energy, no cap πŸ•°οΈβœ¨

openssl s_time  [-bugs] [-CAfile file] [-CApath directory] [-cert file]
                [-cipher cipherlist] [-connect host[:port]]
                [-key keyfile] [-nbio] [-new] [-no_shutdown] [-reuse]
                [-time seconds] [-verify depth] [-www page]

The options are as follows, bestie:

  • -bugs β€” Enable various workarounds for buggy implementations. πŸ›
  • -CAfile file β€” A file containing trusted certificates to use during server authentication and to use when attempting to build the client certificate chain. πŸ”
  • -CApath directory β€” The directory to use for server certificate verification. This directory must be in "hash format"; see verify for more information. These are also used when building the client certificate chain. πŸ“
  • -cert file β€” The certificate to use, if one is requested by the server. The default is not to use a certificate. πŸͺͺ
  • -cipher cipherlist β€” Modify the cipher list sent by the client. Although the server determines which cipher suite is used, it should take the first supported cipher in the list sent by the client. See the ciphers command for more information. πŸ”’
  • -connect host[:port] β€” The host and port to connect to. 🌐
  • -key keyfile β€” The private key to use. If not specified, the certificate file will be used. πŸ—οΈ
  • -nbio β€” Turn on non-blocking I/O. ⚑
  • -new β€” Perform the timing test using a new session ID for each connection. If neither -new nor -reuse are specified, they are both on by default and executed in sequence. πŸ†•
  • -no_shutdown β€” Shut down the connection without sending a "close notify" shutdown alert to the server. πŸ™ˆ
  • -reuse β€” Perform the timing test using the same session ID for each connection. If neither -new nor -reuse are specified, they are both on by default and executed in sequence. πŸ”
  • -time seconds β€” Limit s_time benchmarks to the number of seconds. The default is 30 seconds. ⏳
  • -verify depth β€” Turn on server certificate verification, with a maximum length of depth. Currently the verify operation continues after errors, so all the problems with a certificate chain can be seen. As a side effect, the connection will never fail due to a server certificate verify failure. πŸ‘€
  • -www page β€” The page to GET from the server. A value of / gets the index.htm[l] page. If this parameter is not specified, s_time will only perform the handshake to establish SSL connections but not transfer any payload data. πŸ“„

πŸͺͺ SESS_ID πŸŽ€

The sess_id program processes the encoded version of the SSL session structure and optionally prints out SSL session details (for example the SSL session master key) in human-readable format. It's giving session-inspector main character energy πŸ”πŸ’–

openssl sess_id  [-cert] [-context ID] [-in file] [-inform der | pem]
                 [-noout] [-out file] [-outform der | pem] [-text]

The options are as follows:

  • -cert β€” If a certificate is present in the session, it will be output using this option; if the -text option is also present, then it will be printed out in text form. πŸ“œ
  • -context ID β€” Set the session ID. The ID can be any string of characters. 🏷️
  • -in file β€” The input file to read from, or standard input if not specified. πŸ“₯
  • -inform der | pem β€” The input format. der uses an ASN.1 DER-encoded format containing session details. The precise format can vary from one version to the next. pem is the default format: it consists of the DER format base64-encoded with additional header and footer lines. 🧬
  • -noout β€” Do not output the encoded version of the session. 🚫
  • -out file β€” The output file to write to, or standard output if not specified. πŸ“€
  • -outform der | pem β€” The output format. πŸ”„
  • -text β€” Print the various public or private key components in plain text, in addition to the encoded version. πŸ“

The output of sess_id is composed as follows:

  • Protocol β€” The protocol in use.
  • Cipher β€” The actual raw SSL or TLS cipher code.
  • Session-ID β€” The SSL session ID, in hex format.
  • Session-ID-ctx β€” The session ID context, in hex format.
  • Master-Key β€” The SSL session master key.
  • Key-Arg β€” The key argument; this is only used in SSL v2.
  • Start Time β€” The session start time. Unix format.
  • Timeout β€” The timeout, in seconds.
  • Verify return code β€” The return code when a certificate is verified.
⚠️ Since the SSL session output contains the master key, it is possible to read the contents of an encrypted session using this information. Therefore appropriate security precautions should be taken if the information is being output by a "real" application. This is, however, strongly discouraged and should only be used for debugging purposes. πŸ”₯πŸ’€

✨ SMIME ✨

openssl smime  [-aes128 | -aes192 | -aes256 | -des |
               -des3 | -rc2-40 | -rc2-64 | -rc2-128] [-binary]
               [-CAfile file] [-CApath directory] [-certfile file]
               [-check_ss_sig] [-content file] [-crl_check]
               [-crl_check_all] [-decrypt] [-encrypt] [-extended_crl]
               [-from addr] [-ignore_critical] [-in file] [-indef]
               [-inform der | pem | smime] [-inkey file]
               [-issuer_checks] [-keyform der | pem] [-md digest]
               [-noattr] [-nocerts] [-nochain] [-nodetach] [-noindef]
               [-nointern] [-nosigs] [-nosmimecap] [-noverify]
               [-out file] [-outform der | pem | smime] [-passin arg]
               [-pk7out] [-policy_check] [-recip file] [-resign] [-sign]
               [-signer file] [-stream] [-subject s] [-text] [-to addr]
               [-verify] [-x509_strict] [cert.pem ...]

okay so the smime command is your whole S/MIME mail bestie πŸ’Œ β€” it can encrypt, decrypt, sign, and verify S/MIME messages. That's the whole vibe. Four things, all iconic.

Quick vibe check on formatting, bestie, because this is where people mess up: the MIME message has to go out with no blank lines between the headers and the output. Some mail programs will just add a blank line on their own, unprompted, no cap πŸ™„. Piping the mail directly into an MTA is one way to actually get the correct format.

Also, the message you hand over to be signed or encrypted must include the necessary MIME headers, or a lot of S/MIME clients won't display it properly β€” or like, at all 😭. Use the -text option to have plain text headers added for you automatically.

A "signed and encrypted" message is literally one where a signed message gets encrypted afterwards. So you make it by encrypting a message that's already signed. Easy.


There are a handful of operations you can run. Here's the whole lineup:

  • -decrypt β€” decrypt mail using the certificate and private key you supply. The input file is an encrypted mail message in MIME format. The decrypted mail gets written to the output file.
  • -encrypt β€” encrypt mail for the recipient certificates you give it. Input = the message to be encrypted. Output file = the encrypted mail, in MIME format.
  • -pk7out β€” take an input message and write out a PEM-encoded PKCS#7 structure.
  • -resign β€” resign a message: you take an existing message plus one or more new signers.
  • -sign β€” sign mail using the certificate and private key you supply. The input file is the message to sign. The signed message, in MIME format, lands in the output file.
  • -verify β€” verify signed mail. Input is a signed mail message; output is the signed data. Both clear text and opaque signing are supported πŸ’….

✨ the rest of the options ✨

The remaining options are as follows, and yes there are a lot of them, but you got this 🫢:

  • -aes128 | -aes192 | -aes256 | -des | -des3 | -rc2-40 | -rc2-64 | -rc2-128 β€” which encryption algorithm to use. Respectively: 128-, 192-, or 256-bit AES, DES (56 bits), triple DES (168 bits), or 40-, 64-, or 128-bit RC2. If you don't specify anything, 256-bit AES is what you get. Only used with -encrypt.
  • -binary β€” normally the input message gets converted to "canonical" format, which uses CR/LF as end of line, because that's what the S/MIME spec requires. When this option is present, no translation happens. Super useful when you're handling binary data that maybe isn't in MIME format at all.
  • -CAfile file β€” a file containing trusted CA certificates. Only used with -verify.
  • -CApath directory β€” a directory containing trusted CA certificates. Only used with -verify. This directory has to be a standard certificate directory β€” meaning a hash of each subject name (computed with x509 -hash) should be linked to each certificate.
  • cert.pem ... β€” one or more certificates of message recipients. Used when you're encrypting a message.
  • -certfile file β€” lets you specify additional certificates. When signing, these get included with the message. When verifying, they're searched for the signers' certificates. The certificates should be in PEM format.
  • -check_ss_sig, -crl_check, -crl_check_all, -extended_crl, -ignore_critical, -issuer_checks, -policy_check, -x509_strict β€” these set various certificate chain validation options. Go look at the verify command for the details.
  • -content file β€” a file containing the detached content. Only useful with the -verify option, and only usable if the PKCS#7 structure is using the detached signature form where the content isn't included. This option overrides any content if the input format is S/MIME and it's using the multipart/signed MIME content type.
  • -from addr, -subject s, -to addr β€” the relevant mail headers. These are included outside the signed portion of a message, so they can be included manually. When signing, a lot of S/MIME mail clients check that the signer's certificate email address matches the From: address πŸ‘€.
  • -in file β€” the input file to read from.
  • -indef β€” enables streaming I/O for encoding operations. This permits single pass processing of data without needing to hold the entire contents in memory, which can potentially support very large files. Streaming is automatically set for S/MIME signing with detached data if the output format is SMIME; right now it's off by default for all other operations.
  • -inform der | pem | smime β€” the input format.
  • -inkey file β€” the private key to use when signing or decrypting, which has to match the corresponding certificate. If you don't specify this option, the private key must be included in the certificate file specified with the -recip or -signer file. When signing, you can use this option multiple times to specify successive keys.
  • -keyform der | pem β€” input private key format. Default is pem.
  • -md digest β€” the digest algorithm to use when signing or resigning. If it's not present, the default digest algorithm for the signing key gets used (usually SHA1).
  • -noattr β€” don't include attributes.
  • -nocerts β€” don't include the signer's certificate. This shrinks the signed message, but then the verifier has to have a copy of the signer's certificate available locally (passed with the -certfile option, for example).
  • -nochain β€” don't do chain verification of signers' certificates β€” that is, don't use the certificates in the signed message as untrusted CAs.
  • -nodetach β€” when signing a message, use opaque signing. This form is more resistant to translation by mail relays, but it can't be read by mail agents that don't support S/MIME 😬. Without this option, cleartext signing with the MIME type multipart/signed is used.
  • -noindef β€” disable streaming I/O where it would produce an encoding of indefinite length. (Currently has no effect.)
  • -nointern β€” only use certificates specified in the -certfile. The supplied certificates can still be used as untrusted CAs.
  • -nosigs β€” don't try to verify the signatures on the message.
  • -nosmimecap β€” exclude the list of supported algorithms from signed attributes. Other options, like signing time and content type, are still included.
  • -noverify β€” don't verify the signer's certificate of a signed message.
  • -out file β€” the output file to write to.
  • -outform der | pem | smime β€” the output format. Default is smime, which writes an S/MIME format message. pem and der change that so it writes PEM and DER format PKCS#7 structures instead. This currently only affects the output format of the PKCS#7 structure; if no PKCS#7 structure is being output (like with -verify or -decrypt) then this option does nothing.
  • -passin arg β€” the key password source.
  • -recip file β€” the recipient's certificate when decrypting a message. This certificate must match one of the recipients of the message, or you get an error.
  • -signer file β€” a signing certificate when signing or resigning a message. This option can be used multiple times if you need more than one signer. If a message is being verified, the signer's certificates get written to this file if the verification was successful ✨.
  • -stream β€” the same as -indef.
  • -text β€” add plain text (text/plain) MIME headers to the supplied message if you're encrypting or signing. If you're decrypting or verifying, it strips the text headers off β€” and if the decrypted or verified message isn't of MIME type text/plain, then you get an error.

πŸŽ€ exit codes, bestie πŸŽ€

The exit codes for smime are as follows:

  • 0 β€” the operation was completely successful. slay πŸ’…
  • 1 β€” an error occurred parsing the command options.
  • 2 β€” one of the input files could not be read.
  • 3 β€” an error occurred creating the file or when reading the message.
  • 4 β€” an error occurred decrypting or verifying the message.
  • 5 β€” an error occurred writing certificates.

πŸ”₯ SPEED πŸ”₯

openssl speed  [algorithm] [-decrypt] [-elapsed] [-evp algorithm] [-mr]
               [-multi number] [-unaligned number]

The speed command tests how fast cryptographic algorithms actually go. It's giving benchmark era, honestly πŸƒβ€β™€οΈπŸ’¨.

  • algorithm β€” perform the test using algorithm. The default is to test all algorithms.
  • -decrypt β€” time decryption instead of encryption. Must be used with -evp.
  • -elapsed β€” measure time in real time instead of CPU user time.
  • -evp algorithm β€” perform the test using one of the algorithms accepted by EVP_get_cipherbyname(3).
  • -mr β€” produce machine readable output.
  • -multi number β€” run number benchmarks in parallel.
  • -unaligned number β€” use allocated buffers with an offset of number bytes from the alignment provided by malloc(3). number should be between 0 and 16.

πŸ¦‹ TS πŸ¦‹

openssl ts  -query [-md4 | -md5 | -ripemd160 | -sha1] [-cert]
            [-config configfile] [-data file_to_hash]
            [-digest digest_bytes] [-in request.tsq] [-no_nonce]
            [-out request.tsq] [-policy object_id] [-text]

openssl ts  -reply [-chain certs_file.pem] [-config configfile]
            [-in response.tsr] [-inkey private.pem] [-out response.tsr]
            [-passin arg] [-policy object_id] [-queryfile request.tsq]
            [-section tsa_section] [-signer tsa_cert.pem] [-text]
            [-token_in] [-token_out]

okay so ts has two whole modes going on β€” -query for making a request and -reply for making a response β€” and both of them come with a whole lil' bag of options. Stay tuned, the details are coming πŸ’œ

openssl ts  -verify [-CAfile trusted_certs.pem]
            [-CApath trusted_cert_path] [-data file_to_hash]
            [-digest digest_bytes] [-in response.tsr]
            [-queryfile request.tsq] [-token_in]
            [-untrusted cert_file.pem]

Okay so ts is the basic Time Stamping Authority (TSA) client and server app, exactly as specified in RFC 3161 (the Time-Stamp Protocol, aka TSP) πŸ’… A TSA can totally be part of a PKI deployment, and its whole role in life is providing long term proof that some specific data existed. Here's the protocol tea, briefly:

  1. The TSA client computes a one-way hash value for a data file and sends the hash to the TSA.
  2. The TSA attaches the current date and time to the received hash value, signs them and sends the time stamp token back to the client. By creating this token the TSA certifies the existence of the original data file at the time of response generation.
  3. The TSA client receives the time stamp token and verifies the signature on it. It also checks if the token contains the same hash value that it had sent to the TSA.

There's one DER-encoded protocol data unit defined for transporting a time stamp request to the TSA, and one for sending the time stamp response back to the client πŸŽ€ So the ts command has three main functions, no cap: creating a time stamp request based on a data file; creating a time stamp response based on a request; and verifying if a response corresponds to a particular request or a data file.

🫢 Real talk: there is no support for sending the requests/responses automatically over HTTP or TCP yet as suggested in RFC 3161. Users must send the requests either by FTP or email. Yes, fr fr, that's the vibe.

🌸 the -query life: making a request

The -query switch can be used for creating and printing a time stamp request with the following options:

  • -cert β€” Expect the TSA to include its signing certificate in the response.
  • -config configfile β€” Specify an alternative configuration file. Only the OID section is used, bestie.
  • -data file_to_hash β€” The data file for which the time stamp request needs to be created. The default is standard input.
  • -digest digest_bytes β€” Specify the message imprint explicitly without the data file. The imprint must be specified in a hexadecimal format, two characters per byte, the bytes optionally separated by colons. The number of bytes must match the message digest algorithm in use.
  • -in request.tsq β€” A previously created time stamp request in DER format that will be printed into the output file. Useful for examining the content of a request in human-readable format.
  • -md4 | -md5 | -ripemd160 | -sha | -sha1 β€” The message digest to apply to the data file. It supports all the message digest algorithms that are supported by the dgst command. The default is SHA1.
  • -no_nonce β€” Specify no nonce in the request. The default, to include a 64-bit long pseudo-random nonce, is recommended to protect against replay attacks πŸ”₯
  • -out request.tsq β€” The output file to write to, or standard output if not specified.
  • -policy object_id β€” The policy that the client expects the TSA to use for creating the time stamp token. Either dotted OID notation or OID names defined in the config file can be used. If no policy is requested, the TSA uses its own default policy.
  • -text β€” Output in human-readable text format instead of DER.

✨ the -reply era: making a response

A time stamp response (TimeStampResp) consists of a response status and the time stamp token itself (ContentInfo), if the token generation was successful. The -reply command is for creating a time stamp response or time stamp token based on a request, and printing the response/token in human-readable format. If -token_out is not specified the output is always a time stamp response (TimeStampResp), otherwise it is a time stamp token (ContentInfo).

  • -chain certs_file.pem β€” The collection of PEM certificates that will be included in the response in addition to the signer certificate if the -cert option was used for the request. This file is supposed to contain the certificate chain for the signer certificate from its issuer upwards. The -reply command does not build a certificate chain automatically β€” it's giving "you're on your own" energy 😭
  • -config configfile β€” Specify an alternative configuration file.
  • -in response.tsr β€” Specify a previously created time stamp response (or time stamp token, if -token_in is also specified) in DER format that will be written to the output file. This option does not require a request; it is useful, for example, to examine the content of a response or token or to extract the time stamp token from a response. If the input is a token and the output is a time stamp response, a default "granted" status info is added to the token πŸ‘‘
  • -inkey private.pem β€” The signer private key of the TSA in PEM format. Overrides the signer_key config file option.
  • -out response.tsr β€” The response is written to this file. The format and content of the file depends on other options (see -text and -token_out). The default is stdout.
  • -passin arg β€” The key password source.
  • -policy object_id β€” The default policy to use for the response. Either dotted OID notation or OID names defined in the config file can be used. If no policy is requested, the TSA uses its own default policy.
  • -queryfile request.tsq β€” The file containing a DER-encoded time stamp request.
  • -section tsa_section β€” The config file section containing the settings for response generation.
  • -signer tsa_cert.pem β€” The PEM signer certificate of the TSA. The TSA signing certificate must have exactly one extended key usage assigned to it: timeStamping. The extended key usage must also be critical, otherwise the certificate is going to be refused πŸ’€ Overrides the signer_cert variable of the config file.
  • -text β€” Output in human-readable text format instead of DER.
  • -token_in β€” The input is a DER-encoded time stamp token (ContentInfo) instead of a time stamp response (TimeStampResp).
  • -token_out β€” The output is a time stamp token (ContentInfo) instead of a time stamp response (TimeStampResp).

πŸ¦‹ the -verify check: is this even valid?

The -verify command is for verifying if a time stamp response or time stamp token is valid and matches a particular time stamp request or data file. The -verify command does not use the configuration file πŸ™ˆ

  • -CAfile trusted_certs.pem β€” The file containing a set of trusted self-signed PEM CA certificates. See verify for additional details. Either this option or -CApath must be specified.
  • -CApath trusted_cert_path β€” The directory containing the trusted CA certificates of the client. See verify for additional details. Either this option or -CAfile must be specified.
  • -data file_to_hash β€” The response or token must be verified against file_to_hash. The file is hashed with the message digest algorithm specified in the token. The -digest and -queryfile options must not be specified with this one.
  • -digest digest_bytes β€” The response or token must be verified against the message digest specified with this option. The number of bytes must match the message digest algorithm specified in the token. The -data and -queryfile options must not be specified with this one.
  • -in response.tsr β€” The time stamp response that needs to be verified, in DER format. This option is mandatory ⭐
  • -queryfile request.tsq β€” The original time stamp request, in DER format. The -data and -digest options must not be specified with this one.
  • -token_in β€” The input is a DER-encoded time stamp token (ContentInfo) instead of a time stamp response (TimeStampResp).
  • -untrusted cert_file.pem β€” Additional untrusted PEM certificates which may be needed when building the certificate chain for the TSA's signing certificate. This file must contain the TSA signing certificate and all intermediate CA certificates unless the response includes them.

πŸ“ config file things (options on the command line always win, periodt)

Options specified on the command line always override the settings in the config file:

  • tsa section, default_tsa β€” This is the main section and it specifies the name of another section that contains all the options for the -reply option. This section can be overridden with the -section command line switch.
  • oid_file β€” See ca for a description.
  • oid_section β€” See ca for a description.
  • serial β€” The file containing the hexadecimal serial number of the last time stamp response created. This number is incremented by 1 for each response. If the file does not exist at the time of response generation, a new file is created with serial number 1. This parameter is mandatory.
  • signer_cert β€” TSA signing certificate, in PEM format. The same as the -signer command line option.
  • certs β€” A set of PEM-encoded certificates that need to be included in the response. The same as the -chain command line option.
  • signer_key β€” The private key of the TSA, in PEM format. The same as the -inkey command line option.
  • default_policy β€” The default policy to use when the request does not mandate any policy. The same as the -policy command line option.
  • other_policies β€” Comma separated list of policies that are also acceptable by the TSA and used only if the request explicitly specifies one of them.
  • digests β€” The list of message digest algorithms that the TSA accepts. At least one algorithm must be specified. This parameter is mandatory πŸ”₯
  • accuracy β€” The accuracy of the time source of the TSA in seconds, milliseconds and microseconds. For example, secs:1, millisecs:500, microsecs:100. If any of the components is missing, zero is assumed for that field.
  • clock_precision_digits β€” The maximum number of digits, which represent the fraction of seconds, that need to be included in the time field. The trailing zeroes must be removed from the time, so there might actually be fewer digits or no fraction of seconds at all. The maximum value is 6; the default is 0.

ordering

If you set this to yes, the responses your TSA spits out can always be ordered β€” even when the time gap between two responses is less than the sum of their accuracies. Default? no. πŸ’…

tsa_name

Set this to yes if the subject name of the TSA has to be in the TSA name field of the response. Default is no.

ess_cert_id_chain

Okay so the SignedData objects your TSA creates always carry the certificate identifier of the signing certificate inside a signed attribute (peep RFC 2634, Enhanced Security Services). Now: if you set this option to yes and either the certs variable or the -chain option is specified, then the certificate identifiers of the chain get included in the SigningCertificate signed attribute too. If you set it to no, only the signing certificate identifier goes in. Default is no. πŸŽ€


✨ VERIFY ✨

openssl verify  [-CAfile file] [-CApath directory] [-check_ss_sig]
                [-CRLfile file] [-crl_check] [-crl_check_all]
                [-explicit_policy] [-extended_crl] [-help]
                [-ignore_critical] [-inhibit_any] [-inhibit_map]
                [-issuer_checks] [-legacy_verify] [-policy_check]
                [-purpose purpose] [-trusted file] [-untrusted file]
                [-verbose] [-x509_strict] [certificates]

The verify command verifies certificate chains. That's the whole gig bestie. πŸ¦‹

The options are as follows:

  • -CAfile file β€” a file of trusted certificates. It should hold multiple certificates in PEM format, all concatenated together.
  • -CApath directory β€” a directory of trusted certificates. The certificates (or symlinks pointing at them) should be named like hash.0, where hash is the hashed certificate subject name β€” see the -hash option of the x509 utility. πŸ’…
  • -check_ss_sig β€” verify the signature on the self-signed root CA. It's disabled by default because ngl it doesn't add any security.
  • -CRLfile file β€” the file should contain one or more CRLs in PEM format.
  • -crl_check β€” check end entity certificate validity by trying to look up a valid CRL. If no valid CRL can be found, that's an error, periodt.
  • -crl_check_all β€” check the validity of all certificates in the chain by attempting to look up valid CRLs.
  • -explicit_policy β€” set policy variable require-explicit-policy (RFC 3280).
  • -extended_crl β€” enable extended CRL features like indirect CRLs and alternate CRL signing keys.
  • -help β€” print a usage message.
  • -ignore_critical β€” ignore critical extensions instead of rejecting the certificate. πŸ™ˆ
  • -inhibit_any β€” set policy variable inhibit-any-policy (RFC 3280).
  • -inhibit_map β€” set policy variable inhibit-policy-mapping (RFC 3280).
  • -issuer_checks β€” print diagnostics about the search for the issuer certificate of the current certificate, showing why each candidate issuer certificate got rejected. Heads up though: rejection messages showing up does not by itself mean anything's wrong β€” during a normal verify several rejections can totally happen. πŸ’€
  • -legacy_verify β€” use the legacy X.509 certificate chain verification code.
  • -policy_check β€” enable certificate policy processing.
  • -purpose purpose β€” the intended use for the certificate. Without this option, no chain verification is done at all. Currently accepted uses are sslclient, sslserver, nssslserver, smimesign, smimeencrypt, crlsign, any, and ocsphelper.
  • -trusted file β€” a file of trusted certificates. It should contain multiple certificates.
  • -untrusted file β€” a file of untrusted certificates. It should contain multiple certificates.
  • -verbose β€” print extra info about the operations being performed.
  • -x509_strict β€” disable the workarounds for broken certificates that have to be turned off for strict X.509 compliance.
  • certificates β€” one or more PEM certificates to verify. If you don't include any certificate files, it tries to read a certificate from standard input. And if the first certificate filename begins with a dash, use a lone dash to mark the last option. 🫢

The verify program uses the same functions as the internal SSL and S/MIME verification β€” with one crucial difference: wherever possible it tries to keep going after an error, whereas normally the verify operation would bail on the very first error. That's the whole point: it lets you find all the problems with a certificate chain. ✨

The verify operation consists of a number of separate steps. First up, a certificate chain gets built starting from the supplied certificate and ending at the root CA. If the whole chain can't be built up, that's an error. The chain gets built by looking up the issuer's certificate of the current certificate. If a certificate is found which is its own issuer, it's assumed to be the root CA. πŸ‘‘

All certificates whose subject name matches the issuer name of the current certificate are subject to further tests. The relevant authority key identifier components of the current certificate (if present) must match the subject key identifier (if present) plus the issuer and serial number of the candidate issuer; and on top of that, the keyUsage extension of the candidate issuer (if present) must permit certificate signing.

The lookup looks in the list of untrusted certificates first, and if nothing matches, the remaining lookups come from the trusted certificates. The root CA is always looked up in the trusted certificate list: if the certificate you're verifying is a root certificate, then an exact match must be found in the trusted list. No cap. πŸ’…

The second operation is checking every untrusted certificate's extensions for consistency with the supplied purpose. If the -purpose option isn't included, then no checks are done. The supplied or "leaf" certificate must have extensions compatible with the supplied purpose, and every other certificate must also be a valid CA certificate. The precise extensions required are described in more detail in the X509 section below.

The third operation is checking the trust settings on the root CA. The root CA should be trusted for the supplied purpose. A certificate with no trust settings is considered valid for all purposes. 🌈

The final operation is checking the validity of the certificate chain. The validity period is checked against the current system time plus the notBefore and notAfter dates in the certificate. The certificate signatures get checked at this point too. πŸ”₯

If all operations complete successfully, the certificate is considered valid. If any operation fails, then the certificate is not valid. And when a verify operation fails, the output messages can be kinda cryptic. The general form of the error message is:

server.pem: /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Test CA (1024-bit)
error 24 at 1 depth lookup:invalid CA certificate

The first line has the name of the certificate being verified, followed by the subject name of the certificate. The second line has the error number as defined by the X509_V_ERR_* constants in <openssl/x509_vfy.h>, the associated error message documented in X509_STORE_CTX_get_error(3), and the depth. The depth is the number of the certificate being verified when a problem was detected β€” starting with zero for the certificate being verified itself, then 1 for the CA that signed the certificate, and so on. 😭


πŸ’– VERSION πŸ’–

openssl version [-abdfpv]

The version command prints out version information about openssl. Short and sweet.

The options are as follows:

  • -a β€” all information: this is the same as setting all the other flags.
  • -b β€” the date the current version of openssl was built.
  • -d β€” OPENSSLDIR setting.
  • -f β€” compilation flags.
  • -p β€” platform setting.
  • -v β€” the current openssl version.

🌸 X509 🌸

openssl x509  [-addreject arg] [-addtrust arg] [-alias] [-CA file]
              [-CAcreateserial] [-CAform der | pem] [-CAkey file]
              [-CAkeyform der | pem] [-CAserial file] [-certopt option]
              [-checkend arg] [-clrext] [-clrreject] [-clrtrust]
              [-dates] [-days arg] [-email] [-enddate]
              [-extensions section] [-extfile file] [-fingerprint]
              [-force_pubkey key] [-hash] [-in file]
              [-inform der | net | pem] [-issuer] [-issuer_hash]
              [-issuer_hash_old] [-keyform der | pem] [-md5 | -sha1]
              [-modulus] [-multivalue-rdn] [-nameopt option] [-new]
              [-next_serial] [-noout] [-ocsp_uri] [-ocspid] [-out file]
              [-outform der | net | pem] [-passin arg] [-pubkey]
              [-purpose] [-req] [-serial] [-set_issuer name]
              [-set_serial n] [-set_subject name] [-setalias arg]
              [-signkey file] [-sigopt nm:v] [-startdate] [-subject]
              [-subject_hash] [-subject_hash_old] [-text] [-trustout]
              [-utf8] [-x509toreq]

The x509 command is a multi-purpose certificate utility. Like, it can display certificate information, convert certificates to various forms, sign certificate requests like a "mini CA", or edit certificate trust settings. She does it all, main character energy fr. πŸ‘‘βœ¨

The following are x509 input, output, and general purpose options:

  • -in file β€” the input file to read from, or standard input if you don't specify one. This option cannot be used with -new. 🫢
  • -inform der | net | pem β€” the input format. Normally the command expects an X.509 certificate, but this can change if other options like -in or -req are present.
  • -md5 | -sha1 β€” the digest to use. This affects any signing or display option that uses a message digest, such as the -fingerprint, -signkey, and -CA options. If not specified, MD5 is used. SHA1 is always used with DSA keys.
  • -out file β€” the output file to write to, or standard output if none is specified.
  • -outform der | net | pem β€” the output format.
  • -passin arg β€” the key password source.

The following are x509 display options:

  • -certopt option β€” customise the output format used with -text, either using a list of comma-separated options or by specifying -certopt multiple times. The default behaviour is to print all fields. The options are as follows:

okay so the -nameopt lore continues, and honestly this next batch is giving "menu of ways to make your DN look cute or completely unhinged" πŸ’…

  • ca_default β€” equivalent to no_issuer, no_pubkey, no_header, no_version, no_sigdump, and no_signame. the "just the hits" preset fr.
  • compatible β€” equivalent to no output options at all. the bare minimum, the vanilla of nameopts.
  • ext_default β€” print unsupported certificate extensions.
  • ext_dump β€” hex dump unsupported extensions.
  • ext_error β€” print an error message for unsupported certificate extensions.
  • ext_parse β€” ASN.1 parse unsupported extensions.
  • no_aux β€” do not print certificate trust information.
  • no_extensions β€” do not print X509V3 extensions.
  • no_header β€” do not print header (Certificate and Data) information.
  • no_issuer β€” do not print the issuer name.
  • no_pubkey β€” do not print the public key.
  • no_serial β€” do not print the serial number.
  • no_sigdump β€” do not give a hexadecimal dump of the certificate signature.
  • no_signame β€” do not print the signature algorithm used.
  • no_subject β€” do not print the subject name.
  • no_validity β€” do not print the notBefore and notAfter (validity) fields.
  • no_version β€” do not print the version number.

  • -dates β€” print the start and expiry date of a certificate. both. the whole timeline ✨
  • -email β€” output the email addresses, if any.
  • -enddate β€” print the expiry date of the certificate; that is, the notAfter date. it's giving "when does this expire" energy.
  • -fingerprint β€” print the digest of the DER-encoded version of the whole certificate. the full-cert fingerprint, no cuts.
  • -hash β€” a synonym for -subject_hash. same thing, shorter name, iconic.
  • -issuer β€” print the issuer name.
  • -issuer_hash β€” print the hash of the certificate issuer name.
  • -issuer_hash_old β€” print the hash of the certificate issuer name using the older algorithm as used by openssl versions before 1.0.0. legacy behaviour, still slaying in its own way 🫢
  • -modulus β€” print the value of the modulus of the public key contained in the certificate.
  • -multivalue-rdn β€” this option causes the -subj argument to be interpreted with full support for multivalued RDNs, for example /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe. If -multivalue-rdn is not used, the UID value is set to 123456+CN=John Doe. so without the flag that whole thing gets swallowed into one UID and it's a whole mess 😭
  • -nameopt option β€” customise how the subject or issuer names are displayed, either using a list of comma-separated options or by specifying -nameopt multiple times. the default behaviour is to use the compat format. the options, which can be preceded by a dash to turn them off, are as follows β€” and yes there are a LOT of them, buckle up bestie:
    • align β€” align field values for a more readable output. only usable with sep_multiline.
    • compat β€” use the old format, equivalent to specifying no options at all.
    • dn_rev β€” reverse the fields of the DN, as required by RFC 2253. as a side effect, this also reverses the order of multiple AVAs.
    • dump_all β€” dump all fields. when used with dump_der, it allows the DER encoding of the structure to be unambiguously determined.
    • dump_der β€” any fields that need to be hexdumped are dumped using the DER encoding of the field. otherwise just the content octets will be displayed. both options use the RFC 2253 #XXXX... format.
    • dump_nostr β€” dump non-character string types (for example OCTET STRING); usually, non-character string types are displayed as though each content octet represents a single character.
    • dump_unknown β€” dump any field whose OID is not recognised by openssl.
    • esc_2253 β€” escape the "special" characters required by RFC 2253 in a field that is " ,+"<>;". additionally, # is escaped at the beginning of a string and a space character at the beginning or end of a string.
    • esc_ctrl β€” escape control characters. that is, those with ASCII values less than 0x20 (space) and the delete (0x7f) character. they are escaped using the RFC 2253 \XX notation (where XX are two hex digits representing the character value).
    • esc_msb β€” escape characters with the MSB set; that is, with ASCII values larger than 127. πŸ‘€
    • multiline β€” a multiline format. equivalent to esc_ctrl, esc_msb, sep_multiline, space_eq, lname, and align. the combo meal.
    • no_type β€” do not attempt to interpret multibyte characters. that is, content octets are merely dumped as though one octet represents each character. this is useful for diagnostic purposes but results in rather odd looking output. it's giving cursed but useful πŸ’€
    • nofname, sname, lname, oid β€” alter how the field name is displayed: nofname does not display the field at all; sname uses the short name form (CN for commonName, for example); lname uses the long form. oid represents the OID in numerical form and is useful for diagnostic purpose.
    • oneline β€” a one line format which is more readable than RFC2253. equivalent to esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_der, use_quote, sep_comma_plus_space, space_eq, and sname.
    • RFC2253 β€” displays names compatible with RFC 2253. equivalent to esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_unknown, dump_der, sep_comma_plus, dn_rev, and sname.
    • sep_comma_plus, sep_comma_plus_space, sep_semi_plus_space, sep_multiline β€” determine the field separators: the first character is between RDNs and the second between multiple AVAs (multiple AVAs are very rare and their use is discouraged). the options ending in "space" additionally place a space after the separator to make it more readable. sep_multiline uses a linefeed character for the RDN separator and a spaced + for the AVA separator, as well as indenting the fields by four characters. if no field separator is specified then sep_comma_plus_space is used by default.
    • show_type β€” show the type of the ASN.1 character string. the type precedes the field contents. for example BMPSTRING: Hello World.
    • space_eq β€” place spaces round the = character which follows the field name.
    • use_quote β€” escape some characters by surrounding the whole string with " characters. without the option, all escaping is done with the \ character.
    • utf8 β€” convert all strings to UTF8 format first, as required by RFC 2253. on a UTF8 compatible terminal, the use of this option (and not setting esc_msb) may result in the correct display of multibyte characters. usually, multibyte characters larger than 0xff are represented using the format \UXXXX for 16 bits and \WXXXXXXXX for 32 bits, and any UTF8Strings are converted to their character form first. 🌈
  • -next_serial β€” print the next serial number.
  • -noout β€” do not output the encoded version of the request.
  • -ocsp_uri β€” print the OCSP responder addresses, if any.
  • -ocspid β€” print OCSP hash values for the subject name and public key.
  • -pubkey β€” print the public key.
  • -serial β€” print the certificate serial number.
  • -sigopt nm:v β€” pass options to the signature algorithm during sign or certify operations. the names and values of these options are algorithm-specific.
  • -startdate β€” print the start date of the certificate; that is, the notBefore date.
  • -subject β€” print the subject name.
  • -subject_hash β€” print the hash of the certificate subject name. this is used in openssl to form an index to allow certificates in a directory to be looked up by subject name. it's the filing system bestie πŸ“
  • -subject_hash_old β€” print the hash of the certificate subject name using the older algorithm as used by openssl versions before 1.0.0.
  • -text β€” print the full certificate in text form. the whole thing, the full story, no skips.

πŸŽ€ the trust settings part πŸŽ€

a trusted certificate is a certificate which has several additional pieces of information attached to it such as the permitted and prohibited uses of the certificate and an alias. when a certificate is being verified, at least one certificate must be trusted. by default, a trusted certificate must be stored locally and be a root CA. the following are x509 trust settings options β€” yes this is a whole extra little world:

  • -addreject arg β€” add a prohibited use. accepts the same values as the -addtrust option.
  • -addtrust arg β€” add a trusted certificate use. any object name can be used here, but currently only clientAuth (SSL client use), serverAuth (SSL server use), and emailProtection (S/MIME email) are used.
  • -alias β€” output the certificate alias.
  • -clrreject β€” clear all the prohibited or rejected uses of the certificate.
  • -clrtrust β€” clear all the permitted or trusted uses of the certificate.
  • -purpose β€” perform tests on the certificate extensions. the same code is used when verifying untrusted certificates in chains, so this section is useful if a chain is rejected by the verify code. lowkey a whole diagnostic tool hidden in an option πŸ•΅οΈ

the basicConstraints extension CA flag is used to determine whether the certificate can be used as a CA. if the CA flag is true, it is a CA; if the CA flag is false, it is not a CA. all CAs should have the CA flag set to true.

if the basicConstraints extension is absent, then the certificate is considered to be a possible CA; other extensions are checked according to the intended use of the certificate. a warning is given in this case because the certificate should really not be regarded as a CA. however it is allowed to be a CA to work around some broken software. 😬

if the certificate is a V1 certificate (and thus has no extensions) and it is self-signed, it is also assumed to be a CA but a warning is again given. this is to work around the problem of Verisign roots which are V1 self-signed certificates.

bestie note: those last two are straight-up workarounds for broken software and old Verisign roots β€” the tool is being lenient on purpose, and it's telling you so. don't read "no warning" as "all good".

πŸ’… Purpose tests, continued (the vibe check for each cert type)

Quick recap bestie, because this matters: if the keyUsage extension is present, then extra restraints get put on how the certificate can be used. A CA certificate must have the keyCertSign bit set if the keyUsage extension is present.

The extended key usage extension puts even more restrictions on certificate uses. If this extension is present β€” whether critical or not β€” the key can only be used for the purposes specified. Periodt.

A complete description of each test is below, and the comments about basicConstraints and keyUsage and V1 certificates from earlier apply to all CA certificates. πŸ‘‘

SSL Client

  • The extended key usage extension must be absent, or include the web client authentication OID.
  • keyUsage must be absent, or it must have the digitalSignature bit set.
  • The Netscape certificate type must be absent, or it must have the SSL client bit set.

SSL Client CA

  • The extended key usage extension must be absent, or include the web client authentication OID.
  • The Netscape certificate type must be absent, or it must have the SSL CA bit set β€” this is used as a workaround if the basicConstraints extension is absent.

SSL Server

  • The extended key usage extension must be absent, or include the web server authentication and/or one of the SGC OIDs.
  • keyUsage must be absent, or it must have the digitalSignature set, the keyEncipherment set, or both bits set.
  • The Netscape certificate type must be absent, or have the SSL server bit set.

SSL Server CA

  • The extended key usage extension must be absent, or include the web server authentication and/or one of the SGC OIDs.
  • The Netscape certificate type must be absent, or the SSL CA bit must be set β€” this is used as a workaround if the basicConstraints extension is absent.

Netscape SSL Server

For Netscape SSL clients to connect to an SSL server: it must have the keyEncipherment bit set if the keyUsage extension is present. This isn't always valid because some cipher suites use the key for digital signing. Otherwise it's the same as a normal SSL server. πŸ€·β€β™€οΈ

Common S/MIME Client Tests

  • The extended key usage extension must be absent, or include the email protection OID.
  • The Netscape certificate type must be absent, or should have the S/MIME bit set. If the S/MIME bit is not set in Netscape certificate type, then the SSL client bit is tolerated as an alternative β€” but a warning is shown. Why? Because some Verisign certificates don't set the S/MIME bit. πŸ’€

S/MIME Signing

In addition to the common S/MIME client tests, the digitalSignature bit must be set if the keyUsage extension is present.

S/MIME Encryption

In addition to the common S/MIME tests, the keyEncipherment bit must be set if the keyUsage extension is present.

S/MIME CA

  • The extended key usage extension must be absent, or include the email protection OID.
  • The Netscape certificate type must be absent, or must have the S/MIME CA bit set β€” this is used as a workaround if the basicConstraints extension is absent.

CRL Signing

The keyUsage extension must be absent, or it must have the CRL signing bit set.

CRL Signing CA

The normal CA tests apply, except the basicConstraints extension must be present. No workarounds here, bestie. 🚩


πŸŽ€ A couple more certificate-ish options

  • -setalias arg β€” sets the alias of the certificate, so you can refer to it with a nickname. Like literally "Steve's Certificate". Cute, right? 🫢
  • -trustout β€” outputs a trusted certificate (this is the default if any trust settings are modified). You can feed in either an ordinary or a trusted certificate, but by default an ordinary certificate is output and any trust settings get yeeted into the void. πŸ—‘οΈ

✨ The mini-CA era: x509 signing options

The x509 utility can be used to sign certificates and requests β€” so it can totally behave like a mini CA. It's giving main character energy, honestly. 🌈

The following are x509 signing options:

  • -CA file β€” the CA certificate to be used for signing. When this option is present, x509 behaves like a mini CA. The input file is signed by the CA using this option; that is, its issuer name is set to the subject name of the CA, and it is digitally signed using the CA's private key.

This option is normally combined with the -req option. Without the -req option, the input is a certificate which must be self-signed.

  • -CAcreateserial β€” create the CA serial number file if it doesn't exist, instead of throwing an error. The file will contain the serial number 02, and the certificate being signed will have 1 as its serial number. Math is mathing πŸ”₯
  • -CAform der | pem β€” the format of the CA certificate file. The default is pem.
  • -CAkey file β€” set the CA private key to sign a certificate with. Otherwise it's assumed that the CA private key is present in the CA certificate file.
  • -CAkeyform der | pem β€” the format of the CA private key. The default is pem.
  • -CAserial file β€” use the serial number in file to sign a certificate. The file should consist of one line containing an even number of hex digits with the serial number to use. After each use the serial number is incremented and written out to the file again. πŸ”

The default filename consists of the CA certificate file base name with .srl appended. For example, if the CA certificate file is called mycacert.pem, it expects to find a serial number file called mycacert.srl. iykyk πŸ’…

  • -checkend arg β€” check whether the certificate expires in the next arg seconds. If so, exit with return value 1; otherwise exit with return value 0. It's a vibe check for expiry dates, honestly. ⏰
  • -clrext β€” delete any extensions from a certificate. This option is used when a certificate is being created from another certificate (for example with the -signkey or the -CA options). Normally, all extensions are retained.
  • -days arg β€” the number of days to make a certificate valid for. The default is 30 days. πŸ—“οΈ
  • -extensions section β€” the section to add certificate extensions from. If this option is not specified, the extensions should either be contained in the unnamed (default) section, or the default section should contain a variable called "extensions" which contains the section to use.
  • -extfile file β€” file containing certificate extensions to use. If not specified, no extensions are added to the certificate.
  • -force_pubkey key β€” set the public key of the certificate to the public key contained in key.
  • -keyform der | pem β€” the format of the key file used in the -force_pubkey and -signkey options.
  • -new β€” generate a new certificate using the subject given by -set_subject and signed by -signkey. If no public key is provided with -force_pubkey, the resulting certificate is self-signed. This option cannot be used with -in or -req. πŸ™…β€β™€οΈ
  • -req β€” expect a certificate request on input instead of a certificate. This option cannot be used with -new.
  • -set_issuer name β€” the issuer name to use. name must be formatted as /type0=value0/type1=value1/type2=...; characters may be escaped by \ (backslash); no spaces are skipped. No cap, it's that literal. 🎯
  • -set_serial n β€” the serial number to use. This option can be used with either the -signkey or -CA options. If used in conjunction with the -CA option, the serial number file (as specified by the -CAserial or -CAcreateserial options) is not used.

The serial number can be decimal or hex (if preceded by 0x). Negative serial numbers can also be specified, but their use is not recommended. Don't do it bestie, it's giving bad idea energy 🚨

  • -set_subject name β€” the subject name to use. name must be formatted as /type0=value0/type1=value1/type2=...; characters may be escaped by \ (backslash); no spaces are skipped.
  • -signkey file β€” self-sign file using the supplied private key.

If the input file is a certificate, it sets the issuer name to the subject name (i.e. makes it self-signed), changes the public key to the supplied value, and changes the start and end dates. The start date is set to the current time and the end date is set to a value determined by the -days option. Any certificate extensions are retained unless the -clrext option is supplied.

If the input is a certificate request, a self-signed certificate is created using the supplied private key using the subject name in the request. πŸͺ„

  • -utf8 β€” interpret field values read from a terminal or obtained from a configuration file as UTF-8 strings. By default, they are interpreted as ASCII.
  • -x509toreq β€” convert a certificate into a certificate request. The -signkey option is used to pass the required private key.

✨ COMMON NOTATION ✨

okay so bestie, a bunch of these commands share the same ✨vibes✨ when it comes to syntax, and here's the tea πŸ«– β€” it's all laid out below.

Password arguments, usually dropped in via -passin and -passout for the input password and the output password respectively, let you grab a password from like... wherever. Both of these options take a single argument, described down below πŸ‘‡. If you don't give a password argument and a password is needed, then the user gets prompted to type one in: this is normally read from the current terminal with echoing turned off (so nobody sees you typing, very sneaky, love that for you πŸ™ˆ).

  • pass:password β€” the actual password is literally password. But uh, since the password is visible to utilities, only use this form when security is not important. it's giving "my password is password123" energy πŸ’€
  • env:var β€” grab the password from the environment variable var. Since the environment of other processes is visible, use this one with caution, ngl.
  • file:path β€” the first line of path is the password. Here's the cute part: if the same path argument is given to both -passin and -passout, then the first line gets used for the input password and the next line gets used for the output password πŸŽ€. And path doesn't even have to refer to a regular file β€” it could, for example, refer to a device or a named pipe. versatile icon ✨
  • fd:number β€” read the password from the file descriptor number. This can be used to send the data via a pipe, for example. main character file descriptor behavior πŸ’…
  • stdin β€” read the password from standard input. simple, iconic, no notes.

Input/output formats, typically specified using -inform and -outform, tell you what format is being read from or written to. The argument is case insensitive (so go ahead and shout it, she doesn't mind πŸ”₯).

  • der β€” Distinguished Encoding Rules (DER) is a binary format.
  • net β€” insecure legacy format. yes bestie, insecure. we said what we said πŸ’€
  • pem β€” Privacy Enhanced Mail (PEM) is base64-encoded.
  • pvk β€” Private Key format.
  • smime β€” an SMIME format message.
  • txt β€” plain ASCII text.

🌸 ENVIRONMENT 🌸

These environment variables affect how openssl runs, so like... keep them in mind, iykyk:

  • OPENSSL_CONF β€” the location of the master configuration file. literally the blueprint of the whole operation πŸ‘‘

πŸŽ€ FILES πŸŽ€

the paths, the vibes, the lore:

  • /etc/ssl/ β€” default config directory for openssl.
  • /etc/ssl/lib/ β€” unused. she's just there. sitting pretty. no purpose. mood honestly πŸ’€
  • /etc/ssl/private/ β€” default private key directory.
  • /etc/ssl/openssl.cnf β€” default configuration file for openssl.
  • /etc/ssl/x509v3.cnf β€” default configuration file for x509 certificates.

πŸ¦‹ SEE ALSO πŸ¦‹

go read these next, bestie, they're all part of the extended universe:

acme-client(1), nc(1), openssl.cnf(5), x509v3.cnf(5), ssl(8), starttls(8)


🌈 STANDARDS 🌈

the receipts, the citations, the "we didn't make this up" section πŸ“šβœ¨:

  • T. Dierks and C. Allen, The TLS Protocol Version 1.0, RFC 2246, January 1999.
  • M. Wahl, S. Killie, and T. Howes, Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, RFC 2253, December 1997.
  • B. Kaliski, PKCS #7: Cryptographic Message Syntax Version 1.5, RFC 2315, March 1998.
  • R. Housley, W. Ford, W. Polk, and D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 2459, January 1999.
  • M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, RFC 2560, June 1999.
  • R. Housley, Cryptographic Message Syntax, RFC 2630, June 1999.
  • P. Chown, Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS), RFC 3268, June 2002.

and that's a wrap on the whole OPENSSL(1) saga, bestie πŸ«ΆπŸ’– you made it to the end, I'm so proud of you. this page is from Debian, dated August 25, 2026, and it lives under the name OPENSSL(1) β€” go forth and encrypt things responsibly, mwah πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from
  • arch rolling: libressl 4.4.0-1 Β· ISC AND custom:OpenSSL
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms