Platform

Issuance profiles and key usages

CA and endpoint extended key usage restrictions.

Two lists control certificate usage:

  1. the issuing CA's issuance profile;
  2. the endpoint's permitted extended key usages, which must be a subset of the CA profile.

The policy form disables usages that the CA does not permit.

An endpoint's permitted key usages, with usages the CA cannot carry shown disabled

Usage rules

  • A request for a permitted subset receives that subset.
  • A request with no usages receives client authentication only. It is rejected if the endpoint does not permit client authentication.
  • A request for an unpermitted usage is rejected and recorded under Recent enrollments.

Supported usages

Usage Typical use
Client authentication 802.1X, Wi-Fi, VPN, mutual TLS
Server authentication Internal TLS listeners
Email protection (S/MIME) Signing and encrypting mail
Code signing Signed binaries and scripts
Smartcard logon Windows domain logon
IPsec end system, IPsec tunnel, IPsec user IPsec and IKE deployments

Custom dotted OIDs can be added to an issuing CA's own profile for usages not on this list.

Two usages are always excluded:

  • OCSP signing, which would let the certificate act as a delegated responder.
  • anyExtendedKeyUsage (2.5.29.37.0).

Time stamping and MAC address usages are excluded from endpoints as having no enrollment meaning. Issue either from the Certificates page instead.

Per-enrollment restrictions

A SCEP one-time challenge can further restrict usages for one enrollment.

A pin cannot add usages. Usage order does not matter; SAN order does. See SCEP challenges and secrets.

Key usage bits

Key usage bits depend on purpose and key type:

  • digitalSignature is always set — every issuable purpose signs.
  • Encryption bits are added for client and server authentication, email protection, smartcard logon, and IPsec usages.
  • RSA receives keyEncipherment; EC receives keyAgreement.
  • A custom dotted OID is treated as possibly needing both.

Subject and SAN patterns

Both are regular expressions. They accept or reject a CSR without modifying it. Blank patterns allow any value.

The rendered CSR subject encodes emailAddress as an OID (1.2.840.113549.1.9.1=#…). Anchor subject patterns on CN; match email addresses with the SAN pattern.