# AD CS Web Enrollment and certificate template

The portal submits CSRs to **Active Directory Certificate Services Web Enrollment** (`certsrv`), not NDES, not `certreq`, and not `ICertRequest` COM.

## Web Enrollment

On the CA (or a dedicated enrollment host):

1. Install the **Certification Authority Web Enrollment** role service.
2. Require HTTPS on the `certsrv` application.
3. Allow the portal service account to authenticate (Windows Integrated / NTLM). Basic auth is not used.
4. From the Linux host, `curl -I https://ca.example.com/certsrv/` should not fail TLS. A 401 is expected without NTLM.

The portal:

- `POST {CERTSRV_URL}/certfnsh.asp` with `Mode=newreq`, the PEM CSR, and `CertAttrib=CertificateTemplate:{CERTSRV_TEMPLATE}`
- On success, `GET {CERTSRV_URL}/certnew.cer?ReqID={id}&Enc=b64`

If the HTML does not look like “Certificate Issued”, the portal errors out. **Pending** (manager approval) is treated as failure — the template should auto-issue.

## Service account

Use a dedicated domain user (for example `EXAMPLE\cert-portal`):

- **Enroll** on the certificate template
- **Request Certificates** on the CA (often already granted to Authenticated Users)
- Allowed to use the `certsrv` IIS app

This account is what AD CS records as the requester. That is expected. User identity is in the certificate SAN, not the requester field.

## Template

Create a template (example name `UserWifi` — use the **template common name**, not the display name, in `CERTSRV_TEMPLATE`).

Required so the CSR SAN survives issuance:

- Subject name: **Supply in the request**
- Do **not** build subject from Active Directory
- SAN: allow the enrollee to supply SAN (the “enroll subject from request” / `ENROLLEE_SUPPLIES_SUBJECT` style flags)

Typical user-auth / Wi-Fi client settings:

- Category: User (or as your org requires)
- Extension: Application Policy Client Authentication
- Key usage: per your NPS/EAP-TLS needs (Windows templates often want Digital Signature and/or Key Encipherment)
- Validity: as policy allows
- No manager approval (or the portal will raise `CertsrvPendingError`)
- Publish to AD: optional; not required for Apple clients

Compatibility: Windows Server 2016+ for URI SAN strong mapping as described below.

## Strong mapping (SID URI)

The CSR includes:

```
URI:tag:microsoft.com,2022-09-14:sid:S-1-5-21-…
```

and UPN otherName `1.3.6.1.4.1.311.20.2.3`.

That URI is the form Microsoft documents for mapping certificates to AD objects when the CA did not stamp `szOID_NTDS_CA_SECURITY_EXT` itself (offline / “supply in request” workflows). Confirm with `certutil -dump` on a test cert that both SAN values are present.

If the issued cert is missing the URI, the template is still overwriting subject/SAN from Active Directory — fix the template before issuing to phones.

## Testing without the portal

From a domain-joined Windows box you can still use `certreq` to prove the template. The portal’s path is only `certsrv`. If `certreq` works but the portal fails, check NTLM, HTTPS, Enroll ACL, and the HTML parser (pending vs issued).