Consul + CyberArk WIM: External CA for the service mesh

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. 

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: 

»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 

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: 

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: 

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. 

»Further reading 

• Consul Connect CA configuration reference 

• Consul cluster peering 

• CyberArk Workload Identity Manager (formerly Venafi Firefly) 

• SPIFFE and service identity in Consul 

• Workload Identity Manager authentication methods with Certificate Manager