Andre, The CA is only used in the initial issuing of the certificate. When this is done, the CA essentially signs the certificate. This means that any time this certificate is used for authentication, the authenticating device will see which Certificate Authority was used to issue this certificate. If this particular CA is trusted by the authentication server (I.e. The authenticating device has this CA¹s certificate chain in its trusted root store and it trusts all additional intermediate or root CA¹s in the CA¹s certificate chain); then it will trust that the certificate being used to authenticate the device/user is in fact a valid certificate. No additional querying is needed to the CA. Now whether there is a query to validate that the device is in fact enrolled into the domain is a different story (if it is, there should be a copy of the certificate stored with the device/user profile in AD and AD should return with the group membership that the authentication server can use to determine the authorization of the device/user), but the CA itself should not be queried.
A PKI is built simply on a foundation of trust. If both the device/user being authenticated and the authentication server all trust the certificate authorities that issued each certificate, and the certificates haven¹t been revoked or expired; then mutual authentication is successful and the device/user will be allowed on the network. As such, no queries should go back to the issuing CA. The only time you should see communication between the CA and the authentication server is if a new certificate is being issued or if there is a CRL being released (Certificate Revocation List). When doing EAP-TLS, the biggest issue you will run into is not trusting all of the certificate authorities that may be in a certificate chain. In a lab scenario like yours where there is only one CA, this isn¹t as big an issue. However; in the real world, you might easily have 3, 4 or more certificate authorities, intermediate certificate authorities and root certificate authorities. In order to get authentication to work, the authentication server and the supplicant must trust all of the CAs involved on either side. Hope this clears things up a bit. Thanks, Jeff From: Andre Aubet <[email protected]> Date: Sunday, May 18, 2014 at 12:39 PM To: "[email protected]" <[email protected]> Subject: [OSL | CCIE_Wireless] EAP-TLS and Active Directory Hi all! I'm working on EAP-TLS using a DC and CA in an Active Directory domain. No problem to import certificates both on the controller and the client, and authentication works fine. However, I'm not sure of the complete process used by the controller, the client, and the role of the AD Domain Controller. In my setup, the AD DC is used as a CA, and delivers certificates for the controller and the client. These certificates are used by both side to verify the identity, and encrypt data. I can't figure out if, at any point, the CA is interrogated by the controller or the client (except for the certificate request). Especially when I check the box "Check against CA certificates". I would expect my controller to actively interrogate the CA to check the CA or client certificate. However, when I capture traffic on my CA, I can't see any traffic coming from the controller. Can someone clarify this option? And maybe explain if the CA is interrogated and how? Andre. _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
