Prisma Cloud Compute Edition Administrator’s Guide
    : Prisma Cloud Compute certificates
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Configure
    6. Prisma Cloud Compute certificates
    Download PDF

    Prisma Cloud Compute Edition Administrator’s Guide

    Prisma Cloud Compute certificates

    Table of Contents

    Prisma Cloud Compute certificates

    This article summarizes all the certificates used by Prisma Cloud Compute. Learn more about the certificates used on Prisma Cloud Compute including details on what it is used for, signing CA, and your customization options.
    Customizing certificates is only allowed for Prisma Cloud Compute edition.
    Category
    Certificate
    Communication
    Certificate customization
    Default CA
    CA customization
    Prisma Cloud edition
    Console TLS communication
    Console Web and API certificate
    Web browser, API, and Twistcli access to Console
    Customize under
    Manage > Authentication > System certificates > TLS certificate for Console > Concatenate public cert and private key
    Console CA
    Your organization CA
    Compute edition
    Certificate-based authentication to Console
    Clients access the Console
    No CA by default
    Enable Console verification of the client’s CA certificate when accessing the Console.
    Define CA under
    Manage > Authentication > System certificates > Certificate-based authentication to Console > CA certificate
    Compute edition
    Console-Defender communication
    Defender server certificate (Console side)
    Console-Defender communication
    Yes, for Compute Edition only.
    See here
    Defender CA (defender-ca.pem)
    Yes, for Compute Edition only.
    See here
    Compute edition only. Not relevant for Enterprise edition (uses API token)
    Console-Defender communication
    Defender client certificate (Defender side)
    Console-Defender communication
    No
    Defender CA (defender-ca.pem)
    No
    Compute edition, not relevant for Enterprise edition (uses API token)
    Admission certificate (admission-cert.pem)
    Admission webhook authentication with Prisma Cloud Defender
    No
    Defender CA (defender-ca.pem)
    No
    Compute edition, Enterprise edition

    Console TLS communication certificates

    You can secure access to Console with your own digital certificate. By default, Prisma Cloud accesses the Console’s web portal and API with a self-signed certificate.
    The self-managed certificate generated by Console is valid for three years. 90 days prior to expiration, Prisma Cloud will let you rotate it (a banner will appear at the top of the UI). After rotating Console’s certificate, you must restart the Console.
    When you access Console’s web portal with this setup, for example, the browser flags the portal as untrusted with a warning message. The following screenshot shows the warning message in Chrome:
    You can resolve these warnings by installing your own certificate that proves your server’s identity to the client. With the proper certificate, users are taken directly to Console, and the green padlock in the address bar indicates that the site is trusted.
    Creating certificates is outside the scope of this article. For more information about how SSL and certificates secure a site, see How does HTTPS actually work.

    Configuration options

    Prisma Cloud secures the communication between various actors and entities with certificates. These certificates are automatically generated and self-signed during the Prisma Cloud install process. They secure communication between:
    • Users and the Console web portal
    • Users and the Console API
    • Console and the Prisma Cloud Intelligence Stream
    The following options control the properties of the certificates generated during the installation process. The default values for these options are typically adequate.
    Note that these settings only change the values used when creating self-signed certificates. Thus, users accessing the Console will still see warning messages because the certificates are not signed by a trusted certificate authority (CA). To configure the Console to use a certificate signed by a trusted CA, follow the steps later in this article.
    These options can be found in twistlock.cfg under the General Configuration section:
    Configuration option
    Description
    Specifies the Common Name to be used in the certificate generated by Prisma Cloud for the host that runs Console. The Common Name is typically your hostname plus domain name. For example, it might be www.example.com or example.com.
    (Default) By default, the Common Name is assigned the output from the command hostname --fqdn.
    Specifies the Common Name to be used in the certificate generated by Prisma Cloud for the hosts that run Defender.
    (Default) By default, the Common Name is assigned the output from the command hostname --fqdn.
    You can also control the Subject Alternative Names (SANs) in Console’s certificate.

    Securing access to Console with custom certificates

    Secure access to Console with your own custom certificates.
    Prerequisites:
    • Your certs have been generated by a commercial Certificate Authority (CA) or with your own Public Key Infrastructure (PKI). You should have the following files on hand:
      • A .pem file, which contains your certificate and your Certificate Authority’s intermediate certificates.
      • A .key file, which contains your private key.
    1. Have your signed certificate (.pem file) and private key (.key file) ready to be accessed and uploaded to Console.
      Make sure that the private key starts and ends with:
      ----BEGIN PRIVATE KEY----
----END PRIVATE KEY----
      or:
      -----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
    2. Open Prisma Cloud Console in a browser.
    3. Navigate to
      Manage > Authentication > System Certificates
      .
    4. Concatenate your public certificate and private key into a single PEM file.
      $ cat server.crt server.key > server-cert.pem
    5. Open the
      TLS certificate for Console
       section
      1. Upload the PEM file into the
        Concatenate public cert and private key (e.g., cat server-cert.pem server-key.pem)
      2. Click
        Save
    6. Verify that your certs have been correctly installed.
      Open your browser, and navigate to: https://<CONSOLE_HOSTNAME>:8083
      If you see the locked padlock icon, you have installed your certs correctly.
      HTTP Public Key Pinning (HPKP) was a security feature that was used to tell a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of Man In The Middle (MITM) attacks with forged certificates. This feature is no longer recommended. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning

    Certificate-based authentication to Console

    This feature allows the Console to verify the client’s CA certificate when accessing the Console. Use certificates from an implicitly trusted CA for securing the TLS connection. To enable this feature, follow the steps below:
    1. Open Console, and go to
      Manage > Authentication > System Certificates
      .
    2. Open the
      Certificate-based authentication to Console
       card.
    3. Under
      Console Authentication
       upload the CA certificate(s) in PEM format, then click
      Save
      .
      If you have multiple CAs, such as a root CA and several issuing CAs, you must add all these certificates into the PEM file. The order of certificates in the PEM file should be from the lowest tier of the hierarchy to the root. For example, if you have a 3 tier hierarchy that looks like this:
      ->RootCA
     ->IntermediateCA
          ->IssuingCA1
          ->IssuingCA2
      Your PEM file should be ordered as IssuingCA1, IssuingCA2, IntermediateCA, RootCA. To create such a PEM file, you’d get the public keys of each CA in PEM format and concatenate them together:
      $ cat IssuingCA1.pem IssuingCA2.pem IntermediateCA.pem RootCA.pem > CAs.pem

    Console-Defender communication certificates

    By design, Console and Defender don’t trust each other and use certificates to mutually authenticate when Defender establishes a connection with Console. The certificates for Console-Defender communication are issued by the Defender CA (defender-ca.pem). The Defender CA is a self-signed CA, generated by Console, and it’s valid for three years. Console is considered the server and Defender the client. Console generates certs for each party, and signs them with the Defender CA.
    Prisma Cloud automatically rotates the Defender CA and related server and client certificates 1.5 years before the Defender CA expires. Console and Defender use the old certs until the old Defender CA expires.
    New Defenders, deployed after the certificates have been rotated, automatically get both the new and old certificates. Existing Defenders, however, must be redeployed to get the new certificates. Existing Defenders use the old certificates until they expire. Thereafter, these Defenders won’t be able to establish a connection to Console until they’re redeployed.
    Single Defenders upgraded from the Console UI don’t get newly rotated certificates. To set up single Defenders with the new certificate, you must manually redeploy them.
    To identify which Defenders need to be redeployed, go to
    Manage > Defenders > Manage > Defenders
    . Use the
    Status
     column to identify the Defenders that are using an old certificate. Use the note at the top of the page to understand how many Defenders require redeployment, and when the old certificate will expire.
    Use the
    Using old certificate
     filter on the Defenders list to see only the Defenders that are using an old certificate:
    If you still have Defenders in your environment that are using an old certificate, which is about to expire in 60 days or less, you will get notified once entering the Console UI:
    If the old certificate has expired, and you still have Defenders in your environment that are using the expired certificate, you will get notified once entering the Console UI. The
    Status
     column on the Defenders page will reflect the Defenders that are using an expired certificate. Use the
    Certificate expired
     filter on the Defenders list to see only the Defenders with expired certificates.

    Additional technical details

    This section provides additional technical details about how the certificates that secure Console-Defender communication are managed.

    What is the rotation model?

    When Console is first deployed, it generates a set of certs for Console-Defender communication - a Defender CA, a Defender server cert, and a Defender client cert (with keys). The certs are valid for three years. Console initiates the certificate rotation. Console rotates the certs 1.5 years before the Defender CA expires. Thereafter, Console holds two sets of certificates: old and new Console rotates the new certs 1.5 years before the new Defender CA expires. The old certs are deleted, the new certs become the old certs, and a new set of certs are created.
    Newly deployed Defenders, after rotation, are deployed with two sets of certs: old and new. Defenders that aren’t redeployed only have the old client certs and CA, and keep using them until they expire.
    Until the old Defender CA expires, Console responds with the old Defender certs during the TLS handshake when Defender tries to connect to Console. As long as the old Defender CA is valid, Defender uses the old client cert for TLS handshakes. When the old certs expire, Defender uses the new certs for TLS handshakes.

    Which certificates are rotated?

    Console rotates the following files:

    Are all certs rotated at the same time?

    Yes, the Defender CA cert, server cert, and client cert are all rotated at the same time.

    What triggers Console to regenerate and rotate the certs?

    Console checks the expiration date of the Defender CA, and rotates all certs 1.5 years before the Defender CA expires.

    What is the rotation frequency?

    Once every 1.5 years.

    What happens when you upgrade Prisma Cloud Compute?

    When Console or Defenders are upgraded, the old, unexpired certificates remain on the system. Defenders that only have the old certificates are supported until the old Defender CA expires.

    How can you programmatically determine that certs have been rotated?

    Look for changes to the Defender certificates on the machine that runs Console. Certificates are stored in /var/lib/twistlock/certificates.
    Inspect the Defender CA cert for its expiration time. When the .old suffix is added to the cert file, you will know it has been rotated.

    Can you manage the certificate lifecycle yourself?

    Yes, for Compute Edition (self-hosted) only.
    SaaS Defenders connect to Console using an API token, not certs.

    After certs have been rotated, what’s returned from api/v<VERSION>/defenders/daemonset.yaml?

    The DaemonSet yaml will include both sets of new and old certs:
    New certs:
    • defender-ca.pem
    • defender-client-cert.pem
    • defender-client-key.pem
    Old certs:
    • defender-ca.pem.old
    • defender-client-cert.pem.old
    • defender-client-key.pem.old

    Which Defender types support certificate rotation?

    Supported Defender types:
    • Container Defenders (Windows and Linux)
    • Host Defenders (Windows and Linux)
    • DaemonSet Defenders
    • App-Embedded Defenders, including Fargate
    Serverless Defenders aren’t supported. Serverless Defenders are always deployed with old, unexpired certs, even if new certs exist.

    What happens the moment a Defender’s old certs expire?

    Defenders can switch to new certificates from old certificates at runtime. No restart is required.

    Admission control certificates

    Prisma Cloud provides a dynamic admission controller for Kubernetes built on the Open Policy Agent (OPA). The admission control certificate is used for the authentication between the Defenders and the admission webhook. When deploying the admission webhook, make sure it is configured with the right CA bundle, according to the Defender’s admission certificate. See the webhook configuration section on the admission control article.

    Recommended For You

    © 2023 Palo Alto Networks, Inc. All rights reserved.