Consul + CyberArk WIM: External CA for the service mesh

Consul Enterprise 2.0 lets you use CyberArk Workload Identity Manager as an external CA for the mesh, anchoring trust in PKI your security team already governs.

Mridul GuptaJuly 31, 2026 9 min readOriginal

Every service in a Consul service mesh gets a short-lived TLS certificate that proves its identity. By default, Consul runs its own certificate authority to issue those certificates. That is convenient, but it also means the trust anchor for your entire mesh lives inside Consul rather than inside the PKI your security team already operates and audits.

Consul Enterprise already supports Vault and AWS Certificate Manager as external certificate authorities (CAs) for Connect, its service mesh. Organizations that standardize on CyberArk instead can now also use CyberArk Workload Identity Manager (WIM), formerly Venafi Firefly, as its external CA. Service mesh identities are then anchored to a CA your security team already governs, while Consul continues to do what it does best: distribute and rotate workload certificates automatically.


Capability	Availability	What it enables
CyberArk WIM external CA for Connect	Consul Enterprise 2.0.0	Issue mesh mTLS certificates through CyberArk WIM (formerly Venafi Firefly), anchored to your CyberArk root
Automatic trust continuity	Consul Enterprise 2.0.0	Service mesh keeps working when CyberArk WIM rotates its issuing intermediate — no manual intervention
Multi-datacenter via cluster peering	Consul Enterprise 2.0.0	Federate datacenters that each chain to the same CyberArk root

The result is simple: your service mesh, your CA, one trust anchor.

What the CyberArk WIM integration is

CyberArk Workload Identity Manager is a distributed issuer designed for high-volume, short-lived workload certificates. Consul integrates with it through the Connect CA provider-named pan-distributed issuer.

The division of labor is straightforward:

CyberArk owns the PKI hierarchy: a root CA whose private key is protected in an HSM, and one or more subordinate CAs beneath it. The root is the stable anchor every workload ultimately trusts.
CyberArk WIM is the issuing intermediate. A subordinate CA delegates issuance authority to it, and it signs short-lived certificates on demand.
Consul submits certificate signing requests (CSRs) to WIM and distributes the resulting leaf certificates — together with the full issuing chain — to every proxy, agent, server, and gateway in the mesh, renewing them automatically before they expire.
The CyberArk Control Plane governs issuance policy and collects audit and issuance events from WIM, so your security team retains central policy and visibility over what the mesh issues.

Here is that same flow end to end: A workload's sidecar gets its certificate through Consul, which requests it from CyberArk WIM and hands back the signed leaf with its full issuing chain.

When to use it

Reach for this integration when:

You already standardize on CyberArk or Venafi for PKI and want service mesh identities to live under the same root of trust.
Your security or compliance team needs the mesh CA to be a CA they govern and audit, not Consul-internal.
You want short-lived certificate issuance without running and protecting a separate signing key inside Consul.

If you have no external PKI requirement, Consul's built-in CA remains the simplest option. This integration exists specifically to put your mesh under an existing CyberArk trust hierarchy.

Prerequisites and supported topology

To configure the provider, you need:


Requirement	Why
A reachable CyberArk WIM / Firefly request endpoint	Consul authenticates and submits signing requests here
A reachable CA chain endpoint	Consul reads the current CA chain to learn the trust anchor and issuing chain
An issuance policy	Defines what WIM will sign for the mesh
A short-lived auth token	Consul presents it when calling WIM

<p></p>

Single datacenter

In a single datacenter, Consul servers point at one CyberArk WIM endpoint. The WIM- issuing intermediate sits beneath a subordinate CA, which in turn chains to the HSM-protected root. Consul reads the CA chain to identify your CyberArk root as the trust anchor, submits CSRs to WIM, and distributes the issued leaf certificates to every sidecar. WIM streams issuance events to the CyberArk Control Plane for policy enforcement and audit.

The proxies trust your CyberArk root. Every leaf Consul hands them is served together with the full issuing chain, so a verifying peer that trusts only the root can still build a complete path to it.

Multiple datacenters

For multiple datacenters, the supported model is cluster peering, where each datacenter runs its own WIM-backed Consul CA, all subordinate to the same CyberArk root. That topology is covered in its own section below.

What the provider does

Authenticates to CyberArk WIM at startup and when configuration changes.
Learns your CyberArk root from the CA chain and uses it as the mesh trust anchor.
Submits certificate signing requests to WIM and distributes the issued leaf certificates, along with the issuing chain, to mesh workloads.
Tracks the issuing intermediate and reacts automatically when it changes.

Configuration

Configure the provider in the agent's connect stanza:

connect { 
  enabled     = true 
  ca_provider = "pan-distributed-issuer" 
 
  ca_config { 
    address         = "https://wim.example.com:8002" 
    chain_address   = "https://wim.example.com:8008" 
    token           = "<short-lived-auth-token>" 
    policy          = "mesh-issuance-policy" 
    tls_skip_verify = false 
  } 
}

The same configuration can be applied at runtime through the Connect CA configuration API:

curl --request PUT \ 
  --header "X-Consul-Token: <acl-token>" \ 
  --data @- https://127.0.0.1:8500/v1/connect/ca/configuration <<'JSON' 
{ 
  "Provider": "pan-distributed-issuer", 
  "Config": { 
    "Address": "https://wim.example.com:8002", 
    "ChainAddress": "https://wim.example.com:8008", 
    "Token": "<short-lived-auth-token>", 
    "Policy": "mesh-issuance-policy", 
    "TLSSkipVerify": false 
  } 
} 
JSON

Configuration keys


Key	Type	Required	Description
address	string	yes	CyberArk WIM / Firefly endpoint used for authentication and signing requests
chain_address	string	yes	Endpoint Consul reads the CA chain and returns the issuing chain
token	string	yes	Short-lived bearer token CyberArk WIM accepts for client authentication
policy	string	yes	The CyberArk WIM issuance policy Consul should use
tls_skip_verify	bool	no	Skip TLS verification of the WIM endpoint. For non-production or self-signed endpoints only; leave false in production

<p></p>

The auth token is intentionally short-lived. Plan to supply Consul with a freshly issued token whenever you re-apply the CA configuration and treat token rotation as a routine operational task rather than a one-time setup step.

Authentication methods WIM supports

The token in ca config isn't just an opaque secret — it's a JWT, and CyberArk WIM checks it against one of a small set of client authentication policies that a WIM administrator configures:


Method	How it verifies the token	When to use it
JWT_OIDC	Resolves the issuer and signing keys live from an OIDC discovery endpoint	Platforms already running an OIDC provider, such as Kubernetes service account tokens
JWT_JWKS	Verifies against a static, pre-configured JSON Web Key Set	No live discovery call needed; keys are provisioned ahead of time
JWT_STANDARD_CLAIMS	Checks standard claims (issuer, subject, audience) against an explicit allow-list	Fine-grained control: map specific subjects to specific issuance policies
None	No authentication	Not for production

<p></p>

Whichever policy your WIM administrator configures, Consul's job doesn't change: Present the token and let WIM decide whether to trust it.

This is a separate hop from how WIM itself authenticates upstream to CyberArk Certificate Manager — that connection uses either OIDC/JWT (recommended, dynamic, Kubernetes-native) or a static username and password (for non-Kubernetes deployments). Don't confuse the two: One governs who WIM lets request certificates, the other governs how WIM itself proves its identity to the CA behind it.

How certificates flow: roots, intermediates, leaves, and SPIFFE

There are four layers of certificate in this model, and it helps to keep them distinct:


Layer	Owner	Lifetime	Role
Root	CyberArk (HSM-protected key)	Long	The stable trust anchor every workload trusts
Subordinate CA	CyberArk	Long	Chains to the root and delegates issuance to WIM
Issuing intermediate	CyberArk WIM (Firefly)	Short	Signs leaf certificates; may rotate
Leaf	Consul (via WIM)	Very short	The certificate a single workload presents

<p></p>

Every Consul leaf carries a standard SPIFFE identity that encodes the service and its trust domain. Peers verify that identity against the shared CyberArk root. The mesh's identity semantics don't change because the CA is external — what changes is who anchors the trust.

Intermediate CAs per cluster / control-plane domain

Each Consul datacenter, or control-plane domain, is bound to its own CyberArk WIM issuing intermediate — its own trust domain, delegated from the shared CyberArk root. That isolation is deliberate: A compromised intermediate is scoped to the cluster whose certificates it signs, not the whole mesh.

What's actually trusted is narrower than the whole chain. Envoy's trust store holds only the self-signed root. Everything beneath it — the subordinate CA, WIM's issuing intermediate, even the leaf's own signer — is a presented chain: shipped alongside every certificate so a root-only verifier can still build a path.

Intermediate CA rotation

WIM's issuing intermediate is short-lived and can change — for example, when the WIM instance restarts. Consul detects this automatically, the next time it requests a certificate, and reconciles within seconds rather than waiting on a periodic check. Because the root never changes during an intermediate rotation, there's no mesh-wide re-issuance event: Certificates already issued keep working off their already-attached chain until they expire naturally, and only certificates issued after the rotation pick up the new intermediate — immediately, not on a delay. No operator action is required.

Bootstrapping the CA

Issuing a leaf certificate

The important property is that Consul presents the complete issuing chain with each leaf — however many intermediates your CyberArk hierarchy uses between the issuing CA and the root. A peer only needs to trust your CyberArk root to validate any certificate in the mesh.

Multi-datacenter with cluster peering

When you run more than one datacenter, the supported topology is cluster peering. Each region runs its own CyberArk WIM issuing intermediate, all of them subordinate to the same CyberArk root, and the Consul datacenters in each region submit CSRs to their local WIM. Every WIM reports issuance events to the same CyberArk Control Plane, so policy and audit stay centralized even as issuance is distributed.

Because every datacenter chains to the same CyberArk root, federation is straightforward: Cluster peering exchanges root trust bundles, and a workload in dc1 can verify a workload in dc2 using the shared anchor. There is no need to cross-sign intermediates or coordinate issuing CAs between datacenters.

This model also keeps each datacenter independent operationally. If the CyberArk WIM serving one region rotates its issuing intermediate, that datacenter converges on its own; the peer datacenter is unaffected because it was only ever trusting the shared root.

Each datacenter uses the same provider, pointed at its own CyberArk WIM endpoint:

# Datacenter A 
connect { 
  enabled     = true 
  ca_provider = "pan-distributed-issuer" 
  ca_config { 
    address       = "https://wim-dc-a.example.com:8002" 
    chain_address = "https://wim-dc-a.example.com:8008" 
    token         = "<dc-a-token>" 
    policy        = "mesh-issuance-policy" 
  } 
} 

# Datacenter B 
connect { 
  enabled     = true 
  ca_provider = "pan-distributed-issuer" 
  ca_config { 
    address       = "https://wim-dc-b.example.com:8002" 
    chain_address = "https://wim-dc-b.example.com:8008" 
    token         = "<dc-b-token>" 
    policy        = "mesh-issuance-policy" 
  } 
}

Then establish cluster peering between the two datacenters as you normally would; because both chain to the same CyberArk root, the exchanged trust is sufficient for cross-datacenter mTLS.

Why this is better

Putting the Consul mesh CA under CyberArk Workload Identity Manager closes a long-standing gap between how organizations govern PKI and how a service mesh issues identity:

Mesh identities are anchored to a CA your security team already owns and audits.
Consul still automates the hard part — issuing, distributing, and renewing short-lived workload certificates.
A CyberArk WIM intermediate rotation no longer threatens the mesh; trust continuity is automatic.
Multiple datacenters federate cleanly through cluster peering on a shared root.
You get the operational simplicity of Consul's mesh CA with the governance of your existing CyberArk PKI — one trust anchor, automatically maintained, across single- and multi-datacenter deployments.