locked
Importing a public server Certficate for NPS RRS feed

  • Question

  • We have setup a 802.1x enabled wifi network (WPA2-Enterprise). We are using NPS as authenticating server. Domain computers are authenticated using a machine certificate from our internal CA (ADCS). We also allow guests to connect to our wifi network using username/password (we set up an AD-account for each guest). However, our guests get a certificate warning when connecting since the certificate of the authenticating server (Auth-5 and Auth-6) is signed by our local PKI (ADCS). To solve this issue we want to use a certificate from a public PKI (Trustzone) for the server in order to get rid of the certificate warnings.

    We contacted Trustzone and explained what we wanted to do. They recommended us an “UC certificate” and sent us three files:

    142322231.crt AddTrustExternalCARoot.crt TRUSTZONE Intermediate CA.crt

    In the mail they said:

    * TRUSTZONE Intermediate CA – Should be installed as an intermediary root certificate on your server

    * 142322231 – Web server certificate.

    The certificate 142322231 is valid for authentication of a remote server and to confirm your identity towards a remote server

    The certificate 142322231 contains the following information in SAN (Subject Alternate Name): mail.domain.com Auth-5 Auth-6

    What steps should we now take to properly use this certificate? Should we use this certificate to authenticate the auth-servers towards all users or just for our guests?

    Regards,

    Jonas

    Wednesday, May 14, 2014 9:25 AM

Answers

  • At the NPS machine, start a MMC, Snap-In Certificates, local Computer and import

    - the server certificate 142322231.crt to Personal

    - TRUSTZONE Intermediate CA.crt to the Intermediate Certification Authorities store

    The root should be downloaded automatically now if this CA is provided via the MS root program (I did not cross-check - I am assuming you picked the TrustZone CA for that reason)

    Valdiate the chain by double-clicking 142322231.crt on the NPS machine. You should see a cert. chain with three levels: server, intermediate and public root.

    If the chain is not fine ("partial" e.g.), you might have an issue with updating the CAs via the root program (I had encountered issues with servers that were not allowed to access "the internet" or were the root update was turned off via GPO.)

    Assuming the chain is fine, configure this certificate in your EAP policy in NPS' configuration.

    Make sure you have the expiry date of the certificate documented so that somebody will replace it in due time to avoid outages.

    As for your second question - cert. for internal users: I don't have a strong opinion here, you should consider the following:

    Using the same cert. for external and internal users makes the NPS setup simpler (you could probably use the same policy) but internal users will be impacted if you forget to replace the external cert. manually.

    Using an internal cert. in an internal policy makes the policies more complicated but would allow for renewing the internal cert. automatically via autoenrollment. The NPS policy picks up the renewed cert. automatically so there will be no outages.

    Edit: If you use the external cert. for internal clients I would also distribute it via AD (by publishing it to the AIA store using pkiview or certutil) - on principle it should be sent in the SSL handshake but I would perfer to manage trusted certs. in AD, also for "documentation".


    • Edited by Elke Stangl Wednesday, May 14, 2014 11:13 AM
    • Marked as answer by Jonas Haglund Wednesday, May 14, 2014 12:27 PM
    Wednesday, May 14, 2014 11:10 AM
  • After a little bit more research i found this:

    http://support.microsoft.com/kb/2518158

    http://community.arubanetworks.com/t5/Technology-Blog/Apple-iDevice-EAP-Certificate-Validation-Challenges/ba-p/71772

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

    It turns out that both iPhone and Win 7 requires either the user to accepts a certificate warning
    OR
    the admin must preconfigure profiles with approved CA:s (although a well-known CA is used).


    • Marked as answer by Jonas Haglund Wednesday, May 14, 2014 12:27 PM
    • Edited by Jonas Haglund Wednesday, May 14, 2014 12:29 PM Added link.
    Wednesday, May 14, 2014 12:26 PM

All replies

  • At the NPS machine, start a MMC, Snap-In Certificates, local Computer and import

    - the server certificate 142322231.crt to Personal

    - TRUSTZONE Intermediate CA.crt to the Intermediate Certification Authorities store

    The root should be downloaded automatically now if this CA is provided via the MS root program (I did not cross-check - I am assuming you picked the TrustZone CA for that reason)

    Valdiate the chain by double-clicking 142322231.crt on the NPS machine. You should see a cert. chain with three levels: server, intermediate and public root.

    If the chain is not fine ("partial" e.g.), you might have an issue with updating the CAs via the root program (I had encountered issues with servers that were not allowed to access "the internet" or were the root update was turned off via GPO.)

    Assuming the chain is fine, configure this certificate in your EAP policy in NPS' configuration.

    Make sure you have the expiry date of the certificate documented so that somebody will replace it in due time to avoid outages.

    As for your second question - cert. for internal users: I don't have a strong opinion here, you should consider the following:

    Using the same cert. for external and internal users makes the NPS setup simpler (you could probably use the same policy) but internal users will be impacted if you forget to replace the external cert. manually.

    Using an internal cert. in an internal policy makes the policies more complicated but would allow for renewing the internal cert. automatically via autoenrollment. The NPS policy picks up the renewed cert. automatically so there will be no outages.

    Edit: If you use the external cert. for internal clients I would also distribute it via AD (by publishing it to the AIA store using pkiview or certutil) - on principle it should be sent in the SSL handshake but I would perfer to manage trusted certs. in AD, also for "documentation".


    • Edited by Elke Stangl Wednesday, May 14, 2014 11:13 AM
    • Marked as answer by Jonas Haglund Wednesday, May 14, 2014 12:27 PM
    Wednesday, May 14, 2014 11:10 AM
  • Wow excellent answer! 

    The certificate chain now looks like this:

    mail.domain.com
    >COMODO High-Assurance Secure Server CA
    >>USERTrust

    However, when connecting with my iPhone, it tells me this: 

    mail.domain.com (AddTrust External CA Root) - Uncontrolled (with red text)

    There is an option to approve the certificate. What is going on here? Both Addtrust and USERtrust should be in the iPhones default root cert list. 

    Wednesday, May 14, 2014 11:44 AM
  • I don't have access to an iPhone so I can't check the list of roots. Can you confirm you see AddTrust, USERtrust, or Comodo in the list of roots at the device?

    I have also found this list of roots in iOS 7 http://support.apple.com/kb/ht5012 - there is one Comodo, but I don't know if it is the right one.

    A general issue with all these roots is - as you can see from the names - that the CA provider companies have been merged and re-sold, and a consequence all kinds of so-called cross-trusts exist to bind newer certificates to the already hard-coded chains. This can mess up devices so I never believe the root vendors before I have tested myself with specific devices and a specific CA.

    Elke

    Wednesday, May 14, 2014 11:57 AM
  • I tried connecting with a default configured, non-domain win 7 laptop instead and got this mesasge (translated):

    The server provided a valid certificate issued by AddTrust External CA Root, but Addtrust External CA Root is not configured as a valid trust anchor for this profile. Additionally, the server mail.domain.com is not a valid NPS-server for this profile. 

    In Win 7, if you configure a wireless profile, you have to choose witch CA:s you trust from a list. None is selected by default. Isn't this weird? It basically mean that it is impossible to avoid certificate warnings without some manual preparations on each client? Or am I wrong?

    Wednesday, May 14, 2014 12:14 PM
  • After a little bit more research i found this:

    http://support.microsoft.com/kb/2518158

    http://community.arubanetworks.com/t5/Technology-Blog/Apple-iDevice-EAP-Certificate-Validation-Challenges/ba-p/71772

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

    It turns out that both iPhone and Win 7 requires either the user to accepts a certificate warning
    OR
    the admin must preconfigure profiles with approved CA:s (although a well-known CA is used).


    • Marked as answer by Jonas Haglund Wednesday, May 14, 2014 12:27 PM
    • Edited by Jonas Haglund Wednesday, May 14, 2014 12:29 PM Added link.
    Wednesday, May 14, 2014 12:26 PM
  • You're right - at the client the validation of the server cert need to be turned off. (As for the root, this used to work in the past without checking it, but it had probably changed.)

    Re manual preparations: The user needs to configure the EAP type at least, probably turn on the Autoconfig service. So some preparation can't be avoided anyway. Most of my clients configure internal 801.1x via GPOs as they would not want their users to do it / have to deal with it.

    I think it is OK to have another check here and not rely on the external root only - the external root cannot vouch for your internal process to handle server certificates so this additional config. / check should prevent users from connecting to "any network" just validated by a server certificate chaining to some of the many roots in the store. (It is a bit similar to macro signing where it is not sufficient to trust an external chain either - you need to trust the publisher explictly).

    Wednesday, May 14, 2014 12:27 PM
  • I was just typing my answer when you have posted yours - you are correct re Win 7 and warnings in general (though I was not sure about iPhone defaults) ... I thought there was an additional problem with the iPhone chain (root not recognized at alll...)

    • Edited by Elke Stangl Wednesday, May 14, 2014 12:31 PM
    Wednesday, May 14, 2014 12:29 PM
  • Ah ok! I'm new to PKI so I weren't aware about that. However the bad side is we have to preconfig each guests devices manually since we cant affect them with GPO.

    Anyhow, thanks for your help. Greatly appreciated.

    Jonas

    Wednesday, May 14, 2014 12:33 PM
  • Most WLAN guest solutions I have seen use the "hotel" / "airport"-style architecture, that is: "public" WLAN (no WPA, no 802.1x) plus web-based authentication. I don't have experience with these solutions but probably for a smaller number of guests it might be overkill. But these solutions would be straight-forward for the users.
    Wednesday, May 14, 2014 12:37 PM