Certificates and Keys

TLS certificates and keys are used by the Multicloud Defense Gateway in proxy scenarios. For ingress (reverse proxy) users access the application via Multicloud Defense Gateway and it presents the certificate configured for the service. For egress (forward proxy) cases, the external host's certificate is impersonated and signed by the certificate defined.

Certificate body is imported to the Multicloud Defense Controller. The private key can be provided in the following ways:

• Import the private key contents.

• Store in AWS secrets manager and provide the secret name.

• Store in AWS KMS and provide the cipher text contents.

• Store in GCP secrets manager and provide the secret name.

• Store in Azure keyvault and secret and provide the keyvault and secret name.

For testing purposes you can also generate a self-signed certificate on the Multicloud Defense Controller. This is similar to importing the private key contents from your local file system.

Note

Certificates are NOT editable once created. If you need to replace the existing certificate, you will need to create a new certificate, edit the decryption profile to reference the new certificate, and then delete the old certificate. When importing the certificate and private key, the Multicloud Defense Controller / UI can detect if there is a mismatch. However, when using any other import method where the private key is stored within the cloud service provider, the Multicloud Defense Controller / UI will not be able to detect if there is a mismatch. This is by design to ensure the private key remains private and within your cloud service provider. When the private key is needed by the Multicloud Defense Gateway, it is accessed and used, and if there is a mismatch, an error is generated.