Skip to content

Issuer and TLS Protect Datacenter

We have two control planes you can connect Issuer to. Choose between the convenience of the SaaS-based Venafi Control Plane with TLS Protect Cloud, or the control of a self-hosted deployment with TLS Protect Datacenter. In this section you will learn how to use Issuer with TLS Protect Datacenter. For information on how to use CyberArk Workload Identity Manager (formerly known as Firefly) with Venafi Control Plane, see Issuer and Venafi Control Plane

Overview

In this section, Issuer will be deployed on Kubernetes and configured to bootstrap its security settings directly from the TLS Protect Datacenter, eliminating the need to connect to any other Venafi infrastructure.

The Issuer security configuration enables security teams to define policies that align with corporate security requirements. These policies govern the subordinate certificate used to sign certificates requested by clients, the policies applied to the requested leaf certificates, as well as the authentication and authorization configuration for the client.

Once Issuer is deployed and configured, it can serve certificate requests for various use cases, including modern scenarios like mTLS authentication for workloads, as well as traditional use cases such as TLS server termination.

In this way, the issued certificates are:

  • signed and trusted by your organization’s root CAs.

  • compliant with your organization’s PKI policy.

Issuer will handle the load of signing certificate requests, even during high rates of certificate renewals, instead of the TLS Protect Datacenter. TLS Protect Datacenter will only be required when Issuer is restarted or when renewing the subordinate CA certificate.

In this scenario, authentication between Issuer and the TLS Protect Datacenter will use OIDC, where the Kubernetes cluster hosting Issuer issues short-lived JWT credentials, which are then validated by TLS Protect Datacenter.

Prerequisites

  • An instance of Venafi TLS Protect Datacenter, configured with a certificate authority (such as ADCS), and a template that permits the issuance of subordinate CA certificates.

  • Access to the Venafi Configuration Console to configure authentication settings.

  • A Kubernetes cluster where Issuer will be deployed. The cluster must have its OIDC Discovery endpoint exposed for use by unauthenticated clients.

  • Check the network requirements.

Administrative functions

Configuring Issuer to work with TLS Protect Datacenter requires work from more than one administrator:

  • A TLS Protect Datacenter platform administrator is needed to configure the user, API integrations, and JWT mapping.

  • A PKI administrator is required to create policy folders in TLS Protect Datacenter, as well as to generate, modify, and import the security configuration that Issuer will use.

  • A Kubernetes Platform administrator is needed to bootstrap Issuer, and must have information about how Issuer will authenticate to TLS Protect Datacenter, security configuration, and bindings.

Let's begin

Here are the steps we'll take in getting started with Issuer on TLS Protect Datacenter:

  1. Authenticating to TLS Protect Datacenter In this step you'll learn how to configure an API integration in TLS Protect Datacenter, and configure authentication settings for Issuer.

  2. Create a CA template in TLS Protect Datacenter In this step you will create a new CA template. This will be used to sign the subordinate CA certificate for each Issuer.

  3. Create a policy folder in TLS Protect Datacenter In this step you will create a TLS Protect Datacenter policy folder in which to store the security configuration and define policies for the issuance of the subordinate CA certificates.

  4. Push an Issuer security configuration to TLS Protect Datacenter In this step you will create an Issuer security configuration and store it in TLS Protect Datacenter.

  5. Deploy an Issuer in Kubernetes In this final step, as a Kubernetes platform administrator, you will need to use the information from your TLS Protect Datacenter administrators regarding how Issuer should authenticate with TLS Protect Datacenter, and which security configuration it will use.

Known issues

  • As best practice dictates following the principle of least privilege in security, it is recommended that the users used by your Issuer instances to authenticate have minimal permissions in TLS Protect Datacenter. However, a side effect of this is that when Issuer starts, you may see the warning message below, indicating insufficient rights to retrieve the security configuration. Although this message appears, Issuer is still able to retrieve the security configuration, so you can safely ignore the warning:

    Warning   Secret Store - Insufficient Rights (Retrieve)    firefly had insufficient rights to retrieve the secret for entry 243046   Secret Store - Insufficient Rights (Retrieve)    firefly had insufficient rights to retrieve the secret for entry 243046

  • When Issuer is managed by TLS Protect Datacenter and the subordinate issuer is Zero Touch PKI, you must specify the validity period of the requested subordinate certificate in the relevant Policies folder. This validity setting will be used when issuing the subordinate certificate. For more information, refer to the Zero Touch PKI installation instructions.

What's next?