YubiKey PKI Provisioning: When Certificate Template Permissions Break Everything

The Setup

We were rolling out YubiKey-based certificate authentication across a mid-market organization. The plan was straightforward: bulk-provision certificates to YubiKeys using a dedicated script, then distribute them to users.

It wasn't.

The Error

Provisioning requests started failing with CERTSRV_E_UNSUPPORTED_CERT_TYPE. The CA was rejecting requests against the Smart Card template. The error message didn't help—it just said "unsupported cert type," which could mean a dozen things.

We spent time checking:

• Certificate template configurations
• CA policy module settings
• Request formatting
• Network connectivity (Darktrace was blocking some traffic during testing, which added noise)

None of it was the issue.

Root Cause: Permissions

The culprit was permissions on the certificate template itself. Authenticated Users had been removed from the Read-only ACL on the Smart Card - YubiKey template.

Without Read permission, the CA policy module couldn't even inspect the request. It failed before validation logic ran. That's why the error was so generic.

Restoring Read-only access for Authenticated Users fixed it immediately.

What We Changed

We granted Authenticated Users → Read-only on the certificate template used for YubiKey provisioning. That's it. No template reconfiguration, no policy module tweaks.

What We Learned About the Rollout

We originally planned bulk provisioning via script on a single machine. After this troubleshooting session, we pivoted to a departmental approach: one dedicated computer per department for one-off certificate requests.

This reduced operational risk and made troubleshooting easier downstream. Bulk provisioning can scale, but in this environment, the manual approach was more reliable and easier to audit.

One More Thing: FIDO2 vs PIV

During the same engagement, we clarified slot usage for different authentication methods:

• PIV slot (9A): Used for Windows sign-in via smart card GPO configuration
• FIDO2 slot (502): Used for web/passwordless sign-in via Entra ID

We also discovered that adding users to an Entra FIDO2 group caused email and phone notification disruptions—a scope issue we're still investigating. If you've seen this, reach out.

Smart card login requires both FIDO2 group membership (for Entra recognition) and GPO smart card sign-in policy (for Windows). Missing either one breaks authentication.

Where This Breaks in Production

This doesn't show up during pilot deployments.

It shows up in production PKI environments where:

• Certificate templates have been modified incrementally over time by multiple admins
• Effective permissions are spread across template-level and CA-level ACLs with no single clean view
• Bulk provisioning is run against a fleet rather than individual test devices

The pilot works. The first 10 devices enroll without issues. Then you hit a device that was previously enrolled under a different template configuration, and the error surfaces with no clear pointer to the actual cause.

Template permissions that look correct in isolation can still block enrollment if the CA's issuance policy doesn't match what the template expects.

If This Is Happening in Your Environment

Certificate enrollment failures like this are rarely isolated to one template or one device.

They're usually a sign that the PKI configuration has drifted — templates modified over time, CA policies not aligned with what's actually being requested.

If your YubiKey or smart card deployment is producing enrollment failures that don't clearly map to a single cause, that's typically where we get brought in.

We don't rebuild from scratch — we fix and stabilize what's already there.

→ itccinc.com