none
Public Certificate for NPS/NAP? RRS feed

  • Question

  • Ok I am trying to get NPS setup that will be used for guests to access the Internet but still require a login on our network using PEAP.  I got a trial certificate from GeoTrust/RapidSSL/FreeSSL and it only offers "Digital Signature, Key Encipherment (a0)" but NPS requires a certificate with "Data Encipherment".  I have not found ANY public CA that issue this type of certificate so if Microsoft requires this for PEAP where am I to get a valid certificate for this?

    I have check Verisign, and GoDaddy and all of them only offer "Key Encipherment".


    • Edited by yaplej Saturday, December 10, 2011 1:39 AM
    Friday, December 9, 2011 10:45 PM

Answers

  • I was able to find the text of the article. I've posted it below. I'll keep looking for the full article with links.

    Get PEAP with MSCHAP v2 working with NPS on Windows Server 2008 and 2012
    Curated by Greg Lindsay
    This curation contains a summary of how PEAP with MSCHAP v2 works and provides links to several topics that can help you deploy and troubleshoot PEAP authentication on a network. PEAP with certificate based authentication (PEAP with EAP-TLS) is not discussed.
    Background:
    PEAP with MSCHAP v2 is a password based authentication method used to gain access to local and remote networks. This authentication method is commonly used for VPN connections and for networks using 802.1X enabled switches and access points. PEAP is an acronym for Protected Extensible Authentication Protocol. MSCHAP is an abbreviation for Microsoft Challenge Handshake Authentication Protocol.
    How PEAP works:
    --------------------
    There are five basic components required for the PEAP authentication method to work securely and correctly:
    1. A client device: This can be a computer or mobile device.
    2. A network access point:
    - For VPN connections, this is a VPN server.
    - For 802.1X based connections, this is a wireless access point or wired switch.
    3. A RADIUS server: Microsoft's RADIUS server is called Network Policy Server (NPS).
    4. A server certificate: A certificate must be installed on NPS that can be validated by the client device. You can use a Microsoft certification authority (CA) to issue this certificate, or you can purchase a certificate from a public CA such as VeriSign or Thawte.
    5. A user database: The database must support MSCHAP v2. This is typically Active Directory.
    For PEAP to work correctly, the following must be configured:
    1) The network connection on the client computer must be configured to perform PEAP authentication.
    2) The network access point must be configured to forward (aka pass-thru) authentication requests to the RADIUS server. This typically also requires that a shared secret is configured on the network access point which matches a corresponding shared secret on the RADIUS server.
    3) A certificate with the server authentication purpose and correct subject alternative name must be installed on NPS. Note: This procedure must be completed prior to configuring PEAP on NPS (step 4 below).
    4) NPS must be configured to perform PEAP authentication. The preferred method to configure NPS is using the scenario wizard in the NPS console. To use the wizard, click NPS in the console tree and then under Standard Configuration in the right-hand pane, select an item from the drop-down list that matches the type of network connection used by the client device (ex: VPN or wireless). When the configuration scenario is selected, click the corresponding Configure text that is displayed under the drop-down to launch the wizard.
    Note: Server certificate validation can be disabled on client devices. However, in order for PEAP authentication to be secure, the client device must be configured to validate the server's certificate. This validation occurs when the client verifies that the certificate (which was installed in step 3 above) meets either of two requirements:
    1) The certificate is found in the Enterprise NTAuth store.
    2) The certificate is found in the client's Trusted Root Certification Authorities container, and it is marked as trusted.
    If the certificate is found in the Trusted Root Certification Authorities container (but not NTAuth) and it is not marked as trusted, the client device receives a warning. The warning message is intended to provide the client an opportunity to mark the CA as trusted. The client should only receive this message once, provided the certificate is marked as trusted.
    If the certificate is not found in the Trusted Root Certification Authorities Container or the Enterprise NTAuth store, a PEAP error is generated and authentication fails.


    Tuesday, January 30, 2018 6:58 AM
    Owner

All replies

  • Well I have wasted an entire day on this.  I have gone round and round the technet site looking up requirements for the certificate used for nps.  It only makes mention that it must specifically include "Server Authentication" Extended Key Usage.  This however does not seam to be adaquate for nps to work with PEAP.

    http://www.windowsnetworking.com/articles_tutorials/network-access-protection-revisited-part7.html

    According to the artical above you must "make sure that the Purpose option is set to Signature and Encryption" now to me "Encryption" would equal the Key Usage option of "Data Encipherment".  However, none of the public CAs I contacted offer certificates with that Key Usage.  I have generated multile self-signed certificates and all of them include "Data Encipherment" and seem to work well for NPS but this is unacceptable in my case where we want guest systems to natively trust logging onto our network.

    Does anyone know of a CA that offers certificates with "Data Encipherment" as an enabled Key Usage?

    Thanks.

    Saturday, December 10, 2011 3:47 AM
  • Hi,

    This topic is good for you to read: http://technet.microsoft.com/en-us/library/cc772401(WS.10).aspx

    The server certificate on NPS must have the server authentication EKU and the client must have the correct trusted root certification authority certificate. You can achieve this with a Microsoft certification authority server or a 3rd party certificate. You must have this certificate on NPS or it won't let you configure a policy that uses the PEAP authentication method. I am not sure where you found the Data Encipherment EKU requirement, but the one you need for PEAP is server authentication.

    -Greg

    Saturday, December 10, 2011 12:50 PM
    Owner
  • Greg,

    Reguardless of what that document says PEAP does not work with any certificate that does not have the Key Usage of Data Encipherment.  All public CA certificates I have found (GoDaddy, VeriSign, GeoTrust) do not have that listed in the Key Usage field.  They only have Signature and Key Encipherment their Extended Key Usage is always set to Server Authentication and Client Authentication but that does not work for NPS becasue they are missing the "Data Encipherment" Key Usage option.

    If you generate a self-signed certificate I noticed it included the Key Usage option of "Data Encipherment" so that does work provided you trust the key on the NAP clients or disable "Verify Server" on the client.  If the certifciate does not have the Key Usage Data Encipherment option the NPS server logs "EAP Type not not supported cannot be processed by this server" paraphrased.

    I can assure you all the public CA certificates I have tried include the Extended Key Usage (EKU) option of Server Authentication but that alone does not work with NPS.  You can get a free trial certificate from FreeSSL (GeoTrust) that is trusted on 99% of systems and NPS will not work with it because public CAs dont issue certificates that include "Data Encipherment" as a Key Usage.

    The certificate NPS/NAP uses must be used to encrypt data directly using the certificate rather than generate a private key to be used for each session.  Its probably fast/easier to code that way but its much more secure to require each session negotiate a private key pair for each session.  Because most of these CAs are issueing certificates for HTTPS it makes sense they disable "Data Encryption" to ensure each web session is generating a unique key and not encrypting data with the certificate directly.

    I am not an expert on PEAP but according to wikipedia PEAP uses the servers public key to encrypt data.  With the certificates from public CAs exclude that particular use.

    http://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol#PEAPv0_with_EAP-MSCHAPv2

    "PEAP is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication, and uses server-side public key certificates to authenticate the server. It then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server's public key."

    Justin.


    • Edited by yaplej Tuesday, December 13, 2011 6:53 AM
    Tuesday, December 13, 2011 6:51 AM
  • Hi,

    We are referring to two different things here. A certificate has Key Usage and Extended Key Usage (EKU).

    Another requirement is for the subject alternative name. Have you checked this on your public cert?

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

    Thanks,

    -Greg

    Tuesday, December 13, 2011 7:19 PM
    Owner
  • Greg,

    We followed your direction and purchased a certificate with SANs for all four of our NPS servers.  As per the KB articles this certificate has EKU of "Server Authentication" and SANs for each of the NPS FQDNs.  We installed the certificate and tested but we still suffering from the same issue. EAP Type is not supported with this certificate.

    So we are going back again that PEAP requires Data Encipherment not just Key Encipherment Key Usage.  The SAN might prevent the certificate from being trusted but we are not even getting that far.

    Where do we go from here?

    Justin.

    Thursday, December 15, 2011 7:50 PM
  • Hi Justin,

    I've always used my own CA to issue certificates. Is there a reason why you can't install certification authority in your environment? I think we can solve the problem using 3rd party certificates, but if you are able to install a CA this might be simpler.

    Please let me know,

    -Greg

    Thursday, December 15, 2011 9:36 PM
    Owner
  • We will be having vendors and systems that will not trust our internal CA.  I tested this with an internal CA and was able to verify it works without the Key Usage option Data Encipherment but the certificate issued by the public CA still does not work.  We are going to try some certificates from other public CAs to see if any of them work.

    Thursday, December 15, 2011 11:13 PM
  • Hi,

    On NPS, do you see the certificate in the enterprise NTAuth store?

    Issue this command to view:

    certutil -v -store -enterprise ntauth

    Ex:

    -Greg


    P.S. I found a GUI method: Certutil –viewstore –enterprise NTauth

    This will show you the trusted Root certificate. It is the same certificate that you should see in the (correction added here) Enterprise Trust container in the local computer certificate MMC.

    Make sure also that the certificate is being imported correctly. At a command line, type MMC, click File... Add/Remove Snap-in, click Certificates, click Add, choose Computer account, click Next, choose Local computer, click Finish and click OK. View the certificates in Certificates (Local Computer)\Personal\Certificates.



    Thursday, December 15, 2011 11:33 PM
    Owner
  • No.

    The command "certutil -v -store -enterprise ntauth" seems to be the same as "Enterprise Trust" container in the local computer certificate MMC and it is empty.  "Trusted Root Certification Authoriteis" contian has all the public CA root certificates listed.

    Friday, December 16, 2011 12:02 AM
  • Thanks for the correction, you are right. It is the Enterprise Trust container, not the Trusted Root Certification Authorities container. I am going to edit my post above so it doesn't provide incorrect advice. Thanks again.

    -Greg

    Friday, December 16, 2011 1:27 AM
    Owner
  • So we tried to generate the CSR with IIS7 on a laptop and get a new certificate but that didnt work.

    Then we tried to generate a certificate with IIS7 directly on the NPS it... also didnt work.

    http://social.technet.microsoft.com/Forums/en-US/winserverNAP/thread/b867409d-afe8-49a9-87d8-65a323c4c5cb/

    Still broken.

    Friday, December 16, 2011 1:52 AM
  • Have you added the 3rd party certificate to the enterprise NTAuth store on NPS?

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

    I have had to do this before in a different scenario, but it might help here. If this doesn't help I'll have to either do some testing myself and/or find someone with 3rd party certificate experience.

    certutil -enterprise -addstore NTAuth cert.cer

    -Greg


    Friday, December 16, 2011 2:07 AM
    Owner
  • What should I be adding to the enterprise NTAuth store? 

    I already tried adding the root CA public certificate and it didnt make any difference.  I dont think that would be any help for PEAP because if I export the certificate from my test NPS server I have that used a Microsoft PKI it works.  That PKI is in a totally separate domain and was not trusted but it still worked for PEAP on these new NPS servers I am setting up.  I also could not find any differences between the certificate from our test PKI and the public CA in terms of EKU and Key Usage options.

    So I know my NPS configuration is good because it works great with a self-signed certificate or a certificate from a MS PKI/Enterprise Root CA.  Minus having to "trust" the certificate on some clients and disable Server Validation on Windows clients.

    For whatever reason when I select the public CA certificate for PEAP it cannot process PEAP requests.

     

    Saturday, December 17, 2011 5:48 PM
  • So here are some of the details from our public certificate issued by a common public CA.
    "General" tab of certificate.
    This certificate is inteded for he following purpose(s):
    Ensures the identity of a remote computer
    Proves your identity to a remote computer
    2.16.840.1.114413.1.7.23.1
    
    Issued to: nps.domain.blah
    
    Issued by: Public CA Secure CA
    
    Valid from 12/ 15 / 2011 to 12/ 15/ 2016

    "Details" tab of certificate.
    Version "V3"
    
    Serial number "Hex Stuff"
    Signature algorithm "sha1RSA"
    Signature hash algorithm "sha1"
    Issuer "####, Public CA Secure CA"
    Valid from "date"
    Valid to "date"
    Subject "
    CN=nps.domain.blah
    OU=Domain Control Validated
    O=nps.domain.blah"
    Public key "RSA (2048 Bits)"
    Enhanced Key Usage "
    Server Authentication (1.3.6.1.5.5.7.3.1)
    Client Authentication (1.3.6.1.5.5.7.3.2)"
    Subject Alternative Name"
    DNS Name=nps.domain.blah DNS Name=www.nps.domain.blah
    DNS Name=nps1.domain.blah
    DNS Name=nps2.domain.blah
    DNS Name=nps3.domain.blah
    DNS Name=nps4.domain.blah"
    Basic Constraints "
    Subject Type=End
    Entity Path Length Constraint=None"
    Key Usage "Digital Signature, Key Encipherment (a0)"
    The certificate looks perfectly fine to me.  Unles you see something that would prevent it from working.

    • Edited by yaplej Monday, December 19, 2011 6:57 PM
    Monday, December 19, 2011 6:57 PM
  • Hi Justin,

    When you install the certificate and start to configure policies on NPS, does the certificate show up as one that you can pick? When and what is the exact error message?

    Thanks,

    -Greg

    Monday, December 19, 2011 7:13 PM
    Owner
  • Yes, the certificate shows up and allows me to select it.  The error message shows in the NPS logs when a client tries to connect.  If I change the certificate for a self-signed certificate or a certificate issues by a MS Enterprise root CA it works.  Even if the certificate is not trusted.  This is the event generated when a client tries to connect and NPS is trying to use the public certificate.

    Network Policy Server denied access to a user.
    
    Contact the Network Policy Server administrator for more information.
    
    User:
    	Security ID:			NULL SID
    	Account Name:			myguest
    	Account Domain:			DOMAIN
    	Fully Qualified Account Name:	DOMAIN\myguest
    
    Client Machine:
    	Security ID:			NULL SID
    	Account Name:			-
    	Fully Qualified Account Name:	-
    	OS-Version:			-
    	Called Station Identifier:		001d.7095.3dfa
    	Calling Station Identifier:		f81e.df3b.7e3a
    
    NAS:
    	NAS IPv4 Address:		<private ip>
    	NAS IPv6 Address:		-
    	NAS Identifier:			W-AP1
    	NAS Port-Type:			Wireless - IEEE 802.11
    	NAS Port:			844
    
    RADIUS Client:
    	Client Friendly Name:		W-AP1
    	Client IP Address:			<private ip>
    
    Authentication Details:
    	Connection Request Policy Name:	NAP 802.1X
    	Network Policy Name:		-
    	Authentication Provider:		Windows
    	Authentication Server:		DC01.domain.blah
    	Authentication Type:		EAP
    	EAP Type:			-
    	Account Session Identifier:		-
    	Logging Results:			Accounting information was written to the local log file.
    	Reason Code:			22
    	Reason:				The client could not be authenticated  because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.

     

    Tuesday, December 20, 2011 6:51 PM
  • I just requested a single use certificate and it worked without any problems. Any ideas why the multi-domain certificate would not work?
    Friday, December 23, 2011 1:36 AM
  • Hi,

    It must have something to do with the SAN requirement. I have been meaning to follow up on this by reviewing the EAP logs but holidays have kept me pretty busy. I am going to be out for the next week also on vacation, but it sounds like you might have found a solution anyway. I'm sorry I wasn't able to provide more helpful advice on this thread.

    -Greg

    Friday, December 23, 2011 4:29 AM
    Owner
  • Hello,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue.

    Regards,
    Rick Tan
    Forum Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Rick Tan

    TechNet Community Support

    Tuesday, December 27, 2011 2:54 AM
    Moderator
  • Use OID "1.3.6.1.4.1.311.10.3.4" to get a certificate that has Data Encipherment as a Key Usage.

    This might be useful:

    How to enable LDAP over SSL with a third-party certification authority http://support.microsoft.com/kb/321051

     

     


    Sumesh P - Microsoft Online Community Support
    Tuesday, December 27, 2011 6:24 AM
    Moderator
  • Turned out that the Data Encipherment Key Usage mades no difference.  The working public certificate does not have Data Encipherment so that was not the problem.  The problem is related to the multi-domain public certificate.  I dont know why it is not working while the single domain certificate is.  They are both from the same public CA.


    If we can review the EAP logs to figure out why the multi-domain certificate didnt work that would be great.  I did not want to get a certificate for each of our NPS servers if I could use the multi-domain certificate.

    PS.
    Hope everyone had a great Holiday and Christmas.

    • Edited by yaplej Tuesday, December 27, 2011 6:03 PM
    Tuesday, December 27, 2011 5:58 PM
  • Hello,

    I am glad to see that you have realized the problem with your certificate.  As Greg noted, the KU was correct.  One of the additional requirements is the SAN field which must contain the FQDN of the server as noted in KB814394:

    "the Subject Alternative Name (SubjectAltName) extension contains the server's fully qualified domain name (FQDN)."

    While you have the FQDN, it does not look like it is the first entry.  When RAS-TLS is looking for a valid certificate, it is looking in the SAN at the first entry which does not match the name of the server, so RAS-TLS will skip this certificate, hence the error that you were getting.

    A single certificate issued to all your servers, unfortunately, will not work.

     

    Thanks,

    Clay


    Clay Seymour - MSFT
    Wednesday, December 28, 2011 6:47 PM
  • Clay,

    While that may be the case that NPS only looks at the first entry in the SAN field it does not fully explain the issue.  I have for instance used certificates that do not match the FQDN at all and the NPS was still able to authenticate using PEAP.  Using this multi-domain certificate however it does not and will not even process the PEAP requests.

    I have used certificates from another domain that in no way matches the FQDN or even the DN and RAS-TLS did not skip that certificate and was able to accept and process PEAP requests.  Why then if it was willing to user a certificate issued to another domain name would it skip the certificate just becase the FQDN did not match.  It also didnt match the other and was still willing to use it.

    Does NPS RAS-TLS behave different when the domain name does not match?

    Thanks,
    Justin.

    Tuesday, January 3, 2012 6:07 PM
  • Hello Justin,

    I am looking to setup an environment very similar to yours with our NPS and using SAN on the certificate.  Where you able to get this working?

    Thanks,

    Jeff

     

    Friday, January 13, 2012 10:13 PM
  • No, I could never get it to work with a multi-host SAN certificate.  Even though MS stated the issue was because the first entry in the SAN did not match the RAS-TLS service would not use the certificate I found in many other cases where the RAS-TLS service would use a certificate where the first entry in the SAN field did not match the FQDN at all yet still worked although with a certificate warning being presented to the user.
    Wednesday, January 18, 2012 9:30 PM
  • I'm having the same issue and want to verify what kind of certificate I should purchase. So for a single NPS I would want to request a single name cert with the server name (ie nps01.local) as the subject name? Is it fine to just create the CSR from IIS?

    Thanks

    Friday, January 25, 2013 7:51 PM
  • From all of the replies it appears that THERE IS NO PUBLIC CA that would sell a certificate which would work with NPS? How could this be possible?

    Obviously an SSL certificate won't work. 

    Has anyone been able to purchase a certificate that actually worked with NPS? If yes which CA sold it and what was the process on the NPS server of creating the certificate request that ended up with the public CA ultimately a working certificate on NPS?

    Friday, September 19, 2014 6:29 PM
  • A public certificate will work with NPS. Many people have used them. It must meet certain requirements.

    I wrote a summary that explains some of the requirements here: http://curah.microsoft.com/39626/get-peap-with-mschap-v2-working-with-nps-on-windows-server-2008-and-2012

    Note the trust requirements having to do with the CA chain. There are also the normal certificate property requirements.

    Monday, September 22, 2014 6:56 PM
    Owner
  • Friday, November 25, 2016 5:21 PM
  • Thursday, December 1, 2016 5:38 AM
    Owner

  • Hi Greg, do you still have a copy of NPS public certificate requirements and can you please post it again as all mirror links are not working anymore? Many thanks in advance.
    Monday, January 29, 2018 2:28 PM
  • I'll try to find the original article and repost it somewhere that won't get deleted.

    Here is a forum post that has just about all the same information:

    https://social.technet.microsoft.com/Forums/windows/en-US/c66cf0a8-24dd-4ccd-b5bb-16bd28ad8d4c/having-issues-getting-peap-with-eapmschap-v2-working-on-windows-2008-r2?forum=winserverNAP


    Tuesday, January 30, 2018 6:51 AM
    Owner
  • I was able to find the text of the article. I've posted it below. I'll keep looking for the full article with links.

    Get PEAP with MSCHAP v2 working with NPS on Windows Server 2008 and 2012
    Curated by Greg Lindsay
    This curation contains a summary of how PEAP with MSCHAP v2 works and provides links to several topics that can help you deploy and troubleshoot PEAP authentication on a network. PEAP with certificate based authentication (PEAP with EAP-TLS) is not discussed.
    Background:
    PEAP with MSCHAP v2 is a password based authentication method used to gain access to local and remote networks. This authentication method is commonly used for VPN connections and for networks using 802.1X enabled switches and access points. PEAP is an acronym for Protected Extensible Authentication Protocol. MSCHAP is an abbreviation for Microsoft Challenge Handshake Authentication Protocol.
    How PEAP works:
    --------------------
    There are five basic components required for the PEAP authentication method to work securely and correctly:
    1. A client device: This can be a computer or mobile device.
    2. A network access point:
    - For VPN connections, this is a VPN server.
    - For 802.1X based connections, this is a wireless access point or wired switch.
    3. A RADIUS server: Microsoft's RADIUS server is called Network Policy Server (NPS).
    4. A server certificate: A certificate must be installed on NPS that can be validated by the client device. You can use a Microsoft certification authority (CA) to issue this certificate, or you can purchase a certificate from a public CA such as VeriSign or Thawte.
    5. A user database: The database must support MSCHAP v2. This is typically Active Directory.
    For PEAP to work correctly, the following must be configured:
    1) The network connection on the client computer must be configured to perform PEAP authentication.
    2) The network access point must be configured to forward (aka pass-thru) authentication requests to the RADIUS server. This typically also requires that a shared secret is configured on the network access point which matches a corresponding shared secret on the RADIUS server.
    3) A certificate with the server authentication purpose and correct subject alternative name must be installed on NPS. Note: This procedure must be completed prior to configuring PEAP on NPS (step 4 below).
    4) NPS must be configured to perform PEAP authentication. The preferred method to configure NPS is using the scenario wizard in the NPS console. To use the wizard, click NPS in the console tree and then under Standard Configuration in the right-hand pane, select an item from the drop-down list that matches the type of network connection used by the client device (ex: VPN or wireless). When the configuration scenario is selected, click the corresponding Configure text that is displayed under the drop-down to launch the wizard.
    Note: Server certificate validation can be disabled on client devices. However, in order for PEAP authentication to be secure, the client device must be configured to validate the server's certificate. This validation occurs when the client verifies that the certificate (which was installed in step 3 above) meets either of two requirements:
    1) The certificate is found in the Enterprise NTAuth store.
    2) The certificate is found in the client's Trusted Root Certification Authorities container, and it is marked as trusted.
    If the certificate is found in the Trusted Root Certification Authorities container (but not NTAuth) and it is not marked as trusted, the client device receives a warning. The warning message is intended to provide the client an opportunity to mark the CA as trusted. The client should only receive this message once, provided the certificate is marked as trusted.
    If the certificate is not found in the Trusted Root Certification Authorities Container or the Enterprise NTAuth store, a PEAP error is generated and authentication fails.


    Tuesday, January 30, 2018 6:58 AM
    Owner
  • Thursday, February 8, 2018 11:17 PM
    Owner
  • As yapelj suggested, I came across this thread also searching for the key usage requirement of Data Encipherment after reading a suggestion in a different post but cannot find supporting documentation. I too am running into the same problem and am very frustrated.

    ;

    I've run into the same issue using publicly signed certificates with two different providers, InCommon and GoDaddy. My issue is slightly different because we are not using wildcard's at all, single domain / server only. The issuing and intermediate CA's are located in the trusted root / intermediate stores but still present the user with a message to trust and continue. I'm somewhat confused reading the certificates should be in the computer account store. Isn't the session validated against the logged in user? This is being used for wireless 802.1x PEAP, after the user has logged into the machine.

    ;

    One thing I've noticed and wondering if it's a problem is the chaining of intermediates in a single file on the public side. Example, InCommon utilizes User Trust intermediates. If you open the single file from the Windows store, it actually has 2 intermediates inside. I'm wondering if this is causing a problem when the chain is validated during the EAP session.. Say for example 3 CA's need validation, only 2 files drawn from the certificate store. I cannot replicate this problem using an internal AD CA. That is the only difference for me, and certificate does not have client authentication in the EKU.



    Feel like I should edit this before someone asks. The subject and SAN have fully qualified domain name of the system and reverse DNS matches.



    • Edited by Al Kayal Monday, August 20, 2018 8:34 PM
    Monday, August 20, 2018 8:19 PM
  • Greg i am not sure why you marked your post as answering the question, as this does not seem resolved. Your last comment is the telling one "The warning message is intended to provide the client an opportunity to mark the CA as trusted. The client should only receive this message once, provided the certificate is marked as trusted."

    How am i supposed to do that for someones personal iphone? or a contractors laptop. Yes i can tell them to always trust, but its the same damn thing as a self signed cert. We want to avoid trust issues completely which is the ENTIRE POINT of buying a comercial certificate. The certificate i am using is of type PositiveSSL.

    So we had a wildcard cert, and NPS would not deal with that. Fine. So i went to ssls.com and purchased a ssl cert for a single domain NPS.domain.com

    Installed it into the machine, and configured with NPS as per this article (https://wifinigel.blogspot.com/2014/03/microsoft-nps-as-radius-server-for-wifi_15.html ) (he uses his own cert authority, but the process is the same)

    But the results are that the cert is still marked as not trusted. Its signed by comodo. I know on some webservers like apache and AWS we have to import that full certificate chain into the machines local repository. I have added the other 3 certs that they sent me as well to personal, trusted and enterprise store on the NPS machine and still nothing.

    I dont get this whole data encipherment thing. The documentation i linked above says the server certificate only need be client and server.

    i will keep researching and post back if i get it working on my test ipad.

    Friday, September 21, 2018 5:57 PM
  • sharepoint,

    This is a long thread about a similar issue, not specifically yours. You should try the advice in this thread about adding the cert to the NTAuth store, and viewing the contents of that store.

    https://support.microsoft.com/en-us/help/295663/how-to-import-third-party-certification-authority-ca-certificates-into

    Saturday, September 22, 2018 6:36 AM
    Owner
  • Thanks that is interesting and i had never seen that interface before. Looks like there are some errors in there to do with certificates expired in 2014, and i guess i should be revoking old certificates...

    But the problem on the ipad remains.

    I believe it is caused by not having an internet connection to check the validity of the certificate (i am trying to establish said connection, which appears to be a catch22). I think I would have to get the intermediate certificates on the ipad which is not possible, especially with peoples BYOD. I might be able to push it to corporate ipads with meraki, but they are on a different network that isnt 802.11x anyways...

    If you are microsoftie, can you tell me does anyone have a trusted certificate working with NPS and BYOD devices? i talked to our reseller of certificates and they said that they cant provide one that meets this requirement. They said i can buy a certificate direct from comodo but the costs would be "quite high", which is probably not worth it for getting rid of a client prompt for BYOD devices... Just sad that MS cant support this obvious scenario of nps and 802.11x. I mean technically its the devices, and the certificates all conspiring together to make things difficult, so not entirely M$ fault but still, sad.

    Someone must be able to do this kind of auth correctly! Well worst comes to worst i just have to tell IOS users to accept the cert like always. Just wanted to get rid of that hiccup.

    Monday, September 24, 2018 3:07 PM
  • @sharepointisneedlesslycomplex I can not agree more with you. I have tested this with what many would consider as the premiere SSL house - Go Daddy and I still get the warning.

    Without reiterating what's already said:

    IS THERE A WAY to avoid any and all warnings regarding 802.1x certificates, period?

    Is this a Microsoft OS defect? Or is it a matter of using another RADIUS for 802.1x other than NPS

    Monday, September 24, 2018 6:41 PM
  • Hi there,

    Can you please provide a screenshot of the warning that you are describing?

    Also please check your PEAP configuration.  Note the configuration below and the following settings:

    - Validate server certificate (selected)

    - Do not prompt user to authorize new servers or trusted certification authorities (not selected)

    Tuesday, October 2, 2018 8:17 PM
    Owner
  • In iOS 12.0, under Settings > About > Certificate Trust Settings there is a list of trusted certificates.

    There is also a link here that takes you to a topic on support.apple.com

    https://support.apple.com/en-us/HT204132

    About trust and certificates

    Each iOS Trust Store listed below contains three categories of certificates:

    • Trusted certificates establish a chain of trust that verifies other certificates signed by the trusted roots—for example, to establish a secure connection to a web server. When IT administrators create Configuration Profiles for iOS, these trusted root certificates don't need to be included.
    • Always Ask certificates are untrusted but not blocked. When one of these certificates is used, you'll be prompted to choose whether or not to trust it.
    • Blocked certificates are believed to be compromised and will never be trusted.

    https://www.bomgar.com/docs/remote-support/getting-started/customer-client/apple-ios/iosconfigurationprofiles.htm

    Tuesday, October 2, 2018 8:27 PM
    Owner
  • Well thanks for replying.

    Under about, there is a radio slider that is "enable full trust for root certificates" and it was set to off. It has one item in there which is CA. I assume that "CA" is our own self signed certificate authority, as that is what it is called on our domain. When we were trying to get this working, i manually installed our internally signed root certificate on this ipad. However if i switch that to green (full trust) and switch the cert on the NPS to our self signed one, it still prompts for trust. So it was an intriguing idea and something I didnt see before, but appears not to work. Since that would require me getting users to install the root cert, it is also not a good solution, even if it did work.

    It has no effect, setting this, for the comodo cert. In both cases, the trust prompt is still displayed. It looks like this:

    I am interested in the screen where you are setting protected EAP properties. Where on the NPS server are you setting that? My EAP screen with the certificates does not look like that. Is that a windows client screen which would not apply?

    Wednesday, October 3, 2018 3:05 PM
  • It's in the PEAP properties of the policy that uses PEAP as an authentication method.

    It's very difficult to find a screenshot of this because the topics that were written for 2008 R2 and 2012 are no longer discoverable using search.

    This is a pretty good article: http://powershell365.com/2016/02/12/windows-2012-r2-nps-with-peap-mschapv2-authentication-for-wifi-users/

    I'll try to bring up a VM today and install NPS then get a certificate added for PEAP so I can screen shot it myself. If I don't get it today I'll get it asap.

    That certificate definitely needs to be trusted.
    Wednesday, October 3, 2018 4:06 PM
    Owner
  • like this you mean?

    not as many options, which is why i think its the wrong panel.

    Wednesday, October 3, 2018 6:51 PM
  • My apologies, I don't work in this area anymore so my memory is a bit foggy.

    As it happens, that is a client-side setting. If you enable 802.1X authentication on the client's network interface, then view the properties of that interface, the setting is there on the Authentication tab / PEAP settings.

    Obviously this won't be present on non-Windows clients. I'm outside my area of expertise w.r.t. iOS but perhaps you should look at this article:

    https://support.apple.com/en-us/HT207866

    Wednesday, October 3, 2018 7:43 PM
    Owner
  • It basically says "install a configuration profile on the device", which would be great for managed ipads, but not so great for BYOD. Getting the user to do anything but connect is going to be a problem. Its much easier to just tell them to trust the certificate at this point.

    Conclusion, this is not possible as the iphone or pad cannot trust the certificate natively. If anyone in the future gets this working, please leave a note. Thanks for trying greg!

    Wednesday, October 3, 2018 10:13 PM
  • The way it should work is that any consumer device should have public certificates installed and trusted by default.  That's how it works on a Windows client, and I assume Apple or Android is the same.

    For example, I'm on my home computer right now. If I type certmgr.msc and open the console, I see Go Daddy Class 2 Certification Authority, GlobalSign, Hotspot 2.0 Trust Root CA, and many other public certificates present in the Trusted Root Certification Authorities\Certificates container. I didn't install any of those. They were already present.

    Now then, how about certificates from your company CA? They obviously won't be installed by default on any client device. And you wouldn't want there to be a mechanism for some network to simply present a certificate and push it onto a device without user knowledge or activity. That would be a serious security flaw.

    So either the user needs to interact with the certificate somehow, or you need to use a public certificate that is already approved by unmanaged devices - or the device must be managed and an administrator sets the certificate trusts.




    Wednesday, October 3, 2018 10:26 PM
    Owner
  • We are just talking around in circles now because that is the conclusion that i reached several posts ago. It appears that no public CA will issue the required certificate without great cost. And even with great cost, no one can say for sure if it will work to justify that, or even know which specific cert to buy that is working. And for BYOD devices, say the cert costs 10k per year, well I am not going to pay that so that people don't have to click a button on connection. Its just a sad state of affairs it seems. In my company, even a few hundred per year would probably be too much.

    i appreciate the time you took to puzzle it out, but its the same conclusion we reached earlier.

    Thursday, October 4, 2018 3:17 PM
  • So is it possible to get correct certificate that will ALWAYS be trusted on iOS devices (so users do not need to accept)?

    Seb

    • Edited by scerazy Sunday, March 31, 2019 9:02 AM
    Friday, February 1, 2019 1:20 PM
  • Bump!

    Anybody ever managed?

    Sunday, March 31, 2019 9:02 AM
  • So is it possible to get correct certificate that will ALWAYS be trusted on iOS devices (so users do not need to accept)?

    Seb

    You can review the certs at this link: https://support.apple.com/en-us/HT209144#trusted

    Maybe that will help?


    Computer Solutions Group Lead Engineer www.csgsupport.net

    Monday, April 1, 2019 10:22 PM
  • Sorry, but that helps me HOW exactly?

    Seb

    Tuesday, April 2, 2019 1:17 PM
  • secrazy, did you even read the entire thread? you can clearly see that no one has got this working.

    If you get it working, post back. But just posting "bump" or snarky comments does not add anything to the discussion.

    Tuesday, April 2, 2019 2:18 PM
  • Great, so the answer is NO, as simple as that. In which case I can leave it as is, and not bother again

    Unfortunately what was marked as answer, really is not (not to say that it does not display correctly at all!)

    • Edited by scerazy Wednesday, April 3, 2019 10:01 AM
    Wednesday, April 3, 2019 9:58 AM
  • I believe you can get a public certificate to be always trusted, but it must be imported into the NTAuth store, and it must meet specific requirements. One of those requirements has to do with the subject alternative name (SAN) of the certificate which must contain the FQDN of the server as noted in KB814394:

    "the Subject Alternative Name (SubjectAltName) extension contains the server's fully qualified domain name (FQDN)."

    So if you have multiple NPS servers then a single certificate won't work because each NPS has a different FQDN.  If you have a single NPS, make sure the SAN matches the FQDN of your NPS.

    -Greg

    Wednesday, April 3, 2019 3:06 PM
    Owner
  • NTAuth store on iOS?

    SAN name is not a single line, it can have MANY

    • Edited by scerazy Thursday, April 4, 2019 7:36 PM
    Thursday, April 4, 2019 7:36 PM
  • Sorry, I had forgotten that iOS was folded into the thread at one point.  Unless iOS has something similar to NTAuth then it's correct to say it isn't possible to avoid the alert on all iPhones/iPads. In the thread above I did provide a link once but I'm unsure how helpful it is

    https://support.apple.com/en-us/HT207866

    I'm reposting what Clay said above about the SAN:

    "When RAS-TLS is looking for a valid certificate, it is looking in the SAN at the first entry which does not match the name of the server, so RAS-TLS will skip this certificate, hence the error that you were getting."

    So even though it supports many, it doesn't work to put many names in there.  Don't ask me why. I do know that if Clay says it's true you can count on that as he is extremely experienced with certificate auth issues.


    Thursday, April 4, 2019 8:28 PM
    Owner