Salesforce B2C Commerce 24.7 > B2C Commerce Security Guide > Security Best Practices for Administrators > Secure Storage

Private Keys and Certificates

In various scenarios, you need to import your 3rd 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: Salesforce B2C Commerce uses an internal password to encrypt the instance’s keystore.

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: The certificate needed for the eCDN is imported separately to the eCDN’s keystore and not to the instance’s keystore.

Trusted Certificate Entry

Each TrustedCertificateEntry in an instance’s keystore holds the public key certificates that are used to 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.

Generate a new key.
Identify the data encrypted with the old key.
Decrypt the data with the old key.
Re-encrypt the data with the new key.
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.