Ensure that the issuers of Identity Server and Embedded Service Provider certificates are added to the appropriate trusted root containers.
When the server certificates are sent from the identity provider to the service provider client, and from the service provider to the identity provider client, the client needs to be able to validate the certificates. Part of the validation process is to confirm that the server certificate has been signed by a trusted source. By default, well known external trusted certificates are bundled with Access Manager. You can view this list here: Administration Console > Security > Certificates > External Trusted Roots. If the issuer of server certificate is not present in the External Trusted Root list, the import the issuers of the server certificate (intermediate and trusted roots) into the correct trusted root stores:
The intermediate and trusted roots of the Embedded Service Provider (ESP) certificate must be imported into the NIDP Trust Store.
The intermediate and trusted roots of Identity Server certificate must be imported into the ESP Trust Store.
For more information, see Section 16.5, Importing a Signed Certificate.
If you use certificates generated by Administration Console CA, the trusted root certificate is the same for Identity Server and ESP. If you are using external certificates, the trusted root certificate might not be the same, and there might be intermediate certificates that need to be imported.
To verify the trusted root certificates:
Click Security > Certificates.
Determine the issuer of Identity Server certificate and the ESP certificate:
Click the Identity Server certificate, note the name of the Issuer, then click Close.
Click the ESP certificate of Access Gateway, note the name of the Issuer, then click Close.
(Conditional) If you do not know the names of these certificates, see Certificate Names.
To verify the trusted root for Identity Server, click Devices> Identity Servers > Edit > Security > NIDP Trust Store.
In the Trusted Roots section, scan for a certificate subject that matches the issuer of the ESP certificate, then click its name.
If the Issuer has the same name as the Subject name, then this certificate is the root certificate.
If the Issuer has a different name than the Subject name, the certificate is an intermediate certificate in the chain. Click Close, and ensure that another certificate in the trust store is the root certificate. If it isn’t there, you need to import it and any other intermediate certificates between the one you have and the root certificate.
To verify the trusted root for ESP, click Devices > Access Gateways > Edit > Service Provider Certificates > Trusted Roots.
In the Trusted Roots section, scan for a certificate subject that matches the issuer of Identity Server certificate, then click its name.
If the Issuer has the same name as the Subject name, then this certificate is the root certificate.
If the Issuer has a different name than the Subject name, the certificate is an intermediate certificate in the chain. Click Close, and ensure that another certificate in the trust store is the root certificate. If it isn’t there, you need to import it and any other intermediate certificates between the one you have and the root certificate.
(Optional) If you have clustered your Identity Servers and Access Gateways and you are concerned that not all members of the cluster are using the correct trusted root certificates, you can re-push the certificates to the cluster members.
Click Troubleshooting > Certificates.
Select the Trust Store of your Identity Servers and Access Gateways, and click Re-push certificates.
Update the Identity Severs and Access Gateways.
Check the command status of each device to ensure that the certificate was pushed to the device. From Identity Servers page or Access Gateways page, click the Commands link.
To view sample log entries that are logged to the catalina.out file when a trusted root certificate is missing, see Trusted Roots Are Not Imported into the Appropriate Trusted Root Containers.