Importing and Reverting a Signed Certificate

Overview

This procedure describes how to import a CA-signed certificate into TOS, and if needed, revert to a self-signed certificate.

The CA-signed certificate does not replace self signed certificates on internal Kubernetes cluster components. See Self-signed certificates on internal components.

Prerequisites

General prerequisites

  • The signed certificate must:

    • Be RSA compatible

    • In .PEM format; other formats are not supported

  • Verify the certificate pair.

    openssl rsa -noout -modulus -in server.key | openssl md5
    • openssl x509 -noout -modulus -in site-certificate.crt | openssl md5

    The hash for both files should match.

  • Verify the certificate has a valid SAN.

    openssl x509 -noout -ext subjectAltName -in site-certificate.crt

    • For example:

    [root@OS4 certest]# openssl x509 -noout -ext subjectAltName -in web.server.crt
                    X509v3 Subject Alternative Name: DNS:tufin.com, DNS:www.tufin.com, IP Address:192.168.1.81

  • Verify the certificate expiration date.

    • openssl x509 -enddate -noout -in site-certificate.crt

    The certificate date must be in the future.

Signed Certificate Bundle and Order

The certificate bundle refers to the certificate chain file, and must include the following certificates:

  • <your_domain>.crt

  • intermediate.crt

  • root.crt, only when using an internal or a private self-signed certificate

Each certificate in the bundle must be preceded by the -----BEGIN CERTIFICATE----- header and ended by the -----END CERTIFICATE----- footer.

Certificate creation

Here's an example of the command to create the certificate bundle:

cat your_domain.crt intermediate.crt root.crt > fullchain.pem

Certificate order in bundle

The order of the certificates in the chain file is important for clients to fully verify the server certificate. The chain file must start with the server certificate, followed by the intermediate CA certificates, and end with the root CA certificate.

-----BEGIN CERTIFICATE-----
(Domain  Server Certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate-1)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate-2)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root)
-----END CERTIFICATE-----

 

Import CA-Signed Server Certificate

Import a CA-signed server certificate into TOS to authenticate and encrypt communications with your TOS server. Make sure you import the entire certificate chain as a bundle including the root, an intermediate certificate, and the server certificate.

We recommend saving a copy of the signed certificate in case you need to re-import it in the future. For example, if an attempt to update to a newer signed certificate fails you may need to re-import the current signed certificate.

  1. If your organization uses an intermediate CA, first create the certificate bundle:

    1. If the private key has a passphrase, remove it now.

      • Run: 

        • openssl rsa -in [original.key] -out [new.key]
        openssl rsa -in [original.key] -out [new.key]

      • When prompted, enter the passphrase for the original key.

        • The output file [new. key] is now unencrypted.

    2. Create a certificate bundle (bundle.crt) from a signed server certificate (certificate.cer) and an intermediate CA certificate (intermediate.cer):

      cat certificate.cer  <(echo) intermediate.cer > bundle.crt
      cat certificate.cer <(echo) intermediate.cer > bundle.crt

  2. Stop all TOS services:

    [<ADMIN> ~]$ sudo tos stop
    sudo tos stop

  3. Import the signed server certificate:

    [<ADMIN> ~]$ sudo tos certificate import --type="server" --cert=<CERT-PATH> --key=<KEY-PATH>
    sudo tos certificate import --type="server" --cert=<CERT-PATH> --key=<KEY-PATH>

    where:

    • <CERT-PATH> is the full path to the certificate bundle (certificate chain) with the required certificates.
    • <KEY-PATH> is the full path to your private key.

    Example

    $ sudo tos certificate import --type="server" --cert=/tmp/certfile.pem --key=/tmp/keyfile.key

  4. Restart TOS:

    [<ADMIN> ~]$ sudo tos run
    sudo tos run

Revert CA-Signed Certificate to Self-Signed

Revert a CA-signed server certificate to a self-signed one if needed.

  1. Stop all TOS services:

    [<ADMIN> ~]$ sudo tos stop
    sudo tos stop

  2. Revert the certificate:

    [<ADMIN> ~]$ sudo tos certificate renew --type="server" [--help] [--debug]
    sudo tos certificate renew --type="server"

  3. Restart TOS:

    [<ADMIN> ~]$ sudo tos run
    sudo tos run

Self-signed certificates on internal components

When you import a CA-signed certificate, it replaces the certificate used by the TOS web interface (port 443) only. It does not replace the self-signed certificates that are generated and managed by K3s for internal Kubernetes cluster components. These components handle internal node-to-node and pod-to-pod communication in TOS. They are not exposed to end users, and therefore there is no need to replace their certificates with CA-signed certificates.

The following internal components use self-signed certificates and are not affected by the CA certificate import:

  • Ports 2379/2380: etcd server communication

  • Port 6443: K3s API server

  • Port 9100: Node exporter (monitoring)

  • Port 10250: Kubelet

  • Port 32444: Disaster recovery

  • Port 32500: Container registry

If a vulnerability scanner flags these self-signed certificates, the findings can be marked as accepted risk or false positive, or the ports can be excluded from scan scope. No mitigation is required.