Salesforce Docs Portal

Private Keys and Certificates in B2C Commerce

In various scenarios, you must import your third-party certificates and private keys into your instance’s keystore. A keystore can store multiple entries, each of which can be of type PrivateKeyEntry or of type TrustedCertificateEntry. This is similar to the terminology used by java.security.KeyStore.

Note
Note Salesforce B2C Commerce uses an internal password to encrypt the instance’s keystore.
Tip
Tip In releases 26.1 through 26.3, import dates for certificates and private keys were incorrectly reset during migration and when updating any certificate. Starting in release 26.4, import dates display correctly. Certificates and keys imported before release 26.1 show their correct original import dates. All newly imported certificates and keys show accurate import dates.

Private Key Entry

Each PrivateKeyEntry in an instance’s keystore holds the private key and its corresponding public key. This set of keys is used to communicate with external web services and to transfer files from your instance’s WebDAV client to external WebDAV servers. Custom code that uses a KeyRef or CertificateRef parameter use these keys when encrypting or decrypting data, for example, custom code used to encrypt or decrypt data.

Note
Note Import the certificate needed for the eCDN separately to the eCDN’s keystore, not to the instance’s keystore.

Trusted Certificate Entry

Each TrustedCertificateEntry in an instance’s keystore holds the public key certificates that validate server certificates when establishing outbound SSL connections. By default, B2C Commerce recognizes only the root CAs that ship with Oracle's Java platform. However, you can import a CA certificate to the instance’s keystore.

Certificate Rotation

The rotation of certificates, and their corresponding private keys, is important for a variety of reasons, including dealing with expired certificates, revoked certificates, or private key compromise. If a certificate expires, certificate rotation is required to continue using the certificate to secure your communications. If a certificate is revoked or a private key is compromised, certificate rotation is required to prevent an attacker from abusing the certificate.

If you use certificate rotation to protect data at rest using custom code, then the situation is more complex because you must deal with data that was encrypted with the previous key.

Follow these steps to handle this situation.

  1. Generate a new key.
  2. Identify the data encrypted with the old key.
  3. Decrypt the data with the old key.
  4. Re-encrypt the data with the new key.
  5. Delete the old key and the data encrypted with the old key.

Retain the old key in case data that was encrypted with the old key wasn’t identified in this process.