OPENSSL-REQ(1SSL)

📦
version 4.0.3 · 13 versions
, in ubuntu stonking

💖 OPENSSL-REQ(1SSL) 💖

okay bestie, pull up a chair, we're doing openssl-req, aka the openssl manual for the PKCS#10 certificate request and certificate generating command. yes that's a mouthful. yes it's iconic. let's go 🎀

✨ NAME ✨

openssl-req — the command that does PKCS#10 certificate request and certificate generating. that's the whole vibe. CSRs and the certs that come from them. periodt.

🌸 SYNOPSIS 🌸

openssl req [-help] [-cipher] [-inform DER|PEM] [-outform DER|PEM] [-in
filename] [-passin arg] [-out filename] [-passout arg] [-text] [-pubkey]
[-noout] [-verify] [-modulus] [-new] [-newkey arg] [-pkeyopt opt:value]
[-noenc] [-nodes] [-key filename|uri] [-keyform DER|PEM|P12] [-keyout
filename] [-digest] [-config filename] [-section name] [-x509] [-x509v1]
[-CA filename|uri] [-CAkey filename|uri] [-not_before date] [-not_after
date] [-days n] [-set_serial n] [-newhdr] [-copy_extensions arg]
[-extensions section] [-reqexts section] [-addext ext] [-precert]
[-utf8] [-reqopt] [-subject] [-subj arg] [-multivalue-rdn] [-sigopt
nm:v] [-vfyopt nm:v] [-batch] [-verbose] [-quiet] [-nameopt option]
[-rand files] [-writerand file] [-provider name] [-provider-path path]
[-provparam [name:]key=value] [-propquery propq]

like… look at her. so many flags. she's serving versatility 💅

👑 DESCRIPTION 👑

so what does this thing actually do, bestie? two things, and both are lowkey important:

  • its main character job is creating and processing certificate requests (CSRs) in PKCS#10 format
  • but she also moonlights as a self-signed certificate generator, which you'd use for stuff like root CAs, for example

that's it. that's the whole personality. and yet every tutorial on the internet uses her, so. 🤷♀️

🌈 OPTIONS 🌈

this is the long part. stay with me. every single one of these matters, no skipping, no skimming, the way that I'm about to explain all of them in order 🔥

  • -help — prints out a usage message. the "help me bestie" button.
  • -inform DER|PEM — which format the CSR input file is in. by default, PEM gets tried first. for the deets, go see openssl-format-options(1).
  • -outform DER|PEM — the output format. it's unspecified by default. again, openssl-format-options(1) has the details.

just so you know, the data here is a PKCS#10 object.

  • -cipher name — tells it which cipher to use when encrypting the private key. if you don't name one, AES-256-CBC is used by default. and you can override that by giving it any valid OpenSSL cipher name. your key, your rules 💅
  • -in filename — the input filename to read a request from. defaults to standard input, unless -x509 or -CA is specified. heads up: a request only gets read if the creation options (-new or -newkey or -precert) are not specified. so if you're making something new, this one just chills.
  • -sigopt nm:v — passes options to the signature algorithm during sign operations. the names and values are algorithm-specific, so iykyk.
  • -vfyopt nm:v — same deal but during verify operations. also algorithm-specific with the names and values.
  • -passin arg — the password source for private key and certificate input. the format of arg lives in openssl-passphrase-options(1).
  • -passout arg — the password source for the output file. same thing, format of arg is in openssl-passphrase-options(1).
  • -out filename — the output filename to write to. defaults to standard output.
  • -text — prints out the certificate request in text form. human-readable slay.
  • -subject — prints out the certificate request subject. (or the certificate subject, if -x509 is in use.)
  • -pubkey — prints out the public key.
  • -noout — stops it from outputting the encoded version of the certificate request. very "i don't need to see all that" of her.
  • -modulus — prints out the value of the modulus of the public key contained in the request.
  • -verify — verifies the self-signature on the request. and bestie, listen: if the verification fails, the program immediately exits, meaning further option processing (like -text) gets skipped. it does not wait around. 💀
  • -new — generates a new certificate request. it'll prompt the user for the relevant field values. which fields get prompted for, plus their max and min sizes, comes from the configuration file and any requested extensions.

and if you didn't give it -key, it generates a new private key using info from the configuration file, or from the -newkey and -pkeyopt options. failing all that, the default is an RSA key with 2048 bits length.

  • -newkey arg — generates a new private key, unless -key was given. after that it's used exactly as if you'd passed it with the -key option.

this option implies the -new flag, so it creates a new certificate request — or a new certificate, in the case that -x509 is used.

the argument takes one of several forms, so let's break it down:

  • [rsa:]nbits — generates an RSA key nbits in size. if nbits is omitted, i.e. you typed -newkey rsa, then the default key size from the config file's default_bits option is used if present, else 2048.
  • every other algorithm supports the -newkey algname:file form, where file is an algorithm parameter file (created with openssl genpkey -genparam) or an X.509 certificate for a key with appropriate algorithm.
  • param:file — generates a key using the parameter file or certificate file; the algorithm is determined by the parameters.
  • algname[:file] — generates a key using the given algorithm algname. if a parameter file file is given, the parameters in there are used, and the algorithm parameters must match algname. if algorithm parameters aren't given, any necessary parameters should be specified via the -pkeyopt option.
  • dsa:filename — generates a DSA key using the parameters in the file filename. ec:filename generates an EC key (usable with both ECDSA or ECDH algorithms). gost2001:filename, gost2012_256:filename and gost2012_512:filename generate GOST R 34.10-2001 and GOST R 34.10-2012 keys with a 256 and 512 bit modulus respectively — note these require the gostprov provider. and if you just say gost2001, a parameter set should be specified by -pkeyopt paramset:X.
  • -pkeyopt opt:value — sets the public key algorithm option opt to value. the exact set of options supported depends on the public key algorithm you're using and its implementation, so don't expect a universal list. more detail lives in "KEY GENERATION OPTIONS" in openssl-genpkey(1).
  • -key filename|uri — this is where you hand over the private key for signing a new certificate or certificate request. unless -in is given, the matching public key gets placed into the new certificate or request, which means… a self-signature ✨.

if you're doing certificate signing, this option gets overridden by the -CA option.

also, for PEM format files, this option happily accepts PKCS#8 format private keys.

  • -keyform DER|PEM|P12 — the format of the private key. unspecified by default. openssl-format-options(1) for details.
  • -keyout filename — the filename to write any private key to that was newly created or read from -key. if you give neither -keyout nor -key, then the filename from the config file's default_keyfile option is used, if present. so real talk: if you want the private key written and you gave -key, you should pass -keyout explicitly. and if a new key is generated with no filename specified, the key goes to standard output. 🙈
  • -noenc — if this is specified, then if a private key gets created, it will not be encrypted.
  • -nodes — ⚠️ this one is deprecated since OpenSSL 3.0; use -noenc instead. still there, but she's retired, bestie.
  • -digest — the message digest used to sign the request. you can use any digest supported by the OpenSSL dgst command. this overrides the digest algorithm specified in the config file.

caveat: some public key algorithms may override this choice. for instance, DSA signatures always use SHA1, GOST R 34.10 signatures always use GOST R 34.11-94 (-md_gost94), and Ed25519 and Ed448 never use any digest. so yeah, she doesn't always get the final say.

  • -config filename — lets you specify an alternative configuration file. optional! for a description of the default value, see "COMMAND SUMMARY" in openssl(1).
  • -section name — the name of the section to use. the default is req.
  • -subj arg — sets the subject name for a new request, or supersedes the subject name when you're processing a certificate request.

the arg must be formatted as "/type0=value0/type1=value1/type2=...". some notes, because this one bites people:

  • special characters can be escaped with "\" (backslash)
  • whitespace is retained
  • empty values are permitted, but the corresponding type will not be included in the request
  • giving a single "/" leads to an empty sequence of RDNs (a NULL-DN)
  • multi-valued RDNs can be formed by putting a "+" character instead of a "/" between the AttributeValueAssertions (AVAs) that specify the members of the set

example, because a visual helps:

"/DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe"
  • -multivalue-rdn — this option has been deprecated and has no effect. so… don't. 💀
  • -x509 — outputs a certificate instead of a certificate request. typically used to generate test certificates. it gets implied by the -CA option.
    • this option implies the -new flag if -in isn't given
    • if an existing request is specified with -in, it's converted to a certificate; otherwise a request is created from scratch
    • unless you specify it with -set_serial, a large random number is used for the serial number
    • unless the -copy_extensions option is used, X.509 extensions are NOT copied from any provided request input file 🚨
    • the X.509 extensions you want added can be specified in the configuration file — possibly using -config and -extensions — and/or by using the -addext option
    • unless -x509v1 is given, generated certificates bear X.509 version 3, even if no extensions are added
  • -x509v1 — requests generation of certificates with X.509 version 1. this implies -x509. but plot twist: if X.509 extensions are added, X.509 version 3 is used regardless of this option.
  • -CA filename|uri — specifies the "CA" certificate to sign a new certificate with, and implies use of -x509. when present, this behaves like a "micro CA", and here's how: the subject name of the "CA" certificate gets placed as the issuer name in the new certificate, which is then signed using the "CA" key given as specified below. cute, functional, effective. 💖
  • -CAkey filename|uri — sets the "CA" private key to sign a certificate with. the private key must match the public key of the certificate given with -CA. if you don't provide this option, then the key must be present in the -CA input.
  • -not_before date — when -x509 is in use, this lets you explicitly set the start date. otherwise, it's ignored. the format of date is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure), or YYYYMMDDHHMMSSZ (the same as an ASN1 GeneralizedTime structure). in both formats, the seconds SS and the timezone Z must be present. alternatively, you can also use "today". ⭐

and that's part one, bestie!! don't go anywhere, there's more of this masterpiece coming 🦋

  • -not_after date — okay so when you're using -x509 this lets you set the expiry date explicitly, and if you're not using -x509? It just gets ignored, bestie, no drama. The format of date is YYMMDDHHMMSSZ (same vibe as an ASN1 UTCTime structure), or YYYYMMDDHHMMSSZ (same vibe as an ASN1 GeneralizedTime structure). In both formats the seconds SS and the timezone Z must be there, no skipping 💅. Oh and you can also just write "today".

This one overrides the -days option, so it wins the argument, slay.

  • -days n — when -x509 is in use this says how many days from today to certify the certificate for; otherwise it's ignored. n should be a positive integer. Default is 30 days.

Regardless of the option -not_before, the days are always counted from today. And when you use it together with -not_after, the explicit expiry date takes precedence. Periodt.

  • -set_serial n — the serial number to use when you're outputting a self-signed certificate. You can hand it over as a decimal value, or as a hex value if it's preceded by "0x". If you don't give one, a big random number gets used instead ✨.
  • -copy_extensions arg — this one decides how X.509 extensions in certificate requests get handled when -x509 is in use. If arg is none, or the option isn't there at all, then extensions are just ignored 🫥. If arg is copy or copyall then all extensions in the request get copied to the certificate.

The main use of this option is letting a certificate request supply values for certain extensions, like subjectAltName. Super useful.

  • -extensions section, -reqexts section — these let you override the name of the configuration file section that X.509 extensions get pulled from, either for certificates (when -x509 is in use) or for certificate requests. This means you can have several different sections in the same config file for requests of all different purposes, iconic.

So when signing a new CSR or X.509 certificate, if neither -extensions nor its alias -reqexts is specified, the name of the extension section is taken from the "req" section of the configuration file. Specifically, from the value of that section's "req_extensions" variable (for a CSR) or its "x509_extensions" variable (for a certificate). If there's no setting for the variable in question (that's the name/value assignment, see config(5)), the configuration file doesn't add any extensions. And the -section option can override "req" with a custom section to go looking for those "req_extensions" and "x509_extensions" variables.

Heads up bestie: OpenSSL 4.0 removed built-in generation of the subjectKeyIdentifier and authorityKeyIdentifier extensions when generating certificates. Any extensions you want need to be listed either in the configuration file or via the -addext option down below. No cap.
  • -addext ext — adds a specific extension to the certificate (if -x509 is in use) or to the certificate request. The argument has to have the form of a "key=value" pair, exactly like it would appear in a configuration file.

Each extension can appear at most once in a certificate or certificate request, so don't get greedy. Extensions listed via this option on the command line override any corresponding extensions in the configuration file 👑

You can give this option multiple times, but any given extension can be specified through it at most once.

To drop any unwanted subjectKeyIdentifier or authorityKeyIdentifier extensions that might get added by default via the configuration file, use either or both of these:

-addext subjectKeyIdentifier=none
-addext authorityKeyIdentifier=none

These work as expected even if the extensions weren't there to begin with 🙈.

  • -precert — a poison extension gets added to the certificate, making it a "pre-certificate" (see RFC6962). You can submit this to Certificate Transparency logs to obtain signed certificate timestamps (SCTs). Then those SCTs can be embedded into the pre-certificate as an extension, before removing the poison and signing the certificate. Full main character journey 💀

This implies the -new flag.

  • -utf8 — this makes field values be interpreted as UTF8 strings; by default they're interpreted as ASCII. Which means the field values — whether they're prompted from a terminal or obtained from a configuration file — must be valid UTF8 strings.
  • -reqopt option — customises the printing format used with -text. The option argument can be a single option, or multiple options separated by commas.

See the discussion of the -certopt parameter in the openssl-x509(1) command.

  • -newhdr — adds the word NEW to the PEM file header and footer lines on the outputted request. Some software (Netscape certificate server) and some CAs need this. Retro of them 🌸
  • -batch — non-interactive mode.
  • -verbose — prints extra details about the operations being performed.
  • -quiet — prints fewer details about the operations being performed, which can be handy during batch scripts or pipelines (specifically, the "progress dots" during key generation get suppressed).
  • -nameopt option — specifies how the subject or issuer names are displayed. See openssl-namedisplay-options(1) for the details.
  • -rand files, -writerand file — see "Random State Options" in openssl(1) for details.
  • -provider name
  • -provider-path path
  • -provparam [name:]key=value
  • -propquery propq — see "Provider Options" in openssl(1), provider(7), and property(7).

🎀 CONFIGURATION FILE FORMAT 🎀

Okay so the configuration options live in the req section of the configuration file. You can name a different section by using the -section option. And just like with every configuration file ever, if no value is specified in that specific section, the initial unnamed or default section gets searched too. Thrilling, I know 💜

The options available are described in detail below.

✨ input_password, output_password ✨

The passwords for the input private key file (if there is one) and the output private key file (if one's going to be created). The command line options passin and passout override the configuration file values.

✨ default_bits ✨

Specifies the default key size in bits.

This option works together with the -new option to generate a new key. It can be overridden by specifying an explicit key size in the -newkey option. The smallest accepted key size is 512 bits. If no key size is specified, then 2048 bits is used.

✨ default_keyfile ✨

This is the default filename to write a private key to. If it's not specified, the key gets written to standard output. This can be overridden by the -keyout option.

✨ 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.

✨ 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.

✨ RANDFILE ✨

At startup the specified file is loaded into the random number generator, and at exit 256 bytes will be written to it. It's used for private key generation. 🎲

✨ encrypt_key ✨

If this is set to no, then if a private key is generated it is not encrypted. This is equivalent to the -noenc command line option. For compatibility, encrypt_rsa_key is an equivalent option.

✨ default_md ✨

This specifies the digest algorithm to use. Any digest supported by the OpenSSL dgst command can be used. This option can be overridden on the command line. Certain signing algorithms (i.e. Ed25519 and Ed448) will ignore any digest that's been set.

✨ string_mask ✨

This masks out the use of certain string types in certain fields. Most users won't need to change this option. It can be set to several values:

  • utf8only — only UTF8Strings are used (this is the default value)
  • pkix — any string type except T61Strings
  • nombstr — any string type except BMPStrings and UTF8Strings
  • default — any kind of string type

Note that utf8only is the PKIX recommendation in RFC 5280, and it's the default string_mask; default is not the default option (messy, I know 😭). The nombstr value is a workaround for some software that has problems with variable-sized BMPStrings and UTF8Strings.

✨ req_extensions ✨

This specifies the configuration file section containing a list of extensions to add to the certificate request. It can be overridden by the -reqexts (or -extensions) command line switch. See the x509v3_config(5) manual page for details of the extension section format.

✨ x509_extensions ✨

This specifies the configuration file section containing a list of extensions to add to the certificate generated when -x509 is in use. It can be overridden by the -extensions command line switch.

✨ prompt ✨

If this is set to the value no, it disables prompting of certificate fields and just takes values from the config file directly. It also changes the expected format of the distinguished_name and attributes sections.

✨ utf8 ✨

If this is set to the value yes, then field values get interpreted as UTF8 strings; by default they're interpreted as ASCII. Which means the field values — whether prompted from a terminal or obtained from a configuration file — must be valid UTF8 strings.

✨ attributes ✨

This specifies the section containing any request attributes: its format is the same as distinguished_name. Typically these may contain the challengePassword or unstructuredName types. They're currently ignored by OpenSSL's request signing utilities, but some CAs might want them 👀

✨ distinguished_name ✨

This specifies the section containing the distinguished name fields to prompt for when generating a certificate or certificate request. The format is described in the next section.

🦋 DISTINGUISHED NAME AND ATTRIBUTE SECTION FORMAT 🦋

okay bestie so there are two totally different formats for the distinguished name and attribute sections, and which one you get depends on one little option. no cap.

If the prompt option is set to no, then these sections are just field names and values. like, literally just:

CN=My Name
OU=My Organization
emailAddress=someone@somewhere.org

This is the format that lets external programs (GUI-based ones, you know the vibe) generate a template file with all the field names and values already filled in, and then just hand that file straight to this command. there's an example of exactly this kind of configuration file down in the EXAMPLES section, so keep scrolling 💅

Alternatively — if the prompt option is absent or not set to no — then the file contains field prompting information instead. it's made of lines shaped like this:

fieldName="prompt"
fieldName_default="default field value"
fieldName_min= 2
fieldName_max= 4

fieldName is the field name you're using, for example commonName (or CN). the prompt string is what gets used to ask the user to enter the relevant details.

so here's the tea on how it behaves:

  • if the user enters nothing, the default value is used.
  • 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. iconic, honestly.

The number of characters entered has to be between the fieldName_min and fieldName_max limits. there may also be extra restrictions based on which field it is — like, countryName can only ever be two characters long and must fit in a PrintableString. periodt.

Some fields (such as organizationName) can be used more than once in a DN. this is a whole problem because configuration files will not recognize the same name occurring twice. awkward!! 😭 so to dodge that, 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. sneaky but slay.

The actual permitted field names are any object identifier short or long names. these are compiled into OpenSSL and include the usual suspects: commonName, countryName, localityName, organizationName, organizationalUnitName, stateOrProvinceName. plus emailAddress is in there too, alongside name, surname, givenName, initials, and dnQualifier.

Additional object identifiers can be defined with the oid_file or oid_section options in the configuration file. any additional fields get treated as though they were a DirectoryString. 💜

✨ EXAMPLES ✨

okay this is the fun part, let's go.

Examine and verify a certificate request:

openssl req -in req.pem -text -verify -noout

Specify the cipher to be used for encrypting the private key:

openssl req -newkey rsa:2048 -keyout privatekey.pem -out request.csr -cipher aes-256-cbc

Create a private key and then generate a certificate request from it:

openssl genrsa -out key.pem 2048
openssl req -new -key key.pem -out req.pem

The same but just using req:

openssl req -newkey rsa:2048 -keyout key.pem -out req.pem

Generate a self-signed root certificate:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out req.pem

Example of a file pointed to by the oid_file option:

1.2.3.4        shortName       A longer Name
1.2.3.6        otherName       Other longer Name

Example of a section pointed to by oid_section making use of variable expansion:

testoid1=1.2.3.5
testoid2=${testoid1}.6

Sample configuration file prompting for field values:

[ req ]
default_bits           = 2048
default_keyfile        = privkey.pem
distinguished_name     = req_distinguished_name
attributes             = req_attributes
req_extensions         = v3_ca

dirstring_type = nombstr

[ req_distinguished_name ]
countryName                    = Country Name (2 letter code)
countryName_default            = AU
countryName_min                = 2
countryName_max                = 2

localityName                   = Locality Name (eg, city)

organizationalUnitName         = Organizational Unit Name (eg, section)

commonName                     = Common Name (eg, YOUR name)
commonName_max                 = 64

emailAddress                   = Email Address
emailAddress_max               = 40

[ req_attributes ]
challengePassword              = A challenge password
challengePassword_min          = 4
challengePassword_max          = 20

[ v3_ca ]

subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = critical, CA:true

Sample configuration containing all field values:

[ req ]
default_bits           = 2048
default_keyfile        = keyfile.pem
distinguished_name     = req_distinguished_name
attributes             = req_attributes
prompt                 = no
output_password        = mypass

[ req_distinguished_name ]
C                      = GB
ST                     = Test State or Province
L                      = Test Locality
O                      = Organization Name
OU                     = Organizational Unit Name
CN                     = Common Name
emailAddress           = test@email.address

[ req_attributes ]
challengePassword              = A challenge password

Example of giving the most common attributes (subject and extensions) on the command line:

openssl req -new -subj "/C=GB/CN=foo" \
                 -addext "subjectAltName = DNS:foo.co.uk" \
                 -addext "certificatePolicies = 1.2.3.4" \
                 -newkey rsa:2048 -keyout key.pem -out req.pem

🌸 NOTES 🌸

The certificate requests generated by Xenroll with MSIE have extensions added. it includes the keyUsage extension, which determines the type of key (signature only, or general purpose), plus any additional OIDs entered by the script in an extendedKeyUsage extension. history lesson, bestie 🎀

💀 DIAGNOSTICS 💀

these are the messages people ask about the most, so let's vibe check them.

Using configuration from /some/path/openssl.cnf
Unable to load config info

This is followed some time later by:

unable to find 'distinguished_name' in config
problems making Certificate Request

The first error message is the clue: it can't find the configuration file! certain operations (like examining a certificate request) don't need a configuration file, so its use isn't enforced. generation of certificates or requests, however, does need a configuration file. this could be regarded as a bug. 💀

Another puzzling message is this:

Attributes:
    a0:00

this one shows up when no attributes are present and the request includes the correct empty SET OF structure (the DER encoding of which is 0xa0 0x00). but if you just see:

Attributes:

then the SET OF is missing and the encoding is technically invalid (but it is tolerated). see the description of the command line option -asn1-kludge for more information. 🙈

👑 BUGS 👑

buckle up, this one's messy.

OpenSSL's handling of T61Strings (aka TeletexStrings) is broken: it effectively treats them as ISO-8859-1 (Latin 1), and Netscape and MSIE have similar behaviour. this can cause problems if you need characters that aren't available in PrintableStrings and you don't want to — or can't — use BMPStrings. 😭

As a consequence of the T61String handling, the only correct way to represent accented characters in OpenSSL is to use a BMPString. unfortunately Netscape currently chokes on these. so if you have to use accented characters with Netscape and MSIE, then you currently need to use the invalid T61String form. tragic, but that's the tea.

The current prompting is not very friendly. it doesn't allow you to confirm what you've just entered. other things like extensions in certificate requests are statically defined in the configuration file. some of these — like an email address in subjectAltName — should be input by the user.

🫶 SEE ALSO 🫶

🌈 HISTORY 🌈

the lore drop, in order:

  • The default encryption cipher was changed from 3DES to AES-256 in OpenSSL 3.5.
  • The -section option was added in OpenSSL 3.0.0.
  • The -multivalue-rdn option has become obsolete in OpenSSL 3.0.0 and has no effect.
  • The <-nodes> option was deprecated in OpenSSL 3.0; use -noenc instead.
  • The -reqexts option has been made an alias of -extensions in OpenSSL 3.2.
  • Since OpenSSL 3.2, generated certificates bear X.509 version 3 unless -x509v1 is given, and key identifier extensions are included by default.
  • Since OpenSSL 3.3, the -verify option will exit with 1 on failure.
  • The -engine option was removed in OpenSSL 4.0.
  • As of OpenSSL 4.0, the req utility no longer has specialised built-in logic to add the SKID or AKID extensions, they are handled through configuration files and command-line options just like any other extension.

Copyright 2000-2026 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

and that's the whole page, bestie!! 🎀✨ this was version 4.0.3, dated 2026-09-29, and yeah — the manpage is literally called OPENSSL-REQ(1SSL). go forth and generate some certificate requests, you absolute icon. 💅🔥

📦 where this page comes from