Trusted Root Certificate of Root CA removed when browsing to 'wrong' URL RRS feed

  • Question

  • Hello,

    I've a very nasty issue with root CA certificate that's disappearing from the trusted root authorities store. I'll shortly describe the environment: 
    - Two tier PKI infrastructure with a offline, standalone root CA and a domain joined Enterprise issuing CA (both W2012R2); root CA certificate is published in AD
    - There's a parent and child domain. Issuing CA lives in parent domain (2012R2 domain&forest level)
    - Employees are working on a 2012R2 RDS&Citrix XenApp 76 server in the child domain
    - In the parent domain several servers are using a SSL certificate signed by the company owned issuing CA; it's a SAN certificate
    - The root CA's certificate is in the Trusted Root Certification Authorities store of all member servers in parent & child domain (so, that's also valid for the 2012R2 RDS servers)

    The issue is that the certificate of the root CA that's in the trusted CA store of all RDS servers is being deleted on a regular base (at least once a day on each RDS-server). I enabled CAPI2 logging, but I couldn't find anything that makes sense. However I'm able to reproduce this issue in very simple way: if I start IE11 on a RDS-server and browse to the IP-adres or NETBIOS-name of a webserver that host a site that's using a certificate from our PKI (so, it's clear that the URL isn't matching the names entered in the SAN certificate) and I click on 'Continue to this website (not recommended)', the root CA's certificate is being removed from trusted CA store of the server I'm working on.

    Unfortunately I'm unable to exactly determine what happens and how to solve this issue.

    Any idea?

    Tuesday, January 26, 2016 8:58 AM

All replies

  • Hi,

    The interesting part in your issue is that Internet Explorer already rejects something in the certificate chain the moment you access the website. I don't have an immediate idea to the problem, but some steps may help gather more information. When you have the page: "There is a problem with this website’s security certificate.", could you tell us what the lines below that state? There should be a brief description of the error.

    Also, it may be helpful for us to know the details of the Certificates involved in the tree, especially the Root CA Certificate.

    Also, did you check if you have a logon script, scheduled task or something similar that cleans out the certificate store of 'unwanted' certificates? See

    Finally, could you run an rsop.msc and show us the settings for Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Path Validation Settings and ...\Trusted Root Certification Authorities?

    Lookin forward to your reply.

    Kind Regards,

    Wednesday, January 27, 2016 7:22 AM
  • I see this error message when browsing to the NETBIOS name of the server instead of the FQDN:

    The security certificate presented by this website was issued for a different website's address.

    Which (rootca)certificate details do you want to know?

    I've checked for tasks or scripts, but there's no that cleans up certificates.

    In GPO's Certificate Path Validation Settings isn't configured. The Root CA certificate is published twice: once by using certutil -dspublish and once in a GPO.

    Wednesday, January 27, 2016 10:41 AM
  • Hi,

    OK, so the error is a dead end. The website certificate is probably issued for the FQDN, and you access it using the netBIOS name, so they don't match.

    Root CA details: Basically any red crosses in the General or Certification Path tabs, other than that anything out of the ordinary. But it's probably a dead end as well.

    So we come up empty on deletion scripts or adverse GPO's.

    I suppose it's time to see if we can track down the process. Could you reproduce the problem, but this time with Microsoft Sysinternals Process Monitor ( running along and saving the capture? You'll be especially interested in any Operation=RegDeleteKey and Operation=RegDeleteValue events on subkeys of HKLM\Software\Microsoft\SystemCertificates\ROOT\Certificates, or perhaps HKLM\Software\Microsoft\EnterpriseCertificates\ROOT\Certificates. When you filter on RegDeleteKey and RegDeleteValue, this starting point should be easy to find.

    Kind Regards,

    • Proposed as answer by Tony_TaoModerator Thursday, February 4, 2016 6:36 AM
    • Unproposed as answer by ASG_1977 Thursday, February 4, 2016 7:00 AM
    Thursday, January 28, 2016 8:10 AM
  • Hi,

    We have not heard from you in a couple of days, have you solved the problem? We are looking forward to your good news.

    Best Regards,


    Monday, February 1, 2016 1:17 AM
  • Excuse me, I'm a little bit slow with a reply. 

    The suggestion for tracing with ProcMon is a good one! Thanks for that!

    However, in the time between I've spoken with the RES Software support team (RES One Workspace 2015 is being used on the XenApp servers). It seems to be that one of the filter/guard drivers being responsible for this issue. RES Software is investigating it.

    I'll keep the folks here updated!

    Kind regards!

    Thursday, February 4, 2016 7:04 AM
  • Hi,

    Thanks for the update, especially pointing out that there's third-party software involved.

    Kind Regards,

    Friday, February 5, 2016 8:09 AM