Configure certificates#

About configuring certificates#

Introduction#

You can configure certificates in Aspen Mesh in the following ways:

  • Plug in your own certificate-authority (CA) certificates to the Aspen Mesh CA

  • Enable ECC workload certificates so the Aspen Mesh CA generates and signs ECC instead of RSA workload certificates

About plugging in CA certificates#

Introduction#

If you don’t plug in certificate-authority (CA) certificates, the Aspen Mesh CA (istiod) generates a self-signed RSA root certificate (which it also uses as a CA certificate) and a private key and uses them to generate signed workload certificates in your cluster. You can plug in your own root, CA, and intermediate certificates and private key so the Aspen Mesh CA instead uses your CA certificate and private key to generate signed workload certificates.

When to plug in CA certificates#

Plug in certificate-authority (CA) certificates when any of the following is true:

  • Your organization’s security and compliance policies require the use of your centralized CA infrastructure as root for all issued certificates, including workload certificates generated and signed by the Aspen Mesh CA.

  • You’re using Citadel (for example, because you’re using Packet Inspector 1)

Required credential files#

To plug in certificate-authority (CA) certificates, you need the following credential files, which will be used in the Kubernetes secret referenced by the Aspen Mesh CA as the root CA credential to generate signed workload certificates:

File

Description

ca-cert.pem

The CA certificate used by the Aspen Mesh CA to generate signed workload certificates. This file can be the same certificate as root-cert.pem.

ca-key.pem

The private key used by the Aspen Mesh CA to generate signed workload certificates

root-cert.pem

The root certificate that generated and signed ca-cert.pem. This file can be the same certificate as ca-cert.pem.

cert-chain.pem

The certificate chain of trust that includes all intermediate certificates between the workloads and the root CA. This file should be empty if root-cert.pem and ca-cert.pem are the same certificate.

Note

  • You may not use different filenames.

  • The certificates you plug in can be either Rivest–Shamir–Adleman (RSA) or elliptic-curve cryptography (ECC) certificates and do not affect the type of workload certificates generated and signed by the Aspen Mesh CA.

About enabling ECC workload certificates#

Introduction#

If you don’t enable ECC workload certificates, the Aspen Mesh certificate authority (CA) generates and signs RSA certificates for workloads in your cluster. To have the Aspen Mesh CA (istiod) generate and sign ECC instead of RSA workload certificates, you can enable ECC workload certificates.

When to enable ECC workload certificates#

Enable ECC workload certificates when any of the following is true:

  • Your organization’s security and compliance policies require the use of ECC certificates for all workloads.

  • You want to take advantage of the benefits that ECC workload certificates provide.

Benefits of ECC#

These are some of the benefits of ECC:

  • Small ECC keys (stored in ECC certificates) have the equivalent strength of larger RSA keys. For instance, a 256-bit ECC key is roughly equivalent to a 3072-bit RSA key.

  • Smaller ECC keys mean less data is transmitted between the client and server during the mTLS handshake.

  • Key generation for ECC is substantially faster than for RSA.

  • ECC requires less CPU and memory than RSA when encrypting and decrypting keys.

Drawback of ECC#

The ECC signature verification can be computationally intensive and may be slower than RSA on some devices.

Supported ECC algorithm and curve#

ECC workload certificates generated and signed by the Aspen Mesh certificate authority (CA) use the Elliptic Curve Digital Signature Algorithm (ECDSA) and curve P-256.

Tasks#

Configure certificates#

  1. Do you want to plug in CA certificates?

  2. Do you want to enable ECC workload certificates?

  3. Is Aspen Mesh already installed?

    Note

    Answer no if you were directed to this page while performing a clean installation of Aspen Mesh.

    • Yes:

      • Go to step 4.

    • No:

      • Stop. Continue performing the clean installation.

  4. Did you plug in CA certificates or enable ECC workload certificates?

Plug in CA certificates#

Note

Perform this task only when other instructions tell you to do so.

  1. Create a directory to hold the required credential files.

  2. Change to the directory you created.

  3. Create the required credential files if they don’t already exist.

  4. Is Aspen Mesh already installed?

    • Yes:

      • Go to step 5.

    • No:

      • Create the istio-system namespace:

          $ kubectl create namespace istio-system

  5. Use the required credential files to create a certificate secret named cacerts in the istio-system namespace:

    $ kubectl create secret generic cacerts --namespace istio-system \
    --from-file=ca-cert.pem \
    --from-file=ca-key.pem \
    --from-file=root-cert.pem \
    --from-file=cert-chain.pem

Enable ECC workload certificates#

Note

Perform this task only when other instructions tell you to do so.

  1. Open your Aspen Mesh override values file (for example, aspen-mesh-override-values.yaml) in a text editor.

  2. Copy the following information and paste it into the file:

    global:
  enableEccCertificates: true

  3. Save and close the file.

Complete the certificate configuration#

Note

Perform this task only when other instructions tell you to do so.

  1. Change to the Aspen Mesh release directory.

  2. Did you enable ECC workload certificates?

    • Yes:

      • Upgrade the Istio control plane, Aspen Mesh control plane, and Aspen Mesh dashboard, making sure to replace <aspenMeshOverrideValuesFilename> with the path and filename (for example, aspen-mesh-override-values.yaml) of your Aspen Mesh override values file:

        $ helm upgrade istiod manifests/charts/istio-control/istio-discovery \
    --namespace istio-system \
    --values <aspenMeshOverrideValuesFilename>

      • Go to step 3.

    • No:

      • Go to step 3.

  3. Restart the istiod pods:

    $ kubectl rollout restart deployment istiod --namespace istio-system

  4. Did you plug in CA certificates?

    • Yes:

      • If Citadel is already installed, restart it:

        $ kubectl rollout restart deployment istio-citadel \
    --namespace istio-system

      • Go to step 5.

    • No:

      • Go to step 5.

  5. In each namespace in which sidecar injection (either automatic or manual) should occur, restart all pods with sidecars:

    $ kubectl delete pods --namespace <namespaceName> \
    --selector security.istio.io/tlsMode=istio

  6. Upgrade the Istio ingress gateway components, making sure to replace <ingressNamespaceName> with the name of the namespace to use for these components and <aspenMeshOverrideValuesFilename> with the path and filename (for example, aspen-mesh-override-values.yaml) of your Aspen Mesh override values file:

    $ helm upgrade istio-ingress manifests/charts/gateways/istio-ingress \
    --namespace <ingressNamespaceName> \
    --values <aspenMeshOverrideValuesFilename>

  7. If you’re using the Istio egress gateway, upgrade the Istio egress gateway components, making sure to replace <egressNamespaceName> with the name of the namespace to use for these components and <aspenMeshOverrideValuesFilename> with the path and filename (for example, aspen-mesh-override-values.yaml) of your Aspen Mesh override values file:

    $ helm upgrade istio-egress manifests/charts/gateways/istio-egress \
    --namespace <egressNamespaceName> \
    --values <aspenMeshOverrideValuesFilename>

  8. Did you enable ECC workload certificates?

    • Yes:

      • Inspect the certificate of any pod with a sidecar to make sure it’s an ECC certificate:

        $ ./bin/istioctl proxy-config secret <podName> -o json | jq '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' -r | base64 -d | openssl x509 -noout -text

    • No:

      • Stop.