1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Administrator’s Guide (Compute)
    5. Configure
    6. Prisma Cloud Compute certificates

    Prisma Cloud Compute certificates

    This article summarizes all the certificates used by Prisma Cloud Compute. For each certificate, you can learn more about its functionallity, 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, Enterprise edition
    Client certificates
    To enforce Docker access control, client certs should be installed on any host where the docker client can be run.
    Clients (users) access to remote Docker Engine instances
    Customize your own certificates for your clients
    Explicit list of trusted certificates can be defined under
    Manage > Authentication > System certificates > Client certificates > Explicit certificate trust list
    Console CA
    Customize under
    Manage > Authentication > System certificates > Client certificates > CA certificate
    Compute edition, Enterprise 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.
    Defender CA (defender-ca.pem)
    Yes, for Compute Edition only.
    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 install 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 host name 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.

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

    Docker role-based access control certificates

    These certificates settings are related to the Docker access control feature. Using the Docker access control you can validate that Docker commands only run from remote machines through Defender on port 9998. Any user running Docker commands on port 9998 must be authenticated and authorized. By default the Console generates certificates for users to authenticate to Defender. Any command run against Defender must also be explicitly allowed.
    Prisma Cloud lets you use your own certificates for Docker access control. Customize the Docker access control certificates, by providing Prisma Cloud the CA that signs the client (user) certificates. You can also specify an explicit list for client trusted certificates.
    NOTES:
    • External certification authority (CA) section will be visible only to an Admin role user.
    • All trusted certificate information will be retrieved from the certificate itself, so the user doesn’t have to manually add info such as CN, issuer etc.
    • Only the public portion of a user certificate should be added to the explicit trust list. Private keys are not required and should be excluded from this process.

    Setting up your custom certs

    To set up your custom certs:
    1. Open Console, and go to
      Manage > Authentication > System certificates
      .
    2. Open the
      CA certificate
       card.
      1. Under
        CA certificat
        , upload CA certificate to trust.
        Once this configuration is enabled, users must copy their keys (both public and private) to the host they’re using to run commands with docker or kubectl. Though the path can be referenced in each command, it’s usually simpler to place them in the default directory that docker looks in for certificates (~/.docker).
        Each user certificate used with Prisma Cloud must have the user’s CN embedded in the Subject field of the certificate. You can validate these settings by running the following command against the certificate:
        $ openssl x509 -in .docker/cert.pem -text | grep Subj
Subject: CN=username
        Finally, Docker requires that the CA certificate used to sign the server certificate on the nodes Prisma Cloud is protecting must also be in the ~/.docker folder, in a file called ca.pem. Because the 'server' certificate used in this deployment model is still generated by Prisma Cloud, this means that on each host where you’re running docker or kubectl commands, you must also add the CA certificate to this folder.
    3. You can also choose to set
      Explicit certificate trust list
       to
      ON
       (this configuration is optional)
      Explicit certificate trust list allows you to create a list of explicitly trusted custom certificates. A typical use case of this feature would be when you have multiple certificates issued to a given user, but only want specific ones to be available for use with Prisma Cloud. By adding an explicit trust list, you can control what certificates can be used, as Prisma Cloud compares any certificates presented to it against the allowed trusted certificates list. This way, a user using a certificate not in the explicitly allowed list will not be able to use the certificate with Prisma Cloud, even if it was issued by a trusted CA. Note that this feature is valid only when a custom CA is configured. When enabled, this feature allows users to add new certificates to a table by uploading public certificates in PEM format.
    4. Click
      Add certificate
      , copy the PEM-formatted public certificate which was issued by the trusted CA, then click
      Add
      .
      When a custom certificate is provided to Prisma Cloud, it first checks the certificate against this list. If the certificate is matched to an entry in the list, then the previously existent flow continues. If the certificate is not in the trusted list, then the authentication fails with an error 'Certificate not in certificate trust list configured in Prisma Cloud'.

    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 require redployment, go to
    Manage > Defenders > Manage > Defenders
    . Using the
    Status
     column, you will be able 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 certificate.

    Additional technical details

    This section provides additional technical details about how the certs 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 that is 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

    Recommended Videos

    Recommended videos not found.

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

    Techdocs Logo