Certificate and Keys Tech Notes

Azure Key Vault

Multicloud Defense integrates with many secret management systems offered by public cloud providers to store the private keys corresponding to the certificates to be used in TLS decryption. In this section, you can view the steps to retrieve a stored private key in Azure Key Vault for a certificate. Multicloud Defense supports retrieval of private keys through Azure Key Vault secrets.

Create Azure Key Vault and User-assigned Managed Identities

Multicloud Defense uses a user-assigned managed identity to access the Azure Key Vault secret. The following steps show how to create the Key Vault and how to grant the managed identity the necessary permissions to access the secret:

Procedure

Step 1

Create a new User-assigned Managed Identity.

Step 2

Create a new Key Vault, for example, mcd-key-vault.

Step 3

In the newly created Key Vault, go to Access Policies.

Step 4

Select Add Access Policy.

Step 5

Assign Secret permissions: Get.

Step 6

Select Principal.

Step 7

Select the Managed Identity.

Step 8

Staying on the Key Vault configuration, navigate to Access Control (IAM) > Select Add > Role Assignment.

Step 9

Select Reader Role.

Step 10

Search for the Managed Identity in the Select field and select it.

Step 11

Click Save.

Store Private Keys into Azure Key Vault Secrets

Import your private key for your secret into the secrets folder of the Azure Key Vault that you have created. Since the private key is a multi-line string, this can be imported via the Azure Cloud Shell.

Start the Azure Cloud Shell and run the following command:


az keyvault secret set --file <privatekey file> --encoding ascii --vault-name <key vault name> --name <secret name>

The key file is created by simply creating a new file with a text editor (vi) in Azure Cloud Shell, pasting the contents of the private key and saving it.

Configure Gateway with User-assigned Managed Identity

Before you begin

You need to ensure that the Multicloud Defense Gateway deployed in Azure is configured with the user-managed identity as specified in Azure Key Vault and User-assigned Managed Identities.

Procedure

Step 1

Copy the Resource ID of the User-assigned Managed Identity that you created.

Step 2

Navigate to Managed Identities.

Step 3

Click on the Managed Identity created for the Multicloud Defense Gateway.

Step 4

Select Property.

Step 5

Select the icon on the right side of the Resource ID field to copy the ID.

Step 6

Paste this Resource ID in the Multicloud Defense Gateway configuration for your Azure Gateway under the User Assigned Identity ID field.

Configure Multicloud Defense to Retrieve Private Key

Before you begin, ensure that the Multicloud Defense Gateway deployed in Azure is configured with the user- managed identity as specified in Azure Key Vault and User-assigned Managed Identities.

Paste the certificate body into the field associated with the private key in the Azure Key Vault secret

Once you have created the Multicloud Defense certificate, it can be used with a Decryption Profile when defining services in Multicloud Defense Controller.

Generate a Self-Signed Root CA

Generate a self-signed root certificate authority (CA).


openssl genrsa -out myca.key 2048
# password protect key: openssl genrsa -out myca.key -des3 2048
openssl req -x509 -new -key myca.key -sha384 -days 1825 -out myca.crt \
  -subj "/C=US/ST=CA/L=Santa Clara/O=MyOrg/OU=SecurityOU/CN=rootca.myorg.com/emailAddress=rootca@myorg.com"

This root CA must be installed as a trusted root CA on the users (client) machines


Note

Generating a self-signed certificate using macOS will not produce a certificate suitable for forward and reverse proxy scenarios. The certificate must have the Is CA option set to True and the certificate generated using macOS does not. It is recommended that the self-signed certificate be generated from within the Multicloud Defense UI (Certificates > Create > Generate) or using Linux.

Generate a Certificate Signed by your Self-Signed Root CA

Generate a certificate signed by the above root certificate authority (CA). You can use this certificate in applications.


openssl genrsa -out app1.key 2048
# password protect key: openssl genrsa -out -des3 app1.key 2048 
openssl req -new -key app1.key -out app1.csr \
  -subj "/C=US/ST=CA/L=Santa Clara/O=MyOrg/OU=AppOU/CN=app1.myorg.com/emailAddress=app1@myorg.com"
openssl x509 -req -in app1.csr -CA myca.crt -CAkey myca.key -out app1.crt -sha384\
  -days 365 -CAcreateserial -extensions SAN \
  -extfile <(printf " [SAN]\nbasicConstraints=CA:false\nsubjectAltName=DNS:app1.myorg.com,DNS:app1- 1.myorg.com,IP:192.168.10.21,IP:192.168.10.22")

Generate an Intermediate CA Signed by Your Root CA

If you don't want to use the root certificate authority (CA) to sign app certs, then create an intermediate CA signed by the root CA, then sign the app certs using the intermediate CA. Append the intermediate cert to the app cert. At this point the app crt has 2 certs (as a chain). 


openssl genrsa -out interca.key 2048
# password protect key: openssl genrsa -out -des3 interca.key 2048
openssl req -new -key interca.key -out interca.csr \
  -subj "/C=US/ST=CA/L=Santa Clara/O=MyOrg/OU=InterSecurityOU/CN=interca1.myorg.com/emailAddress=interca1@myorg.com"
openssl x509 -req -in interca.csr -CA myca.crt -CAkey myca.key -out interca.crt - sha384 \
  -days 365 -CAcreateserial -extensions SAN \
  -extfile <(printf "[SAN]\nbasicConstraints=CA:true")

App Certificate signed using the Intermediate CA


openssl genrsa -out app1.key 2048
# password protect key: openssl genrsa -out -des3 app1.key 2048 
openssl req -new -key app1.key -out app1.csr \
  -subj "/C=US/ST=CA/L=Santa Clara/O=MyOrg/OU=AppOU/CN=app1.myorg.com/emailAddress=app1@myorg.com" 
openssl x509 -req -in app1.csr -CA interca.crt -CAkey interca.key -out app1.crt - sha384 \
  -days 365 -CAcreateserial -extensions SAN \
  -extfile <(printf " [SAN]\nbasicConstraints=CA:false\nsubjectAltName=DNS:app1.myorg.com,DNS:app1- 1.myorg.com,IP:192.168.10.21,IP:192.168.10.22")

Append the files app1.crt and interca.crt to create a combined certificate, and use it in your application. The root CA must be installed as a trusted root CA on your client machines.

Install Root CA as Trusted CA on the Hosts

OS

Command

Ubuntu

Copy crt file to /usr/local/share/ca-certificates. Run the command sudo update-ca- certificates.

CentOS

Copy crt file to /etc/pki/ca-trust/source/anchors. Run the command sudo update-ca- trust extract.

Windows

Double click the file and add the cert to Trusted Root, or run the command certutil -addstore "Root" <crt-file>.