Niech odnowienie stanie się zadaniem zapewniającym ciągłość usług
Odnawianie certyfikatu HTTPS dla MTA-STS Host zasad jest kompletny tylko wtedy, gdy w wymaganym punkcie końcowym faktycznie zostanie dostarczony poprawny certyfikat, a sprawdzający poprawność klient może pobrać politykę. Pomyślne powiadomienie o wydaniu nie potwierdza wdrożenia, kompletności łańcucha zaufania ani dostępności. Zorganizuj pracę wokół działającej usługi, a nie kolejności certyfikatów.
W tym przewodniku zaproponowano kontrolę odnowienia i przegląd fikcyjnej awarii. Nie wystawia certyfikatów, nie sprawdza kluczy prywatnych, nie modyfikuje hostingu ani nie łączy się z domeną klienta. Nadal wymagany jest oryginalny certyfikat i obserwacje HTTP. Właściciele powinni uzgodnić zatwierdzoną procedurę wdrażania i wycofywania zmian, zanim operator dotknie usługi.
Zinwentaryzuj dwie powierzchnie certyfikatów
Certyfikat hosta zasad uwierzytelnia nazwę taką jak mta-sts.example.com podczas pobierania HTTPS. Odbierające serwery SMTP przedstawiają osobne certyfikaty dla swoich nazw hostów MX . Usługi te mogą mieć różnych właścicieli, systemy odnawiania i daty wygaśnięcia. Odnowienie jednego nie naprawia drugiego, nawet jeśli obydwoma zarządza ten sam dostawca usług hostingowych. RFC 8461 sekcje 3.3 i 4.2
Zapisz nazwę hosta zasad, odpowiedzialny zespół, platformę wdrożeniową, bieżący odcisk palca certyfikatu publicznego, okres ważności i planowany mechanizm odnawiania. Uwzględnij każdy adres lub warstwę obsługi, która może odpowiadać za punkt końcowy. Wartości notBefore i notAfter wyznaczają okres ważności certyfikatu, podczas gdy weryfikacja ścieżki zależy również od innych ograniczeń certyfikatu i zaufania. Sama pozornie przyszła data ważności nie stanowi pomyślnego wyniku weryfikacji. RFC 5280 sekcje 4.1.2.5 i 6
Przed wdrożeniem sprawdź tożsamość i łańcuch
Host zasad musi przedstawić niewygasły certyfikat ważny dla wymaganej tożsamości DNS i powiązany z zaufanym katalogiem głównym nadawcy MTA. Delegowanie hostingu poprzez a CNAME nie sprawia, że certyfikat dla nazwy hosta dostawcy jest wystarczający. Zachowaj oryginalną nazwę hosta zasad w testach sprawdzających i udokumentuj, jaki łańcuch publiczny ma wysłać serwer. RFC 8461 sekcje 3.3 i 8.2
Podczas oceny zamierzonej tożsamości usługi użyj alternatywnych nazw podmiotu certyfikatu. RFC 9525 to bieżąca ogólna specyfikacja tożsamości usług, która jest przestarzałą specyfikacją RFC 6125 , na którą cytuje RFC 8461 . Zachowaj jawne reguły DNS-ID specyficzne dla aplikacji MTA-STS , zamiast dyskretnie zastępować niepowiązane zachowania aplikacji. Nazwa zwyczajowa czytelna dla człowieka nie jest powodem do odstąpienia od niezgodności nazwy hosta. RFC 9525 sekcje 2 i 6
Zaplanuj wystarczająco dużo czasu na bezpieczną regenerację
Wybierz wewnętrzny termin odnowienia, który pozostawia czas na nieudane wydanie, błędy we wdrożeniu i weryfikację. Odpowiedni margines zależy od okresu ważności certyfikatu i własności operacyjnej; nie ustala się tu uniwersalnej liczby dni. Przypisz osobę odpowiedzialną i kontakt zapasowy. Zaplanowane zadanie bez miejsca docelowego alertu lub właściciela to niezweryfikowana zależność, a nie pełny proces odnawiania.
Przechowuj obsługę certyfikatów w zatwierdzonym systemie zarządzania sekretami. Pakiet dowodów powinien zawierać szczegóły certyfikatu publicznego i wyniki weryfikacji, a nie klucze prywatne czy dane uwierzytelniające konta. Zdefiniuj, co operator może wycofać, w jaki sposób będzie sprawdzana aktualna ważność i które awarie wymagają eskalacji. Przywracanie wygasłego certyfikatu ze względu na wczorajszą znaną konfigurację nie jest użytecznym planem odzyskiwania.
Przetestuj wdrożony punkt końcowy, a nie plik certyfikatu
Po autoryzowanym wdrożeniu proponowana kontrola powinna identyfikować dokładną nazwę hosta, adres, czas UTC, obserwowany łańcuch, wynik weryfikacji nazwy i wynik zaufania. Jeśli istnieje wiele węzłów obsługujących, zachowaj aktualnie sprawdzany zakres. Pomyślny test lokalny operatora nie może udowodnić, że każdy zewnętrzny nadawca ufa temu samemu katalogowi głównemu lub dociera do tego samego węzła. Zapisz te ograniczenia, zamiast przekształcać jedną obserwację w gotowość uniwersalną.
Następnie sprawdź, czy oryginalny, dobrze znany adres URL generuje bezpośredni kod HTTP 200 z zamierzoną polityką. Praca z certyfikatami może przypadkowo zmienić wybór hosta wirtualnego, routing lub kontrolę dostępu do aplikacji. MTA-STS zabrania korzystania z przekierowań HTTP podczas pobierania, więc sukces przeglądarki po przekierowaniu jest niewystarczający. Prawidłowe połączenie TLS i użyteczna odpowiedź HTTP to odrębne warunki akceptacji. RFC 8461 sekcje 3.2–3.3
Zbadaj fikcyjne częściowe wdrożenie
Rozważmy fikcyjną witrynę example.com , której nazwa hosta zasad jest obsługiwana przez dwa węzły brzegowe. System odnawiający uzyskuje nowy certyfikat, ale tylko jeden węzeł go przeładowuje. Drugi nadal obsługuje wygasły certyfikat. Test, który dociera do zaktualizowanego węzła, przechodzi pomyślnie; nadawca docierający do drugiego węzła nie może uwierzytelnić zasady. Obserwacje te są wymyślone i nie potwierdzają rzeczywistego zachowania dostawcy.
Proponowane badanie porównuje publiczne odciski palców i okresy ważności w węzłach obsługujących, a następnie następuje uwierzytelnione pobieranie przy niezmienionej nazwie hosta. Nie zaczyna się od złagodzenia kontroli certyfikatów ani usunięcia rekordu odkrycia. Właściciel rozwiązania zaradczego dokończy zatwierdzone wdrożenie i zweryfikuje oba węzły. Certyfikaty SMTP MX nadal wymagają własnej weryfikacji, ponieważ naprawa hosta zasad nie mówi nic o ich stanie.
Poznaj granicę pamięci podręcznej podczas awarii
Nadawca pomocniczy z ważną, nie wygasłą polityką buforowaną musi nadal z niej korzystać, jeśli nie można pobrać aktywnej polityki. Nadawca bez takiej zasady działa tak, jakby MTA-STS był nieobecny po niepowodzeniu pobierania. Dlatego też okres istnienia pamięci podręcznej zapewnia niektórym nadawcom ograniczoną korzyść w zakresie ciągłości, a nie pozwolenie na wygaśnięcie certyfikatu HTTPS. Różni nadawcy mogą legalnie zajmować różne stany podczas tej samej awarii. RFC 8461 sekcja 3.3
Identyfikator wykrycia identyfikuje instancję zasady, a nie numer seryjny certyfikatu. Jeśli zmieni się tylko certyfikat, a treść polisy pozostanie taka sama, nie zakładaj, że do odnowienia skuteczny jest wymagany nowy identyfikator. Jeśli zasady również się zmienią, postępuj zgodnie z kolejnością aktualizacji treści przed identyfikatorem i uwzględnij zasady w pamięci podręcznej. Zachowaj wdrożenie certyfikatu i rewizję zasad jako zmiany, które można osobno przeglądać. RFC 8461 sekcje 3.1 i 8.1
Zachowaj dowód do następnego odnowienia
Zapisz zatwierdzony rekord wdrożenia, publiczne szczegóły certyfikatu przed i po, uwierzytelnione wyniki pobierania i wszelkie istotne informacje TLS-RPT obserwacje. Awaria sieciowej infrastruktury PKI zasad należy do badania punktu końcowego zasad; zgłoszone wygaśnięcie certyfikatu SMTP dotyczy połączenia odbierającego. Sprawdź, która kategoria została faktycznie zgłoszona. RFC 8460 sekcja 4.3
Obecny rejestr erraty RFC 8461 zawiera zgłoszoną korektę wielkości liter dotyczącą wygasłych certyfikatów odbiorczych MTA; nie zezwala na wygasłe certyfikaty. Nie przedstawiono tutaj żadnych oryginalnych dowodów odnowienia ani hostingu. Ostateczna bramka operacyjna pozostaje oznaczoną datą demonstracją wdrożonej usługi, sprawdzoną przez jej właściciela. Błąd RFC 8461