Skip to content
Docs sslbrain sslbrain.com

Fortinet FortiWeb WAF

Copy link to the page “Fortinet FortiWeb WAF”

← All integrations

Firewall and VPN · Web server

Renews CA certificates on selected FortiWeb server policies and SNI policies with TLS verification and rollback.

The appliance runs the package and connects to Fortinet FortiWeb WAF through FortiWeb REST API over HTTPS on port 443. No agent is installed on Fortinet FortiWeb WAF.

What happens

  1. The appliance connects to Fortinet FortiWeb WAF through FortiWeb REST API on port 443.
  2. Discovery matches the fingerprint from a TLS connection with SNI to the certificate object used by the selected policy. Select the policy, optional SNI member and concrete server name. Address and port overrides support checks through NAT. Unresolved certificate identity or destination produces a share-safe diagnostic without changes.
  3. The agent checks name, validity and key match, imports PEM certificate and key under a new name and creates an intermediate group for the chain. Shared SNI and multi-certificate groups are copied while retaining other members and key slots. Only selected policies are pointed at the new objects.
  4. Every change is read back. A fresh TLS connection with the selected SNI must serve the new certificate with the correct name, trust and intermediates. Lost API responses are reconciled by reading before continuing; writes are never blindly repeated. If it fails: Failure after a binding switch automatically restores original binding values and checks the previous served fingerprints. A binding changed by another writer is preserved; the result identifies the recovery needed.
  5. When you select a destination that FortiWeb native ACME renewal manages, the agent takes over renewal for that binding only. ACME configurations and original certificates are retained, and the result lists the bindings taken over. Rollback and removal restore previous bindings, including ACME renewal, without deleting objects.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to FortiWeb REST API, port 443. No agent is installed.
You need
FortiWeb REST administrator username, password and selected VDOM. The Authorization header travels over verified HTTPS using system trust, a CA bundle or an exact SHA-256 certificate pin. Certificate and policy access must permit reads and writes. Connect to the HA primary; discovery makes no changes and does not test write permission.
Platform
FortiWeb with REST API v2; certificate paths follow the capabilities the device reports during discovery
Actions
Discovery, Installation, Verification, Rollback, Removal
Packages
fortiweb-api 1.0.0
Note
  • Bash and native PowerShell 7+ require Python 3.12+ and OpenSSL on the executing appliance or relay. Management certificates and backend-pool certificates are separate destinations. REST v2 was introduced in 6.3.6; authentication documentation covers 7.2+, while newer fields are chosen by discovery rather than an assumed version number. Regular-expression SNI selection must be unambiguous before changes.
  • A named VIP or interface address requires an explicit service address; the agent does not infer it from an object name. For multiple RSA/ECDSA certificates, the selected algorithm is checked using TLS 1.2. After the rollback retention period, the administrator can remove unreferenced sslbrain-prefixed objects; the agent retains original certificates and ACME configurations.

Certificate requirements

FortiWeb 8.0.5 documents RSA, DSA and ECDSA; DSA applies only to Reverse Proxy. Examples in 8.0.7 include RSA 2048/3072/4096 bits and ECDSA 256/384/521 bits. Agent key choices are RSA 2048/3072/4096 and ECDSA P-256/P-384. Import minima/maxima and the complete curve list are unpublished in these sources. CSR-menu RSA sizes are not import limits.

Import sources publish neither a Common Name (CN) requirement nor a CN-omission guarantee. The agent validates the concrete server name in the certificate and adds no CN requirement; SAN-only tlsserver/minimal input is preserved.

The cited sources publish no import requirement for clientAuth EKU or keyEncipherment KU. The agent requires neither. The certificate must work as a TLS server certificate for the selected names and client trust stores.

CSR documentation permits DNS and IP SANs but publishes no numeric SAN cap or complete external-import encoding rules. The agent matches wildcard and IP SANs to the concrete name without an arbitrary SAN cap. Native ACME wildcard from 7.6.1 and DNS-01 are separate issuance features, not an import version requirement for wildcard certificates.

REST import uses a PEM certificate and matching unencrypted PEM key. FortiWeb GUI documentation lists PEM, DER and PFX/PKCS#12, and the manufacturer REST collection includes PKCS12Certificate import. JKS and PFX AES versus legacy 3DES/RC2 compatibility are not documented here. The agent uses PEM without depending on a PFX encryption variant.

Supply intermediates from the leaf issuer upwards. The agent uses a new Intermediate CA Group and retains old intermediates for other multi-certificate key slots. Normally omit the root from the served chain; the manufacturer publishes no universal root-import prohibition. TLS verification requires the server to send the supplied intermediates.

Local certificate names are at most 63 characters. The agent generates short ASCII names and checks identity after import; existing object names are URL encoded for reads. Sources publish no PFX friendly-name/alias requirement. One filename/_id example does not establish every naming normalization.

Import sources publish no minimum or maximum lifetime. The agent checks current validity and reports expiry without an invented lifetime limit. Native ACME renewal intervals are not limits on imported certificates.

Get started