Sign in
 
HomeWindows Server “8” Beta20082003LibraryForums
Windows Server TechCenter > Windows Server Forums > Security > Problems with PKI and NPS

Answered Problems with PKI and NPS

    •  
      Wednesday, February 22, 2012 9:12 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      We have two domains in a single forest. Domain A has a NPS, CA and is set up to roll out certificates to clients through GPO. Domain B has a subordinate CA and is also set up to roll out certificates through GPO. All this works well. Clients in Domain B gets certificates that is chained like this: Domain A CA -> Domain B CA -> Client.

      However, when a client in Domain B connects using a certificate issued by the subordinate CA in Domain B, the NPS rejects the client saying the client's certificate was issued by a CA that is not trusted. So I get that the NPS then thinks the subordinate CA in Domain B is not trusted, but the sub CA's certificate was issued by the CA in Domain A which the NPS trust, so what is the problem here. Also, the NPS has the sub CA's certificate installed in the trusted root cert storage.

      I feel I have tried almost anything but I am obviously going wrong somewhere here. Deeply appreciate any help.
       

    Answers

    • Friday, February 24, 2012 11:18 AM
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote

      I solved this by doing the following:

      Setting up a NPS in Domain B.

      Configuring the NPS in Domain A so that when a request for Domain B comes in, forward it to NPS in Domain B.

      This seems to work.

      It's not the answer to my problem but it's a way around. I'm suspecting it has something to do with the way NPS and UPN lookups in AD work.


       

    All Replies

    • Thursday, February 23, 2012 3:18 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Sounds possibly like cross certification may not have been configured properly. Was A's root installed on B's Root or Subordinate, and vice versa?

      .

      .

      .

      Also, this question may be better suited for the security forum, which focuses on PKI, CA, etc. Maybe we can ask Tiger to move it, unless you've already posted this question there?
      http://social.technet.microsoft.com/Forums/en/winserversecurity

      Ace

      Ace Fekay
      MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
      Microsoft Certified Trainer
      Microsoft MVP - Directory Services
      Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

      This posting is provided AS-IS with no warranties or guarantees and confers no rights.

      FaceBookTwitterLinkedIn


       
    • Thursday, February 23, 2012 9:03 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      a) If I undrestand it correctly, the SubCA(B) is really subordinate CA of the RootCA(A). So then, on the NPS, you need to make sure the RootCA(A) is in the Trusted Root Certification Authorities instead of the SubCA(B).

      b) NPS not only checks the certificate path (chain) to be trusted, but also verifies CRLs/OCSP (revocation state) of the certificates in the chain. This revocation needs to check both the revocation state of the ClientCert and the revocation state of the SubCA(B) own certificate. If these checks are not possible, the certificate path validation will not success and you may receive the error you mentioned.

      c) how to verify the chain validation for the ClientCert is working correctly from the NPS perspective? Just download the ClientCert onto the NPS server in the form of .CER/.CRT file and verify its chain from command line by using CERTUTIL -VERIFY -URLFETCH ClientCert.CER. Or you can use more user friendly version of the tester with CERTUTIL -URL ClientCert.CER. Both the commands will tell you whether the revocation state checking is available and working correctly.

      d) if the NPS is validating the chaing correctly, you should also make sure that the CLIENT can validate the NPS's certificate. In fact, both the Client and the NPS must be able to verify their respective certificates. Note that NPS server must have its own certificate from either the RootCA(A) or the SubCA(B), which it does not matter. So again, download the NPS's server certificate to the Client workstation in the form of .CER/.CRT file and use the CERTUTIL -URL NPSCert.CER command to verify the validity.

      ondrej.

       
    • Thursday, February 23, 2012 1:11 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Thank you very much for your reply. You understand it correctly. I have verified the certificates as you suggested and they all pass the test. I'm still getting the error though.

      Here's an overview of the servers and what certificates they have:

      Domain A

      - Issuing Root CA (Has its own self signed cert since its the CA and has the cert in the trusted root cert list)
      - NPS (Has a cert from Root CA in Domain A, has a the root CA in Domain A in its trusted root cert list)

      Domain B
      - Issuing Subordinate Root CA (Has a subordinate cert issued by Root CA in Domain A, and has its own and Root CA in its trusted root cert list)
      - Client (Has a cert issued by Root CA in Domain B, and has both Root CA in Domain A's cert AND Root CA in Domain B's cert in its trusted root cert list)

      When I run the commands you gave me, I ran it from various points, from the client, verifying the NPS's cert, root ca in both domain A and B. All pass.

      I ran it from the NPS, veryfing the client in domain B, and the root certs from domain A and B, all pass.

      I ran it from Root CA in Domain B, veryfied the client's cert, Root CA in Domain A's cert, all pass.

      Any further ideas? :)


      • Edited by roxythestar Thursday, February 23, 2012 1:11 PM
      •  
       
    • Thursday, February 23, 2012 8:58 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      I'm thinking the problem lies with the subordinate CA somehow. Would my problem maybe be solved if I uninstalled the subordinate CA and made it a root CA so I would have two roots, one in every domain. Then distribute the root certs to all computers in both domains. Do you think this would be more successfull than what I'm currently doing?

      Or maybe the NPS in domain A wouldn't like domain B issued certificates, even if the domain B root is in the NPS trusted root cert list..

      • Edited by roxythestar Thursday, February 23, 2012 9:03 PM
      •  
       
    • Friday, February 24, 2012 6:47 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      What certificate template version do you use for the ClientCert? Isn't it Windows Server 2008 version (the so called v3)? This information you can find in Certificate Templates console - right click the Certificate Templates in the AD CS and select the Manage option.

      Make sure the template used to enroll the ClientCert is Windows 2003 (version 2 only). The EAP/TLS client does not use CNG even on Windows 7 so this is a quite unknown requirement, although I think the error message should be different that case.

      ondrej.

       
    • Friday, February 24, 2012 11:18 AM
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote

      I solved this by doing the following:

      Setting up a NPS in Domain B.

      Configuring the NPS in Domain A so that when a request for Domain B comes in, forward it to NPS in Domain B.

      This seems to work.

      It's not the answer to my problem but it's a way around. I'm suspecting it has something to do with the way NPS and UPN lookups in AD work.


       
    • Friday, February 24, 2012 2:05 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      a) are both the domains in the same forest?

      b) do the client certificates contain the Computer's FQDN (such as comp58.domain.local) or User's UPN (such as kamil@domain.local)?

      ondrej.

       
    • Friday, February 24, 2012 3:27 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      Hello again,

      Yes to both questions.