TLS Certificate (Optional)

This documentation describes the legacy CDK implementation, which will be deprecated in an upcoming release. We strongly recommend that you transition to the current CDK implementation as soon as possible.

This page covers several options you can use to encrypt HTTP communications over TLS in CDK deployments.

Self-Signed Certificate

By default, Minikube’s ingress controller plugin is configured with a self-signed certificate. This is the simplest encryption option—you don’t have to make any changes to the CDK to get encryption.

However, when you access one of the ForgeRock web applications from your browser, you’ll get a "Not Secure" message from your browser. You’ll need to bypass the message.

Certificate From a Certificate Authority (CA)

If you have a certificate from a CA, you can use the certificate for TLS encryption. Install the certificate and your private key in a Kubernetes secret in your namespace. Minikube’s ingress controller plugin gets the certificate from the secret, and then uses it to encrypt communications.

To use a certficate from a CA in a CDK deployment on Minikube:

Obtain the certificate:
- Make sure that the certificate is PEM-encoded.
- A best practice is to include the entire trust chain in your .pem file.
- Make sure that the certificate’s host name works with the FQDN you’ll use when you deploy the platform.
  
  In the CDK, the deployment FQDN is set to my-namespace.iam.example.com by default. But you’ll want to use a certificate with your own domain, not with example.com. Because of this:
  - When you deploy the CDK. you’ll need to change the deployment FQDN to use your own domain name. For example, change my-namespace.iam.example.com to my-namespace.iam.my-domain.com.
  - Your certificate should also specify this host name. If you’re using a wildcard certificate that could be used by multiple developers, the certificate’s host name should be *.iam.my-domain.com.
  - Note that you can deploy the CDK with a deployment FQDN that does not include the subdomain iam. You might want to do this if you have a wildcard certificate for *.my-domain.com. However, ForgeRock recommends that you use a subdomain, such as iam, in your deployment FQDN when possible. Using a subdomain can help you avoid FQDN collisions, provide simpler routing, and simplify DNS.

Create a secret named sslcert in your namespace that contains the certificate. For example:

$ kubectl create secret tls sslcert --cert=/path/to/my-cert.crt --key=/path/to/my-key.key

Certificate Generated by the mkcert Utility

If you don’t have a certificate from a CA, you can use the mkcert utility to generate a locally trusted certificate. In many cases, it’s acceptable to use such certificates for development purposes.

To use a certificate generated by the mkcert utility in a CDK deployment on Minikube:

If you don’t have mkcert software installed locally, install it. Firefox users also need to install certutil software. See the mkcert installation instructions for more information.
If you haven’t ever done so, run the mkcert -install command to create a local certificate authority (CA) and install it in your system root store. Restart your browser after creating the local CA.
Create a wildcard certificate for the iam.example.com domain:
```
$ cd
$ mkcert "*.iam.example.com"
```

Create a secret named sslcert in your namespace that contains the wildcard certificate. For example:

$ kubectl create secret tls sslcert --cert=./_wildcard.iam.example.com.pem --key=./_wildcard.iam.example.com-key.pem

ForgeOps

TLS Certificate (Optional)

Self-Signed Certificate

Certificate From a Certificate Authority (CA)

Certificate Generated by the mkcert Utility

Next Step