Store certificates in database

Problem

Prior to Safewhere*Identify 5.0, certificates are stored in Windows Certificate Store. This was great for developers to work with using the .Net framework, but it’s a big problem that in a cluster, certificates from metadata are only added to the node on which the Admin is used. It is not added to the other node. Also, very often, Admin is not able certificates to LocalMachine/TrustedPeople because of permissions issues.

Terminology

In the context of this article, certificates refer to the public keys of trusted parties only. In other words, signing certificates which contain private keys are still in Windows Certificate Store.

The solution

From Safewhere*Identify 5.0, we have moved all the certificates from Windows Certificate Store to Identify’s database. This change gives us a bunch of advantages:

  • No need to synchronize certificates between nodes.
  • Get rid of the problem of not having enough permission to import certificates to LocalMachine\Trusted People.
  • Make it easier to implement a management UI and REST API because it is now easier to know what certificates belong to what tenants.

How do I use this new feature

Both newly created 5.0 tenants and upgraded tenants from previous versions will use this new feature by default. However, for upgraded tenants, you will need to do one manual step to import existing certificates from Windows Certificate Store to tenants’ databases as follow:

  1. Go to System Setup -> Manage Certificates tab
  2. Select the Certificate drop down menu -> Import from Windows Store


Manage Certificates

The Manage Certificates UI is also the place where you view detail, delete, or import a new certificate to your tenant’s database.

In addition, we also provide REST API for all the above actions. Please refer to our REST API documentation for more details.

Note: In use certificates cannot be deleted via Manage Certificates tab in Identify*Admin, use the DELETE method in REST API instead.

Other changes

Storing certificates in database led to a few other changes:

On the Upload metadata screen, we renamed the option “Accept untrusted certificates” to “Skip revocation check for certificates” to reflect the real purpose of the setting.

On the certificate selector screen, we added the “Local Database Store certificates” view. In addition, content of the screen varies depending on where the selector is used. The new “Local Database Store certificates” view is only visible where you need to select a public key and is invisible where you need to select a certificate with private key included.

Troubleshooting

When you have upgraded a 4.x tenant to version 5.0 and already imported certificates into its database but you still get an error about not being able to resolve certificates while logging in using a SAML 2.0 IdP, please go to System Setup and check the “Security token resolver factory” setting. The correct value should be Safewhere.IdentityProvider.Saml2.Tokens.CustomSubResolverSecurityTokenResolverFactory, Safewhere.IdentityProvider.Saml2.

Was this helpful ?Good Somewhat Bad