none
Public Certificate for NPS/NAP?

    Soru

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


    • Düzenleyen yaplej 10 Aralık 2011 Cumartesi 01:39
    09 Aralık 2011 Cuma 22:45

Tüm Yanıtlar

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

    10 Aralık 2011 Cumartesi 03:47
  • 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

    10 Aralık 2011 Cumartesi 12:50
  • 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.


    • Düzenleyen yaplej 13 Aralık 2011 Salı 06:53
    13 Aralık 2011 Salı 06:51
  • 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

    13 Aralık 2011 Salı 19:19
  • 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.

    15 Aralık 2011 Perşembe 19:50
  • 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

    15 Aralık 2011 Perşembe 21:36
  • 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.

    15 Aralık 2011 Perşembe 23:13
  • 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.



    15 Aralık 2011 Perşembe 23:33
  • 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.

    16 Aralık 2011 Cuma 00:02
  • 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

    16 Aralık 2011 Cuma 01:27
  • 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.

    16 Aralık 2011 Cuma 01:52
  • 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


    16 Aralık 2011 Cuma 02:07
  • 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.

     

    17 Aralık 2011 Cumartesi 17:48
  • 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.

    • Düzenleyen yaplej 19 Aralık 2011 Pazartesi 18:57
    19 Aralık 2011 Pazartesi 18:57
  • 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

    19 Aralık 2011 Pazartesi 19:13
  • 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.

     

    20 Aralık 2011 Salı 18:51
  • I just requested a single use certificate and it worked without any problems. Any ideas why the multi-domain certificate would not work?
    23 Aralık 2011 Cuma 01:36
  • 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

    23 Aralık 2011 Cuma 04:29
  • 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

    27 Aralık 2011 Salı 02:54
  • 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
    27 Aralık 2011 Salı 06:24
  • 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.

    • Düzenleyen yaplej 27 Aralık 2011 Salı 18:03
    27 Aralık 2011 Salı 17:58
  • 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
    28 Aralık 2011 Çarşamba 18:47
  • 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.

    03 Ocak 2012 Salı 18:07
  • 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

     

    13 Ocak 2012 Cuma 22:13
  • 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.
    18 Ocak 2012 Çarşamba 21:30
  • 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

    25 Ocak 2013 Cuma 19:51