0xC004F30D to 0xC004F310: Certificate Thumbprint Rejected at Activation

Fix it now

None of these four codes has a published meaning, so do not try to decode them. Establish two facts instead: which issuance licences are installed on this machine, and which certificates the licensing service considers usable. Those two lists tell you where the problem is.

slmgr /lil
slmgr /ltc
slui.exe 0x2a 0xC004F30D

1. slmgr /lil lists the installed token-based activation issuance licences. Nothing listed means no policy is present, and that is a different problem from a rejected certificate.
2. slmgr /ltc lists the valid token-based activation certificates that can activate installed software. Nothing listed means no certificate available to this machine satisfies any installed issuance licence.
3. Read what slui.exe 0x2a prints for the code you actually have. That is Microsoft’s own wording for your build and the only authoritative description available.
4. If a thumbprint is listed, use exactly that one: slmgr /fta <thumbprint> <PIN>.
5. If the certificate was recently reissued, its thumbprint changed. Either issue a card from the original template and authority, or have a fresh issuance licence produced for the new credential and install it with slmgr /ilc <path>.

Issuance licences are validated at run time by the Software Protection service rather than at install time, so slmgr /ilc completing successfully does not mean the policy inside the file matches your certificate.

If that fixed it you can stop here. If not, the next section covers what the two lists are telling you and what to ask the team that produced your issuance licence.

Why it happens

An issuance licence is a signed licence file installed on the machine ahead of time, usually with an .xrm-ms extension. It is the local statement of entitlement for token-based activation, and it is what the licensing service tests a presented certificate against. Because it is signed, it cannot be edited to accept something new: a changed policy means a newly issued file from whoever holds the signing authority in your organisation.

This article used to describe the four codes as a graduation of refusals – thumbprint, trust point, certificate property, and no acceptable credential at all. That description is not published anywhere on learn.microsoft.com or support.microsoft.com, and neither is any meaning for 0xC004F30D, 0xC004F30E, 0xC004F30F or 0xC004F310. It has been removed rather than restated. What is documented is the tooling, and the tooling is enough to work with.

The two commands that matter are slmgr /lil, which lists installed issuance licences, and slmgr /ltc, which lists valid token-based activation certificates that can activate installed software. Read them as a pair. Nothing from /lil means there is no policy on the machine. Something from /lil and nothing from /ltc means no credential available here satisfies that policy. Something from both, and activation still failing, means the credential and the policy disagree in a way you will need the policy’s author to explain.

Renewal is the situation that produces most of these reports, and it is worth understanding even without a published code meaning. A thumbprint is a hash of the whole certificate, so any change at all produces a different value. Renewing a certificate, reissuing it from a different template, or issuing it from a subordinate authority that was rebuilt all change the thumbprint even though the subject name looks identical in the properties dialogue. Nothing about the certificate appears to have changed, and the machine treats it as an entirely different credential.

Full reference

What is published about these four codes

That is not a satisfying table, and it is the accurate one. Older versions of this article assigned each value a specific refusal – thumbprint, trust point, property, and no acceptable credential. Those assignments were not sourced. The related code Microsoft does publish in this area is 0xC004F011, SL_E_LICENSE_FILE_NOT_INSTALLED, which appears in Event ID 12321 when the issuance licence is absent.

Reading the two lists together

The commands and what they are documented to do

Do not remove issuance licences with slmgr /ril while experimenting. Removing the wrong one can take a working machine out of an activated state, and reinstating it needs the original file, which is usually held centrally rather than on the machine. Confirm you have that file before removing anything, and note that the switch needs both an issuance licence ID and a version ID, so a half-remembered command will not do what you expect.

Questions to put to the policy’s author

• Which thumbprint, or which set of thumbprints, was this issuance licence built to accept?
• Which root does the policy expect the credential to chain to, and has that authority been rebuilt or migrated?
• Which certificate template should the cards be issued from, and has it changed?
• Is there a newer issuance licence covering the credentials we are now issuing?
• Which edition is this issuance licence for? A file for another product will install cleanly and never activate anything.

Those five questions resolve this class of problem far more reliably than any amount of work on the endpoint, because the policy lives in a signed file that the endpoint cannot alter. If the answer to any of them has changed since the licence was produced, a new licence file is the fix.

Why reinstalling Windows does not help

A rebuild removes the installed issuance licence along with everything else, and the mismatch is reproduced exactly on the fresh installation as soon as you reinstall the same file and present the same card. The variable is the pairing of policy and credential, and neither of those lives in the operating system.

Every code this article covers

Confirm the fix worked

1. slmgr /lil lists the issuance licence you intended to install.
2. slmgr /ltc lists the thumbprint you activated with.
3. slmgr /dlv reports a licence status of Licensed.
4. The Application log shows no further licensing warnings after your attempt.
5. Repeat the activation on a second machine with the same card, to confirm the policy rather than the endpoint was the variable.

Questions people ask about this