Hoppa till innehåll

← Alla integrationer

Brandvägg och VPN · Webbserver

Förnyar CA-certifikat på valda FortiWeb server policies och SNI-policyer med TLS-kontroll och rollback.

Appliancen kör paketet och ansluter till Fortinet FortiWeb WAF genom FortiWeb REST API över HTTPS på port 443. Ingen agent installeras på Fortinet FortiWeb WAF.

Så går det till

  1. Appliancen ansluter till Fortinet FortiWeb WAF genom FortiWeb REST API på port 443.
  2. Discovery jämför fingeravtrycket från en TLS-anslutning med SNI med certifikatobjektet den valda policyn använder. Välj policy och eventuellt SNI-medlem samt konkret servernamn. Adress och port kan anges för kontroll genom NAT. Oklar certifikatidentitet eller destination ger en delbar felkod utan ändringar.
  3. Agenten kontrollerar namn, giltighet och nyckelmatchning, importerar PEM-certifikat och nyckel under ett nytt namn och skapar en intermediärgrupp för kedjan. Delade SNI- och multi-certifikatgrupper kopieras med övriga medlemmar och nyckeltyper bevarade. Endast valda policies pekas på de nya objekten.
  4. Varje ändring läses tillbaka. En ny TLS-anslutning med valt SNI ska visa det nya certifikatet med rätt namn, tillit och intermediärer. Förlorade API-svar kontrolleras genom läsning innan agenten fortsätter; en ändring skickas inte blint igen. Om det misslyckas: Fel efter ett bindingsbyte återställer automatiskt de ursprungliga bindningarna och kontrollerar tidigare serverade fingeravtryck. Om någon annan ändrat en bindning skrivs den inte över; resultatet beskriver återställningen som behövs.
  5. När du väljer en destination som FortiWebs egen ACME-förnyelse hanterar tar agenten över förnyelsen för just den bindningen. ACME-konfigurationer och gamla certifikat bevaras, och resultatet visar vilka bindningar som togs över. Rollback och borttagning återställer tidigare bindningar, även ACME-förnyelsen, utan att radera objekt.

Tekniska detaljer

Anslutning
Paketet körs på appliancen, som ansluter över HTTPS till FortiWeb REST API, port 443. Ingen agent installeras.
Ni behöver
FortiWeb REST-administratörens användarnamn, lösenord och valda VDOM. Authorization-headern skickas över verifierad HTTPS med systemets trust store, CA-bundle eller exakt SHA-256-certifikatpin. Certifikat- och policyåtkomst ska tillåta läsning och skrivning. Anslut HA-primary; discovery ändrar inget och provar inte skrivrätt.
Plattform
FortiWeb med REST API v2; certifikatvägar väljs från de funktioner enheten visar vid discovery
Åtgärder
Discovery, Installation, Kontroll, Rollback, Borttagning
Paket
fortiweb-api 1.0.0
Observera
  • Bash och native PowerShell 7+ kräver Python 3.12+ och OpenSSL på den appliance eller relay som kör agenten. Management-certifikat och backend-poolcertifikat är separata destinationer. REST v2 introducerades i 6.3.6; auth-dokumentationen omfattar 7.2+, medan nyare fält väljs efter discovery i stället för ett antaget versionsnummer. Ett regular-expression SNI-match ska kunna avgöras entydigt före ändringar.
  • En namngiven VIP eller interface-adress kräver en explicit serviceadress; agenten gissar inte från objektnamnet. Vid flera RSA/ECDSA-certifikat kontrolleras den valda nyckeltypens certifikat med TLS 1.2. Efter rollback-perioden kan administratören rensa objekt med sslbrain-prefix som saknar referenser; ursprungliga certifikat och ACME-konfigurationer raderas inte av agenten.

Krav på certifikatet

FortiWeb 8.0.5 dokumenterar RSA, DSA och ECDSA; DSA gäller endast Reverse Proxy. Exemplen i 8.0.7 omfattar RSA 2048/3072/4096 bit och ECDSA 256/384/521 bit. Agentens nyckelval är RSA 2048/3072/4096 och ECDSA P-256/P-384. Importens minimum/maximum och fullständiga kurvlista är inte publicerade i dessa källor. CSR-menyns RSA-storlekar är inte importgränser.

Importkällorna anger inget krav på Common Name (CN) eller löfte om att CN kan utelämnas. Agenten validerar det konkreta servernamnet i certifikatet och lägger inte till ett CN-krav; SAN-only tlsserver/minimal-indata bevaras.

Det finns inget publicerat importkrav på clientAuth EKU eller keyEncipherment KU i de citerade källorna. Agenten kräver inget av dem. Certifikatet ska fungera som TLS-servercertifikat för valda namn och klienternas trust store.

CSR-dokumentationen tillåter DNS- och IP-SAN men anger ingen numerisk SAN-gräns eller alla externa importkodningar. Agenten kontrollerar wildcard och IP-SAN mot det konkreta namnet utan en godtycklig SAN-gräns. Native ACME wildcard från 7.6.1 och DNS-01 är separata utfärdandefunktioner, inte versionskrav för importerade wildcardcertifikat.

REST-importen använder PEM-certifikat och matchande okrypterad PEM-nyckel. FortiWebs GUI dokumenterar PEM, DER och PFX/PKCS#12, och tillverkarens REST-samling har en PKCS12Certificate-import. JKS och PFX AES jämfört med legacy 3DES/RC2 dokumenteras inte här. Agenten använder PEM och är därför oberoende av PFX-krypteringsvariant.

Leverera intermediärer från certifikatets närmaste utfärdare och uppåt. Agenten använder en ny Intermediate CA Group och bevarar gamla intermediärer för övriga multi-certifikatnycklar. Utelämna normalt root från serverkedjan; tillverkaren publicerar inget generellt förbud mot root-import. TLS-kontrollen kräver att servern skickar levererade intermediärer.

Lokala certifikatnamn har högst 63 tecken. Agenten genererar korta ASCII-namn och kontrollerar identiteten efter import; befintliga objektnamn URL-kodas vid läsning. Inget publicerat PFX friendly-name/alias-krav finns i källorna. Ett exempel med filnamn och _id fastställer inte alla namnnormaliseringar.

Importkällorna publicerar ingen minsta eller största livslängd. Agenten kontrollerar aktuell giltighet och anger utgångsdatum utan en påhittad livslängdsgräns. Native ACME-förnyelseintervall är inte gränser för importerade certifikat.

Kom igång