Odnawianie certyfikatu Sophos Firewall przez XML API i weryfikacja usług

Krótsze okresy ważności publicznie zaufanych certyfikatów TLS zwiększają nakład pracy związany z ręcznym odnawianiem. Dlatego certyfikat jest wystawiany w zewnętrznym systemie, importowany z chronionego hosta automatyzacji, przypisywany do przewidzianej usługi, a następnie sprawdzany na rzeczywistym listenerze. Pomyślne wystawienie nie potwierdza jeszcze importu, a istnienie obiektu certyfikatu nie potwierdza, który certyfikat udostępnia WebAdmin, portal, WAF lub SMTP.

Pola XML dla operacji add i update zawsze pochodzą z lokalnej API help używanego buildu SFOS. Pole identyfikujące istniejący obiekt, zachowanie referencji oraz reakcję po błędach ustala się podczas testu. Dlatego artykuł celowo nie przedstawia rzekomo uniwersalnego payloadu aktualizacji.

Proces w czterech fazach

Przygotowanie: wyjaśnij uprawnienia i walidacje CA, wymagania hosta automatyzacji, dostęp do API oraz drogę wycofania zmiany.
Testowanie: dla zbędnej nazwy przekształć lokalny przykład operacji Add/Update w powiązane z wersją żądanie multipart, przetestuj je i zatwierdź.
Odnawianie: sprawdź certyfikat i klucz, prześlij je oraz przypisz do przewidzianych usług.
Odbiór: sprawdź plik obiektu i rzeczywisty listener, monitoruj działanie, a stary certyfikat usuń dopiero później.

Dlaczego krótkie okresy ważności wymagają niezawodnej automatyzacji

Maksymalny dozwolony okres ważności publicznie zaufanych certyfikatów TLS jest stopniowo skracany. Zgodnie z Baseline Requirements CA/Browser Forum dla nowo wystawionych certyfikatów obowiązują następujące limity:

przed 15 marca 2026 r.: najwyżej 398 dni;
od 15 marca 2026 r. do 14 marca 2027 r.: najwyżej 200 dni;
od 15 marca 2027 r. do 14 marca 2029 r.: najwyżej 100 dni;
od 15 marca 2029 r.: najwyżej 47 dni.

Dozwolony okres ponownego wykorzystania zakończonej walidacji domeny lub adresu IP również skraca się w tych samych etapach z 398 do 200, 100, a ostatecznie do 10 dni. Certyfikat i leżąca u jego podstaw walidacja mają zatem oddzielne terminy ważności.

Zgodnie z aktualną informacją DigiCert o krótszych okresach ważności od 24 lutego 2026 r. firma wystawia publiczne certyfikaty TLS o okresie ważności wynoszącym najwyżej 199 dni. Operacyjne limity 99 i 46 dni zapowiedziano dopiero odpowiednio na początek 2027 i 2029 roku; dokładne terminy przejścia mogą się jeszcze zmienić. Dlatego automatyzacja monitoruje rzeczywistą wartość notAfter wystawionego certyfikatu, zamiast zakładać stały roczny okres ważności.

Rozdzielenie wbudowanego Let’s Encrypt od zewnętrznego CA

Wbudowana w SFOS funkcja Let’s Encrypt jest odrębnym procesem zarządzanym przez firewall. Nie jest uniwersalnym klientem ACME dla DigiCert i nie można jej po prostu przełączyć na adres URL ACME DigiCert. W przypadku wbudowanego procesu właściwą procedurę opisuje artykuł Konfiguracja certyfikatów Let’s Encrypt w Sophos Firewall.

W przypadku zewnętrznego publicznego urzędu CA certyfikat jest wystawiany w odpowiednim do tego systemie. Dopiero gotowy certyfikat zostaje przesłany do SFOS przez XML API.

Określenie wymagań niezależnych od CA

Przed rozpoczęciem konfiguracji należy wyjaśnić następujące kwestie u wybranego urzędu CA:

uprawnienia do produktu i dozwolone typy certyfikatów;
zamówienie, subskrypcję lub inną metodę płatności;
tworzenie, ważność i rotację danych dostępowych ACME lub API;
obsługiwaną metodę DCV dla każdej zamówionej nazwy;
w przypadku OV/EV wymaganą walidację organizacji;
terminy ważności certyfikatu, walidacji domeny i walidacji organizacji.

Nazwy i etapy zatwierdzania różnią się w zależności od dostawcy. Dlatego poniższe informacje o koncie stanowią konkretny przykład DigiCert, a nie ogólne wymaganie CA.

Przykład DigiCert: przygotowanie konta i ACME

W CertCentral funkcja automatyzacji musi być aktywna dla danego konta. Dalsza konfiguracja i zatwierdzanie zależą od modelu konta:

W przypadku kont Enterprise, Partner i starszych kont bez subskrypcji adres ACME Directory URL może utworzyć wyłącznie administrator CertCentral. Następnie może przekazać gotowe dane dostępowe kontu serwisowemu o ściśle ograniczonych uprawnieniach, używanemu w bieżącej eksploatacji.
Dla kont Enterprise i innych kont bez subskrypcji trzeba włączyć automatyczne zatwierdzanie wniosków o certyfikat; bez niego żądania ACME domyślnie kończą się niepowodzeniem.
Konta Subscription nie wymagają tego ustawienia do automatycznego zatwierdzania wniosków. Dostępne produkty i status subskrypcji nadal muszą być odpowiednie.

W ten sposób szerokie uprawnienia potrzebne do tworzenia danych dostępowych pozostają oddzielone od późniejszego konta automatyzacji. Przed pierwszym zamówieniem należy dodatkowo sprawdzić uprawnienia do produktu, metodę płatności oraz przypisanie ACME Directory URL i External Account Binding do właściwego konta i produktu. Jednoznacznie wyznaczona osoba odpowiada za tworzenie, rotację i awaryjne zastępowanie danych dostępowych.

Dane dostępowe ACME należy przechowywać w chronionym magazynie sekretów. Nie wolno ich zapisywać w repozytorium, skrypcie powłoki, zgłoszeniu, przykładzie w wiki ani eksporcie Postman.

Przykład DigiCert: DCV dla DV, OV i EV

W przypadku certyfikatu DV DigiCert wykonuje Domain Control Validation od nowa dla każdego zamówienia ACME; wcześniejsza walidacja DCV nie jest uznawana z góry ani ponownie wykorzystywana. Host automatyzacji musi być w stanie zrealizować wybrane wyzwanie przy każdym odnowieniu.

W przypadku certyfikatów OV i EV nienadzorowane wystawianie przez ACME wymaga uprzednio zweryfikowanej organizacji. Ponadto status domeny musi być ważny. DigiCert stosuje obecnie walidację domeny OV/EV, którą można ponownie wykorzystywać przez 199 dni; walidacja organizacji dla publicznych certyfikatów OV może być obecnie ponownie wykorzystywana przez 397 dni. Oba terminy są monitorowane niezależnie od wygaśnięcia certyfikatu.

Dla certyfikatu wildcard, takiego jak *.example.com, typową metodą walidacji jest DNS-01. Dostęp do API DNS powinien umożliwiać modyfikowanie wyłącznie wymaganej strefy lub wymaganego rekordu.

Budowa bezpiecznego hosta automatyzacji

Host automatyzacji okresowo przetwarza klucz prywatny, dane dostępowe CA i hasło SFOS z uprawnieniami do zapisu. Powinien znajdować się w chronionym środowisku zarządzania, a nie na zwykłym notebooku administratora ani w dowolnym środowisku wykonawczym CI.

Minimalne wymagania obejmują:

utwardzony i aktualny system operacyjny z jednoznacznie wyznaczoną osobą odpowiedzialną;
stały źródłowy adres IP lub ściśle ograniczoną sieć zarządzającą;
dostęp wychodzący wyłącznie do CA, API DNS i przewidzianych firewalli;
oddzielne dane dostępowe dla CA, DNS i każdego firewalla lub jasno wydzielonej grupy firewalli;
magazyn sekretów zamiast zmiennych środowiskowych, danych diagnostycznych, parametrów wiersza poleceń lub plików tekstowych;
restrykcyjne uprawnienia do plików oraz tymczasowy katalog roboczy na zaszyfrowanym nośniku;
brak kluczy prywatnych, haseł i pełnych żądań XML w logach;
identyfikowalny numer zlecenia, docelowy firewall, nazwa certyfikatu i wynik bez poufnych treści;
synchronizację czasu i alarmowanie przy powtarzających się błędach lub zbyt krótkim pozostałym okresie ważności.

Jeżeli klucz prywatny jest przesyłany do SFOS w postaci zaszyfrowanej, ze względów zgodności hasło importu powinno mieć najwyżej 30 znaków. Pomoc interfejsu GUI SFOS podaje ten górny limit, podczas gdy pomoc API, zależnie od buildu, opisuje od 4 do 128 znaków. Ograniczenie do 30 znaków służy wyłącznie zgodności i nie jest ogólnym zaleceniem dotyczącym długości haseł. Losowe hasło obowiązuje tylko dla tego klucza i jest przesyłane w chroniony sposób.

Utwardzenie źródła, konta serwisowego, ustawień Device Access i uprawnień API opisuje artykuł Zabezpieczanie dostępu do XML API w Sophos Firewall. W SFOS 22 w sekcji Administration > API access należy zezwolić w polu Allowed IP hosts wyłącznie na IP Host systemu automatyzacji. W starszych wersjach konfiguracja API znajduje się pod inną ścieżką menu.

Test przed odnowieniem produkcyjnym

Test wykorzystuje zbędną nazwę, taką jak test-fw.example.com, oddzielny obiekt certyfikatu i listener, którego przerwa w działaniu jest akceptowalna. Powtarza się go po istotnych aktualizacjach SFOS lub automatyzacji.

Ustalenie zachowania używanego buildu

Testy służą ustaleniu zachowania konkretnego buildu i nie zastępują gwarancji producenta. Należy sprawdzić i zaprotokołować:

dokładny build SFOS i użytą lokalną API help;
dokładne pola add i update oraz pole identyfikujące istniejący obiekt;
wynik ponownego wysłania tego samego żądania oraz stan po przerwanym przesyłaniu;
przetwarzanie pliku certyfikatu zawierającego certyfikat leaf i certyfikaty pośrednie oraz utworzone w wyniku tego obiekty CA;
rzeczywiście udostępniany łańcuch;
zachowanie lub utratę referencji WebAdmin, portalu, WAF i SMTP;
wymaganą aktywację listenera lub ewentualny restart usługi;
w przypadku HA synchronizację certyfikatu, klucza prywatnego i przypisania oraz udostępnianie po failoverze.

Nie należy bez sprawdzenia zakładać, że plik fullchain jest obsługiwany. Automatyzacja nie może również zakładać idempotencji, zachowania referencji ani bezpiecznego automatycznego ponawiania operacji po błędach.

Od lokalnego przykładu Add/Update do żądania

W ten sposób powstaje konkretne żądanie dla zainstalowanego buildu, bez błędnego uznawania go za uniwersalne:

W lokalnej API help docelowego firewalla przejdź do System > Certificates > Certificate > Add Certificate / Update Certificate. Zapisz przykładową konfigurację i opis parametrów dokładnie dla tego buildu.
Dla pierwszego przypadku użyj udokumentowanego wrappera add. Dla drugiego zastosuj pokazane tam update i jego pole identyfikacyjne. Nie kopiuj atrybutu operacji ani identyfikatora obiektu z innego buildu.
W przykładzie zastąp wyłącznie wartości środowiskowe: dane logowania API z magazynu sekretów, nazwę obiektu test-public-cert, akcję przesyłania certyfikatu, format certyfikatu, nazwę pliku certyfikatu, nazwę pliku klucza prywatnego oraz, w razie potrzeby, hasło importu. Usuń niepotrzebne gałęzie przykładu, ale pozostaw niezmienione nazwy i zagnieżdżenie elementów.
Utwórz lokalnie wynikowe żądanie XML jako tymczasowe reqxml. Obie nazwy plików w XML muszą dokładnie odpowiadać przesyłanym plikom.
W Postman lub używanej bibliotece HTTP wybierz metodę POST, poniższy endpoint oraz multipart/form-data:
```
https://<Firewall-FQDN>:<Admin-Port>/webconsole/APIController
```
Utwórz dokładnie trzy części multipart: wskazaną w lokalnej pomocy część plikową certyfikatu, wskazaną tam część plikową klucza prywatnego oraz pole tekstowe reqxml. Nazw pierwszych dwóch części nie należy zgadywać; ich aktualne nazwy i nazwy plików trzeba przejąć z przykładu dla docelowego buildu.
Najpierw wykonaj add, a następnie update z nowo wystawionym certyfikatem testowym. Dodatkowo wyślij nieprawidłowe żądanie w środowisku testowym i przed ponowieniem odczytaj aktualny stan.
Żądanie może zostać zatwierdzone dopiero wtedy, gdy <Response> i <Status> zgłoszą oczekiwany sukces, zmieniony zostanie dokładnie przewidziany obiekt, nie powstaną nieoczekiwane obiekty CA, referencja usługi zachowa się zgodnie z protokołem, a zewnętrzny listener po przypisaniu udostępni nowy certyfikat wraz z prawidłowym łańcuchem. W przypadku HA wymagany jest także kontrolowany failover.

Na podstawie wyników żądanie jest tworzone, testowane i wewnętrznie zatwierdzane dokładnie dla tego buildu. Trzy nazwy części, szablon XML, oczekiwane wartości statusu i warunki przerwania są wspólnie wersjonowane, ale bez zapisywania danych dostępowych lub kluczy.

Sprawdzanie certyfikatu przed przesłaniem

Poniższe przykłady używają następujących wartości zastępczych:

FQDN usługi: vpn.example.com
nazwa obiektu SFOS: public-vpn-example-com
certyfikat leaf: vpn.example.com.pem
klucz prywatny: vpn.example.com.key
pakiet certyfikatów pośrednich: intermediates.pem
pakiet zaufanych certyfikatów głównych: trust-roots.pem
zewnętrzny port HTTPS: 443

Najpierw odczytaj dane certyfikatu:

openssl x509 -in vpn.example.com.pem -noout -subject -issuer -serial -dates -ext subjectAltName -fingerprint -sha256

Wystawca, okres ważności, wpisy SAN i fingerprint SHA-256 muszą być zgodne z zamówieniem. Następnie sprawdź, czy certyfikat i klucz prywatny tworzą tę samą parę kluczy, bez wyświetlania klucza:

(
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl x509 -in vpn.example.com.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
    openssl pkey -in vpn.example.com.key -pubout > "$tmpdir/key-public-key.pem" &&
    cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

Przy identycznych kluczach publicznych cmp nie zwraca żadnego tekstu. W przypadku różnicy proces zostaje przerwany. Dla zaszyfrowanego klucza prywatnego pojawi się interaktywne żądanie hasła; w automatyzacji pochodzi ono z magazynu sekretów i nie pojawia się ani w wywołaniu procesu, ani w logu.

Przewidziany łańcuch jest weryfikowany względem własnego magazynu zaufania:

openssl verify -CAfile trust-roots.pem -untrusted intermediates.pem vpn.example.com.pem

Plik trust-roots.pem zawiera główne urzędy CA zaufane we własnym środowisku, a intermediates.pem — pośrednie urzędy CA związane z wystawieniem. Weryfikacja jest pomyślna wyłącznie wtedy, gdy pojawi się komunikat vpn.example.com.pem: OK; każdy inny wynik zatrzymuje przesyłanie.

Przesyłanie certyfikatu przez XML API

Kontrole przed przesłaniem

Przed zapisem porównaj docelowy firewall, build SFOS, nazwę obiektu i usługi z zatwierdzoną zmianą. Muszą być dostępne: aktualna kopia zapasowa Sophos Firewall, alternatywny dostęp do zarządzania oraz dotychczasowy obiekt certyfikatu. Najpierw wykonaj bezpieczne zapytanie odczytu z tego samego hosta i konta serwisowego. Uprawnienia do plików oraz lokalne testy certyfikatu nie mogą wykazywać błędów.

Wysyłanie żądania i ocena odpowiedzi

Automatyzacja wysyła żądanie multipart zatwierdzone podczas testu. Certyfikat i klucz prywatny są przesyłane jako pliki; reqxml powstaje w czasie wykonywania i jest następnie usuwane. Klient używa nazwy FQDN zgodnej z certyfikatem firewalla, weryfikuje jego CA oraz przerywa działanie w przypadku błędu nazwy hosta lub certyfikatu. Użycie curl -k lub porównywalnego wyłączenia weryfikacji TLS jest niedopuszczalne.

Status HTTP 200 lub komunikat Send successful potwierdza wyłącznie transport. Automatyzacja ocenia w XML co najmniej element <Response> należący do operacji i jego <Status> na podstawie wartości zatwierdzonych podczas testu. W przypadku przekroczenia limitu czasu, niepełnej odpowiedzi lub negatywnego statusu najpierw ponownie odczytuje stan obiektu albo zatrzymuje się w celu ręcznego wyjaśnienia; nie ponawia żądania zapisu bez sprawdzenia.

Kontrola obiektu i pobranego pliku

W sekcji Certificates > Certificates znajdź obiekt docelowy. W interfejsie GUI sprawdź faktycznie dostępne tam informacje, w szczególności nazwę obiektu, status klucza prywatnego, wartość Trusted, widoczne po najechaniu kursorem pola Subject, Issuer i Purpose oraz nieoczekiwane dodatkowe obiekty certyfikatów lub CA.

Nie należy zakładać, że numer seryjny, wpisy SAN, data wygaśnięcia i fingerprint SHA-256 są gwarantowanymi polami GUI. Wyeksportuj docelowy certyfikat za pomocą funkcji pobierania SFOS i sprawdź pobrany plik:

openssl x509 -in downloaded-vpn.example.com.pem -noout -serial -dates -issuer -subject -ext subjectAltName -fingerprint -sha256

Wartości te muszą odpowiadać plikowi sprawdzonemu przed przesłaniem. Sam zielony status Trusted nie potwierdza ani właściwego przypisania do usługi, ani pełnego łańcucha listenera. Formaty, łańcuch i import przez GUI opisuje artykuł Importowanie i przypisywanie certyfikatów w Sophos Firewall.

Przypisywanie certyfikatu do usługi

Import i przypisanie to oddzielne zmiany. Nowy obiekt należy jawnie przypisać do wybranej usługi. W przypadku aktualizacji używa się ścieżki potwierdzonej podczas testu, a po wykonaniu operacji sprawdza się faktyczne zachowanie referencji.

WebAdmin i portale

W sekcji Administration > Admin and user settings > Admin console and end-user interaction pole Certificate jest wspólne dla WebAdmin Console, User Portal, VPN Portal, Captive Portal oraz SPX Registration i Reply Portal. Certyfikat musi zawierać jako SAN wszystkie faktycznie używane nazwy. Po wybraniu Apply sprawdź osobno każdy FQDN i port; pozostaw otwartą istniejącą sesję administratora i alternatywną lokalną ścieżkę zarządzania.

WAF

Dla publikacji WAF certyfikat wybiera się w odpowiedniej regule, w sekcji Rules and policies > Firewall, w polu HTTPS certificate. Domena, SNI, Listen Port i SAN muszą być ze sobą zgodne. Podczas zapisywania reguły Web Server Protection są uruchamiane ponownie; istniejące połączenia mogą zostać przerwane. To, czy wymiana już używanego certyfikatu również powoduje ponowne wczytanie, należy sprawdzić podczas testu na używanym buildzie.

SMTP TLS

W trybie MTA certyfikat wybiera się w sekcji Email > General settings > SMTP TLS configuration, w polu TLS certificate. Po wybraniu Apply należy oddzielnie sprawdzić STARTTLS i, w razie potrzeby, niejawny TLS. VPN i inne zastosowania certyfikatów mogą mieć własne przypisania; identyczna nazwa nie oznacza, że zmienią się automatycznie.

Zewnętrzna walidacja z SNI i właściwym portem

Najpierw sprawdź łańcuch i nazwę hosta z realistycznego zewnętrznego hosta testowego:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts -verify_hostname vpn.example.com -verify_return_error </dev/null

Oczekiwane są wymagane certyfikaty pośrednie i komunikat Verification: OK. Opcja -servername wysyła SNI; FQDN i port należy zastąpić danymi rzeczywistej usługi.

Fingerprint, numer seryjny i pozostałe dane certyfikatu leaf można odczytać w drugim, gotowym do wykonania kroku dla tej samej konfiguracji listenera:

(
  set -o pipefail
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts \
    -verify_hostname vpn.example.com -verify_return_error </dev/null 2>"$tmpdir/s_client.log" |
    openssl x509 -out "$tmpdir/leaf.pem" &&
  openssl x509 -in "$tmpdir/leaf.pem" -noout -serial -fingerprint -sha256 -dates -issuer -subject -ext subjectAltName
)

Numer seryjny, fingerprint SHA-256, okres ważności, wystawca i wpisy SAN muszą odpowiadać zatwierdzonemu certyfikatowi. Następnie sprawdź samą aplikację, na przykład logowanie do portalu, healthcheck WAF lub inną bezpieczną funkcję end-to-end. Umieszczony wcześniej load balancer, CDN lub reverse proxy może terminować TLS przy użyciu innego certyfikatu; punkt testowy musi zatem odpowiadać zamierzonej funkcji SFOS.

SMTP z STARTTLS wymaga osobnego wywołania:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Dla niejawnego TLS na porcie 465 należy pominąć -starttls smtp. Także w tym przypadku łańcuch i nazwa hosta są potwierdzane komunikatem Verification: OK; dane certyfikatu leaf można odczytać za pomocą poprzedniego wzorca wyodrębniania i dostosowanych opcji połączenia. Następnie sprawdź rzeczywisty przepływ poczty.

Okno serwisowe, rollback i HA

Przygotowanie okna serwisowego

Pierwsze uruchomienie produkcyjne oraz zmiany w żądaniu, buildzie SFOS, produkcie CA lub zestawie łańcucha należy przeprowadzać w oknie serwisowym. Dotychczasowy obiekt pozostaje dostępny; znane są objęte zmianą przypisania, alternatywny dostęp do zarządzania oraz osoby odpowiedzialne za wycofanie zmiany i zewnętrzną weryfikację.

Wybór strategii rollbacku

W przypadku nowego obiektu najprostszą drogą wycofania jest ponowne wybranie starego certyfikatu w danej usłudze i ponowne zewnętrzne przetestowanie listenera. Dlatego stary obiekt nie jest usuwany podczas tego samego procesu.

Przy aktualizacji istniejącego obiektu obowiązuje wyłącznie droga wycofania potwierdzona podczas testu. Jeżeli nie potwierdzono bezpiecznego ponownego wgrania poprzedniej zawartości, należy konserwatywnie utworzyć oddzielny nowy obiekt, a następnie jawnie go przypisać.

Oddzielne testowanie HA

W klastrze HA SFOS zasadniczo synchronizuje konfigurację z węzła Primary do Auxiliary. Mimo to certyfikat, klucz prywatny i przypisanie do usługi trzeba sprawdzić na obu węzłach lub we wspólnej usłudze. Następnie wykonuje się kontrolowany failover wraz z zewnętrznym testem listenera. Dopiero pomyślny test pozwala zatwierdzić proces dla HA.

Monitorowanie i cykliczna eksploatacja

Automatyzacja musi odpowiednio wcześnie zgłaszać błędy i brak odnowienia. Należy stale monitorować:

liczbę dni pozostałych do wygaśnięcia certyfikatu na zewnętrznym listenerze i następne okno odnowienia CA;
status DCV, a w przypadku OV/EV również walidację organizacji;
ostatnie pomyślne zamówienie CA i przesłanie do SFOS;
oczekiwany i faktycznie udostępniany fingerprint;
błędy API, niejednoznaczne odpowiedzi i przerwane procesy;
nieplanowane nowe obiekty certyfikatów lub CA;
wygaśnięcie i rotację danych dostępowych;
w przypadku HA ostatni pomyślny test failoveru.

Alarm musi pozostawiać wystarczająco dużo czasu na proces CA/DCV, reakcję wewnętrzną, okno serwisowe i wycofanie zmiany. Po pomyślnej zmianie stary certyfikat pozostaje dostępny przez zdefiniowany okres obserwacji. Tymczasowe pliki certyfikatów, kluczy i XML są usuwane w kontrolowany sposób; trwale zapisane dane dowodowe zawierają wyłącznie niepoufne metadane.

Rozwiązywanie problemów według objawu

CA nie wystawia nowego certyfikatu

U danego dostawcy sprawdź uprawnienia do produktu, status konta, metodę płatności i DCV. W przykładzie DigiCert należy dodatkowo zweryfikować automatyzację oraz automatyczne zatwierdzanie wniosków właściwe dla modelu konta. W przypadku OV/EV organizacja i domena muszą być ważne. Błędy DNS-01 sprawdzaj w autorytatywnym publicznym DNS, a nie tylko w lokalnym resolverze.

XML API jest niedostępne

Sprawdź źródłowy adres IP z perspektywy firewalla, Allowed IP hosts, Device Access, routing, port administracyjny i certyfikat firewalla. Test musi zostać wykonany z rzeczywistego hosta automatyzacji.

Żądanie HTTP kończy się powodzeniem, ale certyfikat nie jest aktualizowany

Sprawdź <Response> i <Status>, a nie tylko kod HTTP. Następnie porównaj nazwę obiektu, format pliku, dozwoloną długość hasła i pola właściwe dla buildu z lokalną pomocą API. W sekcji Diagnostics > Troubleshooting logs pomocne są pliki apiparser.log, validation.log i validationError.log; przed ich udostępnieniem usuń wszystkie dane dostępowe. Jeśli stan jest niejasny, najpierw pobierz i sprawdź obiekt certyfikatu, zamiast ponawiać żądanie zapisu bez weryfikacji.

Obiekt jest nowy, ale usługa nadal pokazuje stary certyfikat

Sprawdź przypisanie do usługi, regułę WAF, wspólny wybór certyfikatu dla WebAdmin i portali lub konfigurację SMTP. Następnie przetestuj połączenie z SNI na właściwym porcie i wyklucz poprzedzający endpoint TLS.

Certyfikat nie jest oznaczony jako `Trusted` lub łańcuch jest niepełny

Porównaj wystawcę certyfikatu leaf z zainstalowanymi pośrednimi urzędami CA. Użyj procedury importu potwierdzonej podczas testu i sprawdź za pomocą -showcerts łańcuch wysyłany przez listener.

Po aktualizacji lub failoverze ponownie pojawia się stary certyfikat

Ustal, który węzeł i listener odpowiada. Następnie porównaj fingerprint pobranego obiektu, referencję usługi i stan HA. W razie rozbieżności wykonaj potwierdzoną procedurę wycofania i zatrzymaj automatyzację.

Lista kontrolna odbioru

Odnowienie produkcyjne można zatwierdzić tylko po spełnieniu wszystkich punktów:

Uprawnienia CA, płatność, DCV oraz, w razie potrzeby, walidacja organizacji są ważne.
Build, lokalna pomoc API i żądanie multipart odpowiadają pomyślnie zakończonemu testowi.
Lokalna weryfikacja certyfikatu, klucza i łańcucha zakończyła się powodzeniem.
<Response> i <Status> zgłaszają oczekiwany sukces; zmieniony został dokładnie obiekt docelowy.
Pobrany plik obiektu ma oczekiwany numer seryjny, wpisy SAN, okres ważności i fingerprint SHA-256; klucz prywatny oraz status Trusted są prawidłowe i nie powstały żadne nieoczekiwane obiekty.
Każdy rzeczywisty FQDN i port udostępnia z SNI nowy certyfikat, oczekiwany łańcuch i komunikat Verification: OK; powiązana usługa działa.
W przypadku HA pomyślnie wykonano kontrolowany failover wraz z zewnętrznym testem.
Monitoring wykrywa nową datę wygaśnięcia i pomyślny wynik; stary certyfikat pozostaje dostępny jako droga wycofania do końca okresu obserwacji.