You may notice that a certificate is soon to expire on Endpoint Management Server. After obtaining a new certificate, devices no longer connect. Inspecting the logs on the client show that there is now a certificate trust error, even though the new certificate is valid

Working with different types of certificates in Endpoint Management Server and Citrix ADC requires different methods to be used.

SSL Listener:

The SSL Listener Certificate should be from a publicly trusted vendor. It should also have a valid current date and a valid common name also. If these requirements are met, then the SSL Listener Certificate is typically not expected to cause any problems.

There are occasions when the installation of a new SSL Listener Certificate can introduce a problem anyway, even though the three requirements listed above have been met. This can be caused by omitting the new certificate from Citrix ADC, where it might be required also.

Alternatively, uploading a new SSL Listener Certificate as a single certificate (for example, as a 'cer' file or 'pem' file) sometimes results in the server failing to link the full certificate chain as expected. Even re-uploading the root and any intermediate certificates to the server sometimes might not resolve this.
In this scenario, build a PFX file containing all required certificates and upload it (as a keystore file) as the SSL Listener. The PFX file which you build should contain the new public certificate which is the SSL Listener Certificate. Also include the Private Key for the certificate. Include any linked intermediate certificates in this PFX file and (optionally) include the root certificate from the chain. Note that it is not best practice to publish a publicly trusted root certificate on the server along with the SSL Listener but to do so is not expected to introduce a problem.
Whilst it is possible to manually link certificates retrospectively on Citrix ADC, this is not something which can be done on Endpoint Management Server. Instead, using the PFX method of uploading a full keystore helps to ensure that all relevant certificate chain links are built by the server. You can use OpenSSL or alternative methods to work with PFX files.

APNs Certificate:

This certificate for Apple devices is very well documented already, though the best advice of working with this certificate is to 'always' seek to renew the old certificate before it expires. To have to 'replace' this certificate (instead of simply 'renewing' it) can result in a need to re-enrol iOS devices.

SAML Certificate:

It is usually acceptable to work with the in-built certificate, which is included with the server. If changing this certificate for any reason, it is assumed that it is being done for specific reasons, which are understood by the agent carrying out the work. A typical reason to have to work on this certificate is to enable Dual-IDP use cases. This is well documented elsewhere already.

Server Certificate:

You might instead by working with a Server Certificate, perhaps related to some User Certificate which is being deployed to devices. If this certificate is going to expire, then be aware of the following details.
The Server Certificate in question would have been created in the first place by a CSR (Certificate Signing Request) and also the creation of a Private Key, specific for that Server Certificate. If creating a new Server Certificate because the old one is expiring, then the same 'original' CSR can be reused (to retain the same Private Key) or instead a new CSR can be generated (and so a new Private Key becomes created also).
It is important to appreciate the different between working with a 'replacement' certificate (which has a new CSR and Private Key) versus a 'renewed' certificate (which reuses the same, old CSR and so also retains the same, old Private Key).

In summary, if choosing to change to a 'new' certificate (including a new Private Key), then the old certificate chain becomes invalidated when the old certificate does actually expire. This can result in a need to issue new User Certificates, as well as deploying the newly created supporting Certificate Chain for that User Certificate. Bear in mind that previously issued User Certificates will still depend on the old, expired 'chain of trust' certificates if those old expired certificates get created with 'new' instead of 'reused' Private Keys.

New Private Key creation might be mandatory as per your internal security requirements, though this can mean more configuration is required so that the client devices to not experience a break down in trust of the certificate chain at any time.
Alternative, retaining the old Private Key can sometimes be more convenient, though the more long lived that any Private Key is, then perhaps the more at risk of compromise that key becomes.

Problem Cause