Updating TLS/SSL certificates¶
You can replace the self-signed certificates generated as part of the initial post-install configuration at any time.
To minimize downtime, make sure that you have completed the preparation steps below before scheduling a maintenance interval to update the certificates. When you are ready, you can update the certificates using either the admin console or the command line. We strongly recommend the use of the admin console to minimize the potential for error.
Caution
Instruct users to save their work and log out before updating the certificates. While sessions, deployments, and jobs will still continue to function properly, there will be a brief interruption of front-end service during the update process.
Preparing for the update¶
Anaconda recommends that you gather the following information and files before you proceed. If you are using the admin console, have your files present in a location where you can enter their contents into the applicable fields within the UI. If you are updating your certificates using the command line, you’ll need to copy the files to your server.
Most installations will need the following items:
The fully qualified domain name of the server.
The public SSL certificate for the domain
<FQDN>
:tls.crt
The private SSL key for the domain
<FQDN>
:tls.key
.If applicable, the intermediate certificate bundle:
intermediate.pem
.If your certificate was issued by a private root CA, the public certificate for that CA:
rootca.crt
.
If you are using LetsEncrypt, the filenames will be different:
The public SSL certificate:
cert.pem
The private SSL key for the domain:
privkey.pem
.The intermediate certificate bundle:
chain.pem
.No root CA file is needed in this case.
If you are using a different domain and/or SSL certificate for the session/deployment subdomains, you will need this additional information:
The wildcard subdomain. We will refer to this as
<DEPLOYMENT-FQDN>
below.The public SSL certificate for
*.<DEPLOYMENT-FQDN>
:wildcard.crt
The private SSL key for
*.<DEPLOYMENT-FQDN>
:wildcard.key
Note that AE5 assumes that the intermediate certificate and root CA, if applicable, are identical for both certificates.
Finally, if you intend to use the command-line approach to updating the certificates, you will need a copy of the the latest set of publicly-trusted root certificates. A copy of this file, current to when AE5 installer package was built, can be found at DIY-SSL-CA/CA/pubCA.crt
in your unpacked installer assets.
Using the admin console¶
Log in to Anaconda Enterprise as an administrator.
Enter your certificate and key information from the files you gathered during preparation into the appropriate fields. Make sure to paste the content of each file into the appropriate box, not the filenames.
Domain name:
<FQDN>
SSL Certificate:
tls.crt
/cert.pem
SSL Private Key:
tls.key
/privkey.pem
Root Certificate:
rootca.crt
, if applicableIntermediate Certificate:
intermediate.pem
/chain.pem
, if applicableWildcard Domain:
<DEPLOYMENT-FQDN>
, or<FQDN>
if identical. Do not include an asterisk.Wildcard Certificate:
wildcard.crt
if different;tls.crt
/cert.pem
if identical.Wildcard Private Key:
wildcard.key
if different;tls.key
/privkey.pem
if identical.
Click Save to update the platform with your changes.
If your root CA has changed, you will need to restart the Anaconda Enterprise system pods to make sure that the pods that use this certificate will pick up the new copy.
Using the command line¶
Log in to the master node and make sure all of the files mentioned above have been transferred there, including the root CA trust file
cacert.pem
. To download the latest version of the root CA trust file, run the command:Make sure you have downloaded a copy of
cacert.pem
per the instructions above. If you have a private root CA, append it to that file:If you have an intermediate bundle, you will need a file that combines that bundle with your main public certificate:
If you are using LetsEncrypt, you may skip this step, as
fullchain.pem
has already been provided for you.Create a file named
certificates.yaml
, then add the following information to it:This file will be used to provide your updated TLS/SSL certificate and key to access the kubernetes cluster. To keep your information secure, use placeholders for the actual values of the certificate and key.
Save your work and close the file.
Replace the placeholders in the
certificates.yaml
file with an encoded version of the actual certificate and key. Run the commands that fit your environment:If you have a single certificate with an intermediate, run the following commands:
If you are using a LetsEncrypt certificate, run the following commands:
If you have separate certificates for the main and wildcard domains, run the following commands:
Verify that your
certificates.yaml
file now contains the correct certificate and key by running the following command:If the command returns nothing, your
certificates.yaml
file has been successfully created.If the command returns a message, re-verify the file name and its contents are correct, then run the command again.
Run the following command to create a backup of your existing secret:
Remove the existing secrets, then recreate them from the new file by running the commands:
Restart all Anaconda Enterprise system pods by running the command:
If you are using a gravity cluster, you will need to perform the following additional steps:
Create a file named
gravity-certificates.yaml
, then add the following information to it:This file will be used to provide your updated TLS/SSL certificate and key to access the gravity cluster. To keep your information secure, use placeholders for the actual values of the certificate and key.
Save your work and close the file.
Replace the placeholders in the
gravity-certificates.yaml
file with an encoded version of the actual certificate and key by running the following commands:If you have a separate set of certificates for the ops-center domain, the command will look something like this:
Verify that your
gravity-certificates.yaml
file now contains the correct certificate and key by running the following command:If the command returns nothing, your
gravity-certificates.yaml
file has been successfully created.If the command returns a message, re-verify the file name and its contents are correct, then run the command again.
Run the following command to create a backup of your existing secret:
Remove the existing secrets by running the command:
Create new secrets using the
gravity-certificates.yaml
file you created by running the command: