Fortinet FortiWeb WAF
Kopiér link til siden “Fortinet FortiWeb WAF”
Fornyer CA-certifikater på valgte FortiWeb server policies og SNI-politikker med TLS-kontrol og rollback.
Sådan forløber det
- Appliancen forbinder til Fortinet FortiWeb WAF gennem FortiWeb REST API på port 443.
- Discovery sammenholder fingeraftrykket fra en TLS-forbindelse med SNI med det certifikatobjekt, den valgte policy bruger. Vælg policy og eventuelt SNI-medlem samt konkret servernavn. Adresse og port kan angives til kontrol gennem NAT. Uafklaret certifikatidentitet eller mål giver en delbar fejlkode uden ændringer.
- Agenten kontrollerer navn, gyldighed og nøglematch, importerer PEM-certifikat og nøgle under et nyt navn og opretter en intermediate-gruppe til kæden. Delte SNI- og multi-certifikatgrupper kopieres med øvrige medlemmer og nøgletyper bevaret. Kun de valgte policies peges på de nye objekter.
- Hver ændring læses tilbage. En ny TLS-forbindelse med det valgte SNI skal vise det nye certifikat med korrekt navn, tillid og intermediates. Mistede API-svar afklares ved læsning, før agenten fortsætter; en ændring sendes ikke blindt igen. Hvis det fejler: Fejl efter et bindingsskift gendanner automatisk de oprindelige bindingsværdier og kontrollerer de tidligere serverede fingeraftryk. Har andre ændret en binding, overskrives den ikke; resultatet beskriver den nødvendige genopretning.
- Når du vælger et mål, som FortiWebs egen ACME-fornyelse styrer, overtager agenten fornyelsen for netop den binding. ACME-konfigurationer og gamle certifikater bevares, og resultatet viser, hvilke bindinger der blev overtaget. Rollback og fjernelse gendanner de tidligere bindingsværdier, også ACME-fornyelsen, uden at slette objekter.
Tekniske detaljer
- Forbindelse
- Pakken kører på appliancen, som forbinder over HTTPS til FortiWeb REST API, port 443. Der installeres ingen agent.
- I skal bruge
- FortiWeb REST-administratorens brugernavn, adgangskode og valgte VDOM. Authorization-headeren sendes over verificeret HTTPS, med systemets trust store, CA-bundle eller præcist SHA-256-certifikatpin. Certifikat- og policyadgang skal tillade læsning og skrivning. Tilslut HA-primary; discovery ændrer intet og afprøver ikke skriveret.
- Platform
- FortiWeb med REST API v2; certifikatstier vælges fra de funktioner, enheden viser ved discovery
- Handlinger
- Discovery, Installation, Kontrol, Rollback, Fjernelse
- Pakker
-
fortiweb-api1.0.0 - Bemærk
-
- Bash og native PowerShell 7+ kræver Python 3.12+ og OpenSSL på den udførende appliance eller relay. Management-certifikater og backend-poolcertifikater er separate destinationer. REST v2 blev introduceret i 6.3.6; auth-dokumentationen omfatter 7.2+, mens nyere felter vælges efter discovery frem for et antaget versionsnummer. Et regular-expression SNI-match skal kunne afgøres entydigt før ændringer.
- En navngiven VIP eller interface-adresse kræver en eksplicit serviceadresse; agenten gætter ikke fra objektnavnet. Ved flere RSA/ECDSA-certifikater kontrolleres den valgte nøgletypes certifikat med TLS 1.2. Efter rollback-perioden kan administratoren rydde urefererede sslbrain-objekter op; oprindelige certifikater og ACME-konfigurationer slettes ikke af agenten.
Krav til certifikatet
FortiWeb 8.0.5 dokumenterer RSA, DSA og ECDSA; DSA gælder kun Reverse Proxy. Eksemplerne i 8.0.7 omfatter RSA 2048/3072/4096 bit og ECDSA 256/384/521 bit. Agentens nøglevalg er RSA 2048/3072/4096 og ECDSA P-256/P-384. Importens minimum/maksimum og komplette kurveliste er ikke offentliggjort i disse kilder. CSR-menuens RSA-størrelser er ikke importgrænser.
Importkilderne angiver ikke et krav om Common Name (CN) eller et løfte om CN-udeladelse. Agenten validerer det konkrete servernavn i certifikatet og tilføjer intet CN-krav; SAN-only tlsserver/minimal-input bevares.
Der er intet offentliggjort importkrav om clientAuth EKU eller keyEncipherment KU i de citerede kilder. Agenten kræver ingen af dem. Certifikatet skal fungere som TLS-servercertifikat for de valgte navne og klienternes trust store.
CSR-dokumentationen tillader DNS- og IP-SAN, men angiver ikke en numerisk SAN-grænse eller alle eksterne importkodninger. Agenten kontrollerer wildcard- og IP-SAN mod det konkrete navn uden en vilkårlig SAN-grænse. Native ACME wildcard fra 7.6.1 og DNS-01 er separate udstedelsesfunktioner, ikke et versionskrav til importerede wildcard-certifikater.
REST-importen bruger PEM-certifikat og matchende ukrypteret PEM-nøgle. FortiWebs GUI dokumenterer PEM, DER og PFX/PKCS#12, og producentens REST-samling har en PKCS12Certificate-import. JKS og PFX AES versus legacy 3DES/RC2 er ikke dokumenteret her. Agenten bruger PEM og afhænger derfor ikke af en PFX-krypteringsvariant.
Lever intermediates fra certifikatets nærmeste udsteder og opad. Agenten bruger en ny Intermediate CA Group og bevarer gamle intermediates til øvrige multi-certifikatnøgler. Udelad normalt root fra serverkæden; producenten offentliggør ikke et generelt root-importforbud. TLS-kontrollen kræver, at serveren sender de leverede intermediates.
Lokale certifikatnavne har højst 63 tegn. Agenten genererer korte ASCII-navne og kontrollerer identiteten efter import; eksisterende objektnavne URL-kodes ved læsning. Intet offentliggjort PFX friendly-name/alias-krav findes i kilderne. Et eksempel med filnavn og _id fastlægger ikke alle navnenormaliseringer.
Importkilderne offentliggør ingen minimums- eller maksimumslevetid. Agenten kontrollerer aktuel gyldighed og oplyser udløbsdato uden en opfundet levetidsgrænse. Native ACME-fornyelsesintervaller er ikke grænser for importerede certifikater.