Importing and Reverting a CA-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 is used for accessing the TOS VIP over HTTPS (both UI and API access).

If the CA-signed certificate requires intermediate certificates then the certificates should be imported together as a bundle (a certificate chain file).

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

Prerequisites

Certificate prerequisites

  • If the certificate contains FQDNs in its Subject Alternative Name (SAN) extension, all SAN entries must be resolvable through the DNS servers configured on the TOS host. Certificates containing unresolved FQDN SAN entries will be rejected.

Bundle prerequisites

  • The certificate bundle must:

    • Be RSA compatible

    • In .PEM format; other formats are not supported

  • The bundle must include must include:

    • The CA-signed certificate

    • One, or more, intermediate certificates.

  • In addition, depending on your security policy, you may be required to add a root certificate to the bundle (root.crt)

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

  • 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 CA-signed certificate, followed by the intermediate CA certificates, and end with the root CA certificate.

-----BEGIN CERTIFICATE-----
<CA-SIGNED CERTIFICATE>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<INTERMEDIATE CERTIFICATE 1>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<INTERMEDIATE CERTIFICATE 2>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CERTIFICATE>
-----END CERTIFICATE-----

Import CA-signed 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 certificates, create a certificate bundle in .pem format from the CA-signed certificate, intermediate certificates and (optional) root certificate:

    cat <CA-SIGNED CERTIFICATE> <INTERMEDIATE CERTIFICATE> <OPTIONAL ROOT CERTIFICATE> > <BUNDLE>.pem

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

    1. Run: 

      2. openssl rsa -in <ORIGINAL KEY> -out <NEW KEY>

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

      3. The output file <NEW KEY> is now unencrypted.

  3. Import the CA-signed certificate or CA-signed certificate bundle:

    [<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 CA-signed certificate or CA-signed certificate bundle
    • <KEY-PATH> is the full path to the private key.

    Example

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

Revert CA-signed certificate to self-signed

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

  1. Stop TOS

    [<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.

Troubleshooting

Check current certificate

  • To check which certificate is in currently in use, run the following command:

    kubectl get secret tls-cert -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout

nginx-ingress pod fails to start after certificate import

The nginx-ingress component uses the Base64-encoded certificate stored in the tls-cert Kubernetes secret.

If the certificate contains syntax errors, an invalid certificate chain, or a mismatch between the certificate and private key, the nginx-ingress pod may fail to start.

If this occurs, verify:

  • The certificate and private key match.

  • The certificate chain is complete and correctly ordered.

  • The certificate bundle contains valid PEM-encoded certificates.