Download user manual

224
Certificates in Detail
If you’re creating a self-signed certificate signed by a raw private key with no
certificate information associated with it, you need to set the CRYPT_CERTINFO_SELFSIGNED attribute before you sign it otherwise cryptlib will flag the attempt to
sign using a non-certificate key as an error. Non-certificate private keys can only be
used to create self-signed certificates (if CRYPT_CERTINFO_SELFSIGNED is set)
or certification requests.
If the object being signed contains unrecognised extensions, cryptlib will not include
them in the signed object (signing extensions of unknown significance is a risky
practice for a CA, which in some jurisdictions can be held liable for any arising
problems). If you want to be able to sign unrecognised extensions, you can enable
this with the cryptlib configuration option CRYPT_OPTION_CERT_SIGNUNRECOGNISEDATTRIBUTES as explained in “Working with
Configuration Options” on page 280.
You can verify the signature on a certificate object using cryptCheckCert and the
public key or certificate corresponding to the private key that was used to sign the
certificate (you can also pass in a private key if you want, cryptCheckCert will only
use the public key components, although you shouldn’t really be in possession of
someone else’s private key). To perform the check using a public key context you’d
use:
CRYPT_CONTEXT pubKeyContext;
/* Check the signature on the certificate object information using the
public key */
cryptCheckCert( cryptCertificate, pubKeyContext );
A signature check using a certificate is similar, except that it uses a certificate object
rather than a public key context.
If the certificate object is self-signed, you can pass in CRYPT_UNUSED as the
second parameter and cryptCheckCert will use the key contained in the certificate
object to check its validity. You can determine whether a certificate object is selfsigned by reading its CRYPT_CERTINFO_SELFSIGNED attribute. Certification
requests are always self-signed, and certificate chains count as self-signed if they
contain a self-signed top-level certificate that can be used to recursively check the rest
of the chain. If the certificate object is a CA certificate which is signing itself (in
other words if it’s a self-signed certificate), you can also pass the certificate as the
second parameter in place of CRYPT_UNUSED, this has the same effect since the
certificate is both the signed and signing object.
If the certificate is invalid (for example because it has expired or because some
certificate usage constraint hasn’t been met), cryptlib will return CRYPT_ERROR_INVALID to indicate that the certificate isn’t valid. This value is returned regardless
of whether the signature check succeeds or fails. You can find out the exact nature of
the problem by reading the extended error attributes as explained in “Error Handling”
on page 288.
If the signing/signature check key is stored in an encryption context with a certificate
associated with it or in a certificate, there may be constraints on the key usage that are
imposed by the certificate. If the key can’t be used for the signature or signature
check operation, the function will return CRYPT_ERROR_INVALID to indicate that
the key isn’t valid for this operation. You can find out more about the exact nature of
the problem by reading the extended error attributes as explained in “Error Handling”
on page 288.
If you’re acting as a CA and issuing significant numbers of certificates then a much
easier alternative to signing each certificate yourself using cryptSignCert is to use
cryptlib’s certificate management capabilities as described in “Managing a
Certification Authority” on page 169.
Certificate Chains
Because of the lack of availability of a general-purpose certificate directory, many
security protocols (most notable S/MIME and SSL) transmit not individual