---
schema_version: "1"
id: e7c9e3bd813976926828f27261b3414bec32673275e58ee6df4adcd3c235d189
title: Private Keys and Certificates in B2C Commerce
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/cc/264-0-0/b2c_certificates_and_private_keys.md
canonical_url: https://help.salesforce.com/s/articleView?id=cc.b2c_certificates_and_private_keys.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 7f144c900194500eb3b9169f10a3da0719d21aceb8c34fd105c570f23c81b9d5
description: 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.
products:
  - Commerce
  - B2C Commerce
release: "264"
---
# 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-cc-b2c_merchandiser_administrator-264-0-0-production-enus/ea76f372-6cfa-42a6-8e7c-05c6df7abed8/images/icon_note.png)

Note Salesforce B2C Commerce uses an internal password to encrypt the instance’s keystore.

![Tip](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-cc-b2c_merchandiser_administrator-264-0-0-production-enus/ea76f372-6cfa-42a6-8e7c-05c6df7abed8/images/icon_tip.png)

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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-cc-b2c_merchandiser_administrator-264-0-0-production-enus/ea76f372-6cfa-42a6-8e7c-05c6df7abed8/images/icon_note.png)

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.