Fix CERTSRV_E_SUBJECT_EMAIL_REQUIRED (0X80094812) Fast

I know this error is infuriating—you're just trying to get a certificate issued, and the CA throws a hissy fit because it can't find an email address. It tripped me up the first time too, back when I was running an ADCS migration for a midsize law firm. Here's the deal: the certificate template is configured to pull the email from the Subject or Subject Alternative Name (SAN), but either the user or computer object doesn't have an email attribute, or you're using an offline CA (like a standalone one) that can't query AD for it.

The Quick Fix

You've got two paths here. Path A: add the email address to the requesting object. Path B: modify the certificate template to stop requiring it. Pick based on your environment.

Path A: Add the Email to the User or Computer

For user certificates: open Active Directory Users and Computers, find the user, double-click, go to the General tab, and fill in the E-mail field. Or use PowerShell if you hate clicking:

Get-ADUser jdoe | Set-ADUser -EmailAddress jdoe@contoso.com

For computer certificates (like domain controllers): you need to set the mail attribute on the computer object. That's a bit trickier—computers don't have a GUI email field. Use ADSI Edit or this PowerShell:

Get-ADComputer DC01 | Set-ADComputer -Replace @{mail='dc01@contoso.com'}

Then re-request the certificate. That's it—the error goes away because the CA finds the email in the SAN.

Path B: Modify the Certificate Template

If you don't need the email in the cert (common for internal server certs), just remove the requirement. Open Certificate Templates Console (certtmpl.msc), duplicate the template you're using, go to the Subject Name tab, and change it from Email in subject name to Common name or DNS. Uncheck Include e-mail name in subject name and Include e-mail name in subject alternative name. Save the template, publish it, and re-request. Boom—no more email needed.

Why This Error Happens

The root cause is a mismatch between the template's intent and the available data. When you configure a template to use Email in subject name or Email in subject alternative name, the CA expects either:

• The email attribute populated on the AD object (for enterprise CAs)
• An explicit email supplied in the request (for standalone CAs)

If the CA is offline (standalone), it can't look up AD to pull the email—it only uses what you provide. So if you submit a request without an email, it fails with 0X80094812. For enterprise CAs, the object itself is missing the mail attribute. Either way, the CA says, "I need this, and I can't find it."

One real-world trigger: domain controllers requesting a Domain Controller certificate. The default DC template includes email in the SAN, but many DCs don't have the mail attribute set. You request a new cert, and suddenly the whole domain feels the pain.

Less Common Variations

Here are a few edge cases I've seen:

• Smart card enrollment agent certs: These also require email sometimes. If the enrollment agent doesn't have an email, you get the same error. Set it on the agent's user object.
• Web server certs with email in SAN: You might be using a template that copies the email from the requesting user. If the user doesn't have one, the cert fails. Either add the user's email or switch to a template that uses DNS.
• NDES (Network Device Enrollment Service): This one's sneaky. NDES uses a service account, and if that account lacks an email, the error pops when enrolling devices. Fix: assign a dummy email to the service account, like ndes@localbox.com.
• Cross-forest or child domain requests: If the CA is in a different domain than the requesting object, it might not see the email attribute. Usually this means the CA doesn't have permissions to read the mail attribute. Check delegation.

Prevention Going Forward

To stop this from biting you again, audit your certificate templates. Open each template and check the Subject Name tab. If you see email required, ask yourself: does every object getting this cert have an email? For servers, the answer is usually no. Switch to Common name or DNS for those templates.

For user certs, batch-set the email attribute on all users who need smart card or email signing certs. Run a one-time PowerShell script:

Get-ADUser -Filter {EmailAddress -notlike '*'} -Properties EmailAddress | ForEach-Object {
    Set-ADUser $_ -EmailAddress "$($_.SamAccountName)@contoso.com"
}

That'll populate missing emails with a default. Not perfect, but it beats re-requesting a thousand certs.

Finally, if you're on a standalone CA, never use email in the template unless you're manually supplying it in every request. It's just not worth the headache. Stick to subject and SAN values you control.