OSSL_CMP_EXEC_CERTREQ(3SSL)
π NAME π
This is the OpenSSL manual page OSSL_CMP_EXEC_CERTREQ(3SSL), and bestie, it's a whole squad of functions all rolled into one entry, so buckle up:
OSSL_CMP_exec_certreq, OSSL_CMP_exec_IR_ses, OSSL_CMP_exec_CR_ses, OSSL_CMP_exec_P10CR_ses, OSSL_CMP_exec_KUR_ses, OSSL_CMP_IR, OSSL_CMP_CR, OSSL_CMP_P10CR, OSSL_CMP_KUR, OSSL_CMP_try_certreq, OSSL_CMP_exec_RR_ses, OSSL_CMP_exec_GENM_ses, OSSL_CMP_get1_caCerts, OSSL_CMP_get1_rootCaKeyUpdate, OSSL_CMP_get1_crlUpdate, OSSL_CMP_get1_certReqTemplate β the functions implementing CMP client transactions π
β¨ SYNOPSIS β¨
#include <openssl/cmp.h>
X509 *OSSL_CMP_exec_certreq(OSSL_CMP_CTX *ctx, int req_type,
const OSSL_CRMF_MSG *crm);
X509 *OSSL_CMP_exec_IR_ses(OSSL_CMP_CTX *ctx);
X509 *OSSL_CMP_exec_CR_ses(OSSL_CMP_CTX *ctx);
X509 *OSSL_CMP_exec_P10CR_ses(OSSL_CMP_CTX *ctx);
X509 *OSSL_CMP_exec_KUR_ses(OSSL_CMP_CTX *ctx);
#define OSSL_CMP_IR
#define OSSL_CMP_CR
#define OSSL_CMP_P10CR
#define OSSL_CMP_KUR
int OSSL_CMP_try_certreq(OSSL_CMP_CTX *ctx, int req_type,
const OSSL_CRMF_MSG *crm, int *checkAfter);
int OSSL_CMP_exec_RR_ses(OSSL_CMP_CTX *ctx);
STACK_OF(OSSL_CMP_ITAV) *OSSL_CMP_exec_GENM_ses(OSSL_CMP_CTX *ctx);
int OSSL_CMP_get1_caCerts(OSSL_CMP_CTX *ctx, STACK_OF(X509) **out);
int OSSL_CMP_get1_rootCaKeyUpdate(OSSL_CMP_CTX *ctx,
const X509 *oldWithOld, X509 **newWithNew,
X509 **newWithOld, X509 **oldWithNew);
int OSSL_CMP_get1_crlUpdate(OSSL_CMP_CTX *ctx, const X509 *crlcert,
const X509_CRL *last_crl,
X509_CRL **crl);
int OSSL_CMP_get1_certReqTemplate(OSSL_CMP_CTX *ctx,
OSSL_CRMF_CERTTEMPLATE **certTemplate,
OSSL_CMP_ATAVS **keySpec);
(yeah the original literally trails off into =head1 DESCRIPTION there at the end, pod source leaks are so real, we don't talk about it π)
π DESCRIPTION π
Okay so this right here is the OpenSSL main API for Certificate Management Protocol (CMP) clients. Every single one of the OSSL_CMP_exec_*() functions runs a whole CMP transaction for you β and a transaction is a sequence of related CMP request messages and response messages, like a lil conversation between you and the CA. π¦
All of these take a populated OSSL_CMP_CTX structure as their first argument. Usually you're gonna need to set the server name, the port, and the path (the "CMP alias"), plus the credentials the client uses to authenticate itself to the server. And to authenticate the server, the client typically needs a trust store. The functions hand back their respective main results directly, and there are also accessor functions for pulling all the other results and status info out of the ctx. Go peek at OSSL_CMP_CTX_new(3) etc. for the details, iykyk.
The default conveying protocol is HTTP. Timeout values may be given per request-response pair and per transaction. See OSSL_CMP_MSG_http_perform(3) for the tea on that. β
Now into the ones that actually get you a cert:
OSSL_CMP_exec_IR_ses()β requests an initial certificate from the given PKI. π±OSSL_CMP_exec_CR_ses()β requests an additional certificate. βOSSL_CMP_exec_P10CR_ses()β conveys a legacy PKCS#10 CSR requesting a certificate. π§OSSL_CMP_exec_KUR_ses()β obtains an updated certificate. π
These four types of certificate enrollment are implemented as macros calling OSSL_CMP_exec_certreq(). Yes queen, macros.
OSSL_CMP_exec_certreq() performs a certificate request of the type specified by the req_type parameter, which may be IR, CR, P10CR, or KUR. For IR, CR, and KUR, the certificate template used in the request may be supplied via the crm parameter, which points to a CRMF structure. Typically crm is NULL, and then the template ingredients are taken from ctx and need to be filled in using OSSL_CMP_CTX_set1_subjectName(3), OSSL_CMP_CTX_set0_newPkey(3), OSSL_CMP_CTX_set1_oldCert(3), etc. For P10CR, you need to use OSSL_CMP_CTX_set1_p10CSR(3) instead. The enrollment session may be blocked (with polling and sleeping in between, aka the vibe of waiting for your food delivery) until the server side can fully process and ultimately answer the request. π΄
OSSL_CMP_try_certreq() is the alternative to all of the above, and it's more flexible about what you do after receiving a checkAfter value. Here's the rundown:
- When called for the first time (with no certificate request in progress for the given
ctx), it starts a new transaction by sending a certificate request constructed as stated above, using thereq_typeand optionalcrmparameter. - Otherwise (when according to
ctxa 'waiting' status has been received before), it continues polling for the pending request β unless thereq_typeargument is< 0, which aborts the request. π
If the requested certificate is available, the function returns 1 and the caller can use OSSL_CMP_CTX_get0_newCert(3) to retrieve the new certificate. π
If no error occurred but no certificate is available yet, then OSSL_CMP_try_certreq() remembers in the CMP context that it should be retried and returns -1, after assigning the received checkAfter value via the output pointer argument (unless it is NULL). The checkAfter value indicates the number of seconds the caller should let pass before trying again. The caller is free to sleep for the given number of seconds or for some other time and/or to do anything else before retrying by calling OSSL_CMP_try_certreq() again with the same parameter values as before, do whatever you want, it's your life β¨
OSSL_CMP_try_certreq() then polls to see whether meanwhile the requested certificate is available. If the caller decides to abort the pending certificate request and provides a negative value as the req_type argument, then OSSL_CMP_try_certreq() aborts the CMP transaction by sending an error message to the server. π
OSSL_CMP_exec_RR_ses() requests the revocation of the certificate specified in the ctx, using the issuer DN and serial number set by OSSL_CMP_CTX_set1_issuer(3) and OSSL_CMP_CTX_set1_serialNumber(3), respectively β otherwise the issuer DN and serial number of the certificate set by OSSL_CMP_CTX_set1_oldCert(3) β otherwise the subject DN and public key of the certificate signing request set by OSSL_CMP_CTX_set1_p10CSR(3).
And here's where it gets ~spicy~: RFC 9810 is vague about which PKIStatus the server should return. So this implementation takes "accepted" and "grantedWithMods" as clear success π₯³ and handles "revocationWarning" and "revocationNotification" just as warnings, because CAs typically return them as an indication that the certificate was already revoked. "rejection" is a clear error. The values "waiting" and "keyUpdateWarning" make no sense for revocation and thus are treated as an error as well. The revocation session may be blocked (with polling and sleeping in between) until the server can fully process and ultimately answer the request.
OSSL_CMP_exec_GENM_ses() sends a genm general message containing the sequence of infoType and infoValue pairs (InfoTypeAndValue; short: ITAV) optionally provided in the ctx using OSSL_CMP_CTX_push0_genm_ITAV(3). The message exchange may be blocked (with polling and sleeping in between) until the server can fully process and ultimately answer the request.
On success, the function records in ctx status OSSL_CMP_PKISTATUS_accepted and returns the list of ITAVs received in a genp response message. You can use this, for instance, with infoType "signKeyPairTypes" to obtain the set of signature algorithm identifiers that the CA will certify for subject public keys. See RFC 9810 section 5.3.19 and appendix D.5 for details. Functions implementing more specific genm/genp exchanges are described next. π
OSSL_CMP_get1_caCerts() uses a genm/genp message exchange with infoType caCerts to obtain a list of CA certificates from the CMP server referenced by ctx. On success it assigns to *out the list of certificates received, which must be freed by the caller. A NULL output means that no CA certificates were provided by the server.
OSSL_CMP_get1_rootCaKeyUpdate() uses a genm request message with infoType rootCaCert to obtain from the CMP server referenced by ctx, in a genp response message with infoType rootCaKeyUpdate, any update of the given root CA certificate oldWithOld, and verifies it as far as possible. See RFC 9810 section 4.4 for details. On success it assigns to *newWithNew the root certificate received. When the newWithOld and oldWithNew output parameters are not NULL, it assigns to them the corresponding transition certificates. NULL means that the respective certificate was not provided by the server. All certificates obtained this way must be freed by the caller.
β οΈ WARNING: ThenewWithNewcertificate is meant to be a certificate that will be trusted. The trust placed in it cannot be stronger than the trust placed in theoldwitholdcertificate if present, otherwise it cannot be stronger than the weakest trust in any of the certificates in the trust store ofctx. Like, read that again. Fr fr. π¨
OSSL_CMP_get1_crlUpdate() uses a genm request message with infoType crlStatusList to obtain CRL from the CMP server referenced by ctx in a genp response message with infoType crls. It uses last_crl and crlcert to create a request with a status field as described for OSSL_CMP_CRLSTATUS_create(3). On success it assigns to *crl the CRL received. NULL means that no CRL was provided by the server. The CRL obtained this way must be freed by the caller.
OSSL_CMP_get1_certReqTemplate() uses a genm request message with infoType certReqTemplate to obtain a certificate request template from the CMP server referenced by ctx. On success it assigns to *certTemplate the certificate template received. A NULL output means that no certificate request template was provided by the server. The optional keySpec output parameter is assigned the key specification if received, otherwise it is set to NULL. Both must be freed by the caller.
πΈ NOTES πΈ
CMP is defined in RFC 9810 (and CRMF in RFC 4211).
This CMP implementation focuses on the Lightweight CMP Profile (RFC 9483). Among other things, this implies that only commonly used CMP message types are supported, and that each CMP message may not contain multiple certificate requests or responses. (One request, one response, monogamy only. π )
When a client obtains from a CMP server CA certificates that it is going to trust β for instance via the caPubs field of a certificate response, or using functions like OSSL_CMP_get1_caCerts() and OSSL_CMP_get1_rootCaKeyUpdate() β authentication of the CMP server is particularly critical. So special care must be taken setting up server authentication in ctx, using functions such as OSSL_CMP_CTX_set0_trusted(3) (for certificate-based authentication) or OSSL_CMP_CTX_set1_secretValue(3) (for MAC-based protection). If authentication is certificate-based, OSSL_CMP_CTX_get0_validatedSrvCert(3) should be used to obtain the server validated certificate and perform an authorization check based on it. π«Ά
π RETURN VALUES π
okay bestie, here's the tea on what these functions hand back to you π«Ά
OSSL_CMP_exec_certreq(),OSSL_CMP_exec_IR_ses(),OSSL_CMP_exec_CR_ses(),OSSL_CMP_exec_P10CR_ses(), andOSSL_CMP_exec_KUR_ses()β these girlies return a pointer to the newly obtainedX509certificate when it all goes right β¨ andNULLwhen it goes wrong π. And like, don't you dare try to free that pointer yourself β it gets freed implicitly byOSSL_CMP_CTX_free()orCSSL_CMP_CTX_reinit(). it's giving not your problem πOSSL_CMP_try_certreq()β returns1if the certificate you asked for is available viaOSSL_CMP_CTX_get0_newCert(3), or if it successfully aborted a pending certificate request π. Returns0on error, and returns-1in case a 'waiting' status has been received and acheckAftervalue is available. and in that last case?OSSL_CMP_CTX_get0_newCert(3)yieldsNULL, and the output parametercheckAfterhas been used to assign the received value β unlesscheckAfterisNULL. no cap πOSSL_CMP_exec_RR_ses(),OSSL_CMP_get1_caCerts(),OSSL_CMP_get1_rootCaKeyUpdate(),OSSL_CMP_get1_crlUpdate()andOSSL_CMP_get1_certReqTemplate()β these ones are simple like that: return1on success,0on error. periodt πOSSL_CMP_exec_GENM_ses()β returnsNULLon error. otherwise it returns a pointer to the sequence ofITAVreceived, which may be empty (yeah, empty is fine, it happens, we don't judge π¦). this pointer must be freed by the caller β so like, that one is your problem bestie, don't forget π€
πΈ EXAMPLES πΈ
See OSSL_CMP_CTX for examples on how to prepare the context for these functions. that's it, that's the section, go read the other one π
π SEE ALSO π
OSSL_CMP_CTX_new(3)OSSL_CMP_CTX_free(3)OSSL_CMP_CTX_set1_subjectName(3)OSSL_CMP_CTX_set0_newPkey(3)OSSL_CMP_CTX_set1_p10CSR(3)OSSL_CMP_CTX_set1_oldCert(3)OSSL_CMP_CTX_get0_newCert(3)OSSL_CMP_CTX_push0_genm_ITAV(3)OSSL_CMP_MSG_http_perform(3)OSSL_CMP_CRLSTATUS_create(3)
π¦ HISTORY π¦
the lore, as promised π
- The OpenSSL CMP functions were added in OpenSSL 3.0.
OSSL_CMP_get1_caCerts()andOSSL_CMP_get1_rootCaKeyUpdate()were added in OpenSSL 3.2.- Support for delayed delivery of all types of response messages was added in OpenSSL 3.3.
OSSL_CMP_get1_crlUpdate()andOSSL_CMP_get1_certReqTemplate()were added in OpenSSL 3.4.
watch her grow π she's literally evolving
π COPYRIGHT π
Copyright 2007-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, we ate π₯ this was OSSL_CMP_EXEC_CERTREQ(3SSL) from the 4.0.3 era, dated 2026-09-29 β iconic, no notes, mwah ππβ¨
π¦ where this page comes from
- ubuntu stonking: libssl-doc 4.0.3-1ubuntu1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms