4

We have a wireless authentication server (Windows 2003 SP2 with IAS). It is configured with a DigiCert certificate. The certificate chain looks like this:

Entrust.net Secure Server Certification Authority
  DigiCert High Assurance EV Root CA
    DigiCert High Assurance CA-3
      ourserver.ourdomain.com

When a Windows 7 client connects to the wireless for the first time, they get a warning about the certificate. It will look like this:

The server "ourserver.ourdomain.com" presented a valid certificate issued by "Entrust.net Secure Server Certification Authority", but "Entrust.net Secure Server Certification Authority" is not configured as a valid trust anchor for this profile.

That is not a big deal as it's supposed to be a one-off. But the root certificate it complains about is inconsistent. Half the time, they get this instead:

The server "ourserver.ourdomain.com" presented a valid certificate issued by "DigiCert High Assurance EV Root CA", but "DigiCert High Assurance EV Root CA" is not configured as a valid trust anchor for this profile.

The reason this is an issue is that it means the client is prompted a second time at some later point when they reconnect to the wireless network, where the connection seems to arbitrarily choose the "other" certificate in the chain as the missing anchor, rather than the first. The selection appears to be random.

To be clear, this has been reproduced where:

  • 2 Windows 7 laptops are in the same physical location (on same AP).
  • One, when initially configured, prompted with the Entrust root cert.
  • The other, when initially configured, prompted with the EV root cert.
  • Both were connecting to the same IAS server, which only has one certificate installed.

Any ideas as to the cause of this inconsistency, and how I can stop it?

Neobyte
  • 3,177
  • 25
  • 29
  • If you haven't done so already, I'd recommend going into the Windows Application and Services Logs and turning on the CAPI2 (certificate api log) and WLAN-AutoConfig. They're under Event Viewer->Application and Services Logs->Microsoft->Windows. Find the operational log and click "Enable Log". It will give you more detail. Also, are your IAS servers load balanced? – Bob Mar 29 '11 at 23:06
  • Unfortunately it appears CAPI2 logging is only available in Windows 2008 and up - our IAS servers are 2003. Yes our IAS servers are load balanced. – Neobyte Mar 30 '11 at 02:03
  • These logs can be enabled on the clients too, it might help you find if there was something odd with the certificate negotiations between the client and the server. (e.g. a wonky subject alternative name or something) – Bob Apr 05 '11 at 23:15

3 Answers3

2

I had exactly this problem and solved it by downloading the DigiCert SSL Certificate Checker and running it on my IAS servers. The tool stated that one of the intermediary certificates, was incorrect and offered to install a new one. Looking at the certificate store, the tool installed a new DigiCert High Assurance CA-3, even though an apparently valid certificate was present. I checked the new certificate against the one it replaced, both had the same version number and expiry date, just a different serial number. Not sure what was wrong with the previous but it all worked with the new one.

Robert Sexstone
  • 36
  • 2
  • 1
    That awkward moment when your work colleague from two metres away answers your question, 11 months later. – Neobyte Apr 02 '12 at 07:44
0

This is just a guess, but I think that both

  • "Entrust.net Secure Server Certification Authority"
  • "DigiCert High Assurance EV Root CA"

are installed as "Trusted Root Certificate Authorities".

When the "ourserver.ourdomain.com" certificate is checked against the trusted anchor profile, for some reason (probably due to a specific issue with the implementation), it will arbitrarily choose either as the root.

I think that removing "DigiCert High Assurance EV Root CA" from Trusted Root Certificate Authorities might resolve the issue. It's signed by the other one, so it will still verify ok.

e_tothe_ipi
  • 478
  • 2
  • 3
-1

Try

First, Go to Control Panel > Network and Internet > Manage Wireless Networks.

Open the wireless network. Or, click the "Add" button to create a new network, then open it.

The Wireless Network Properties window appears. Click the Security tab.

Under "Choose a network authentication method", select "Microsoft: Smart Card or other certificate". I assume this is already selected.

Click the "Settings" button.

The "Smart Card or other Certificate Properties" window appears.

Here is the answer. Under the "Trusted Root Certification Authorities" list, you have to manually select the Root CA of your company. By default, these are all blank. That is why the warning message appears the first time if you do not select your company's Root CA. If you connect despite the warning, then your company's Root CA is now selected, and you no longer get the warning on subsequent connections. So, to avoid the warning, just select this box when you set up the network, before you connect for the first time.

If you do not see your company's Root CA here, that is likely due to the fact that by default, double clicking your certificate to install it probably puts it under the "Intermediate Certification Authorities" tab. You need to select the "Trusted Root Certification Authorities" tab instead. You can see where certificates go under: Internet Explorer > Internet Options > Content > Certificates

user76288
  • 1
  • 1
    None of this answers my question, which is "why am I being prompted with inconsistent trust anchors". – Neobyte Mar 30 '11 at 01:56