none
EAP-TLS ,Problems after implementing new CA structure

    Question

  • Hi

    We recently implemented a new two-tier Certificate Authority to replace our old one-Tier.
    Everything seems to be working with the new CA, Servers and Clients have Root CA and Issuing CA in the correct stores and the certificates issued show no error and appear valid.
    The problem is Wireless security (EAP-TLS) and client certificates. Both Cisco ACS and MS NPS refuse to allow clients to connect using Certificates issued by the new CA even if we use the same certificate template as before. Enroll from the old CA everything works fine…

    Both the client and the NPS server have the new Root CA under “Trusted Root Certificate Authorities” and the issuing CA under “Intermediate Certification Authorities”

     

    Are there any limitations for EAP TLS (Key Length for Root CA, Spaces in CA names and so on?)
    Our root Cert has a 4096 key length and CA name contains spaces.


    Thomas Larsen


    • Edited by Thomas Larsen Monday, September 02, 2013 10:52 AM removed Strange Word formatting
    Monday, September 02, 2013 10:52 AM

Answers

  • You can use certutil.exe to check the CRLs in AD.

    Just save a certificate as .cer file and the run certutil.exe -URL cert.cer

    In the Retrieve box select CRLs (from CDP) and click on Retrieve.

    About ACS (I am not an ACS expert), but ACS can probably not download the CRL over LDAP because authentication issues and also because it does not know how to handle a LDAP:/// connection, because that is AD syntax. Can you force ACS to download the CRL via HTTP? I know that was working with the old VPN concentrators.

    Friday, September 06, 2013 1:00 AM

All replies

  • Hi Thomas,

    with the key length and the CA name your are fine.

    Can you check in the Group Policy you have that the CA verification settings are correct:

    1. Go to GPO/Computer Configuration/Policies/Windows Settings/Security Settings/Wireless Network/NameofYourPolicy

    2. Click on Properties, Select your profile and click on Edit

    3. Go to the Security tab

    4. Click on Properties.

    5. Verify that Validate server certificate is checked

    6. Verify that under Trusted Root Certification Authorities the new CA is listed, and either all CAs are checked, or all CAs are not checked, or only the old and the CA is checked.

    btw: Do you still have the old certificates in the client machine certificate store?

    Regards,

    Lutz

    Tuesday, September 03, 2013 3:54 AM
  • Figured it out. Had to manually import the CRL's to the NPS servers Certificate store.
    None of the logs(that I checked) mentioned anything about CRL check failing. Server logs showed everything OK. Client logs just say client cert is invalid.

    Added both the Root CA's and the intermediates CRL to the "Machine Store\Intermediate Certification Authorities\Certification Revocation List".



    Thomas Larsen

    • Marked as answer by Thomas Larsen Tuesday, September 03, 2013 6:26 AM
    • Unmarked as answer by Thomas Larsen Thursday, September 05, 2013 1:08 PM
    Tuesday, September 03, 2013 6:26 AM
  • Hi,

    I am glad to hear that the issue has been resolved! And thanks for your sharing!

    Have a nice day!

    Regards,

    Yan Li

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Cataleya Li
    TechNet Community Support

    Tuesday, September 03, 2013 6:50 AM
  • Hi Thomas,

    that sounds like a temporary workaround to me. You should verify the CDP settings in your certificates to make sure that the NPS server can retrieve the CRLs! Otherwise next time (what is the validdity of your CRLs? 1 week, 2 weeks?) a new CRLs is needed the download will fail and you are in the same situation again.

    Regards,

    Lutz

    Tuesday, September 03, 2013 12:22 PM
  • Hi Thomas,

    that sounds like a temporary workaround to me. You should verify the CDP settings in your certificates to make sure that the NPS server can retrieve the CRLs! Otherwise next time (what is the validdity of your CRLs? 1 week, 2 weeks?) a new CRLs is needed the download will fail and you are in the same situation again.

    Regards,

    Lutz

    You're probably right. still can't get it to work on our Cisco ACS Servers.

    CRL seems OK ,have only testet the http points, but open them in IE from the NPS and it works.
    Don't know how to verify the CRL stored in AD.

    The NPS server was just temporary ,just configured it to troubleshoot certs.
    We use Cisco ACS in production
    We have added the CRL URL's to the ACS server. BUt the clients still fail with the error message "Handshake failed" on the ACS and "data cannot be decryptet"(loosly translated) on the client.

    Root CA: 


    Intermediate/issuing CA


    Thomas Larsen


    Wednesday, September 04, 2013 10:40 AM
  • You can use certutil.exe to check the CRLs in AD.

    Just save a certificate as .cer file and the run certutil.exe -URL cert.cer

    In the Retrieve box select CRLs (from CDP) and click on Retrieve.

    About ACS (I am not an ACS expert), but ACS can probably not download the CRL over LDAP because authentication issues and also because it does not know how to handle a LDAP:/// connection, because that is AD syntax. Can you force ACS to download the CRL via HTTP? I know that was working with the old VPN concentrators.

    Friday, September 06, 2013 1:00 AM