Error 0x8009480F: the request lacks the DNS name the template demands

Fix it now

0x8009480F is CERTSRV_E_SUBJECT_DNS_REQUIRED: the DNS name is unavailable and cannot be added to the subject alternative name. The template was told to build the name from Active Directory, the attribute it needs is empty, and the CA will not invent a name it was not given.

Get-ADComputer app01 -Properties dNSHostName | Format-List Name,dNSHostName
Get-ADUser jbloggs -Properties mail,UserPrincipalName | Format-List Name,mail,UserPrincipalName
certutil -template

1. Establish which directory object is enrolling. A computer certificate is requested by the computer account, and the DNS name comes from that object’s dNSHostName attribute.
2. Read the template’s Subject Name tab and note exactly which fields it builds from the directory – DNS name, email, user principal name – because the codes for the three are different and the fix is the same shape.
3. If a domain-joined Windows machine has no dNSHostName, check its full computer name and primary DNS suffix in System Properties, then reboot so it re-registers the attribute.
4. For a host that cannot populate the attribute itself – an appliance, a workgroup machine – either set the attribute on the directory object deliberately, or use a template that takes the subject from the request instead.

If the template is already set to supply the subject in the request, the failure is the opposite one: the request itself is missing the extension, and it is the request that has to be rebuilt.

If the certificate issues once the attribute is populated, you are done. The next section separates the two shapes of this failure, because they look identical and their fixes are opposites.

Why it happens

A certificate template chooses one of two ways to name the subject. It can build the name from Active Directory, reading attributes off the enrolling object, or it can accept whatever the requester supplies in the request. Three of the four codes in this family come from the first mode: the template asked the directory for a value, the attribute was empty, and the CA refuses to guess.

The published texts are precise about which value is missing. 0x8009480F says the DNS name is unavailable and cannot be added to the subject alternative name. 0x80094812 says the same about the email name, for the subject or the alternative name. 0x8009480D says the same about the user principal name. In every case, the object is the place to look, not the request.

0x80094803 sits with them and behaves differently. CERTSRV_E_SUBJECT_ALT_NAME_REQUIRED says the request is missing a required subject alternative name extension – it is about what arrived, not about what the directory holds. That is the code you get when the template requires a subject alternative name and the requester built a request without one, which is common with certificates generated outside Windows.

Full reference

The four codes and what each one is asking for

The first three are about the directory object. The fourth is about the request. If you spend an afternoon populating attributes for a 0x80094803, nothing will change.

Which attribute feeds which name

Finding every object that will fail before it does

A template change that adds a required name breaks enrolment for every object missing that attribute, all at once, at the next autoenrolment cycle. Before making the change, run the query across the population: computers with no dNSHostName, or users with no mail value. Fixing forty objects on a Tuesday afternoon is straightforward; discovering them one help-desk ticket at a time is not.

Supplied subject, and why it is not the easy way out

• A supplied-subject template trusts the requester to name itself. Whoever can enrol can ask for any name.
• Restrict enrolment on such templates to a small group, and prefer a manual approval step where the certificates are used for authentication.
• Keep the two kinds of template separate. A template that sometimes builds from the directory and sometimes does not is a template nobody can reason about.
• For appliances that enrol repeatedly, consider a dedicated template with a shorter validity so that a mis-issued name has a shorter life.

Reading the template rather than guessing at it

certutil -template lists the enrolment policy templates the client can see and their settings, which is quicker than opening the console when you are on a server that has no management tools. It also confirms whether the client can see the template at all – a client that cannot see it produces a different failure entirely, and is a permissions or publishing question rather than a naming one.

Every code this article covers

Confirm the fix worked

1. The attribute the template needs has a value on the enrolling object.
2. A test enrolment issues a certificate, and its subject alternative name contains the expected value.
3. For a supplied-subject template, the issued certificate carries the names the request asked for and no others.
4. No further denials for that template in the CA’s log.
5. A sweep of the object population finds no remaining objects missing the attribute.

Questions people ask about this