Odróżnij wygaśnięcie od awarii łańcucha zaufania, zachowaj zgłoszony punkt końcowy i zweryfikuj certyfikat faktycznie dostarczony po odnowieniu.
Przeczytaj dokładnie kategorię wyników
Referencje: RFC 8460 §4.3.1, RFC 8460 §4.3.2.
certyfikat wygasł oznacza, że osoba zgłaszająca zauważyła, że certyfikat wygasł. certyfikat niezaufany obejmuje kilka warunków, w tym nieznane urzędy certyfikacji, błędy łańcucha i ograniczenia nazw. Kod przyczyny awarii może zawęzić diagnozę, ale jest to tekst dostarczony przez reportera, a nie uniwersalną umowę dotyczącą analizatora składni. Nie oznaczaj każdego raportu niezaufanego certyfikatu jako brakującego półproduktu bez dowodów. Zacznij od kontekstu zasad i zgłoś odbierający punkt końcowy, aby problem z certyfikatem SMTP nie został pomylony z sts-webpki-invalid na serwerze MTA-STS Host zasad HTTPS.
Sprawdź certyfikat, który dotarł do nadawcy
Menedżer certyfikatów pokazujący odnowiony certyfikat nie sprawdza, czy obsługuje go każdy słuchacz SMTP . Zapisz numer seryjny lub odcisk palca, okres ważności, łańcuch i znacznik czasu testu z rzeczywistej autoryzowanej kontroli punktu końcowego. Porównaj te wartości na trasach odbiorczych objętych raportami. Nieaktualny proces, zapomniany host zapasowy lub niekompletne wdrożenie modułu równoważenia obciążenia mogą pozostawić aktywne stare certyfikaty. Sprawdź dokładność zegara, gdy granice ważności wydają się niespójne, ale nie zmieniaj zegarów ani magazynów zaufania jedynie po to, aby nie zaliczyć testu.
Odtwórz problem nakładania się odnowień
W ćwiczeniu syntetycznym definiuje się stary certyfikat ważny do t=100 i nowy ważny od t=90 do t=200. W chwili t=110, odbiornik nadal obsługujący stary certyfikat nie przechodzi kontroli okna ważności modelu, podczas gdy odbiornik obsługujący nowy certyfikat przechodzi pomyślnie. Odtwarza to różnicę wdrożeniową bez generowania prawdziwego certyfikatu. Nie dowodzi zaufania łańcucha, dopasowania nazw, zachowania unieważniającego ani konwencji granicznych implementacji. Potrzebują one prawdziwego walidatora TLS i kontrolowanych dowodów na temat punktu końcowego.
Zbadaj zaufanie, nie omijając go
Referencje: RFC 8461 §4.2, RFC 7672 §3.1.1.
Przechwyć liść i obsłuż łańcuch pośredni, a następnie porównaj rozum reportera z utrzymywanym środowiskiem testowym. Wydawca, któremu ufa jedna maszyna lokalna, może nie zostać zaakceptowany przez nadawcę, którego to dotyczy. Brakujące półprodukty, nieoczekiwany certyfikat z podpisem własnym i ograniczenia wynikające z polityki to różne naprawy. Udokumentuj wybrany model walidacji. SMTP DANE przy użyciu DANE-EE ma inną semantykę zaufania niż Web PKI, więc wniosków w stylu STS na temat publicznych urzędów certyfikacji nie można po prostu zastosować do każdego TLSA raport.
Zamknij pętlę wdrażania i raportowania
Referencje: RFC 8460 §4.1.
Zastosuj zatwierdzone odnowienie lub korektę łańcucha do każdego słuchacza, którego to dotyczy, sprawdź zachowanie podczas ponownego ładowania i zachowaj dowód przedstawionego certyfikatu po zmianie. Porównaj raporty, których okresy obserwacji przypadają po naprawie i uwzględnij opóźnienia w agregacji. Zaplanuj monitorowanie odnowienia z wystarczającą ilością czasu na własność i wdrożenie, a także osobno monitoruj, czy nowy certyfikat jest rzeczywiście wdrożony. Nie obniżaj automatycznie wymuszających zasad transportu, aby ukryć błędy certyfikatów. W tym przewodniku opisano wyłącznie kontrolowane badania laboratoryjne; nie odnawia certyfikatów produkcyjnych, nie zmienia zasobów zaufania produkcyjnego ani nie wykazuje przywrócenia produkcji.
Zachowane dowody historyczne i bieżące kontrole
Poniższe obserwacje dotyczące transportu zarejestrowano 7 listopada 2026 r. i skontrolowano, a nie powtórzono w ramach testów sieci na potrzeby niniejszego przeglądu. Nowe kontrole modelu offline są rejestrowane osobno.
Zachowane przechwytywanie pętli zwrotnej obejmuje certyfikat podpisany przez zaufany urząd certyfikacji laboratorium, którego ważność zakończyła się przed testem; kończy się niepowodzeniem z kodem weryfikacyjnym 10, certyfikat wygasł. Oddzielny liść z podpisem własnym kończy się niepowodzeniem z kodem weryfikacyjnym 18, certyfikat z podpisem własnym. Prawidłowa kontrola powiedzie się z tą samą oczekiwaną nazwą hosta. Dowody uzgadniania ze znacznikiem czasu i certyfikaty publiczne są zachowywane, co pozwala na osobną kontrolę wygaśnięcia i niepowodzenia zaufania. Klucze prywatne są tymczasowe i usuwane. Rzeczywiste wdrożenie odnowienia usługi i weryfikacja wdrożenia z udziałem wszystkich słuchaczy pozostają poza tym laboratorium. Historyczny moduł transportowy wymaga języka Python z funkcjami kryptograficznymi i gniazdami pętli zwrotnej. Jego wyniki opierają się na ograniczonych dowodach laboratoryjnych, a nie na obecnym stanie usług lub interoperacyjności produkcji.
Baza pierwotnego źródła
Definicje pól i limity raportowania pochodzą z RFC 8460 , Raportowanie SMTP TLS, sekcje 3 i 4. Jeżeli omawiana jest walidacja STS, należy skonsultować się RFC 8461. Zalecenia operacyjne odróżnia się od wymagań protokołu.