Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a Win2k8 as a Domain Controller in a domain with workstations that run Windows XP. I would like to be able to install via GPO a new trusted root certificate authority certificate that I've generated myself.

I've created a GPO, imported the certificate in Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certificate Authorities and assign the GPO to a group of users. When I do a gpupdate /force on the workstation I can't see the certificate being imported ... even if I reboot the station.

Next, thought that maybe I can do better if I create an intermediate root certificate authority directly on the DC and deploy the intermediate root certificate authority via the GPO. Generated the certificate for the intermediate authority and imported it into the same GPO under Intermediate Certifications Authorities.

Again, ran the gpupdate /force (and rebooted) and checked the workstation. Couldn't see anything either in the Imtermediate or the Root Authorities section.

After a bit of googling managed to find this MSI package Link, installed it on two workstations via a GPO and ran the gpupdate /force on the workstations and noticed that the intermediate authority certificate was installed on the workstations but the root CA wasn't.

Does anyone have any ideas what I could try next?


LE. Forgot to mention the Root CA is on a standalone machine, not part of the domain and which I plan to keep offline.

share|improve this question
Which section of which certificate store are you looking at to check it is installed? (I'm doing this to push a CA's certificate out and it appears in the user's "Trusted Root Certification Authorities".) – Richard Jan 29 '13 at 11:02
I am going into the workstation's Control Panel-> Internet Options->Content->Certificates->Trusted Root Certification Authorities ... and I can't see my CA there. – Chris19 Jan 29 '13 at 11:07

I've created a GPO, imported the certificate in Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certificate Authorities and assign the GPO to a group of users

If you are using the "Computer Configuration" policy tree then it will need to be linked to an OU where the computer accounts are stored.

If you need to install the certificates into the user's certificate store then certutil mioght help. Microsoft's documentation on certutil. Use certutil -installcert <certfile> (I think that one can be run as a user) or certutil -addstore -user root <cert file> in a login script. Note, I haven't tested these, the commands are straight from the help certutil -v -?.

share|improve this answer

We had a similar problem a while ago. If i remember correctly, this helped us:

  1. Computer Configuration > Windows Setting > Public Key Policies > Double-click Certificate Path Validation Settings, and then click the Stores tab.

  2. Select the Define these policy settings check box.

  3. Under Per user certificate stores, clear the Allow user trusted root CAs to be used to validate certificates and Allow users to trust peer trust certificates option in the Per User Certificate Stores check boxes.

  4. Then use gpupdate /force.

Hope this solves your problem.

share|improve this answer
Same thing unfortunately ... This is getting on my nerves now. Thanks. – Chris19 Jan 29 '13 at 13:45
Is this certificate also installed on DC? – 3n3low Jan 29 '13 at 13:53
Yes ... Installed and working just fine ... – Chris19 Jan 29 '13 at 14:49

In that case, why do not you also deploy an intermediate CA to issues Certificates? If Standalone CA can contact domain controllers it publishes it's own certificate to appropriate AD containers, which is the default behavior. If auto enrollment is triggered, computers can request certificates. The best way is to use an Enterprise Root and an Issuing CA. Standalone CAs have limitations when comes to enrollment and deployments. Configuration can be found here. Good Luck!

share|improve this answer
The intermediate CA can issue certificates but from what I understand it needs a valid Root CA defined in order for the intermediate CA certificate to be valid. Thanks. – Chris19 Jan 29 '13 at 13:48
That is installed when Intermediate or subordinate CA is deployed. It cannot be deployed without the root ca. The process is manual. You can make it an ENt. Subordinate. But there are some other things to clarify. First, to install computer certificates, domain admins have to have local administrator permissions in order to access the local computer store. This is a default but needs to be tested. But if the root certificate and CRLs have not been deployed properly to AD DS, you will run in to problems. With certutil: certutil -addstore -f root <root.crt>, certutil -addstore -f root <crl.crl> – Lasith Jan 30 '13 at 11:55
To add a subordinate certificate to the intermediate store: certutil -addstore -f CA <subcertfile.crt>. CRL: certutil -addstore -f CA <subcertfile.crl>. In order to publish certificates to AD DS from an offline CA (make sure auto enrollment is possible). certutil -dspublish -f "rootca.crt" RootCA. Use double quotes if the name includes spaces. certutil -dspublish -f subcert.crt SubCA can be used to deploy subordinate CAs to AD DS. Note that if the root ca is used, certificates will be published to both AIA and Certificate Authority containers while subordinate CA published only into AIA. – Lasith Jan 30 '13 at 12:04
In order to publish the CRLs, use certutil -dspublish -f crlfile.crl. If LDAP and other information related to CRLs are not sufficient or cannot be validated, the request may fail. But still you can force the publishing by adding the netBios name at the end of the command. Now the important part. Force the publication if it is not occurring. 1. Run gpupdate /force. 2. Next to that, certutil -pulse. This will initiate the auto enrollment requests. – Lasith Jan 30 '13 at 12:09
Finally, make sure that you understand the containers. 1. All CA certificates will be published into CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,ForestRootDomain (LDAP Distinguished Name). Root CA Certificates are also published into the CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,ForestRootDomain. Finally, Enterprise CA certificates are published into the CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,ForestRootDomain object (instead container). – Lasith Jan 30 '13 at 12:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.