CMS_sign — create
a CMS SignedData structure
EVP_PKEY *pkey, STACK_OF(X509)
*certs, BIO *data, unsigned int
creates and returns a CMS SignedData structure.
signcert is the certificate to sign with,
pkey is the corresponding private key.
certs is an optional additional set of certificates to
include in the CMS structure (for example any intermediate CAs in the
chain). Any or all of these parameters can be
The data to be signed is read from data.
Any of the following flags (OR'ed together) can be passed in the
- Prepend MIME headers for the type text/plain to the data. Many S/MIME
clients expect the signed content to include valid MIME headers.
- Do not include the signer's certificate in the
CMS_ContentInfo structure. The signer's certificate
must still be supplied in the signcert parameter
though. This can reduce the size of the signature if the signer's
certificate can be obtained by other means, for example from a previously
- Omit the data being signed from the CMS_ContentInfo
structure. This is used for CMS_ContentInfo detached
signatures which are used in S/MIME plaintext signed messages for
- Do not translate the supplied content into MIME canonical format even
though that is required by the S/MIME specifications. This option should
be used if the supplied data is in binary format. Otherwise the
translation will corrupt it.
- Do not add any SignedAttributes. By default, the
signerInfos field includes several CMS
SignedAttributes including the signing time, the CMS
content type, and the supported list of ciphers in an
- Omit just the SMIMECapabilities. If present, the
SMIMECapabilities attribute indicates support for the following algorithms
in preference order: 256-bit AES, Gost R3411-94, Gost 28147-89, 192-bit
AES, 128-bit AES, triple DES, 128-bit RC2, 64-bit RC2, DES and 40-bit RC2.
If any of these algorithms is not available, then it will not be
- Use the subject key identifier value to identify signing certificates. An
error occurs if the signing certificate does not have a subject key
identifier extension. By default, issuer name and serial number are used
- Only initialize the returned CMS_ContentInfo
structure to prepare it for performing the signing operation. The signing
is however not performed and the data to be signed is
not read from the data parameter. Signing is
deferred until after the data has been written. In this way, data can be
signed in a single pass. The returned
CMS_ContentInfo structure is not
complete and outputting its contents via a function that does not properly
finalize the CMS_ContentInfo structure will give
unpredictable results. Several functions including
finalize the structure. Alternatively, finalization can be performed by
obtaining the streaming ASN1 BIO directly using
- Output a partial CMS_ContentInfo structure to which
additional signers and capabilities can be added before finalization.
If a signer is specified, it will use the default digest for the
signing algorithm. This is SHA1 for both RSA and DSA keys.
If signcert and pkey
NULL, then a certificates only CMS structure is
is a basic CMS signing function whose output will be suitable for many
purposes. For finer control of the output format the
certs, signcert and
pkey parameters can all be
NULL and the
flag set. Then one or more signers can be added using the function
CMS_add1_signer(3), non default
digests can be used and custom attributes added.
CMS_final(3) must then be called to
finalize the structure if streaming is not enabled.
CMS_sign() returns either a valid
CMS_ContentInfo structure or
NULL if an error occurred. The error can be obtained
RFC 5652: Cryptographic Message Syntax (CMS)
- section 5.1: SignedData Type
- section 5.3: SignerInfo Type
RFC 8551: Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 4.0 Message Specification, section 2.5.2: SMIMECapabilities
CMS_sign() first appeared in OpenSSL
0.9.8h and has been available since OpenBSD 6.7.
Some attributes such as counter signatures are not supported.