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. The gateway instance must act as a certificate authority itself. This means that it must have its own self-signed certificate with the associated private key to sign impersonation certificates generated locally for any external websites that the client is initiating a connection to. The impersonation server certificate superficially resembles the actual external server’s certificate and is generated on the go, when the client issues a TLS Hello request to connect to a unique website.

The 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 Secret Manager and provide the secret name.

  • Store in Azure Key Vault 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.