In August we introduced the Imperva SSL Integration Center with one idea behind it: the certificates protecting your applications should be governed where you already govern certificates, and deploy to Imperva Cloud WAF without anyone copying a key. DigiCert Trust Lifecycle Manager was the first integration. Keyfactor Command followed. Today the Integration Center adds the platform that a large share of enterprise PKI teams run machine identity management on: Venafi, now part of Palo Alto Networks, delivered as CyberArk Certificate Manager and Palo Alto Networks Next-Gen Trust Security.

The timing is not an accident. Under the CA/Browser Forum timeline, maximum public TLS certificate lifetimes drop to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. Every manual step in a renewal becomes a step you repeat eight times a year, and the manual step breaks first. A WAF that sits outside the automation is the step most likely to break.

What ships: Imperva WAF as a machine

In Certificate Manager terms, an application that receives certificates is a machine. The platform discovers what is installed on it, provisions certificates to it and records every installation. Imperva Cloud WAF is now a machine type, listed alongside the load balancers, gateways and firewalls the platform already manages, in both of the platform’s current homes:

In the platform’s own words, creating the machine lets it “discover the certificates of the sites in your Imperva Cloud Web Application Firewall (WAF) account and provision custom certificates to them.” With the cloud connector, there is no automation host to stand up and no script to maintain: the platform talks to the Imperva API, authenticated by an API ID and key from your Imperva account, and the credentials can be drawn from a credential manager integration rather than typed into a form. Teams whose policy keeps such connections inside their own network can run the same connector on a VSatellite instead.

For WAF Gateway, the self-hosted platform (CyberArk Trust Protection Foundation, formerly Venafi Trust Protection Platform) carries a separate, long-standing Imperva MX driver that provisions key pairs to the Imperva management server for on-premises deployments. That path has its own prerequisites and limits; the documentation lists them.

How it works: provisioning certificates to Imperva Cloud WAF

The whole setup is two screens in the certificate platform and one API key in the Imperva Cloud Security Console.

  1. Generate an API key in Imperva under Account > Account Management > API Keys, with the entitlement to manage custom certificates for the sites you will provision to, and copy the API ID and API Key. Note the numeric Site ID of each target site from its General settings.
  2. Create the machine. Choose Imperva WAF as the machine type (or Imperva WAF (VSatellite) to run the connector in your network), confirm the hostname (the default is my.imperva.com) and port 443, supply admin credentials directly or select stored credentials from a credential manager integration, enter the API ID and API Key, and click Test Access. Continue is enabled only when the connection test succeeds.
  3. Set the discovery and provisioning schedule for the machine, the same way as for any other machine on the platform.
  4. Provision. From Insights > Certificate Installations > Machines, select Provision on the Imperva WAF row, choose the certificate from the inventory, check its subject, validity and fingerprint, enter the Site ID, and save. Push upon saving is on by default; turn it off to stage the certificate without deploying it.

The platform provisions the certificate to the Imperva site and writes an installation record on the Installations tab, so the WAF now shows up in the same inventory, the same reports and the same renewal workflow as everything else the platform manages. The target site must already exist in Imperva with a site ID; the integration installs to it, it does not create it.

What this means for your team

  • One system of record, now including the WAF. Certificates governed in Certificate Manager deploy to Imperva sites on the platform’s schedule, with the installation recorded where your auditors already look. The WAF stops being the exception to your automation.
  • Nothing to host by default. The connection runs from the platform to the Imperva API. No automation server, no post-enrollment script, no credentials pasted into a job definition: stored credentials can come from a credential manager integration.
  • Your certificate is the one served. Since the 14 September release, when a site holds a valid custom certificate and a valid Imperva site certificate for the same host, Cloud WAF serves yours; the Imperva certificate is the fallback only if yours is invalid or does not cover the host. Bring-your-own-CA means exactly that.
  • Ready for the 47-day clock. Shorter lifetimes are a scheduling problem, and the platform already carries a 47-Day Validity Readiness Dashboard. With the WAF inside the loop, the renewal that used to need a person now needs a schedule.
  • No change of CA. You keep your issuing CAs, your policies and your approval workflows; the WAF is one more place they deploy to.
  • Both estates covered. Cloud WAF through the SaaS platform, WAF Gateway through the self-hosted driver, so a hybrid estate does not need two processes.

Imperva-managed certificates: nothing changes

Many Cloud WAF customers let Imperva issue and renew their certificates, and for them nothing changes: Imperva site certificates keep renewing on their own, with no action and no integration to configure. The Integration Center is for the teams that run their own CA and PKI processes and want the WAF to follow them. Nobody is being asked to switch certificate authorities in either direction.

A wider Integration Center

Each certificate lifecycle platform reaches the Integration Center in its own shape: DigiCert through a post-enrollment agent script, Keyfactor through a Universal Orchestrator extension, and now Venafi through the machine model of CyberArk Certificate Manager and Palo Alto Networks Next-Gen Trust Security. The destination is the same Imperva API every time, which is why the customer-side work stays at one API key and one site ID whichever platform you run. Further platforms are in progress.

The partnership also reaches past the WAF. Palo Alto Networks is a Thales technology partner across the wider portfolio, and the same certificate platform that now feeds Imperva can draw on Thales Luna HSMs for key protection where the policy demands it.

Get started with Imperva WAF in Next-Gen Trust Security

If you run CyberArk Certificate Manager or Palo Alto Networks Next-Gen Trust Security today, the integration is already in your Installations menu and there is nothing to install. Three steps get you to the first certificate the platform provisions:

  1. In the Imperva Cloud Security Console, create an API key under Account > Account Management > API Keys with the entitlement to manage custom certificates, and note the Site ID of each site the platform will serve.
  2. In the certificate platform, follow Create an Imperva WAF Machine, then Provision to an Imperva WAF. The same steps under the CyberArk name are in the Imperva WAF machine documentation.
  3. Running WAF Gateway? Start from the Imperva MX driver documentation for Trust Protection Foundation and check the version prerequisites against your deployment.

The Imperva side of the setup, including API key permissions and the custom certificate priority rules, is in the SSL Integration Center documentation. If 47-day renewals are still a plan rather than a process in your organization, five steps to prepare is the place to start.

The certificate manager that already knows every certificate you own now knows the one on your WAF as well: who requested it, which CA issued it, when it renews, and that the platform installed it on schedule. When the 47-day clock starts in March 2029, the WAF renewal is already one more scheduled job, recorded where the rest of them are.

The post Bring Your Own CA: Palo Alto Networks Joins the Imperva SSL Integration Center appeared first on Blog.