OPENSSL-CMP(1SSL)

📦

version 4.0.3 · 13 versions

💖 `openssl-cmp(1SSL)` 💖

bestie, you're looking at the openssl-cmp manual page. it's the OpenSSL command for the Certificate Management Protocol (CMP). we're gonna go through it together, no stress. 🫶

✨ NAME ✨

openssl-cmp — Certificate Management Protocol (CMP, RFCs 9810 and 9811) application. 💅

✨ SYNOPSIS ✨

okay so the basic shape is:

openssl cmp [-help] [-config filename] [-section names] [-verbosity
level]

Generic message options 🌈

[-cmd ir|cr|kur|p10cr|rr|genm] [-infotype name] [-profile name]
[-geninfo values] [-template filename] [-keyspec filename]

Certificate enrollment options 🎀

[-newkey filename|uri] [-newkeypass arg] [-centralkeygen [-newkeyout
filename] [-subject name] [-days number] [-reqexts name] [-sans spec]
[-san_nodefault] [-policies name] [-policy_oids names]
[-policy_oids_critical] [-popo number] [-csr filename] [-out_trusted
filenames|uris] [-implicit_confirm] [-disable_confirm] [-certout
filename] [-chainout filename]

Certificate enrollment and revocation options 🔄

[-oldcert filename|uri] [-issuer name] [-serial number] [-revreason
number]

Message transfer options 📬

[-server [http[s]://][userinfo@]host[:port][/path][?query][#fragment]]
[-proxy [http[s]://][userinfo@]host[:port][/path][?query][#fragment]]
[-no_proxy addresses] [-recipient name] [-path remote_path] [-keep_alive
value] [-msg_timeout seconds] [-total_timeout seconds]

Server authentication options 🔐

[-trusted filenames|uris] [-untrusted filenames|uris] [-srvcert
filename|uri] [-expect_sender name] [-ignore_keyusage]
[-unprotected_errors] [-ta_in_ip_extracerts] [-no_cache_extracerts]
[-srvcertout filename] [-extracertsout filename] [-cacertsout filename]
[-oldwithold filename] [-newwithnew filename] [-newwithold filename]
[-oldwithnew filename] [-crlcert filename] [-oldcrl filename] [-crlout
filename]

Client authentication and protection options 🛡️

[-ref value] [-secret arg] [-cert filename|uri] [-own_trusted
filenames|uris] [-key filename|uri] [-keypass arg] [-digest name] [-mac
name] [-extracerts filenames|uris] [-unprotected_requests]

Credentials format options 📄

[-certform PEM|DER] [-crlform PEM|DER] [-keyform PEM|DER|P12]
[-otherpass arg] [-provider name] [-provider-path path] [-provparam
[name:]key=value] [-propquery propq]

Random state options 🎲

[-rand files] [-writerand file]

TLS connection options 🔒

[-tls_used] [-tls_cert filename|uri] [-tls_key filename|uri]
[-tls_keypass arg] [-tls_extra filenames|uris] [-tls_trusted
filenames|uris] [-tls_host name]

Client-side debugging options 🐛

[-batch] [-repeat number] [-reqin filenames] [-reqin_new_tid] [-reqout
filenames] [-reqout_only filename] [-rspin filenames] [-rspout
filenames] [-use_mock_srv]

Mock server options 🎭

[-port number] [-max_msgs number] [-srv_ref value] [-srv_secret arg]
[-srv_cert filename|uri] [-srv_key filename|uri] [-srv_keypass arg]
[-srv_trusted filenames|uris] [-srv_untrusted filenames|uris] [-ref_cert
filename|uri] [-rsp_cert filename|uri] [-rsp_key filename|uri]
[-rsp_keypass filename|uri] [-rsp_crl filename|uri] [-rsp_extracerts
filenames|uris] [-rsp_capubs filenames|uris] [-rsp_newwithnew
filename|uri] [-rsp_newwithold filename|uri] [-rsp_oldwithnew
filename|uri] [-poll_count number] [-check_after number]
[-grant_implicitconf] [-pkistatus number] [-failure number]
[-failurebits number] [-statusstring arg] [-send_error]
[-send_unprotected] [-send_unprot_err] [-accept_unprotected]
[-accept_unprot_err] [-accept_raverified]

Certificate verification options, for both CMP and TLS ✅

[-allow_proxy_certs] [-attime timestamp] [-no_check_time]
[-check_ss_sig] [-crl_check] [-crl_check_all] [-explicit_policy]
[-extended_crl] [-ignore_critical] [-inhibit_any] [-inhibit_map]
[-partial_chain] [-policy arg] [-policy_check] [-policy_print] [-purpose
purpose] [-suiteB_128] [-suiteB_128_only] [-suiteB_192] [-trusted_first]
[-no_alt_chains] [-use_deltas] [-auth_level num] [-verify_depth num]
[-verify_email email] [-verify_hostname hostname] [-verify_ip ip]
[-verify_name name] [-x509_strict] [-issuer_checks]

✨ DESCRIPTION ✨

so the cmp command is a client implementation for the Certificate Management Protocol (CMP), as defined in RFCs 9810 and its HTTP(S) transfer as defined in RFC 9811. fr fr.

you can use it to:

request certificates from a CA server 🎓
update their certificates 🔄
request certificates to be revoked 🚫
and perform other types of CMP requests 💅

it's lowkey the whole PKI vibe. periodt.

✨ OPTIONS ✨

okay bestie, here comes the big list of flags. don't panic, we'll go one by one. 🫶

-help — display a summary of all options. cute, right? ✨
-config filename — configuration file to use. An empty string "" means none. Default filename is from the environment variable OPENSSL_CONF.
-section names — section(s) to use within config file defining CMP options. An empty string "" means no specific section. Default is cmp.

multiple section names may be given, separated by commas and/or whitespace (where in the latter case the whole argument must be enclosed in "..."). Contents of sections named later may override contents of sections named before. In any case, as usual, the [default] section and finally the unnamed section (as far as present) can provide per-option fallback values.

-verbosity level — level of verbosity for logging, error output, etc. 0 = EMERG, 1 = ALERT, 2 = CRIT, 3 = ERR, 4 = WARN, 5 = NOTE, 6 = INFO, 7 = DEBUG, 8 = TRACE. Defaults to 6 = INFO.

Generic message options 💌

-cmd ir|cr|kur|p10cr|rr|genm — CMP command to execute. Currently implemented commands are:
- ir — Initialization Request
- cr — Certificate Request
- p10cr — PKCS#10 Certification Request (for legacy support)
- kur — Key Update Request
- rr — Revocation Request
- genm — General Message

ir requests initialization of an end entity into a PKI hierarchy by issuing a first certificate.

cr requests issuing an additional certificate for an end entity already initialized to the PKI hierarchy.

p10cr requests issuing an additional certificate similarly to cr but using legacy PKCS#10 CSR format.

kur requests a (key) update for an existing certificate.

rr requests revocation of an existing certificate.

genm requests information using a General Message, where optionally included InfoTypeAndValues may be used to state which info is of interest. Upon receipt of the General Response, information about all received ITAV infoTypes is printed to stdout.

-infotype name — set InfoType name to use for requesting specific info in genm, e.g., "signKeyPairTypes". There is specific support for "caCerts", "rootCaCert", "certReqTemplate", and "crlStatusList" (CRL update retrieval).
-profile name — name of a certificate profile to place in the PKIHeader generalInfo field of request messages.
-geninfo values — a comma-separated list of InfoTypeAndValue to place in the generalInfo field of the PKIHeader of requests messages. Each InfoTypeAndValue gives an OID and an integer or string value of the form OID:int:number or OID:str:text, e.g., '1.2.3.4:int:56789,id-kp:str:name'.
-template filename — the file to save any CRMF certTemplate in DER format received in a genp message with id-it-certReqTemplate.
-keyspec filename — it is optional and used to specify the file to save any keySpec if present in a genp message with id-it-keyGenParameters.

Note: any keySpec field contents received are logged as INFO.

Certificate enrollment options 🎓

-newkey filename|uri — the source of the private or public key for the certificate being requested. Defaults to the public key in the PKCS#10 CSR given with the -csr option, the public key of the reference certificate, or the current client key.

The public portion of the key is placed in the certification request.

Unless -cmd p10cr, -popo -1, or -popo 0 is given, the private key will be needed as well to provide the proof of possession (POPO), where the -key option may provide a fallback.

-newkeypass arg — pass phrase source for the key given with the -newkey option. If not given here, the password will be prompted for if needed.

For more information about the format of arg see openssl-passphrase-options(1).

-centralkeygen — request central key generation for certificate enrollment. This applies to -cmd ir|cr|kur|p10cr.
-newkeyout filename — file to save centrally generated private key, in PEM format.
-subject name — X.509 Distinguished Name (DN) to use as subject field in the requested certificate template in IR/CR/KUR messages. If the NULL-DN ("/") is given then no subject is placed in the template. Default is the subject DN of any PKCS#10 CSR given with the -csr option. For KUR, a further fallback is the subject DN of the reference certificate (see -oldcert) if provided. This fallback is used for IR and CR only if no SANs are set.

If provided and neither of -cert, -oldcert, or -csr is given, the subject DN is used as fallback sender of outgoing CMP messages.

The argument must be formatted as /type0=value0/type1=value1/type2=..... Special characters may be escaped by "\" (backslash); whitespace is retained. Empty values are permitted, but the corresponding type will not be included. Giving a single "/" will lead to an empty sequence of RDNs (a NULL-DN). Multi-valued RDNs can be formed by placing a "+" character instead of a "/" between the AttributeValueAssertions (AVAs) that specify the members of the set. Example:

"/DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe"

-days number — number of days the new certificate is requested to be valid for, counting from the current time of the host. Also triggers the explicit request that the validity period starts from the current time (as seen by the host).
-reqexts name — name of section in OpenSSL config file defining certificate request extensions. If the -csr option is present, these extensions augment the extensions contained the given PKCS#10 CSR, overriding any extensions with same OIDs.
-sans spec — one or more IP addresses, email addresses, DNS names, or URIs separated by commas or whitespace (where in the latter case the whole argument must be enclosed in "...") to add as Subject Alternative Name(s) (SAN) certificate request extension. If the special element "critical" is given the SANs are flagged as critical. Cannot be used if any Subject Alternative Name extension is set via -reqexts.
-san_nodefault — when Subject Alternative Names are not given via -sans nor defined via -reqexts, they are copied by default from the reference certificate (see -oldcert). This can be disabled by giving the -san_nodefault option.
-policies name — the name of a section in your OpenSSL config file that defines the policies you wanna set as a certificate request extension. 🎀 But heads up: you cannot use this together with -policy_oids, bestie. Pick one. 💅
-policy_oids names — one or more OID(s), separated by commas and/or whitespace (if you use whitespace, the whole argument must be wrapped in "..."). These get added as a certificate policies request extension. ✨ And obvi, this one can't be used with -policies either. No double-dipping. 🙅‍♀️
-policy_oids_critical — this flags the policies you gave with -policy_oids as critical. 🔥
-popo number — the proof-of-possession (POPO) method to use for IR/CR/KUR. Values: -1..<2> where -1 = NONE (which implies central key generation), 0 = RAVERIFIED, 1 = SIGNATURE (the default), and 2 = KEYENC. 💖

Note: a signature-based POPO can only be produced if you provide a private key via the -newkey or -key options.

-csr filename — a PKCS#10 CSR in PEM or DER format that contains a certificate request. When you use -cmd p10cr, it's used directly in a legacy P10CR message. 🦋 When used with -cmd ir, cr, or kur, it gets transformed into the respective regular CMP request. In that case, you must provide a private key (with -newkey or -key) for the proof of possession (unless -popo -1 or -popo 0 is used), and the respective public key is placed in the certification request (rather than taking over the public key inside the PKCS#10 CSR). 💅 PKCS#10 CSR input can also be used with -cmd rr to specify the certificate to be revoked via the included subject name and public key. Its subject is used as a fallback sender in CMP message headers if -cert and -oldcert are not given. 🎀
-out_trusted filenames|uris — trusted certificate(s) to use for validating the newly enrolled certificate. During this verification, any certificate status checking is disabled. 😮 You can give multiple sources, separated by commas and/or whitespace (if you use whitespace, wrap the whole argument in "..."). Each source can contain multiple certificates. 🎀 The certificate verification options -verify_hostname, -verify_ip, and -verify_email only affect the certificate verification enabled via this option. ✨
-implicit_confirm — request implicit confirmation of newly enrolled certificates. 💖
-disable_confirm — don't send a certificate confirmation message for a newly enrolled certificate, and don't request implicit confirmation. This is to cope with broken servers that don't support implicit confirmation correctly. 😭

WARNING: This leads to behavior violating RFC 9810. 🚨

-certout filename — the file where any newly enrolled certificate should be saved. 💾
-chainout filename — the file where the chain of any newly enrolled certificate should be saved. This chain excludes the leaf certificate (i.e., the newly enrolled certificate). Also the trust anchor (the root certificate) is not included. 🌈 If you also give the -certout option with an equal filename argument, then the file produced contains both outputs concatenated: the newly enrolled certificate followed by its chain. 🎀

✨ Certificate enrollment and revocation options ✨

-oldcert filename|uri — the certificate to be updated (i.e., renewed or re-keyed) in Key Update Request (KUR) messages, or to be revoked in Revocation Request (RR) messages. For KUR, the certificate to be updated defaults to -cert, and the resulting certificate is called the reference certificate. For RR, the certificate to be revoked can also be specified using -csr. -oldcert and -csr are ignored if -issuer and -serial are provided. 💅 The reference certificate, if any, is also used for deriving default subject DN and Subject Alternative Names, and the default issuer entry in the requested certificate template of an IR/CR/KUR. Its public key is used as a fallback in the template of certification requests. Its subject is used as the sender of outgoing messages if -cert is not given. Its issuer is used as the default recipient in CMP message headers if neither -recipient, -srvcert, nor -issuer is given. 🦋
-issuer name — an X.509 Distinguished Name (DN) to place as the issuer field in the requested certificate template in IR/CR/KUR/RR messages. If you give the NULL-DN ("/"), then no issuer is placed in the template. 🙅‍♀️ If provided and neither -recipient nor -srvcert is given, the issuer DN is used as a fallback recipient of outgoing CMP messages. 🎀 The argument must be formatted as /type0=value0/type1=value1/type2=..... For details, see the description of the -subject option. ✨
-serial number — specify the serial number of the certificate to be revoked in a revocation request. The serial number can be decimal or hex (if preceded by "0x"). 🔢
-revreason number — set the CRLReason to be included in a revocation request (RR). Values: 0..10 or -1 for none (which is the default). 💅 Reason numbers defined in RFC 5280 are:

CRLReason ::= ENUMERATED {
     unspecified             (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6),
     -- value 7 is not used
     removeFromCRL           (8),
     privilegeWithdrawn      (9),
     aACompromise           (10)
 }

✨ Message transfer options ✨

-server [http[s]://][userinfo@]host[:port][/path][?query][#fragment] — the host domain name or IP address and optionally the port of the CMP server to connect to using HTTP(S). IP address can be v4 or v6, like 127.0.0.1 or "[::1]" for localhost. If the host string is an IPv6 address, it must be enclosed in "[" and "]". 🌐 This option excludes -port and -use_mock_srv. It's ignored if -rspin is given with enough filename arguments. 🙈 If the scheme "https" is given, the -tls_used option is implied. When TLS is used, the default port is 443, otherwise 80. The optional userinfo component is ignored. Any given query and fragment components are handled as part of the path component. If a path is included, it provides the default value for the -path option. 🎀
-proxy [http[s]://][userinfo@]host[:port][/path][?query][#fragment] — the HTTP(S) proxy server to use for reaching the CMP server, unless -no_proxy applies (see below). If the host string is an IPv6 address, it must be enclosed in "[" and "]". The proxy port defaults to 80 or 443 if the scheme is "https"; apart from that, the optional "http://" or "https://" prefix is ignored (note that using TLS may be required by -tls_used or -server with the prefix "https"), as well as any path, userinfo, query, and fragment components. 🌀 Defaults to the environment variable "http_proxy" if set, else "HTTP_PROXY" in case no TLS is used, otherwise "https_proxy" if set, else "HTTPS_PROXY". This option is ignored if -server is not given. 💅
-no_proxy addresses — a list of IP addresses and/or DNS names of servers not to use an HTTP(S) proxy for, separated by commas and/or whitespace (if you use whitespace, the whole argument must be enclosed in "..."). Default is from the environment variable "no_proxy" if set, else "NO_PROXY". This option is ignored if -server is not given. 🚫
-recipient name — a Distinguished Name (DN) to use in the recipient field of CMP request message headers, i.e., the CMP server (usually the addressed CA). 💌 The recipient field in the header of a CMP message is mandatory. If not given explicitly, the recipient is determined in the following order: the subject of the CMP server certificate given with the -srvcert option, the -issuer option, the issuer of the certificate given with the -oldcert option, the issuer of the CMP client certificate (-cert option), as far as any of those is present, else the NULL-DN as last resort. 🎀 The argument must be formatted as /type0=value0/type1=value1/type2=..... For details, see the description of the -subject option. ✨
-path remote_path — the HTTP path at the CMP server (aka CMP alias) to use for POST requests. Defaults to any path given with -server, else "/". 🛣️
-keep_alive value — if the given value is 0, then HTTP connections are closed after each response (which would be the default behavior of HTTP 1.0) even if a CMP transaction needs more than one round trip. If the value is 1 or 2, then for each transaction a persistent connection is requested. If the value is 2, then a persistent connection is required, i.e., an error occurs if the server does not grant it. The default value is 1, which means preferring to keep the connection open. 🔗
-msg_timeout seconds — number of seconds a CMP request-response message round trip is allowed to take before a timeout error is returned. A value <= 0 means no limitation (waiting indefinitely). Default is to use the -total_timeout setting. ⏳
-total_timeout seconds — maximum total number of seconds a transaction may take, including polling etc. A value <= 0 means no limitation (waiting indefinitely). Default is 0. ⌛

✨ Server authentication options ✨

-trusted filenames|uris — the certificate(s), typically of root CAs, that the client shall use as trust anchors when validating signature-based protection of CMP response messages. This option is ignored if the -srvcert option is given as well. It provides more flexibility than -srvcert because the CMP protection certificate of the server is not pinned but may be any certificate from which a chain to one of the given trust anchors can be constructed. 🌳 If none of -trusted, -srvcert, and -secret is given, message validation errors will be thrown unless -unprotected_errors permits an exception. 😬 Multiple sources may be given, separated by commas and/or whitespace (if you use whitespace, the whole argument must be enclosed in "..."). Each source may contain multiple certificates. 🎀 The certificate verification options -verify_hostname, -verify_ip, and -verify_email have no effect on the certificate verification enabled via this option. 🙅‍♀️
-untrusted filenames|uris — bestie, this is your pile of non-trusted intermediate CA certificate(s). Anything extra you hand over with -cert gets tacked onto this list too. Why do we care? Because all of these certs lowkey do the heavy lifting for several jobs at once: cert path construction for your own CMP signer certificate (so it can be dropped into the extraCerts field of request messages), the TLS client certificate situation (if TLS is even in the picture), chain building while validating server certificates (aka checking signature-based CMP message protection), and validating newly enrolled certificates. The way it just does four jobs at once? Iconic.

You can give multiple sources, split by commas and/or whitespace — and if you go the whitespace route, the whole argument has to be wrapped in "...". Each source is allowed to hold multiple certificates, no cap. 💅

-srvcert filename|uri — the one specific CMP server certificate you're expecting and directly trusting (yep, even if it's expired 💀) when verifying signature-based protection of CMP response messages. This pins the accepted server, which means the -trusted option gets straight-up ignored. Periodt.

If you set it, the subject of that certificate also becomes the default value for the recipient of CMP requests and the default value for the expected sender of CMP responses. Two defaults, one cert. 🎀

-expect_sender name — the Distinguished Name (DN) you expect to see in the sender field of incoming CMP messages. It defaults to the subject DN of whatever you pinned with -srvcert, if anything.

This is how you make sure only one particular entity gets accepted as your CMP message signer — so attackers can't grab arbitrary certs from a trusted PKI hierarchy and fraudulently cosplay as a CMP server. 🙈 Note that this option gives you slightly more freedom than setting -srvcert, since -srvcert pins the server to the holder of one particular certificate, whereas the expected sender name will keep matching even after the server cert gets updated. Glow-up friendly.

The argument must be formatted as /type0=value0/type1=value1/type2=.... — for the deets, go read the description of the -subject option.

-ignore_keyusage — ignores key usage restrictions in CMP signer certificates when validating signature-based protection of incoming CMP messages. By default, "digitalSignature" must be allowed by CMP signer certificates. Applies to both CMP clients and the mock server. ✨
-unprotected_errors — accepts missing or invalid protection of negative responses from the server. Applies to these message types and contents:
- error messages
- negative certificate responses (IP/CP/KUP)
- negative revocation responses (RP)
- negative PKIConf messages

WARNING: this setting leads to unspecified behavior and it exists exclusively to allow interoperability with server implementations that violate RFC 9810, for example:

section 5.1.3.1 allows exceptions from protecting only for special cases: "There MAY be cases in which the PKIProtection BIT STRING is deliberately not used to protect a message [...] because other protection, external to PKIX, will be applied instead."
section 5.3.21 is clear on ErrMsgContent: "The CA MUST always sign it with a signature key."
appendix D.4 shows PKIConf message having protection

-ta_in_ip_extracerts — a quirk option, added to support 3GPP TS 33.310. WARNING: this leads to behavior that violates RFCs 4210 and 9810. 🚨

What it does: it lets you use self-issued certificates from the extraCerts in an IP message as non-authenticated trust anchors when validating the CMP message protection certificate in this and any subsequent responses from the server in the same transaction — but only if those extraCerts can also be used as trust anchors for validating the newly enrolled certificate you received in the IP message.

Note that using this option is dangerous, because the to-be-trusted certificates you obtain this way have not been authenticated (at least not at CMP level). Taking them over as initial trust anchors implements a form of trust-on-first-use (TOFU). Bestie, please know what you're doing. 😭

-no_cache_extracerts — don't cache the certificates sitting in the extraCerts field of CMP messages you receive. By default they are kept, since they might be helpful for validating further messages. This option applies to both CMP clients and the mock server. 🦋

Either way, after successfully validating an incoming message, its protection certificate (if any) gets cached for reuse when validating subsequent messages. That's not just about efficiency — it also eliminates the need for the sender to shove its certificate and related chain into the extraCerts field of subsequent messages in the same transaction. Slay, less bandwidth. 💜

-srvcertout filename — the file where you save the successfully validated certificate, if any, that the CMP server used for signature-based response message protection. If there's no such certificate — typically because the protection was MAC-based — that's indicated by deleting the file (if it existed). Not me deleting files as a status code. 💀
-extracertsout filename — the file where you save the list of certificates contained in the extraCerts field of the last received response message that is not a pollRep nor PKIConf.
-cacertsout filename — the file where you save the list of CA certificates contained in the caPubs field, if a positive certificate response (i.e., IP, CP, or KUP) message was received, or contained in a general response (genp) message with infoType "caCerts".
-oldwithold filename — the root CA certificate to include in a genm request of infoType "rootCaCert". If it's present and the optional oldWithNew certificate is received, that certificate is verified using the newWithNew certificate as the (only) trust anchor. 👑
-newwithnew filename — this option must be provided when -infotype rootCaCert is given. It names the file where you save the newWithNew certificate received in a genp message of type "rootCaKeyUpdate". If it succeeds but no such cert was received, this file (if present) gets deleted, indicating that the requested root CA certificate update isn't available.

Any received newWithNew certificate is verified using any received newWithOld certificate as an untrusted intermediate certificate, and the certificate provided with -oldwithold as the (only) trust anchor — or, if -oldwithold wasn't provided, using the certificates given with the -trusted option.

WARNING: the newWithNew certificate is meant to be a certificate that will be trusted. The trust placed in it cannot be stronger than the trust placed in the -oldwithold certificate if present; otherwise it cannot be stronger than the weakest trust placed in any of the -trusted certificates. Trust is only as strong as your weakest link, no cap. 🔗

-newwithold filename — the file to save any newWithOld certificate received in a genp message of infoType "rootCaKeyUpdate". If it succeeds but no such cert was received, that's indicated by deleting the file.
-oldwithnew filename — the file to save any oldWithNew certificate received in a genp message of infoType "rootCaKeyUpdate". If it succeeds but no such cert was received, that's indicated by deleting the file. Same energy, different cert. 🎀
-crlcert filename — certificate to derive CRL issuer data for the source field when obtaining a CRL in a genm request with infoType "crlStatusList". Any available distribution point name is preferred over issuer names.
-oldcrl filename — the CRL to obtain an update for in a genm request with infoType "crlStatusList". Unless you also provide the -crlcert option, the given CRL is used for deriving CRL issuer data for the source field. Any available distribution point name is preferred over issuer names. And if the CRL contains a thisUpdate field, its value gets copied to the request. ✨
-crlout filename — the file to save any CRL received in a genp message of infoType "crls". If it succeeds but no such CRL was received, that's indicated by deleting the file.

🔐 Client authentication options 🔐

Okay bestie, this is the section where we figure out who you are. Very main character. 💅

-ref value — reference number/string/value to use as a fallback senderKID. This is required if no sender name can be determined from the -cert or <-subject> options, and it's typically used when authenticating with a pre-shared key (password-based MAC). 🫶
-secret arg — provides the source of a secret value to use with MAC-based message protection. This takes precedence over the -cert and -key options. The secret is used for creating MAC-based protection of outgoing messages and for validating incoming messages that have MAC-based protection. The algorithm used by default is Password-Based Message Authentication Code (PBM) as defined in RFC 9810 section 5.1.3.1.

For more info on the format of arg, go see openssl-passphrase-options(1). 🔑

-cert filename|uri — the client's current CMP signer certificate. Requires the corresponding key to be given with -key.

The subject and public key contained in this certificate serve as fallback values in the certificate template of IR/CR/KUR messages.

The subject of this certificate will be used as the sender of outgoing CMP messages, while the subject of -oldcert or -subjectName may provide fallback values.

The issuer of this certificate is used as one of the recipient fallback values and as the fallback issuer entry in the certificate template of IR/CR/KUR messages.

When performing signature-based message protection, this "protection certificate" — also called the "signer certificate" — gets included first in the extraCerts field of outgoing messages, and the signature is done with the corresponding key. In Initialization Request (IR) messages this can be used for authenticating using an external entity certificate as defined in appendix D.7 of RFC 9810. 😌

For Key Update Request (KUR) messages, this is also used as the certificate to be updated if the -oldcert option isn't given.

If the file includes further certs, they get appended to the untrusted certs, because they typically constitute the chain of the client certificate — which is included in the extraCerts field in signature-protected request messages. Chain 'em up. ⛓️

-own_trusted filenames|uris — if you provide this list of certificates, then the chain built for the client-side CMP signer certificate given with the -cert option is verified using the given certificates as trust anchors. 🌈

Multiple sources may be given, separated by commas and/or whitespace (where in the latter case the whole argument must be enclosed in "..."). Each source may contain multiple certificates.

Quick heads-up before we keep going, bestie: the certificate verification options -verify_hostname, -verify_ip, and -verify_email have no effect on the certificate verification that gets enabled via this option. Like, none. Zero. They simply don't apply here. 💅

-key filename|uri — the matching private key file for the client's current certificate, the one you handed over in -cert. This is what gets used for signature-based message protection… unless you gave -secret (which means MAC-based protection) or -unprotected_requests. It also does double duty as a fallback for the -newkey option when you're dealing with IR/CR/KUR messages. 🗝️
-keypass arg — the pass phrase source for the private key you gave in -key. It's also used for -cert and -oldcert when one of those turns out to be an encrypted PKCS#12 file. If you don't give it here, the password gets prompted for whenever it's actually needed. For the tea on how arg is formatted, go read openssl-passphrase-options(1). 🔐
-digest name — picks the name of the supported digest to use in RFC 9810's MSG_SIG_ALG, and also as the one-way function (OWF) inside MSG_MAC_ALG. Where it applies, it's used for message protection and proof-of-possession (POPO) signatures. Wanna see the supported digests? Run openssl list -digest-commands. Defaults to sha256. ✨
-mac name — names the MAC algorithm for MSG_MAC_ALG. To get the names of supported MAC algorithms, hit up openssl list -mac-algorithms, and you can totally combine one of those names with the name of a supported digest algorithm, like hmacWithSHA256. Defaults to hmac-sha1, purely for backward compatibility with RFC 4210. 🧬
-extracerts filenames|uris — certificates to append into the extraCerts field when messages get sent. They can serve as the default CMP signer certificate chain to include. Multiple sources are allowed, separated by commas and/or whitespace (and if you go the whitespace route, the whole argument has to be wrapped in "..."). Each source can hold multiple certificates. 📎
-unprotected_requests — sends request messages with no CMP-level protection at all. Living dangerously, no cap. 🙈

💖 Credentials Format Options 💖

-certform PEM|DER — the file format to use when a certificate gets saved to a file. Default value is PEM. 🎀
-crlform PEM|DER — the file format to use when a CRL gets saved to a file. Default value is DER. DER is the preferred one because it stores large CRLs more efficiently. 🗂️
-keyform PEM|DER|P12 — the format of the key input; unspecified by default. Peep "Format Options" in openssl(1) for the deets. 🔑
-otherpass arg — the pass phrase source for the certificate given with the -trusted, -untrusted, -own_trusted, -srvcert, -crlcert, -out_trusted, -extracerts, -srv_trusted, -srv_untrusted, -ref_cert, -rsp_extracerts, -rsp_capubs, -rsp_newwithnew, -rsp_newwithold, -rsp_oldwithnew, -tls_extra, and -tls_trusted options. If you don't give it here, the password gets prompted for whenever it's needed. For how arg is formatted, check openssl-passphrase-options(1). 🫶

🌈 Provider Options 🌈

-provider name
-provider-path path
-provparam [name:]key=value
-propquery propq

See "Provider Options" in openssl(1), provider(7), and property(7). 👑

🍓 Random State Options 🍓

-rand files, -writerand file — see "Random State Options" in openssl(1) for the full rundown. 🎲

🦋 TLS Connection Options 🦋

-tls_used — tells the CMP client it must use TLS (no matter whether any other TLS-related options are set) for message exchange with the server over HTTP. Heads up: this option is not supported together with the -port option. It's implied when the -server option comes with the scheme https. And it gets ignored if -server isn't given, or if -use_mock_srv is given, or if -rspin is given with enough filename arguments. 🛡️

The following TLS-related options are all ignored if TLS isn't being used. 💀

-tls_cert filename|uri — the client's TLS certificate, used to authenticate to the TLS server. If the source includes further certs, those get used too (along with the -untrusted certs) to build the client cert chain handed to the TLS server. 🪪
-tls_key filename|uri — the private key for the client's TLS certificate. 🔐
-tls_keypass arg — the pass phrase source for the client's private TLS key -tls_key. It's also used for -tls_cert when that happens to be an encrypted PKCS#12 file. If you don't give it here, the password gets prompted for when needed. And yeah — for how arg is formatted, see openssl-passphrase-options(1). 💜
-tls_extra filenames|uris — extra certificates to hand to the TLS server during the handshake. 🤝
-tls_trusted filenames|uris — trusted certificate(s) used to validate the TLS server certificate. This one implies hostname validation. Multiple sources may be given, separated by commas and/or whitespace (where, in the latter case, the whole argument must be enclosed in "..."). Each source may contain multiple certificates.

Also, just so we're clear: the certificate verification options -verify_hostname, -verify_ip, and -verify_email have no effect on the certificate verification enabled via this option. 💅

-tls_host name — the address to check during hostname validation. It can be a DNS name or an IP address. If you don't give it, it defaults to the -server address. 🌐

👑 Client-Side Options for Debugging and Offline Scenarios 👑

-batch — don't interactively prompt for input, like when a password is needed. Super handy for batch processing and testing. 🤖
-repeat number — invokes the command the given positive number of times with the same parameters. Default is one invocation. 🔁
-reqin filenames — takes the sequence of CMP requests to send to the server from the given file(s), instead of from the sequence of requests produced internally.

This one shines for offline scenarios where the certificate request (or any other CMP request) is produced beforehand and sent out later. 🕰️

It gets ignored if the -rspin option is given, because in that case no requests are actually sent at all.

Note that the client always produces its sequence of CMP request messages internally. So every option needed to do that (like -cmd and all the options providing the required parameters) must be given even when -reqin is present.

If -reqin is given for a certificate request and none of -newkey, -key, -oldcert, or -csr is given, a fallback public key gets taken from the request message file (if it's included in the certificate template).

Hint: when -reqin is given for a certificate request, there are situations where the client has access to the public key to be certified but not to the private key that would by default be needed for proof of possession. In that case the POPO isn't actually needed (because the internally produced certificate request message will never be sent), and you can disable its generation with -popo -1 or -popo 0. 🧠

Multiple filenames may be given, separated by commas and/or whitespace (where, in the latter case, the whole argument must be enclosed in "...").

The files are read as far as needed to complete the transaction and filenames have been provided. If more requests are needed, the remaining ones are taken from the items at the respective position in the sequence of requests produced internally.

The client needs to update the recipNonce field in the given requests (except for the first one) in order to satisfy the checks the server will perform. This causes re-protection (if protecting requests is required). 🔄

-reqin_new_tid — uses a fresh transactionID for CMP request messages read via -reqin, which causes their reprotection (if protecting requests is required). You might need this when the sequence of requests gets reused and the CMP server starts complaining that the transaction ID has already been used. 🆔
-reqout filenames — saves the sequence of CMP requests created by the client to the given file(s). These requests are not sent to the server if the -reqin option is used too.

Multiple filenames may be given, separated by commas and/or whitespace.

Files are written as far as needed to save the transaction and filenames have been provided. If the transaction contains more requests, the remaining ones are not saved. 💾

-reqout_only filename — saves the first CMP request created by the client to the given file and then exits. Any options related to CMP servers and their responses are ignored. This option does not combine with the -port option.

Again, this is the move for offline scenarios where the certificate request (or any other CMP request) is produced beforehand and sent out later. ✈️

-rspin filenames — processes the sequence of CMP responses provided in the given file(s) without contacting any given server, as long as enough filenames are provided to complete the transaction.

Multiple filenames may be given, separated by commas and/or whitespace.

Any server specified via -server or -use_mock_srv is contacted only if more responses are needed to complete the transaction. In that case the transaction will fail unless the server has been prepared to continue the already started transaction. 😭

-rspout filenames — saves the sequence of actually used CMP responses to the given file(s). These have been received from the server unless -rspin takes effect.

Multiple filenames may be given, separated by commas and/or whitespace.

Files are written as far as needed to save the responses contained in the transaction and filenames have been provided. If the transaction contains more responses, the remaining ones are not saved. 📥

-use_mock_srv — test the client using the internal CMP server mock-up at API level, bypassing socket-based transfer via HTTP. This one excludes the -server and -port options. 🧪

🎀 Mock Server Options 🎀

-port number — act as an HTTP-based CMP server mock-up listening on the given local port. The client can address the server via, like, 127.0.0.1 or "[::1]". This option excludes the -server and -use_mock_srv options. And heads up: the -rspin, -rspout, -reqin, and -reqout options so far are not supported in this mode. 🚧
-max_msgs number — the absolute max number of CMP (request) messages our lil CMP HTTP server mock-up is willing to handle. Gotta be nonnegative, bestie. Default is 0, and 0 means no limit at all — it just keeps going forever like my Spotify queue. Either way the server dips out on internal errors, but NOT when it spots a CMP-level error that it can actually clap back at with an error message. 💅
-srv_ref value — the Reference value to use as senderKID of the server, for when you didn't hand over a -srv_cert.
-srv_secret arg — password source for server auth using a pre-shared key (a secret, aka the tea only you and the server know 🤫).
-srv_cert filename|uri — certificate of the server.
-srv_key filename|uri — private key the server uses to sign messages.
-srv_keypass arg — server private key (and cert) file pass phrase source.
-srv_trusted filenames|uris — trusted certificates for client authentication.

Heads up: the certificate verification options -verify_hostname, -verify_ip, and -verify_email have no effect on the certificate verification that gets enabled via this option. Like, none. Zero. 🫥

-srv_untrusted filenames|uris — intermediate CA certs that might come in handy when validating client certificates.
-ref_cert filename|uri — the certificate to be expected for RR messages and any oldCertID in KUR messages.
-rsp_cert filename|uri — the certificate to be returned as the mock enrollment result.
-rsp_key filename|uri — the private key to be returned as the central key generation result.
-rsp_keypass arg — pass phrase source for rsp_cert and rsp_key.
-rsp_crl filename|uri — the CRL to be returned in genp of type "crls".
-rsp_extracerts filenames|uris — extra certificates to be included in mock certification responses.
-rsp_capubs filenames|uris — CA certificates to be included in the mock Initialization Response (IP) message.
-rsp_newwithnew filename|uri — certificate to be returned in the newWithNew field of genp of type rootCaKeyUpdate.
-rsp_newwithold filename|uri — certificate to be returned in the newWithOld field of genp of type rootCaKeyUpdate.
-rsp_oldwithnew filename|uri — certificate to be returned in the oldWithNew field of genp of type rootCaKeyUpdate.
-poll_count number — how many times the client has to poll before it finally gets a certificate. Patience is a virtue fr fr ⏳
-check_after number — the checkAfter value (number of seconds to wait, iconic unit) to include in the poll response.
-grant_implicitconf — grant implicit confirmation of the newly enrolled certificate. Slay, no extra round trip needed ✨
-pkistatus number — the PKIStatus to be included in the server response. Valid range is 0 (accepted) .. 6 (keyUpdateWarning).
-failure number — a single failure info bit number to be included in the server response. Valid range is 0 (badAlg) .. 26 (duplicateCertReq).
-failurebits number — Number representing failure bits to be included in server response. Valid range is 0 .. 2^27 - 1.
-statusstring arg — the text to be included as the status string in the server response.
-send_error — force the server to reply with an error message. Rude but on purpose 💀
-send_unprotected — send response messages without CMP-level protection.
-send_unprot_err — in case of negative responses, the server shall send unprotected error messages, certificate responses (IP/CP/KUP), and revocation responses (RP).

WARNING: this setting leads to behavior violating RFC 9810. Not a vibe. Do not make this your whole personality.

-accept_unprotected — accept missing or invalid protection of requests.
-accept_unprot_err — accept unprotected error messages from the client. So far this has no effect, because the server doesn't accept any error messages at all. It's giving decorative button 🎀
-accept_raverified — accept RAVERIFIED as proof of possession (POPO).

🔐 Certificate verification options, for both CMP and TLS 🔐

-allow_proxy_certs, -attime, -no_check_time, -check_ss_sig, -crl_check, -crl_check_all, -explicit_policy, -extended_crl, -ignore_critical, -inhibit_any, -inhibit_map, -no_alt_chains, -partial_chain, -policy, -policy_check, -policy_print, -purpose, -suiteB_128, -suiteB_128_only, -suiteB_192, -trusted_first, -use_deltas, -auth_level, -verify_depth, -verify_email, -verify_hostname, -verify_ip, -verify_name, -x509_strict, -issuer_checks — set various options of certificate chain verification. See "Verification Options" in openssl-verification-options(1) for the actual details, bestie, that's where the lore lives 📖

And real quick: the certificate verification options -verify_hostname, -verify_ip, and -verify_email only affect the certificate verification that gets enabled via the -out_trusted option. That's it, that's the whole scope. 🎯

💖 NOTES 💖

Okay so here's the tea. When a client obtains CA certificates from a CMP server that it's actually going to trust — for instance via the "caPubs" field of a certificate response, or by using general messages with infoType "caCerts" or "rootCaCert" — authentication of the CMP server is particularly critical. Like, main character level important. So you need to take special care setting up server authentication using -trusted and related options for certificate-based authentication, or -secret for MAC-based protection. And if the authentication is certificate-based, you should use the -srvcertout option to obtain the validated server certificate and then do an authorization check based on it. ✅

When you're setting up CMP configurations and experimenting with enrollment options, you're typically gonna hit various errors until the configuration is correct and complete — that's normal, that's just the process, don't panic 🫶. When the CMP server reports an error, the client will by default check the protection of the CMP response message. But some CMP services tend not to protect negative responses. In that case the client will reject them, and thus their contents are not shown — even though they usually contain hints that would've been super helpful for diagnostics 😭. To help with exactly this situation, the CMP client offers a workaround via the -unprotected_errors option, which lets you accept such negative messages. Lifesaver honestly.

Also! If OpenSSL was built with trace support enabled (e.g., ./config enable-trace) and the environment variable OPENSSL_TRACE includes HTTP, then the requests and the response headers transferred via HTTP are printed. Free behind-the-scenes footage 🔍✨

💖 EXAMPLES 💖

✨ Simple examples using the default OpenSSL configuration file ✨

okay bestie, this CMP client ships with demonstrative CMP sections in the example config file openssl/apps/openssl.cnf, and you can use them to vibe with the Insta Demo CA, no cap. 🦋

To enroll an initial certificate from that CA it's literally just this:

export OPENSSL_CONF=/path/to/openssl/apps/openssl.cnf

openssl genrsa -out insta.priv.pem
openssl cmp -section insta

Slay — this should produce the file insta.cert.pem holding a shiny new certificate for the private key in insta.priv.pem. Wanna peek at it? Do this:

openssl x509 -noout -text -in insta.cert.pem

Now, if your network setup needs an HTTP proxy, you can hand it over the usual way — via the environment variable http_proxy, or via the -proxy option in the configuration file, or the CMP command-line argument -proxy, like:

-proxy http://192.168.1.1:8080

In the Insta Demo CA scenario both clients and the server may use the pre-shared secret insta and the reference value 3078 to authenticate to each other. 🔐

Alternatively, CMP messages may be protected in a signature-based manner, where the trust anchor in this case is insta.ca.crt and the client may use any certificate already obtained from that CA, as specified in the [signature] section of the example configuration. You can combine this with the [insta] section, simply by:

openssl cmp -section insta,signature

By default the CMP IR message type is used, but CR works equally well here. You can also specify it right at the command line:

openssl cmp -section insta -cmd cr

or by referencing in addition the [cr] section of the example configuration:

openssl cmp -section insta,cr

Want to update the enrolled certificate? Just call

openssl cmp -section insta,kur,signature

using signature-based protection with the certificate that is to be updated. ⚠️ Lowkey important: for certificate updates, MAC-based protection should generally not be used. fr fr.

In a similar way any previously enrolled certificate may be revoked by

openssl cmp -section insta,rr -trusted insta.ca.crt

openssl cmp -section insta,rr,signature

Many more options can be given in the configuration file and/or on the command line. For instance, the -reqexts CLI option may refer to a section in the configuration file defining X.509 extensions to use in certificate requests, such as "v3_req" in openssl/apps/openssl.cnf:

openssl cmp -section insta,cr -reqexts v3_req

💅 Certificate enrollment 💅

The following examples do not make use of a configuration file at first. They assume that a CMP server can be contacted on the local TCP port 80 and accepts requests under the alias /pkix/. 👑

For enrolling its very first certificate the client generates a client key and sends an initial request message to the local CMP server using a pre-shared secret key for mutual authentication. In this example the client does not have the CA certificate yet, so we specify the name of the CA with the -recipient option and save any CA certificates that we may receive in the "capubs.pem" file.

Heads up bestie: in the command line usage examples below, the "\" at line ends is used just for formatting; each of the command invocations should be on a single line. ✨

openssl genrsa -out cl_key.pem
openssl cmp -cmd ir -server 127.0.0.1:80/pkix/ -recipient "/CN=CMPserver" \
  -ref 1234 -secret pass:1234-5678 \
  -newkey cl_key.pem -subject "/CN=MyName" \
  -cacertsout capubs.pem -certout cl_cert.pem

🌸 Certificate update 🌸

Then, when the client certificate and its related key pair needs to be updated, the client can send a key update request taking the certs in "capubs.pem" as trusted for authenticating the server and using the previous cert and key for its own authentication. Then it can start using the new cert and key. 🦋

openssl genrsa -out cl_key_new.pem
openssl cmp -cmd kur -server 127.0.0.1:80/pkix/ \
  -trusted capubs.pem \
  -cert cl_cert.pem -key cl_key.pem \
  -newkey cl_key_new.pem -certout cl_cert.pem
cp cl_key_new.pem cl_key.pem

This command sequence can be repeated as often as needed. 🔁

🎀 Requesting information from CMP server 🎀

Requesting "all relevant information" with an empty General Message. This prints information about all received ITAV infoTypes to stdout.

openssl cmp -cmd genm -server 127.0.0.1/pkix/ -recipient "/CN=CMPserver" \
  -ref 1234 -secret pass:1234-5678

🌈 Using a custom configuration file 🌈

For CMP client invocations, in particular for certificate enrollment, usually many parameters need to be set, which is tedious and error-prone to do on the command line. 😭 Therefore, the client offers the possibility to read options from sections of the OpenSSL config file, usually called openssl.cnf. The values found there can still be extended and even overridden by any subsequently loaded sections and on the command line. 💯

After including in the configuration file the following sections:

[cmp]
server = 127.0.0.1
path = pkix/
trusted = capubs.pem
cert = cl_cert.pem
key = cl_key.pem
newkey = cl_key.pem
certout = cl_cert.pem

[init]
recipient = "/CN=CMPserver"
trusted =
cert =
key =
ref = 1234
secret = pass:1234-5678-1234-567
subject = "/CN=MyName"
cacertsout = capubs.pem

the above enrollment transactions reduce to

openssl cmp -section cmp,init
openssl cmp -cmd kur -newkey cl_key_new.pem

and the above transaction using a general message reduces to

openssl cmp -section cmp,init -cmd genm

👑 HISTORY 👑

The cmp application was added in OpenSSL 3.0. ✨

The -oldwithold, -newwithnew, -newwithold, -oldwithnew, The -srvcertout, and -serial option were added in OpenSSL 3.2, as well as an extension of -cacertsout to use when getting CA certificates. Since then, the -issuer may be used also for certificates to be revoked.

The -profile and -no_cache_extracerts options were added in OpenSSL 3.3, as well as support for delayed delivery of all types of response messages.

The -template, -crlcert, -oldcrl, -crlout, -crlform and -rsp_crl options were added in OpenSSL 3.4.

-centralkeygen, -newkeyout, -rsp_key and -rsp_keypass were added in OpenSSL 3.5.

The -ta_in_ip_extracerts quirk option was added in OpenSSL 4.0.

The -engine option was removed in OpenSSL 4.0. 💀

💜 COPYRIGHT 💜

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 a wrap, bestie 🎀 this whole thing is from OpenSSL 4.0.3, dated 2026-09-29 — that's the OPENSSL-CMP(1SSL) manual page, and you just read the entire thing. iconic behavior honestly. go forth and cert responsibly 💅✨

📦 where this page comes from

ubuntu stonking: openssl 4.0.3-1ubuntu1
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms

OPENSSL-CMP(1SSL)

💖 openssl-cmp(1SSL) 💖

✨ NAME ✨

✨ SYNOPSIS ✨

Generic message options 🌈

Certificate enrollment options 🎀

Certificate enrollment and revocation options 🔄

Message transfer options 📬

Server authentication options 🔐

Client authentication and protection options 🛡️

Credentials format options 📄

Random state options 🎲

TLS connection options 🔒

Client-side debugging options 🐛

Mock server options 🎭

Certificate verification options, for both CMP and TLS ✅

✨ DESCRIPTION ✨

✨ OPTIONS ✨

Generic message options 💌

Certificate enrollment options 🎓

✨ Certificate enrollment and revocation options ✨

✨ Message transfer options ✨

✨ Server authentication options ✨

🔐 Client authentication options 🔐

💖 Credentials Format Options 💖

🌈 Provider Options 🌈

🍓 Random State Options 🍓

🦋 TLS Connection Options 🦋

👑 Client-Side Options for Debugging and Offline Scenarios 👑

🎀 Mock Server Options 🎀

🔐 Certificate verification options, for both CMP and TLS 🔐

💖 NOTES 💖

💖 EXAMPLES 💖

✨ Simple examples using the default OpenSSL configuration file ✨

💅 Certificate enrollment 💅

🌸 Certificate update 🌸

🎀 Requesting information from CMP server 🎀

🌈 Using a custom configuration file 🌈

🫶 SEE ALSO 🫶

👑 HISTORY 👑

💜 COPYRIGHT 💜

💖 `openssl-cmp(1SSL)` 💖