The error below just started happening at work with a personal laptop running Windows 7 Ultimate. I'm unable to use installed, non-expired certificates to connect to a private wireless network. No recent changes were made by IT that would explain the issue. It worked fine several weeks ago and happens on two laptops I own.

The details and some screen shots are available here:

The connection attempt could not be completed

The error we don't understand is this:

The credentials provided by the server could not be validated. We recommend that you terminate the connection and contact your administrator with the information provided in the details. You may still connect but doing so exposes you to the security risk by a possible rogue server.

The server XYZ presented a valid certificate issued by Company Name Certificate Authority but Company Name Certificate Authority is not configured as a valid trust anchor for this profile.

We don't know to to resolve the issue without ignoring the error (nor what's changed that could explain this new error).

The new information is that we have our own Root CA, and that the certificates were not updated recently, nor have any expired.


I ran across the same issue. Found the answer.

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

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

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

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

  5. Click the "Settings" button.

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

  7. 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.

  8. 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

  • 3
    It's not the problem I'm having as the corporate certificate was already listed properly in the Trusted Root Certificate Authorities list. – WiredPrairie Jul 26 '10 at 17:58

The way an SSL certificate is authenticated as valid is by following a chain of trust. Whatever cert that your company is using to secure wifi is then validated against (at least) one intermediate certificate that verifies that it is legit. That intermediate certificate is, in turn, authenticated against a root certificate from a verified and trusted company.

The way the root certificates are validated as authentic and can be trusted is that Microsoft builds trust into Windows for certain certs, but these roots are usually outdated and don't have some major players in the SSL cert game. Verisign and Thawt usually have no problems, but Digicert (Entrust.net) is a huge SSL cert company that isn't natively trusted by Windows for 802.1x (which I'm assuming your wifi is using to authenticate based on the screen shots provided). This means that the cert is probably valid, but your computer doesn't know to trust it. You can certainly import that root cert as a trusted cert so that you aren't prompted with this any more. I would contact your system administrator about how to do that.

This could be caused by either the expiration of an intermediate or root cert if your company uses their own CA, or by them issuing a new root cert and not deploying it to you.

  • (Just found out) The company uses its own CA and no-certs have expired or been recently updated. – WiredPrairie Mar 14 '10 at 15:23
  • To expand on this - within an active directory domain, the domain controller is generally considered "trusted" by machines joined to the domain. Machines outside the domain, like your personal laptop, may have to explicitly trust the certificate. That's doesn't sound like what's going on here, but it's close enough to be worth mentioning. – Joel Coehoorn Jul 25 '10 at 4:31
  • @Joel - That has nothing to do with it. When you configure 802.1x through NPS you should provide an SSL certificate. It has nothing to do with being a domain member. Also, your characterization of trust is a little off. – MDMarra Jul 25 '10 at 12:03

I got to exactly the same point. If I accept the certificate warning, a userid / password prompt appears. If I enter my userid (the common name of the client cert - I shouldn't have to enter it), and leave the password blank, I successfully connect. Pretty weird and not how it was before.

Edit. All sorted. I had manually entered a wireless network profile, and used a lower case name whereas the corporate wireless starts with an uppercase letter. My successful connection mentioned earlier was not using my manually created profile at all. Once I defined a correclty named profile, it all worked as it used to.

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