none
NPS Using 3rd Part (GoDaddy in this case) Certificate

    Question

  • I realize there are other posts regarding this but I do not believe I have found any that specifically answer this question but sorry if I missed it or I am hoping for a different answer. :)

    I have a school that is going to be a hybrid of BYOD and school provided Windows 7/8 and iPads. I have NPS setup on a 2008 R2 server and had purchased a cert from GoDaddy to be used on PEAP. With that said I realize that the server verification warning on the domain-based Win7 computers could be resolved if I install the cert in a NTAuth which would then distribute the same configuration in all domain computers...however this does not resolve the issue with non-domain based computers and devices (such as iPads, iPhones, Chromebooks, Android...etc) from warning them of a need to validate the server. I realize that some of these devices you can actually turn off validation but these students are not going to do this on every device they bring in. Is there any way that we can either stop the server validation requirement or reconfigure (something) so that these devices will valid the server? I have read that the reason is that public CA's do not provide "Data Encipherment" into their certs "key usage". If this sounds like part or all of the cause is it possible to have a public CA (GoDaddy) include "Data Encipherment" in their certs? I just cannot believe that everyone in a BYOD situation just accepts the fact they are going to receive warnings about validating the server every time they connect a new device or "forget" the SSID and reconnect.

    Thanks in advance. 

    Thursday, September 12, 2013 7:25 PM

Answers

  • Hi,

    No. When I say 'marked as trusted' what I'm referring to is what happens when the user clicks yes in the warning dialog. In PEAP properties, there is a list of certificates that are found in Trusted Root Certification Authorities. Next to each is a checkbox - see the image below. If the checkbox is checked, that means the certificate is trusted. If it isn't checked, it just means the certificate was found in Trusted Root Certification Authorities container on the local computer but isn't trusted yet.

    If the user clicks yes on the warning message, this does two things:

    1. Imports the certificate from NPS into Trusted Root Certification Authorities if it isn't already there.

    2. Checks the checkbox, marking the certificate as trusted.

    If the certificate was already in NTAuth, neither of the two steps above are necessary. This entire process is skipped.  You can import the certificate into NTAuth in the domain, or locally. Doing it locally isn't really an effective way to accomplish it though because you can just click yes on the warning message instead.


    Monday, September 16, 2013 5:24 PM

All replies

  • Hi,


    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.


    Thanks for your understanding and support.


    Alex Lv

    Monday, September 16, 2013 6:32 AM
  • HI,

    Please take at following articles:

    http://support.microsoft.com/kb/814394/en-us

    http://blogs.technet.com/b/pki/archive/2012/02/27/ndes-and-ipads.aspx


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, September 16, 2013 11:08 AM
  • HI,

    Please take at following articles:

    http://support.microsoft.com/kb/814394/en-us

    http://blogs.technet.com/b/pki/archive/2012/02/27/ndes-and-ipads.aspx


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Hi,

    The article on the requirements can be a bit confusing when discussing clients of all types of operating systems. Maybe this additional information will help:

    I created the certificate on the school's outside domain (for example school.org) and not their internal AD domain (for example school.int). The school.org DNS zone is on the internal servers and I had created an A record that pointed wifi.school.org to the NPS server of (for ex. again) server.schoo.int. With that said is it possible the problem would be resolved if I could have a 3rd party cert provider, such as GoDaddy, provide a cert to the FQDN of server.school.int as opposed to wifi.school.org? I have read that GoDaddy will provide a cert for an internal domain but will stop doing so after 2015. Thoughts?

    Oh and doing enrollment for devices was not an option for this school. It was to intrusive and too much overhead. They simply want the students and faculty to be able to bring in their own devices and connect to the Wifi. I have firewall rules setup so they only have access to printing resources, DHCP and DNS. Guests only have access to the internet. Not that any of that mattered for this subject.

    Thanks again

    Monday, September 16, 2013 2:57 PM
  • Hi,

    If I am reading your question correctly, the answer is no, you can't do this.

    What you are asking is to be able to configure an authentication provider (NPS) so that non-domain devices automatically trust it without question. If this were possible, it would be a serious security flaw.

    You must do one of two things:

    1. Trust the provider domain-wide and distribute this setting via Group Policy.

    2. Manually trust the provider on each device.

    Since you can't get Group Policy on non-domain devices, you simply must trust the provider individually on each device.

    Keep in mind that trusting the provider is a single question (phrased as a warning) asked once. If you respond yes, then this question/warning should not be seen again on that device. What you are doing when you answer yes is #2 above.

    -Greg

    Monday, September 16, 2013 4:47 PM
  • Hi,

    If I am reading your question correctly, the answer is no, you can't do this.

    What you are asking is to be able to configure an authentication provider (NPS) so that non-domain devices automatically trust it without question. If this were possible, it would be a serious security flaw.

    You must do one of two things:

    1. Trust the provider domain-wide and distribute this setting via Group Policy.

    2. Manually trust the provider on each device.

    Since you can't get Group Policy on non-domain devices, you simply must trust the provider individually on each device.

    Keep in mind that trusting the provider is a single question (phrased as a warning) asked once. If you respond yes, then this question/warning should not be seen again on that device. What you are doing when you answer yes is #2 above.

    -Greg

    Either I am confused here or maybe I relayed the previous question wrong. The provider IS trusted by every device because the certificate is provided by GoDaddy which is in pretty much every devices' trusted certificate authority listing. Unless your terminology of the "provider" is not that of the CA but the provider of authentication? Just to reiterate...I have heard that GoDaddy will create certificates for internal domains such as server.school.int (or .local or whatever AD domain be used). With that being said the FQDN would be the exact name of the server's AD FQDN but yet the certificate would have been issued by an already trusted CA (GoDaddy). All of this would be a moot point if the issue here is not that of the certificate not matching the Active Directory FQDN of the NPS server.
    Monday, September 16, 2013 4:57 PM
  • Hi,

    Sorry but this isn't enough.

    The actual certificate that you have installed on NPS must be in the Trusted Root Certificates container and also marked as trusted (or in NTAuth). Just having the Godaddy root CA certificate in Trusted Root Certificates isn't enough.

    I should have been clearer: when I say 'authentication provider' I mean NPS, i.e. actual computer that NPS is running on. The client needs to trust this, which it does by trusting the certificate that is installed on NPS (not the root CA for that certificate).

    -Greg





    Monday, September 16, 2013 5:08 PM
  • Hi,

    Sorry but this isn't enough.

    The actual certificate that you have installed on NPS must be in the Trusted Root Certificates container and also marked as trusted. Just having the Godaddy root CA certificate in Trusted Root Certificates isn't enough.

    I should have been clearer: when I say 'authentication provider' I mean NPS, i.e. actual computer that NPS is running on.

    -Greg

    OK - so when you say "also marked as trusted" are you referring to the NTAuth? If so, there is no such thing on iOS, Android and Chromebook devices.
    Monday, September 16, 2013 5:14 PM
  • Hi,

    No. When I say 'marked as trusted' what I'm referring to is what happens when the user clicks yes in the warning dialog. In PEAP properties, there is a list of certificates that are found in Trusted Root Certification Authorities. Next to each is a checkbox - see the image below. If the checkbox is checked, that means the certificate is trusted. If it isn't checked, it just means the certificate was found in Trusted Root Certification Authorities container on the local computer but isn't trusted yet.

    If the user clicks yes on the warning message, this does two things:

    1. Imports the certificate from NPS into Trusted Root Certification Authorities if it isn't already there.

    2. Checks the checkbox, marking the certificate as trusted.

    If the certificate was already in NTAuth, neither of the two steps above are necessary. This entire process is skipped.  You can import the certificate into NTAuth in the domain, or locally. Doing it locally isn't really an effective way to accomplish it though because you can just click yes on the warning message instead.


    Monday, September 16, 2013 5:24 PM
  • That's what I figured you meant. Your description of this last post I bet is found by many future searches...very well described. However, my biggest concern is not the Windows devices though... How can we keep iOS, Android and Linux (Chromebook) devices from prompting every time they connect a new device. This may not be that big of a deal though as I think this should only happen the first time they connect to the SSID. They would have to "Forget" the network for it to occur again...at least from my experience anyway.

    Thanks again for your quick responses.

    Monday, September 16, 2013 5:44 PM
  • Thanks,

    Yes - it should only happen once. As for forgetting the SSID and reconnecting later it might be possible that the certificate is already imported and trusted so even forgetting the SSID won't cause the warning message to pop up again. I don't know for sure.

    Good luck!

    -Greg

    Monday, September 16, 2013 5:50 PM
  • Yeah that doesn't work on non-Windows OS computers. I think everything is deleted once you forget the network as in there is no permanent store that remembers you validated the server/certificate in the past. I have tested that and that was my primary concern since there will be 4x the amount of non-Windows devices than Windows devices. Anyway, looks like nothing I can do with the non-Windows devices other than just accept they will receive this prompt the first time they connect and anytime thereafter should they forget the network.


    Thanks again.

    Monday, September 16, 2013 6:37 PM
  • HI,

    the pop-up box may be caused by the cert is not trusted. For non-MS devices, you may ask 3rd party for help. Any way, here are some articles for your reference.

    http://longwhiteclouds.com/2013/01/03/installing-corporate-ca-certificates-on-iphone-or-ipad-for-use-with-vmware-view/

    http://support.apple.com/kb/HT1978

    Thanks for your understanding.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    • Edited by Jason Mei Wednesday, September 18, 2013 9:43 AM typo
    Wednesday, September 18, 2013 9:42 AM
  • HI,

    the pop-up box may be caused by the cert is not trusted. For non-MS devices, you may ask 3rd party for help. Any way, here are some articles for your reference.

    http://longwhiteclouds.com/2013/01/03/installing-corporate-ca-certificates-on-iphone-or-ipad-for-use-with-vmware-view/

    http://support.apple.com/kb/HT1978

    Thanks for your understanding.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.



    Thanks for replying but this is not what is happening and this is the reason I stated that it is GoDaddy certificate. Both GoDaddy's CA and their Intermediate is, by default, trust and installed on pretty much all devices. Even with this said I called their support any way and they said that the certificate looks fine and that they have nobody that can help support a NPS/RADIUS environment.
    Wednesday, September 18, 2013 12:21 PM
  • HI,

    Do you mean you called 3rd party device support or the GOdaddys support? please let me know.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, September 23, 2013 6:49 AM
  • GoDaddy
    Monday, September 23, 2013 12:44 PM
  • Hi,

    From windows side, the certificate used for NPS/RADIUS must be trusted by the client. http://technet.microsoft.com/en-us/library/cc772401(v=ws.10).aspx

    For 3rd party device, i'm not quite sure what's the basic requirements.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, September 24, 2013 12:24 PM
  • I think you are missing much of the conversation here. GoDaddy is trusted by all of these devices as well as its intermediate certificate. Bottom line is the server is not listed in the "Verification" side of the wireless environment so the prompt is going to occur. Unless ever device is set to not try to verify the server. This has nothing to do with the CA being trusted or not at this point.

    It's becoming a moot point. The first time they connect is the only time they will receive this verification warning. So much time has already gone by that most of these devices have already accepted the fact that the device could not verify the server so it is now no big deal. Just wish this worked differently. To me if the certificate is trusted that is all that should matter. You shouldn't also have to verify the server along with trusting the cert.

    Wednesday, September 25, 2013 2:47 PM
  • Hi,

    If the certificate trusted by all device, I'm afraid there is some additional requirement needed for the certificate or the 3rd device for the wireless connection. For windows, i remember the root certificate must be published to NTAuthCertificates . So, I recommend you to create a case to MS professional support for help.

    http://support.microsoft.com/kb/814394/en-us


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, September 27, 2013 9:08 AM
  • Jason, please let me clarify. The certificate can be either trusted or published to NTAuth. Both are not required.

    NTAuth is like a super-trust. If the certificate is here then it is automatically trusted, no questions asked.

    Trusted Root Certificates is not quite the same. The certificate must be here and then the user must agree to trust it by clicking yes in the warning dialog.

    Both techniques will cause the warning to go away, but you only need to perform one.

    -Greg

    Friday, September 27, 2013 3:15 PM