Certificates Overview

Once a year, Salesforce admins receive an email with the subject “SFDC Expiring Certificate Notification.” (You may receive this email multiple times if you don’t know what to do and decide to ignore it.) The email contains the following explanation:

You have one or more certificates in your Salesforce org My Awesome Org 00D8c0002f25UxU that will expire soon. Review the list below and visit Certificate and Key Management from Setup to make an update.

What it doesn’t tell you is how to make an update. That is the focus of this article. First, though, I’d like to offer a bit of context and address some common questions.

Common Questions About Certificates

What are they, and why do they expire so often?

Security certificates are small data files used to prove the authenticity of a website. Generally speaking, certificates need to be renewed regularly to ensure that security is maintained. Think of it as something like changing your password periodically. The longer it hangs around, the greater the chance it could become compromised. Expiration is one way of helping to establish and maintain trust between systems on the internet. If you allow a certificate to expire, it’s possible that a third-party app, integration, or SSO provider will no longer trust your Salesforce environment. If this happens, your third-party apps and integrations may no longer work.

Can I set the expiration date to be longer than one year?

You may think, “I’m tired of doing this every year, and I need fewer fire drills in my life.”

The answer is — kind of. You don’t get to choose your expiration date, but the duration varies depending on the type of certificate chosen. The following buttons let you create a Self-Signed or a CA-Signed Certificate. 

Here’s how that decision affects you.

• Self-signed certificate — you’ll be given another choice:
  • 2048 bit will give you a one-year expiration.
  • 4096 bit will give you a two-year expiration. (Note: This certificate takes longer to process, which could be interpreted as a performance issue.)
• CA-signed certificate — a “CA” is a third-party certificate authority:
  • The CA can specify a longer duration due to the fact that these are considered more trustworthy. 
  • These can also be renewed, extending the expiration without starting from scratch.
  • The downside is that you have to pay for a CA-signed certificate.

All of this leads to the inevitable next question…

What type and duration of certificate should I use?

We advise that you follow the guidelines given by security experts: 

• For production environments, use CA-signed certificates. These are the most secure and most performant.
• For test environments, it’s okay to use self-signed certificates, with the caveat that sandbox environments with production data copied into them may require special consideration, as discussed later in this post.

Despite this guidance, I’ve found that many firms use self-signed certificates for all environments.

How to Renew or Extend a Certificate

Here’s how to get it done. The instructions are slightly different for the two types of certificates.

Self-signed certificates

You can’t truly renew or extend a self-signed certificate; you must create a new one and may need to import it to the external systems. Here are the steps:

Step 1: Go to Setup > Security > Certificate and Key Management

Step 2: Back up the current certificates by clicking Export to Keystore — You’ll be prompted to set a password for the file that is generated, and all of your certificates will be included.

Step 3: Create the new certificate by clicking Create Self-Signed Certificate — You’ll be prompted to fill in a few fields, as shown below. Click SAVE.

Step 4: After saving, download the new certificate by clicking Download Certificate — This button appears on the certificate’s detail page, and it generates a .crt file that you can import to your external systems.

Step 5: Next, you will update the various settings that external systems rely on. One or more of these may apply:

• If you use Single-Sign On to handle user sign-ins, you’ll need to update the SSO settings. 
  Go to Setup > Single Sign-On Settings and click Edit next to the SAML SSO record that’s in use. Then modify the Request Signing Certificate dropdown to select the new certificate.

• • The other fields should still align with the original settings of the SSO provider you use, but you can update them if needed. 
• If you use a named credential to allow connectivity with external systems, you’ll need to:
  • Update the named credential in Salesforce. Go to Setup > Named Credentials and click Edit. Then select the new certificate in the Client Certificate field.
  • You may also need to import the certificate (downloaded in Step 4) into the external system.
• If you use Salesforce as an identity provider (allowing users to access other systems based on their Salesforce credentials), you’ll need to update the Identity Provider settings in Salesforce.
  • Go to Setup > Identity Provider and click Edit. Use the dropdown to select the new certificate.

Step 6: Return to Certificate and Key Management, and delete the old certificate. You have a backup from Step 1 that can be restored if the testing is unsuccessful.

Step 7: Test the new certificate.

• Verify that communications with the external system are successful with the new certificate.
• Ask another user to sign in with SSO.
• If there are problems, return to the Certificate & Key Management screen and restore the prior certificate by clicking Import from Keystore. This ensures you can continue operations until the new certificate can be fully onboarded to external systems and firewalls.

CA-signed certificates

This resembles the process for self-signed certificates, except that Steps 3 and 4 are replaced by the following:

• Create the certificate — Click Create CA-Signed Certificate, and you’ll be prompted to fill in a few more fields than for self-signed. The good news is that this form gives you great help text for every field.
  

• Get the certificate signed by a certificate-signing authority — After saving, download the certificate by clicking Download Certificate Signing Request. You’ll send this .csr file to the certificate authority of your choice.
• Upload the signed certificate — When the CA provides a signed certificate, return to the new certificate that you created and click Upload Signed Certificate.

Once this is done, you’ll be able to implement the CA-signed certificate in the same places listed for self-signed certificates, in Steps 5–7 above.

Manage Certificates when Refreshing Sandboxes

If you have SSO or other third-party systems that integrate with your sandboxes, and those integrations are relying on certificates within that sandbox, you may encounter problems when refreshing the sandbox. The sandbox certificate (along with all other sandbox data) will be wiped out by the refresh and replaced with a copy of the production certificate(s). This means you may need to create new certificates and import them to the other systems each time you refresh the sandbox. This could even be expensive if you are paying for CA-signed certificates. Here is an alternative:

Before sandbox refresh

Back up your sandbox certificates.

1. Go to Setup > Security Controls > Certificate and Key Management.
2. Click on Export to Keystore.
3. Create a keystore password.
4. Click on Export.
5. A Java Keystore file with extension .jks (e.g. 00D180000001XWw.jks) will be downloaded to your local system.

After sandbox refresh

Restore the backed-up certificates.

1. Go to Setup > Security Controls > Certificate and Key Management.
2. Click on Import from a Keystore.
3. Choose the downloaded .jks file, provide the keystore password, and click Save.
4. All certificates inside the keystore are imported to the environment.
5. For SSO apps, named credentials, and identity providers (if used in the sandbox), you’ll need to make updates so they use the restored certificates — the same as when creating a new certificate in production (see instructions under Step 5 above).
6. Optional: Return to Setup > Certificate and Key Management and DELETE the certificates that were copied into the sandbox from production.

Dealing with an expired certificate can be cumbersome, but I hope this provides a bit of clarity around the process and what you need to do. One encouraging sign is that Salesforce is always improving, and it’s likely that both their certificate documentation and the overall process will get easier over time. For additional information from Salesforce, I’d suggest checking the group of knowledge articles under Certificates and Keys. To learn more about ShellBlack and the Salesforce solutions we provide, contact us.

 

AUTHOR CREDIT: 

Brian Knezek, Consultant at ShellBlack