CERTSRV_E_SUBJECT_UPN_REQUIRED (0x8009480D) quick fix

Yeah, this error is annoying

You're enrolling for a certificate — maybe a smart card logon, maybe an Exchange server cert — and you get slapped with 0x8009480D. The template says "I need a User Principal Name in the Subject Alternate Name," but the CA can't find one. Let's fix it.

The fix: give the object a UPN

What's actually happening here is the certificate template has the Subject Name setting configured to "Build from this Active Directory information" with "User principal name (UPN)" checked under Subject Alternate Name. The CA looks up the requesting user or computer in AD, grabs the userPrincipalName attribute, and tries to stuff it into the SAN. If that attribute is empty, the enrollment fails with 0x8009480D.

Here's how to fix it for a user:

1. Open Active Directory Users and Computers (dsa.msc).
2. Find the user who's failing enrollment.
3. Right-click → Properties → Account tab.
4. Look at the User logon name field. If it's blank, type it in. Format is username@domain.com. Click OK.
5. Wait for AD replication (or force it with repadmin /syncall) and try enrollment again.

For a computer object, it's trickier: computers don't have a UPN field in the GUI. You need to use ADSI Edit.

For a computer:

1. Install or open ADSI Edit (adsiedit.msc) and connect to the default domain partition.
2. Navigate to the computer's DN: CN=Computers,DC=yourdomain,DC=com or wherever it lives.
3. Right-click the computer → Properties.
4. Find userPrincipalName. If it's not listed, click Add, type userPrincipalName, set the value to computerhostname$@domain.com (yes, include the dollar sign for computer accounts).
5. Click OK, apply, and replicate.

Pro tip: If you don't want to mess with computers' UPNs, you can change the certificate template to not require a UPN. But that's a separate discussion — and often not an option if you need smart card or Exchange SAN requirements.

Why this fixes it

The reason step 4 above works is simple: the certificate services CA queries the userPrincipalName attribute during enrollment. If it's null, the CA can't build the SAN entry the template demands, so it returns CERTSRV_E_SUBJECT_UPN_REQUIRED. The fix literally fills that attribute. No magic, no registry hacks — just AD hygiene.

One nuance: the CA reads the attribute from the requesting security principal, not from any arbitrary object. So if you're enrolling as a service account, that service account needs the UPN. If you're enrolling on behalf of a device using its machine account, the computer object needs it.

Less common gotchas

1. The attribute exists but isn't replicating

You set the UPN, waited 15 minutes, still get the error. What's happening is the CA is talking to a domain controller that hasn't received the change yet. Force replication with:

repadmin /syncall /AdeP

Then check on the CA's preferred DC (often the same one it queries during enrollment). You can see which DC it's hitting by enabling CAPI2 logging — but honestly, just sync all DCs and retry.

2. Template is misconfigured for computers

Some admins copy the "Smartcard Logon" template for computer certificates and forget that computers don't get a UPN by default. If you must keep the UPN in the SAN for a computer template (rare but possible), you need to either set the UPN via ADSI Edit as shown above, or modify the template to use DNS instead. Check the template's Subject Name tab in Certificate Templates Console — if UPN is ticked and the requester is a computer, you're gonna have a bad time.

3. Domain controller with a stale UPN

If the user's UPN was set but later removed (maybe by an admin or a cleanup script), the attribute can linger in the CA's cached view until the request is made. The CA doesn't cache; it queries live. But if the DC being queried has a stale copy because replication is broken, you'll see the error even after the fix. Check event logs on the CA for Event ID 53 under Certification Services — it logs the DC used.

Prevention: make UPN assignment automatic

Don't chase this error again. Set up a standard for UPNs in your domain:

• For users: ensure your provisioning process (whether manual, PowerShell, or HR sync) populates userPrincipalName for every account. Most modern setups do this automatically from the sAMAccountName and domain suffix.
• For computers: if you issue computer certificates that need a UPN in the SAN, either script UPN assignment via PowerShell at computer creation time, or better yet, change the template to use DNS-based SAN entries instead. Computers are identified by their DNS name in most cases — not their UPN.
• Audit yearly: run dsquery * domainroot -filter "(userPrincipalName=*)" -attr userPrincipalName from a domain-joined machine to see which objects have it. Then find what's missing.

That's it. Fill the UPN, replicate, retry. 0x8009480D is one of those errors that looks scary but boils down to an empty field in AD. Fix the field, and you're done.