# Venafi (CyberArk Certificate Manager)

> Machine identity security: discovery, issuance, provisioning, renewal and retirement of TLS/SSL
> certificates, SSH keys, code-signing keys and workload identities across data centers, clouds and
> Kubernetes. Two public REST contracts — a multi-region SaaS Control Plane and a customer-installed
> Trust Protection Foundation WebSDK.

GENERATED by API Evangelist on 2026-09-02 from Venafi's own published surface. Venafi does not
serve an llms.txt: https://developer.venafi.com/llms.txt returns 404 and every other probed host
returns 404, a 403 or an SPA shell. This file is a third-party summary, not a provider document.

Corporate note: Venafi was acquired by CyberArk (2024); Palo Alto Networks subsequently acquired
CyberArk. As of 2026-09-02 every path on venafi.com 301-redirects to the Palo Alto Networks
Certificate Manager marketing page. The engineering surfaces below are all still live under
Venafi-owned hostnames, and everything here was read from them.

## APIs

- [Certificate Manager - SaaS API](https://developer.venafi.com/tlsprotectcloud/reference/tls-protect-overview):
  184 operations, 120 paths, OpenAPI 3.0.1. Base `https://api.venafi.cloud` (US), with
  `api.eu`, `api.uk`, `api.au`, `api.sg` and `api.ca` under `venafi.cloud` for other regions.
  Certificates, certificate requests, issuing templates, applications, machines and machine
  identities, credential managers, users, teams, service accounts, tags, event logs, VSatellites,
  webhook connectors, monitoring, approval rules, plugins, Workload Identity Manager.
- [Trust Protection Foundation WebSDK](https://docs.venafi.com/Docs/currentAPI/): 388 operations,
  364 paths, OpenAPI 3.0.1, version 26.1.1. Self-hosted — server is templated
  (`https://{dnsname}/`), so the base URL is whatever the operator installed it on. Certificate
  management, discovery, identity and permissions, OAuth administration, SSH certificates and
  authorized keys, code signing and HSM, SecretStore, flows, recycle bin, statistics.
- ACMEv2 server (RFC 8555) with External Account Binding, for ACME clients such as Lego and
  cert-manager: https://docs.venafi.cloud/vaas/configurations/acme-server-overview/

## Authentication

- SaaS user key: `tppl-api-key: <uuid>` header. Obtain from the console (avatar > Preferences >
  API Keys) or `vcert getcred --email <address>`.
- SaaS service account: bearer token; scopes enumerated at `GET /v1/serviceaccounts/scopes`.
- Self-hosted: OAuth 2.0 bearer. Five grant paths under `/vedauth/authorize/` (oauth, device, jwt,
  certificate, integrated); refresh at `/vedauth/authorize/token`; revoke at `/vedauth/revoke/token`.
  33 scopes, published as prose in each operation description, normalised in `scopes/`.
- Docs: https://docs.venafi.cloud/api/obtaining-api-key/

## What an agent needs to know

- No idempotency. Neither contract declares an `Idempotency-Key` header. A retried POST can issue a
  duplicate certificate.
- No published rate limits, no `429` response, no `RateLimit-*` or `Retry-After` header anywhere in
  either spec.
- Dry-run exists for the operations that matter: `/certificaterequests/validation`,
  `/certificates/validation`, `/certificateinstances/validation`, plus connection-test endpoints.
- Reversibility: retirement (`/certificates/retirement`) is reversible via `/certificates/recovery`;
  `/certificates/deletion` is permanent and accepts only already-retired certificates. Self-hosted
  deletes are reversible via `POST /vedsdk/recyclebin/restore` (scope `admin:recyclebin`). No
  retention window is published for either.
- Errors are plain JSON, not RFC 9457: `{"errors":[{"code":<int>,"message":"...","args":[...]}]}`.
  The numeric code is stable; 90 of them are documented.
- Pagination is a request-body `paging: {pageNumber, pageSize}` object on SaaS search operations and
  `offset`/`limit` query parameters on the WebSDK. No cursors, no Link header.
- Property names are camelCase; top-level resources carry an `object` property naming their type.
  Ids are bare UUIDs with no type prefix.

## Tooling

- vcert (Go SDK + CLI, v5.13.9): https://github.com/Venafi/vcert
- vcert-python (PyPI `vcert`, 0.21.1): https://github.com/Venafi/vcert-python
- pyVenafi (PyPI `pyvenafi`, 1.1.0): https://github.com/Venafi/pyVenafi
- VenafiPS (PowerShell Gallery, 7.0.6): https://github.com/Venafi/venafips
- Terraform provider (registry `Venafi/venafi`, 0.24.1): https://github.com/Venafi/terraform-provider-venafi
- Ansible collection (`venafi.machine_identity`, 1.3.1): https://github.com/Venafi/ansible-collection-venafi
- vsign, code signing (v1.0.3): https://github.com/Venafi/vsign
- HashiCorp Vault PKI backend: https://github.com/Venafi/vault-pki-backend-venafi
- cert-manager issuer: https://cert-manager.io/docs/configuration/venafi/
- Archived and stale: vcert-java (Maven `io.github.venafi:vcert-java`, 0.9.3, 2022) and vcert-ruby
  (RubyGems `vcert`, 0.3.1, 2021). Java and Ruby have no maintained first-party client.

## No agent surface

- No MCP server. The npm packages matching "venafi" that mention MCP are published by an
  individual (github.com/abhadfield/venafi-integration-mcps), not by Venafi.
- No A2A agent card. `/.well-known/agent-card.json` and `/.well-known/agent.json` return 404, 403
  or an HTML SPA shell on every probed host.
- No `/.well-known/security.txt`, `openid-configuration`, `oauth-authorization-server` or
  `api-catalog` on any host.
- No AsyncAPI. A real webhook surface exists (Connectors API, generic + Slack, EXPIRATION filter,
  10 per tenant) but no event contract is published, and no signing secret or signature header is
  documented.

## Operations

- Status: https://status.venafi.cloud/ (Atlassian Statuspage; machine-readable at
  `/api/v2/summary.json`)
- Changelog: https://docs.venafi.cloud/whatsnew/ and https://docs.venafi.cloud/enhancements/
- Support: https://community.cyberark.com/s/
- Console: https://login.venafi.cloud/
- Source: https://github.com/Venafi
- Pricing: none published. Enterprise contract only; venafi.com/pricing/ 301s to the Palo Alto
  Networks product page.