Securely configured network devices typically would not connect to a controller that presents an expired or revoked server certificate, although it is possible for them to do so at their own risk. If configured to do so, a network device can contact the appropriate CA to learn of the revocation of a CA-issued server certificate by means of the Certificate Revocation List (CRL) or Online Certificate Status Protocol (OSCP).
You can configure a non-PnP device to use an external CA. PnP-managed devices use the APIC-EM private CA only. In the current release of APIC-EM (1.2.x), a device cannot use both the private CA and an external CA.
It is important to understand that a non-PnP device may use CA-issued certificates without contacting the CA to determine whether the server certificate presented has been revoked. A device performs a revocation cross-check with the external CA only when configured to do so; that is, only when its CRL distribution point (CDP) points to the external CA. Without CRL check enabled, the device simply checks its own internal truststore of valid and/or private CA root certs along with the expiration date of the server cert that the controller presents to it. The device cannot determine whether the external CA that issued the controller cert has revoked that certificate unless the device is configured to check a CRL or to issue an OSCP request to the external CA.
The most likely circumstance under which a controller's server certificate might be revoked would be an explicit request by the controller admin to the external CA to revoke the server certificate. The administrator might issue this request if the controller was stolen or if failed hardware was returned to Cisco without having been processed properly for return. In this situation, it is reasonable to assume that the admin issuing the revocation request would know of the revocation and would take steps to generate and install a new, valid, CA-managed replacement server certificate on the controller or on a replacement controller.
Devices configured to interact with the trusted CA that manages the server certificate should continue to work correctly upon installation of another valid, CA-managed server certificate on the controller. Devices that do not interact with the trusted CA might need to be updated manually as necessary to trust the new server certificate; until this update takes place, these devices may refuse to connect to the controller, and REST API requests that involve these devices may fail.
PnP-managed devices never interact with any CA other than the APIC-EM private CA; therefore, the status of the APIC-EM server certificate is of no consequence to PnP-managed devices. Such devices might respond to a change in status of the private CA server certificate, however, as described in Device-to-Device DMVPN Connections.
If a Northbound REST caller follows best practice and requires a valid server certificate, it would refuse to connect to a controller that presents an invalid server certificate.
The APIC-EM controller itself does NOT interact with any external CA directly; therefore, it has no way to learn of the revocation of its server certificate by an external CA. Note, also, that the controller does not update its server certificate automatically under any circumstances. Replacement of an expired or revoked server certificate requires explicit action on the part of a ROLE_ADMIN user. Thus, it is important for the server admin to monitor GUI notifications and audit logs for PKI-related events.
Invalidation of an intermediary CA certificate in the trustpool bundle is a special case. The controller GUI does notify ROLE_ADMIN users when the trustpool bundle changes, and it provides a button that the admin can click to download and install a new trustpool bundle on the controller. However, the means by which network elements get the new trustpool bundle vary according to how the bundle was installed on those devices. Devices not managed by PnP cannot get the trustpool bundle from the controller, but they may be configured to download a new trustpool bundle from the cloud automatically. PnP-managed devices that got the trustpool bundle from the controller cannot get the new trustpool bundle from the controller, nor can they download it from the cloud, nor can the controller push a new trustpool bundle to these devices. However, as long as the Network Plug and Play-installed trustpool bundle has a valid root CA certificate, those devices will continue to trust the controller after installation of the new trustpool bundle on the controller. The same is true of devices not managed by PnP. Therefore, although best practice recommends manual update of devices with the new trustpool bundle in timely fashion, a change to an intermediary CA is not likely to cause an immediate problem.
The private CA that manages Distributed Multipoint VPN connections does not manage the controller's server certificate. Therefore, it cannot provide revocation status of the controller's server certificate. For more information, see Device-to-Device DMVPN Connections.