Skip to content

Trust chains

Trust chains are a way to manage and distribute certificates within the Enclave platform. They allow you to create a chain of trust, starting from a root certificate, through intermediate signing certificates, and finally to the certificates issued to nodes.

Best practices

We recommend using the following best practices when managing trust chains in Enclave:

  • Use a trust chain for a singular purpose: Each trust chain should be used for a specific purpose, such as issuing certificates for nodes or users. This helps to keep the trust chain organized and manageable.

Supported certificate types and signature algorithms

Enclave managed roots are created with a 2048-bit RSA key and SHA-56-RSA signature algorithm. This is a current standard of balance for security and performance. However, you can create your own root certificates with different key types and signature algorithms if needed. We support the following certificates key types and signature algorithms:

  • RSA 2048-bit with SHA256-RSA signature
  • RSA 4096-bit with SHA512-RSA signature
  • RSA 2048-bit with SHA256-RSAPSS signature
  • RSA 4096-bit with SHA512-RSAPSS signature
  • ECDSA P-256 with SHA-256 signature
  • ECDSA P-512 with SHA-512 signature
  • Ed25519 with Ed25519 signature

Agent generated keys

The Enclave agent generates keys which are then used to request a certificate from the EMC. The agent passes up a public key to the EMC, which is then used in the issued certificate. The private key is stored on the agent's file system to verify the authenticity of the certificate.

You can customize which key type is used by the agent to generate the keys. This can be done in the EMC under trust chain settings. We support the following key types for agent generated keys:

  • RSA 2048-bit
  • RSA 4096-bit
  • ECDSA P-256
  • ECDSA P-512
  • Ed25519

When you change the key type, the agent will use the new key type for all future certificate requests. Existing certificates will not be affected, but you may want to renew them to use the new key type.

Enclave managed root certificates

Enclave provides managed root certificates that are automatically created and maintained by the Enclave platform. These root certificates are used to issue signing certificates and are designed to be secure and up-to-date. You can create a new Enclave managed root certificate in the trust chain view by selecting "Enclave managed" when adding a root certificate. By default, these root certificates are created with a 2048-bit RSA key and SHA256-RSA signature algorithm, which is a current standard of balance for security and performance. The default time period for these root certificates is 3 years, but you can customize the time period to suit your needs. Intermediate signing certificates created from an Enclave managed root will inherit the properties of the root certificate, including the key type and signature algorithm. They have a default time period of 6 months, but you can also customize this time period.

Rolling intermediate signing certificates

Rolling intermediate signing certificates is a process of replacing an existing signing certificate with a new one. This is done to ensure that the signing certificate remains secure and up-to-date. Simply add in a new intermediate signing certificate to the root certificate and toggle it live in the root certificate view. The new signing certificate will be used for all future certificate requests, while existing certificates will continue to use the old signing certificate until they are renewed.

Rolling root certificates

There can only be one primary root certificate in a trust chain at a time. The primary root is used for issuance. To roll a root certificate, you can add in a new root certificate and intermediate signing certificate. Set the root certificate to be the primary root in the root certificate view. The new root certificate will be used for all future certificate requests, while existing certificates will continue to use the old root certificate until they are renewed. As long as you keep the old root certificate around until all issuance has been moved to the new root certificate, agents will continue to trust the old root certificate while the agents renew their certificates to the new root certificate. This allows for a smooth transition to the new root certificate without any downtime or disruption to existing certificates.