Security

Hey,

It sounds like you're hitting a snag with EAP-TLS authentication using certificates deployed via Intune and CloudPKI, while certificates from your on-premises CA work fine. The "client did not complete EAP transaction" error in ClearPass often points to a breakdown in the EAP-TLS handshake, and since your locally generated certificates work, the issue likely lies in how the CloudPKI certificates are being issued, configured, or trusted. Let's break this down step-by-step to pinpoint the problem.

First, since the certificates (personal and trusted root) are showing up on the PC, deployment via Intune seems to be working. However, the failure during authentication suggests the client (PC) or ClearPass isn't happy with something in the certificate chain or the TLS negotiation. The fact that on-premises CA certificates work is a big clue-there's likely a difference in the certificate properties or the trust setup between the two scenarios.

One common culprit is the certificate itself. EAP-TLS requires the client certificate to have specific attributes, like the correct Enhanced Key Usage (EKU) for client authentication (OID 1.3.6.1.5.5.7.3.2). If CloudPKI isn't setting this properly, the handshake could fail. Check the personal certificate on the PC deployed via Intune-open it in the Windows Certificate Manager (certmgr.msc), go to the Details tab, and look at the EKU field. Compare it to the working on-premises certificate. If the CloudPKI cert is missing this or has an unexpected EKU, that could be the issue.

Next, consider the Subject Name or Subject Alternative Name (SAN) in the certificate. ClearPass might be expecting a specific format (e.g., hostname, device ID, or UPN) to match its policy rules. If Intune/CloudPKI is generating a certificate with a different naming convention than your on-premises CA, ClearPass might reject it or the client might not present it correctly. Again, compare the Subject and SAN fields between the two certificates.

The trust chain is another area to dig into. You mentioned the root CA and intermediate CA are in ClearPass's trusted list-double-check that they're enabled and that the exact same root and intermediate certs deployed to the PC match what's in ClearPass. Even a slight mismatch (different issuance date, serial number, or version) can break trust. Export the root and intermediate certs from the PC (via certmgr.msc) and compare their thumbprints to what's in ClearPass under Administration > Certificates > Trust List. Also, ensure the intermediate CA is properly chained-sometimes CloudPKI setups miss including the intermediate in the client's certificate store or the chain isn't sent during the handshake.

Speaking of the handshake, the client might not trust ClearPass's RADIUS certificate. Even though you're focused on client auth, EAP-TLS is mutual-ClearPass presents its cert to the PC too. If the PC doesn't trust it (e.g., missing the RADIUS server's issuing CA in the PC's Trusted Root store), the client could abort the transaction. When you used the on-premises CA, the PC likely already trusted the entire chain from prior config. Check the ClearPass RADIUS cert (under Administration > Certificates > Server Certificate) and ensure its issuing CA is in the PC's Trusted Root store when using CloudPKI.

TLS version mismatch is another possibility. Windows defaults to negotiating the highest TLS version supported (often 1.2 or 1.3), but ClearPass or your network gear might be stuck on an older version (like 1.0 or 1.1) or vice versa. The on-premises setup might have aligned versions by chance. You can test this by forcing the PC to use TLS 1.2 (via registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13, add DWORD TlsVersion = 0xC0, then reboot) and see if it changes the behavior.

Finally, peek at the ClearPass logs for more detail. In Monitoring > Live Monitoring > Access Tracker, find a failed attempt, click it, and check the logs tab at the bottom. Look for specific errors like "TLS handshake failed," "certificate rejected," or timeout codes (e.g., 9002). This can narrow down whether it's a client-side issue (e.g., not sending the cert) or a server-side rejection.

Since the on-premises certs work, a quick test could be to mimic that setup with CloudPKI-match the EKU, SAN, and chain as closely as possible in Intune's certificate profile. If that still fails, packet capture the handshake (Wireshark on the PC, filter for EAP) and look at the Client Hello and Server Hello to see where it drops-certificate issues often show up as an "Alert" message from the client.

My gut says it's either an EKU mismatch or a trust issue with the CloudPKI chain not aligning perfectly with ClearPass's expectations. Start with the certificate properties and work outward from there. Let me know what you find in the certs or logs, and we can zero in further!

Regards

Rupesh Mishra

Hey,

It sounds like you're hitting a snag with EAP-TLS authentication using certificates deployed via Intune and CloudPKI, while certificates from your on-premises CA work fine. The "client did not complete EAP transaction" error in ClearPass often points to a breakdown in the EAP-TLS handshake, and since your locally generated certificates work, the issue likely lies in how the CloudPKI certificates are being issued, configured, or trusted. Let's break this down step-by-step to pinpoint the problem.

First, since the certificates (personal and trusted root) are showing up on the PC, deployment via Intune seems to be working. However, the failure during authentication suggests the client (PC) or ClearPass isn't happy with something in the certificate chain or the TLS negotiation. The fact that on-premises CA certificates work is a big clue-there's likely a difference in the certificate properties or the trust setup between the two scenarios.

One common culprit is the certificate itself. EAP-TLS requires the client certificate to have specific attributes, like the correct Enhanced Key Usage (EKU) for client authentication (OID 1.3.6.1.5.5.7.3.2). If CloudPKI isn't setting this properly, the handshake could fail. Check the personal certificate on the PC deployed via Intune-open it in the Windows Certificate Manager (certmgr.msc), go to the Details tab, and look at the EKU field. Compare it to the working on-premises certificate. If the CloudPKI cert is missing this or has an unexpected EKU, that could be the issue.

Next, consider the Subject Name or Subject Alternative Name (SAN) in the certificate. ClearPass might be expecting a specific format (e.g., hostname, device ID, or UPN) to match its policy rules. If Intune/CloudPKI is generating a certificate with a different naming convention than your on-premises CA, ClearPass might reject it or the client might not present it correctly. Again, compare the Subject and SAN fields between the two certificates.

The trust chain is another area to dig into. You mentioned the root CA and intermediate CA are in ClearPass's trusted list-double-check that they're enabled and that the exact same root and intermediate certs deployed to the PC match what's in ClearPass. Even a slight mismatch (different issuance date, serial number, or version) can break trust. Export the root and intermediate certs from the PC (via certmgr.msc) and compare their thumbprints to what's in ClearPass under Administration > Certificates > Trust List. Also, ensure the intermediate CA is properly chained-sometimes CloudPKI setups miss including the intermediate in the client's certificate store or the chain isn't sent during the handshake.

Speaking of the handshake, the client might not trust ClearPass's RADIUS certificate. Even though you're focused on client auth, EAP-TLS is mutual-ClearPass presents its cert to the PC too. If the PC doesn't trust it (e.g., missing the RADIUS server's issuing CA in the PC's Trusted Root store), the client could abort the transaction. When you used the on-premises CA, the PC likely already trusted the entire chain from prior config. Check the ClearPass RADIUS cert (under Administration > Certificates > Server Certificate) and ensure its issuing CA is in the PC's Trusted Root store when using CloudPKI.

TLS version mismatch is another possibility. Windows defaults to negotiating the highest TLS version supported (often 1.2 or 1.3), but ClearPass or your network gear might be stuck on an older version (like 1.0 or 1.1) or vice versa. The on-premises setup might have aligned versions by chance. You can test this by forcing the PC to use TLS 1.2 (via registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13, add DWORD TlsVersion = 0xC0, then reboot) and see if it changes the behavior.

Finally, peek at the ClearPass logs for more detail. In Monitoring > Live Monitoring > Access Tracker, find a failed attempt, click it, and check the logs tab at the bottom. Look for specific errors like "TLS handshake failed," "certificate rejected," or timeout codes (e.g., 9002). This can narrow down whether it's a client-side issue (e.g., not sending the cert) or a server-side rejection.

Since the on-premises certs work, a quick test could be to mimic that setup with CloudPKI-match the EKU, SAN, and chain as closely as possible in Intune's certificate profile. If that still fails, packet capture the handshake (Wireshark on the PC, filter for EAP) and look at the Client Hello and Server Hello to see where it drops-certificate issues often show up as an "Alert" message from the client.

My gut says it's either an EKU mismatch or a trust issue with the CloudPKI chain not aligning perfectly with ClearPass's expectations. Start with the certificate properties and work outward from there. Let me know what you find in the certs or logs, and we can zero in further!

Regards

Rupesh Mishra

Hey,

It sounds like you're hitting a snag with EAP-TLS authentication using certificates deployed via Intune and CloudPKI, while certificates from your on-premises CA work fine. The "client did not complete EAP transaction" error in ClearPass often points to a breakdown in the EAP-TLS handshake, and since your locally generated certificates work, the issue likely lies in how the CloudPKI certificates are being issued, configured, or trusted. Let's break this down step-by-step to pinpoint the problem.

First, since the certificates (personal and trusted root) are showing up on the PC, deployment via Intune seems to be working. However, the failure during authentication suggests the client (PC) or ClearPass isn't happy with something in the certificate chain or the TLS negotiation. The fact that on-premises CA certificates work is a big clue-there's likely a difference in the certificate properties or the trust setup between the two scenarios.

One common culprit is the certificate itself. EAP-TLS requires the client certificate to have specific attributes, like the correct Enhanced Key Usage (EKU) for client authentication (OID 1.3.6.1.5.5.7.3.2). If CloudPKI isn't setting this properly, the handshake could fail. Check the personal certificate on the PC deployed via Intune-open it in the Windows Certificate Manager (certmgr.msc), go to the Details tab, and look at the EKU field. Compare it to the working on-premises certificate. If the CloudPKI cert is missing this or has an unexpected EKU, that could be the issue.

Next, consider the Subject Name or Subject Alternative Name (SAN) in the certificate. ClearPass might be expecting a specific format (e.g., hostname, device ID, or UPN) to match its policy rules. If Intune/CloudPKI is generating a certificate with a different naming convention than your on-premises CA, ClearPass might reject it or the client might not present it correctly. Again, compare the Subject and SAN fields between the two certificates.

The trust chain is another area to dig into. You mentioned the root CA and intermediate CA are in ClearPass's trusted list-double-check that they're enabled and that the exact same root and intermediate certs deployed to the PC match what's in ClearPass. Even a slight mismatch (different issuance date, serial number, or version) can break trust. Export the root and intermediate certs from the PC (via certmgr.msc) and compare their thumbprints to what's in ClearPass under Administration > Certificates > Trust List. Also, ensure the intermediate CA is properly chained-sometimes CloudPKI setups miss including the intermediate in the client's certificate store or the chain isn't sent during the handshake.

Speaking of the handshake, the client might not trust ClearPass's RADIUS certificate. Even though you're focused on client auth, EAP-TLS is mutual-ClearPass presents its cert to the PC too. If the PC doesn't trust it (e.g., missing the RADIUS server's issuing CA in the PC's Trusted Root store), the client could abort the transaction. When you used the on-premises CA, the PC likely already trusted the entire chain from prior config. Check the ClearPass RADIUS cert (under Administration > Certificates > Server Certificate) and ensure its issuing CA is in the PC's Trusted Root store when using CloudPKI.

TLS version mismatch is another possibility. Windows defaults to negotiating the highest TLS version supported (often 1.2 or 1.3), but ClearPass or your network gear might be stuck on an older version (like 1.0 or 1.1) or vice versa. The on-premises setup might have aligned versions by chance. You can test this by forcing the PC to use TLS 1.2 (via registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13, add DWORD TlsVersion = 0xC0, then reboot) and see if it changes the behavior.

Finally, peek at the ClearPass logs for more detail. In Monitoring > Live Monitoring > Access Tracker, find a failed attempt, click it, and check the logs tab at the bottom. Look for specific errors like "TLS handshake failed," "certificate rejected," or timeout codes (e.g., 9002). This can narrow down whether it's a client-side issue (e.g., not sending the cert) or a server-side rejection.

Since the on-premises certs work, a quick test could be to mimic that setup with CloudPKI-match the EKU, SAN, and chain as closely as possible in Intune's certificate profile. If that still fails, packet capture the handshake (Wireshark on the PC, filter for EAP) and look at the Client Hello and Server Hello to see where it drops-certificate issues often show up as an "Alert" message from the client.

My gut says it's either an EKU mismatch or a trust issue with the CloudPKI chain not aligning perfectly with ClearPass's expectations. Start with the certificate properties and work outward from there. Let me know what you find in the certs or logs, and we can zero in further!

Regards

Rupesh Mishra

Hey,

It sounds like you're hitting a snag with EAP-TLS authentication using certificates deployed via Intune and CloudPKI, while certificates from your on-premises CA work fine. The "client did not complete EAP transaction" error in ClearPass often points to a breakdown in the EAP-TLS handshake, and since your locally generated certificates work, the issue likely lies in how the CloudPKI certificates are being issued, configured, or trusted. Let's break this down step-by-step to pinpoint the problem.

First, since the certificates (personal and trusted root) are showing up on the PC, deployment via Intune seems to be working. However, the failure during authentication suggests the client (PC) or ClearPass isn't happy with something in the certificate chain or the TLS negotiation. The fact that on-premises CA certificates work is a big clue-there's likely a difference in the certificate properties or the trust setup between the two scenarios.

One common culprit is the certificate itself. EAP-TLS requires the client certificate to have specific attributes, like the correct Enhanced Key Usage (EKU) for client authentication (OID 1.3.6.1.5.5.7.3.2). If CloudPKI isn't setting this properly, the handshake could fail. Check the personal certificate on the PC deployed via Intune-open it in the Windows Certificate Manager (certmgr.msc), go to the Details tab, and look at the EKU field. Compare it to the working on-premises certificate. If the CloudPKI cert is missing this or has an unexpected EKU, that could be the issue.

Next, consider the Subject Name or Subject Alternative Name (SAN) in the certificate. ClearPass might be expecting a specific format (e.g., hostname, device ID, or UPN) to match its policy rules. If Intune/CloudPKI is generating a certificate with a different naming convention than your on-premises CA, ClearPass might reject it or the client might not present it correctly. Again, compare the Subject and SAN fields between the two certificates.

The trust chain is another area to dig into. You mentioned the root CA and intermediate CA are in ClearPass's trusted list-double-check that they're enabled and that the exact same root and intermediate certs deployed to the PC match what's in ClearPass. Even a slight mismatch (different issuance date, serial number, or version) can break trust. Export the root and intermediate certs from the PC (via certmgr.msc) and compare their thumbprints to what's in ClearPass under Administration > Certificates > Trust List. Also, ensure the intermediate CA is properly chained-sometimes CloudPKI setups miss including the intermediate in the client's certificate store or the chain isn't sent during the handshake.

Speaking of the handshake, the client might not trust ClearPass's RADIUS certificate. Even though you're focused on client auth, EAP-TLS is mutual-ClearPass presents its cert to the PC too. If the PC doesn't trust it (e.g., missing the RADIUS server's issuing CA in the PC's Trusted Root store), the client could abort the transaction. When you used the on-premises CA, the PC likely already trusted the entire chain from prior config. Check the ClearPass RADIUS cert (under Administration > Certificates > Server Certificate) and ensure its issuing CA is in the PC's Trusted Root store when using CloudPKI.

TLS version mismatch is another possibility. Windows defaults to negotiating the highest TLS version supported (often 1.2 or 1.3), but ClearPass or your network gear might be stuck on an older version (like 1.0 or 1.1) or vice versa. The on-premises setup might have aligned versions by chance. You can test this by forcing the PC to use TLS 1.2 (via registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13, add DWORD TlsVersion = 0xC0, then reboot) and see if it changes the behavior.

Finally, peek at the ClearPass logs for more detail. In Monitoring > Live Monitoring > Access Tracker, find a failed attempt, click it, and check the logs tab at the bottom. Look for specific errors like "TLS handshake failed," "certificate rejected," or timeout codes (e.g., 9002). This can narrow down whether it's a client-side issue (e.g., not sending the cert) or a server-side rejection.

Since the on-premises certs work, a quick test could be to mimic that setup with CloudPKI-match the EKU, SAN, and chain as closely as possible in Intune's certificate profile. If that still fails, packet capture the handshake (Wireshark on the PC, filter for EAP) and look at the Client Hello and Server Hello to see where it drops-certificate issues often show up as an "Alert" message from the client.

My gut says it's either an EKU mismatch or a trust issue with the CloudPKI chain not aligning perfectly with ClearPass's expectations. Start with the certificate properties and work outward from there. Let me know what you find in the certs or logs, and we can zero in further!

Regards

Rupesh Mishra

Hey,

It sounds like you're hitting a snag with EAP-TLS authentication using certificates deployed via Intune and CloudPKI, while certificates from your on-premises CA work fine. The "client did not complete EAP transaction" error in ClearPass often points to a breakdown in the EAP-TLS handshake, and since your locally generated certificates work, the issue likely lies in how the CloudPKI certificates are being issued, configured, or trusted. Let's break this down step-by-step to pinpoint the problem.

First, since the certificates (personal and trusted root) are showing up on the PC, deployment via Intune seems to be working. However, the failure during authentication suggests the client (PC) or ClearPass isn't happy with something in the certificate chain or the TLS negotiation. The fact that on-premises CA certificates work is a big clue-there's likely a difference in the certificate properties or the trust setup between the two scenarios.

One common culprit is the certificate itself. EAP-TLS requires the client certificate to have specific attributes, like the correct Enhanced Key Usage (EKU) for client authentication (OID 1.3.6.1.5.5.7.3.2). If CloudPKI isn't setting this properly, the handshake could fail. Check the personal certificate on the PC deployed via Intune-open it in the Windows Certificate Manager (certmgr.msc), go to the Details tab, and look at the EKU field. Compare it to the working on-premises certificate. If the CloudPKI cert is missing this or has an unexpected EKU, that could be the issue.

Next, consider the Subject Name or Subject Alternative Name (SAN) in the certificate. ClearPass might be expecting a specific format (e.g., hostname, device ID, or UPN) to match its policy rules. If Intune/CloudPKI is generating a certificate with a different naming convention than your on-premises CA, ClearPass might reject it or the client might not present it correctly. Again, compare the Subject and SAN fields between the two certificates.

The trust chain is another area to dig into. You mentioned the root CA and intermediate CA are in ClearPass's trusted list-double-check that they're enabled and that the exact same root and intermediate certs deployed to the PC match what's in ClearPass. Even a slight mismatch (different issuance date, serial number, or version) can break trust. Export the root and intermediate certs from the PC (via certmgr.msc) and compare their thumbprints to what's in ClearPass under Administration > Certificates > Trust List. Also, ensure the intermediate CA is properly chained-sometimes CloudPKI setups miss including the intermediate in the client's certificate store or the chain isn't sent during the handshake.

Speaking of the handshake, the client might not trust ClearPass's RADIUS certificate. Even though you're focused on client auth, EAP-TLS is mutual-ClearPass presents its cert to the PC too. If the PC doesn't trust it (e.g., missing the RADIUS server's issuing CA in the PC's Trusted Root store), the client could abort the transaction. When you used the on-premises CA, the PC likely already trusted the entire chain from prior config. Check the ClearPass RADIUS cert (under Administration > Certificates > Server Certificate) and ensure its issuing CA is in the PC's Trusted Root store when using CloudPKI.

TLS version mismatch is another possibility. Windows defaults to negotiating the highest TLS version supported (often 1.2 or 1.3), but ClearPass or your network gear might be stuck on an older version (like 1.0 or 1.1) or vice versa. The on-premises setup might have aligned versions by chance. You can test this by forcing the PC to use TLS 1.2 (via registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13, add DWORD TlsVersion = 0xC0, then reboot) and see if it changes the behavior.

Finally, peek at the ClearPass logs for more detail. In Monitoring > Live Monitoring > Access Tracker, find a failed attempt, click it, and check the logs tab at the bottom. Look for specific errors like "TLS handshake failed," "certificate rejected," or timeout codes (e.g., 9002). This can narrow down whether it's a client-side issue (e.g., not sending the cert) or a server-side rejection.

Since the on-premises certs work, a quick test could be to mimic that setup with CloudPKI-match the EKU, SAN, and chain as closely as possible in Intune's certificate profile. If that still fails, packet capture the handshake (Wireshark on the PC, filter for EAP) and look at the Client Hello and Server Hello to see where it drops-certificate issues often show up as an "Alert" message from the client.

My gut says it's either an EKU mismatch or a trust issue with the CloudPKI chain not aligning perfectly with ClearPass's expectations. Start with the certificate properties and work outward from there. Let me know what you find in the certs or logs, and we can zero in further!

Regards

Rupesh Mishra

Hey,

It sounds like you're hitting a snag with EAP-TLS authentication using certificates deployed via Intune and CloudPKI, while certificates from your on-premises CA work fine. The "client did not complete EAP transaction" error in ClearPass often points to a breakdown in the EAP-TLS handshake, and since your locally generated certificates work, the issue likely lies in how the CloudPKI certificates are being issued, configured, or trusted. Let's break this down step-by-step to pinpoint the problem.

First, since the certificates (personal and trusted root) are showing up on the PC, deployment via Intune seems to be working. However, the failure during authentication suggests the client (PC) or ClearPass isn't happy with something in the certificate chain or the TLS negotiation. The fact that on-premises CA certificates work is a big clue-there's likely a difference in the certificate properties or the trust setup between the two scenarios.

One common culprit is the certificate itself. EAP-TLS requires the client certificate to have specific attributes, like the correct Enhanced Key Usage (EKU) for client authentication (OID 1.3.6.1.5.5.7.3.2). If CloudPKI isn't setting this properly, the handshake could fail. Check the personal certificate on the PC deployed via Intune-open it in the Windows Certificate Manager (certmgr.msc), go to the Details tab, and look at the EKU field. Compare it to the working on-premises certificate. If the CloudPKI cert is missing this or has an unexpected EKU, that could be the issue.

Next, consider the Subject Name or Subject Alternative Name (SAN) in the certificate. ClearPass might be expecting a specific format (e.g., hostname, device ID, or UPN) to match its policy rules. If Intune/CloudPKI is generating a certificate with a different naming convention than your on-premises CA, ClearPass might reject it or the client might not present it correctly. Again, compare the Subject and SAN fields between the two certificates.

The trust chain is another area to dig into. You mentioned the root CA and intermediate CA are in ClearPass's trusted list-double-check that they're enabled and that the exact same root and intermediate certs deployed to the PC match what's in ClearPass. Even a slight mismatch (different issuance date, serial number, or version) can break trust. Export the root and intermediate certs from the PC (via certmgr.msc) and compare their thumbprints to what's in ClearPass under Administration > Certificates > Trust List. Also, ensure the intermediate CA is properly chained-sometimes CloudPKI setups miss including the intermediate in the client's certificate store or the chain isn't sent during the handshake.

Speaking of the handshake, the client might not trust ClearPass's RADIUS certificate. Even though you're focused on client auth, EAP-TLS is mutual-ClearPass presents its cert to the PC too. If the PC doesn't trust it (e.g., missing the RADIUS server's issuing CA in the PC's Trusted Root store), the client could abort the transaction. When you used the on-premises CA, the PC likely already trusted the entire chain from prior config. Check the ClearPass RADIUS cert (under Administration > Certificates > Server Certificate) and ensure its issuing CA is in the PC's Trusted Root store when using CloudPKI.

TLS version mismatch is another possibility. Windows defaults to negotiating the highest TLS version supported (often 1.2 or 1.3), but ClearPass or your network gear might be stuck on an older version (like 1.0 or 1.1) or vice versa. The on-premises setup might have aligned versions by chance. You can test this by forcing the PC to use TLS 1.2 (via registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13, add DWORD TlsVersion = 0xC0, then reboot) and see if it changes the behavior.

Finally, peek at the ClearPass logs for more detail. In Monitoring > Live Monitoring > Access Tracker, find a failed attempt, click it, and check the logs tab at the bottom. Look for specific errors like "TLS handshake failed," "certificate rejected," or timeout codes (e.g., 9002). This can narrow down whether it's a client-side issue (e.g., not sending the cert) or a server-side rejection.

Since the on-premises certs work, a quick test could be to mimic that setup with CloudPKI-match the EKU, SAN, and chain as closely as possible in Intune's certificate profile. If that still fails, packet capture the handshake (Wireshark on the PC, filter for EAP) and look at the Client Hello and Server Hello to see where it drops-certificate issues often show up as an "Alert" message from the client.

My gut says it's either an EKU mismatch or a trust issue with the CloudPKI chain not aligning perfectly with ClearPass's expectations. Start with the certificate properties and work outward from there. Let me know what you find in the certs or logs, and we can zero in further!

Regards

Rupesh Mishra