Are you using ClearPass from HPE Aruba Networking with PKI services where the root CA certificate will need to be renewed in the future?

In this case, you need to know the following about how ClearPass handles multiple CA certificates with the same common name. This is not documented in the ClearPass documentation and the outcome also depends on whether the CA certificate is an intermediate or root certificate.

The worst case scenario is that a renewal of the internal root CA certificate is done by a PKI admin. The new CA certificate is sent to the ClearPass administrator who in turn installs it in ClearPass and EAP-TLS suddenly stops working.
Another outcome of the above is that the validation of old certificates still works, but no newly issued certificates with the new root certificate can authenticate.

The problem is that currently ClearPass will evaluate all trusted intermediate CA certificates with the same common name, but only one of the root certificates if there is more than one certificate installed.

To solve this problem, I have submitted a feature request in Aruba’s Innovation Zone that all root certificates should be included in the evaluation of the certificate chain:

If you think this is an important change in the behavior of ClearPass, go to the link above and vote for the proposal!

Below is an in-depth look at the aspects of the problem, mainly from the perspective of medium-sized enterprises.

Many private PKI implementations made over the last 20 years have been made on Windows CA servers and are maintained by the Windows server team. However, the general PKI knowledge among technicians is generally quite low and CA servers can be more or less unattended.

In this situation, it is reasonable to believe that renewing a CA certificate will be done in the simplest way in Windows, i.e. just renew the CA certificate with the wizard in the CA server’s admin interface. This process will create a fresh new certificate with a new key pair. It is also reasonable to think that not too many customers have a full test environment with PKI, Active Directory, ClearPass and other equipment to test. More commonly, some parts of the infrastructure are shared.

A renewal of an intermediate CA may have already taken place within an organization and a new CA certificate has been successfully installed in ClearPass and the validation has been confirmed to work well.

If the root certificate is due to expire and is renewed with the CA renewal function, the new root will have the same common name but new keys. When the new root certificate is deployed to ClearPass, validation will not be possible with both the old and new root CA certificate. Only one of the certificates will be included in the validation.

Many of the installed root CA servers have never expired yet as they were installed with relatively long validity periods, so this problem will become increasingly common and if the intermediate CA has been renewed, both ClearPass and PKI administrators can be fooled that the renewal of the root will be as smooth as the intermediate renewal was.

Given that PKI knowledge is generally low, renewal is sometimes forgotten and done at the last minute, and the behavior for ClearPass validation of multiple CA certificates with the same common name is not documented, my suggestion is that the behavior should be the same for root certificate validation as it is now for intermediate certificates.

If general PKI recommendations regarding renewal of CA certificates are followed, there will be a need to have two active root certificates for some time. Possibly at least 1-2 years if this is the validity period for client certificates so that all client certificates have time to expire.