locked
Any way to tell which client side computer certificate does NPS Server use for validating ? RRS feed

  • Question

  • Hello All,

    We are currently using EAP-TLS  Microsoft:Smart Card or certificates" as the Authentication Method on our Radius/NPS server for authenticating domain laptops to be enable to connect to corporate wireless network. 

    We have a Windows 2003 Root& Issuing CA which has published computer certificates to all the domain laptops/workstations. We have also setup a parallel PKI ( Root and Issuing CA) setup on Windows 2012 OS in the same domain. 

    This Windows 2012 ISsuing CA has also deployed computer certificates to a cpl of testing domain workstations.  So the end result, each of these testing workstations has  2 computer certificates in its PERSONAL Store (1) One issued by the Windows 2003 CA (2) Other cert issued by the Windows 2012 CA.

    How do we know when connecting to corporate wireless, which client computer cert out of the 2 does the RADIUS/NPS server look at and thereby authenticate the workstation ?  Reason i am asking is, at times we are noticing  the RADIUS Server which  itself is using the a computer certificate issued by the new Windows 2012 CA  as its "proof of identity"  is able to authenticate those client workstations successfully which have both the computer certs as mentioned above in their respective personal store.

    What is weird is ,  as a test i deleted the certificate issued by Windows 2012 CA from the personal certificate store of that laptop and it was still able to connect successfully even though it NOW was left with a cert issued by old Windows 2003 CA.   This technically shouldn't work because the chain of trust isn't the same.


    • Edited by Neeraj_Shah Tuesday, February 3, 2015 8:18 PM typo
    Tuesday, February 3, 2015 8:11 PM

Answers

  • You only deleted the client cert. The new Root CA is still in the truated root CA store, so, of course, the connection succeeds. It always comes down to root trust. There is no requirement that the client and server use certs with the same CA chain.

    When the clients received a cert from the "new" CA, they now added a new root CA to the trusted store.

    Brian

    • Proposed as answer by Brian Komar [MVP] Tuesday, February 3, 2015 10:06 PM
    • Marked as answer by Neeraj_Shah Wednesday, February 4, 2015 3:07 PM
    Tuesday, February 3, 2015 10:06 PM
  • I personally do not use GPO for publication of trusted root certs. I use certutil -dspublish -f RootCert.crt

    This allows removal of a root certificate by using the pkiview.msc console (View AD containers and delete the root cert from the AIA container and the Certification Authorities container). But, I would not jump the gun until you are *positive* that all new certs are issued.

    If you were to create a new client authentication certificate template, you could set it to supercede the previous certificate (allowing a cleaner replacement). But, if you remove the old CA from the root trust, the chaining engine would no longer select a non-trusted chain at authentication time.

    Brian

    P.S. The removal could take some hours, as the GPO mechanism is used to establish root trust (even though the certs are not directly defined in GPO

    • Proposed as answer by Brian Komar [MVP] Wednesday, February 4, 2015 4:10 AM
    • Marked as answer by Neeraj_Shah Wednesday, February 4, 2015 3:07 PM
    Wednesday, February 4, 2015 4:10 AM

All replies

  • On Tue, 3 Feb 2015 20:11:39 +0000, Neeraj_Shah wrote:

    What is weird is ,  as a test i deleted the certificate issued by Windows 2012 CA from the personal certificate store of that laptop and it was still able to connect successfully even though it NOW was left with a cert issued by old Windows 2003 CA.   This technically shouldn't work because the chain of trust isn't the same.

    You're confused here. There are two different chain validations happening
    here:

    1. The client validates the server's cert.
    2. The server validates the client's cert.

    There is no need for the server's cert to chain to the same root as the
    client's cert. If the server can validate the client's chain (and its own
    cert has nothing at all to do with this) then the server accepts the client
    cert is valid. If the client can validate the server's cert then the client
    considers the server's cert to be valid.


    Paul Adare - FIM CM MVP
    superglue works better on cats than paste. it sets much faster which is
    important when you are gluing a cat. -- John W. Krahn about 'cat-and-paste'

    Tuesday, February 3, 2015 8:28 PM
  • You only deleted the client cert. The new Root CA is still in the truated root CA store, so, of course, the connection succeeds. It always comes down to root trust. There is no requirement that the client and server use certs with the same CA chain.

    When the clients received a cert from the "new" CA, they now added a new root CA to the trusted store.

    Brian

    • Proposed as answer by Brian Komar [MVP] Tuesday, February 3, 2015 10:06 PM
    • Marked as answer by Neeraj_Shah Wednesday, February 4, 2015 3:07 PM
    Tuesday, February 3, 2015 10:06 PM
  • Thanks Brian. Appreciate your response. 

    Is there any way to delete a particular certificate from ROOT Store on all domain joined workstations ?  

    I am assuming that if we delete our ROOT certificate from "Default Domain Policy -> Computer Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Auth " folder in Group Policy Mgmt,  this will only prevent it from getting published to new laptops/workstations when they join the domain.  Wiill it also delete the cert from the local Trusted Root CA store of  the  existing workstations ?

    Also, is there any automated way to delete client Computer Certificates from the " personal ->Certificates store" of all domain computers/workstations via Group Policy.  If we retire our Windows 2003 Root CA, we ideally wouldnt want any client comp certs issued by it to be hanging on the domain machines.

    Thanks again


    • Edited by Neeraj_Shah Tuesday, February 3, 2015 10:29 PM typo
    Tuesday, February 3, 2015 10:17 PM
  • I personally do not use GPO for publication of trusted root certs. I use certutil -dspublish -f RootCert.crt

    This allows removal of a root certificate by using the pkiview.msc console (View AD containers and delete the root cert from the AIA container and the Certification Authorities container). But, I would not jump the gun until you are *positive* that all new certs are issued.

    If you were to create a new client authentication certificate template, you could set it to supercede the previous certificate (allowing a cleaner replacement). But, if you remove the old CA from the root trust, the chaining engine would no longer select a non-trusted chain at authentication time.

    Brian

    P.S. The removal could take some hours, as the GPO mechanism is used to establish root trust (even though the certs are not directly defined in GPO

    • Proposed as answer by Brian Komar [MVP] Wednesday, February 4, 2015 4:10 AM
    • Marked as answer by Neeraj_Shah Wednesday, February 4, 2015 3:07 PM
    Wednesday, February 4, 2015 4:10 AM
  • Brian,

    I have a question. Please excuse me if this is not related to this question or you need a new one to be opened.

    If we are doing a 2 tier PKI deployment and my root CA is supposed to be offline,  is it necessary to configure AIA and CDP settings on both the servers ( Root CA and as well as Enterprise Issuing CA) ? I noticed that if i dont configure the AIA and CDP on the Ent Issuing CA, i got an error saying  AD CS services could not start because the revocation server is offline.  I then had to manually publish a new CRL on the ROOT CA server and copy it over to the Issuing CA server. It then started the services successfully.


    Thursday, February 5, 2015 4:56 PM