# Issuance profiles and key usages

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](/assets/docs/issuance-policy.png)

## 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](/protocols/scep/authentication).

## 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.