Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, February 18, 2011 6:31 AM | 2 votes
Two years ago I requested a WLAN certificate from Thawte only to learn that Windows XP and Windows Vista would choke on the certificate and fail to connect because they couldn't validate the intermediate.
I opened a case with Microsoft at that time, and I was told to deploy the intermediate through group policy, which might be fine in a completely AD managed Windows-only environment. However, I am in higher education where the majority of the users for the wireless network manage their own laptops and have freedom of platform choice.
Thawte eventually re-issued the certificate from their root, without any intermediate, as this was still customary practice until the arrivel of the EV, SGC, and DV certificate chains. Their technical support has told me that it is no longer possible for them to issue a certificate in the same manner.
This time I tested with Thawte's TEST CA, and only installed the Root in to the client's Trusted Roots. When connecting, the client didn't exhibit any problems; however, I had only tested with Windows 7.
But herein lies the problem. Even when configuring a certificate for IIS, Thawte prescribes instructions on how to properly install the DV (SSL123) certificates. I've abided by these installation procedures, even going so far as to also include the intermediate in the Personal and the Trusted Root stores. The NPS server has no issues with the trust chain. However, the NPS server is apparently not handing off the intermediate to the client, and the client, therefore, cannot associate the endpoint identity certificate with the intermediate and up to the trusted root.
XP and Vista continue to show these problems, however, Apple OS X (even as early as 10.4) and Windows 7 computers are able to complete the chain of trust.
With XP, it's a trivial task to browse for the network, which always defaults to EAP-TLS, and switch it over to PEAP with MSCHAPv2 authentication, and with the intermediate not being delivered, uncheck the validate certificate setting.
Vista is an entirely different beast and in my test case, the Vista client complained about the trust chain, but prompted for me to accept the certificate.
However, upon deploying this new Thawte certificate in to production, an entirely new batch of unintended test cases showed up. Almost all of them were Vista clients and unless the Wireless Network profile is manually configured to not validate the certificate, Vista refuses to display the certificate warning prompt -- it just fails to connect after prompting for credentials twice with an immediate failure message. Browsing for the profile fails to register the Wireless Network Profile automatically because it rejects the certificate. Similarly, it also asks for credentials but fails the certificate check. This will leave thousands of students in a state where they have to manually configure the wireless network properties.
So I am left to wonder why NPS refuses to deliver the intermediate to the client. The same type of SSL123 certificate has been used for several months on production IIS servers and clients don't have a problem trusting the certificate; and I'm guessing because IIS delivers the intermediate. If I install the Intermediate for the certificate, the client doesn't complain (in most cases).
How do I go about configuring NPS to deliver the intermediate?
All replies (4)
Monday, February 21, 2011 9:49 PM âś…Answered
Thanks for replying. That is the precise conclusion I have come to; however, I am going to open a support case with Microsoft to verify that there isn't an outstanding hotfix that could resolve the problem.
Sunday, February 20, 2011 6:29 PM
Since you're talking about WLAN certs and not IIS SSL certs, and the users are not AD members (GPOs can't be used), the only thing I can think of is to create an installation package that will install the cert for the students and offer it on the university's website.
Something like this would have to be stated in the school's Network FAQ or Acceptable Use policy, as well setting up the website to download the installer package. One example of an installer package that I know of that exists, is the SBS 2008 cert installer. If you can get a hold of this installer, you can use it to install the intermediate certificate, and provide it for download to new students or students connecting from new laptops.
The public CAs started using intermediates for increased security. There's not much you can do to override that, as far as I can see.
Ace
Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
This posting is provided AS-IS with no warranties or guarantees and confers no rights.
Monday, February 28, 2011 10:09 PM | 1 vote
The answer I got back from Microsoft is the Network Policy Server does not deliver intermediate certificates with the identity certificate -- it is up to the client to trust the certificates, be it through Group Policy, another deployment method, or utilize a certificate that doesn't require an intermediate.
Although Microsoft hasn't explicitly identified an RFC that states the RADIUS server isn't required or cannot send intermediates along with the identity certificate, they did state clearly that NPS does not deliver it due to RFC specification.
I hope this helps others out. Before buying a 3rd party trusted certificate, be prepared to either deploy the intermediates to workgroup clients or verify the issuing party will provide a certificate less any intermediates.
Tuesday, March 1, 2011 4:38 AM
Kind of what I thought.
It's possible that they are referring to RFC 2865 & 2866, more than likely 2866. I haven't read through them, but Just searching on "RCC 2866 cerfitificates" I saw the reference about it.
Here's a link from Microsoft Technet site:
Planning NPS as a RADIUS server
(NPS supports all network access servers and RADIUS proxies that comply with the RADIUS protocol as described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," and RFC 2866, "RADIUS Accounting.")
http://technet.microsoft.com/es-es/library/dd197604(WS.10).aspx
The following link indicates it's not a good idea for an NPS to provide certificates due to security reasons. That may be the basis of the whole thing and why you have to provide them to your clients another way, where you can verifythe clients asking for them so they may not be attackers.
RADIUS - Accounting is described in RFC 2866. When network access is granted to the user by ..... "MD5 considered harmful today - Creating a rogue CA certificate". ...
http://en.wikipedia.org/wiki/RADIUS
Ace
Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
This posting is provided AS-IS with no warranties or guarantees and confers no rights.