Security

I have an existing 802.1x EAP-TLS solution managed by a SaaS provider that we would like to test alternative solutions for.  Clearpass 802.1x EAP-TLS auth is our next evaluation.  I've configured a service and applied a service certificate, but the client continues to come back with an error code 215:

Essentially the client doesn't trust the certificate being presented by Clearpass.  I've run packet captures and checked the eapol system logs, yet nothing is really clear about what the root cause is.  I've re-issued the certificate with SAN entries for DNS and the CN subject is there.  The service certificate, intermediate, and root CA certs are all in the keychain access app marked as Always Trust.  The JAMF 802.1x profile includes all three of these certs.

My current working theory is that the existing 802.1x profile from JAMF for our current wifi signal is being used rather than the new profile.  When I try to select it by checking WiFi -> Details -> 802.1X, I can see there are multiple profile options to use when authenticating.  

Has anyone dealt with a similar situation where multiple profiles are deployed and certs appear to be untrusted?

When you installed the certificate in ClearPass, did you include any/all intermediates in the certificate chain?  You can include the entire chain, including the root, but that requires more data exchange when setting up the TLS session and is unnecessary.

Windows is the only OS I've found that will automatically check against trusted intermediates, others all require the intermediate be present in the chain with the root set as trusted.

Also, if you are using a service certificate then make sure you've actually specified the service certificate to be used in the service.  Otherwise the RADIUS certificate gets used.

I have an existing 802.1x EAP-TLS solution managed by a SaaS provider that we would like to test alternative solutions for.  Clearpass 802.1x EAP-TLS auth is our next evaluation.  I've configured a service and applied a service certificate, but the client continues to come back with an error code 215:

Essentially the client doesn't trust the certificate being presented by Clearpass.  I've run packet captures and checked the eapol system logs, yet nothing is really clear about what the root cause is.  I've re-issued the certificate with SAN entries for DNS and the CN subject is there.  The service certificate, intermediate, and root CA certs are all in the keychain access app marked as Always Trust.  The JAMF 802.1x profile includes all three of these certs.

My current working theory is that the existing 802.1x profile from JAMF for our current wifi signal is being used rather than the new profile.  When I try to select it by checking WiFi -> Details -> 802.1X, I can see there are multiple profile options to use when authenticating.  

Has anyone dealt with a similar situation where multiple profiles are deployed and certs appear to be untrusted?

I'm not including the entire certificate chain, though I have the option to generate the service cert with the entire chain.  I believe looking at the cert in Clearpass that it only has the direct intermediate CA visible.  I have definitely selected this service certificate for the authentication portion of the service I'm building.

I'll try with the entire cert chain to see if that makes any difference.

When you installed the certificate in ClearPass, did you include any/all intermediates in the certificate chain?  You can include the entire chain, including the root, but that requires more data exchange when setting up the TLS session and is unnecessary.

Windows is the only OS I've found that will automatically check against trusted intermediates, others all require the intermediate be present in the chain with the root set as trusted.

Also, if you are using a service certificate then make sure you've actually specified the service certificate to be used in the service.  Otherwise the RADIUS certificate gets used.

I have an existing 802.1x EAP-TLS solution managed by a SaaS provider that we would like to test alternative solutions for.  Clearpass 802.1x EAP-TLS auth is our next evaluation.  I've configured a service and applied a service certificate, but the client continues to come back with an error code 215:

Essentially the client doesn't trust the certificate being presented by Clearpass.  I've run packet captures and checked the eapol system logs, yet nothing is really clear about what the root cause is.  I've re-issued the certificate with SAN entries for DNS and the CN subject is there.  The service certificate, intermediate, and root CA certs are all in the keychain access app marked as Always Trust.  The JAMF 802.1x profile includes all three of these certs.

My current working theory is that the existing 802.1x profile from JAMF for our current wifi signal is being used rather than the new profile.  When I try to select it by checking WiFi -> Details -> 802.1X, I can see there are multiple profile options to use when authenticating.  

Has anyone dealt with a similar situation where multiple profiles are deployed and certs appear to be untrusted?

I'm not including the entire certificate chain, though I have the option to generate the service cert with the entire chain.  I believe looking at the cert in Clearpass that it only has the direct intermediate CA visible.  I have definitely selected this service certificate for the authentication portion of the service I'm building.

I'll try with the entire cert chain to see if that makes any difference.

When you installed the certificate in ClearPass, did you include any/all intermediates in the certificate chain?  You can include the entire chain, including the root, but that requires more data exchange when setting up the TLS session and is unnecessary.

Windows is the only OS I've found that will automatically check against trusted intermediates, others all require the intermediate be present in the chain with the root set as trusted.

Also, if you are using a service certificate then make sure you've actually specified the service certificate to be used in the service.  Otherwise the RADIUS certificate gets used.

I have an existing 802.1x EAP-TLS solution managed by a SaaS provider that we would like to test alternative solutions for.  Clearpass 802.1x EAP-TLS auth is our next evaluation.  I've configured a service and applied a service certificate, but the client continues to come back with an error code 215:

Essentially the client doesn't trust the certificate being presented by Clearpass.  I've run packet captures and checked the eapol system logs, yet nothing is really clear about what the root cause is.  I've re-issued the certificate with SAN entries for DNS and the CN subject is there.  The service certificate, intermediate, and root CA certs are all in the keychain access app marked as Always Trust.  The JAMF 802.1x profile includes all three of these certs.

My current working theory is that the existing 802.1x profile from JAMF for our current wifi signal is being used rather than the new profile.  When I try to select it by checking WiFi -> Details -> 802.1X, I can see there are multiple profile options to use when authenticating.  

Has anyone dealt with a similar situation where multiple profiles are deployed and certs appear to be untrusted?