Cannot replace expired certificates used by SAML2 SP when signing cert per SAML SP is enabled

  • 7017837
  • 12-Jul-2016
  • 12-Jul-2016


NetIQ Access Manager 4.2
NetIQ Access Manager 4.1
NetIQ Access Manager 4.0
Access Manager Identity Server
SAML2 Service Providers enabled with different signing cert per SP


When assigning a different signing cert per SAML SP, the UI provides a drop down menu to select the cert you want to add for use per SAML2 SP. The certificate in the NIDP signing keystore is the one that is used by 'All remaining SPs', but a list of available certificates which may be used by specific SAML2 SPs is also shown.

This all works fine when adding a certificate from scratch - but not when an already existing certificate is about to expire. In one specific customer environment, they had specified their own certificate that is marked with Used By All Remaining SPs eg. cert1. The test-signing is still in the Certificates list, it is just not used by any SP’s. The cert1 certificate expired and they added a new one to the list called cert2. They switched all of the SP’s over to the valid cert2 certificate. Now they want to remove the expired certificate, cert1, but when they go to the certificates list the checkbox to click on so they can remove it is greyed out. There is no visible way of replacing the expired certificate.


The iManager UI does not allow this to be done easily and an issue has been raised with the product team. To workaround the issue:

- clicking the ‘replace’ option to replace the default cert … the replace should really be ‘replace default singing cert’.
- add the new certificate you want to use. After performing the initial step above, the ‘used by’ ‘All Service Providers’ flag will change and the UI should allow the replacement.

Note too that in one environment, a further problem was identified ... we thought we had got around the UI restriction by exporting and reimporting the cert with a new alias. This did indeed allow us to select the new cert via the new alias to replace the default signing cert. Unfortunately, the configuration update then Failed with a message about being unable to read the keystore.

We had to manually re-push the keystore from the Troubleshooting tab (even though the Command status had suggested that the previous config had already successfully pushed the certs). Only then did everything finally work.