Let’s Encrypt ACME: automatyzacja certyfikatów i bezpieczne zarządzanie ich odnawianiem

Procedura ACME i odrębne role kluczy

ACME standaryzuje komunikację między klientem a urzędem certyfikacji, a nie całe środowisko operacyjne. Klient najpierw korzysta z konta ACME, a następnie tworzy zlecenie dotyczące jednej lub kilku nazw domen. Dla każdego identyfikatora serwer wymaga autoryzacji. Dopiero po pomyślnym zakończeniu tego procesu klient może sfinalizować zlecenie za pomocą żądania podpisania certyfikatu (Certificate Signing Request, w skrócie CSR) i pobrać wydany certyfikat.

1. Utwórz klucz konta lub skorzystaj z istniejącego konta ACME i utwórz zlecenie.
2. Dla każdego żądanego identyfikatora należy dostarczyć podane wyzwanie i poczekać na autoryzację.
3. Należy wygenerować oddzielną parę kluczy dla certyfikatu, utworzyć na jej podstawie żądanie CSR i sfinalizować zamówienie. Klucz publiczny w żądaniu CSR nie może być taki sam jak klucz konta, który służy do uwierzytelnienia zlecenia finalizacji.
4. Pobierz certyfikat i łańcuch certyfikatów, zabezpiecz je i rozesłać do odpowiednich punktów końcowych TLS.

Der Klucz konta ACME uwierzytelnia klienta w odniesieniu do konta wobec serwera ACME oraz podpisuje komunikaty protokołu. Natomiast klucz prywatny użyty w CSR należy do późniejszej tożsamości TLS. RFC 8555 wymaga dwóch różnych klas kluczy: klucz publiczny w CSR nie może odpowiadać żadnemu znanemu kluczowi konta, a w szczególności nie może być identyczny z kluczem konta, który uwierzytelnia zlecenie finalizacji. Klient i serwer muszą sprawdzić to rozdzielenie.

W przypadku DNS-01 dochodzi jeszcze trzeci wrażliwy element: uprawnienia do API DNS. Let’s Encrypt zwraca uwagę, że przechowywanie pełnych danych dostępowych do interfejsu API DNS na serwerze WWW znacznie zwiększa skutki ewentualnego ataku. W ramach środków bezpieczeństwa operacyjnego token powinien zatem mieć uprawnienia wyłącznie do zmiany niezbędnych rekordów wyzwania; alternatywnie weryfikacja DNS może odbywać się na oddzielnym systemie.

Klucze konta, klucze certyfikatu i dostęp do DNS stanowią odrębne strefy zaufania. Stosowanie różnych par kluczy dla konta i certyfikatu jest wymogiem protokołu; ich oddzielne przechowywanie, ściśle ograniczone uprawnienia dostępu oraz niezależne procesy rotacji stanowią ponadto ważne środki operacyjne. W ten sposób naruszenie bezpieczeństwa tokenu DNS nie musi oznaczać uzyskania dostępu ani do prywatnego klucza certyfikatu, ani do konta ACME.

Automatyzacja nie eliminuje błędnych warunków wstępnych. Niedostępny port, nieprawidłowe trasowanie, nieodpowiednie delegowanie DNS lub zbyt szerokie uprawnienia dostępu pozostają problemami operacyjnymi, nawet jeśli tworzenie zleceń jest zautomatyzowane. ACME przyspiesza powtarzalny proces; operatorzy muszą niezawodnie wdrożyć w swoim środowisku koncepcję uprawnień, wymagany rozdział kluczy konta i certyfikatu, bezpieczne przechowywanie oraz kontrolę faktycznie dostarczonych certyfikatów.

Odpowiednie wyzwanie dla infrastruktury

Wyzwanie określa, w jaki sposób urząd certyfikacji weryfikuje kontrolę nad identyfikatorem. Powinno się je zatem wywodzić ze ścieżki sieciowej, zarządzania DNS i terminacji TLS, a nie z ogólnej preferencji dla konkretnego narzędzia klienckiego. HTTP-01, DNS-01 i TLS-ALPN-01 opisują różne rodzaje kontroli i stawiają odpowiednio inne wymagania dotyczące infrastruktury i uprawnień.

W przypadku pojedynczej, publicznie dostępnej strony internetowej HTTP-01 zazwyczaj jest to najprostsza droga. Klient udostępnia zasób pod adresem /.well-known/acme-challenge/ gotowy do pobierania certyfikatu Let’s Encrypt przez port 80. Jeśli domena wskazuje na kilka adresów A lub AAAA, zasób ten musi być dostępny na wszystkich systemach, do których może dotrzeć żądanie weryfikacyjne. W przeciwnym razie pojawi się sporadyczny błąd weryfikacji.

Certyfikaty z symbolami wieloznacznymi dla *.example.org natomiast wymagają bezwzględnie DNS-01. W tym celu klient publikuje rekord TXT pod adresem _acme-challenge.example.org. Rozwiązanie to sprawdza się w przypadku wielu dynamicznych subdomen, rozproszonych serwerów WWW lub modułu równoważenia obciążenia, ponieważ żadna pojedyncza instancja HTTP nie musi dostarczać pliku weryfikacyjnego. Warunkiem jest jednak niezawodna, dająca się zautomatyzować zmiana w systemie DNS.

Proxy odwrotne bez dostępnego portu 80 może TLS-ALPN-01 można go zastosować, o ile kontroluje on zakończenie połączenia TLS na porcie 443, a używany klient obsługuje to wyzwanie. Weryfikacja odbywa się za pośrednictwem specjalnego połączenia TLS, a nie poprzez zwykły plik internetowy. Procedura ta nadaje się zatem szczególnie do specjalistycznej infrastruktury proxy lub hostingowej, ale nie jako ogólny zamiennik dla HTTP-01. Również w tym przypadku nie są obsługiwane symbole wieloznaczne.

Żadna z metod nie jest ogólnie lepsza: HTTP-01 ogranicza liczbę żądań DNS w przypadku prostej strony internetowej, DNS-01 umożliwia stosowanie symboli wieloznacznych i oddziela weryfikację od ścieżki internetowej, a TLS-ALPN-01 w sposób ukierunkowany wykorzystuje istniejące mechanizmy kontroli TLS. Kluczowe znaczenie ma to, aby wybrane wyzwanie działało w rzeczywistych ścieżkach przełączania awaryjnego, IPv4 i IPv6, a jego uprawnienia były dostosowane do danego modelu operacyjnego.

ARI, profile i krótsze okresy obowiązywania

Z Informacje dotyczące odnowienia ACME (ARI) logika odnawiania zmienia się z lokalnie ustalonej daty granicznej na przedział czasowy zalecany przez serwer ACME. Klient pobiera tę informację dla istniejącego certyfikatu i wybiera losowy moment w ramach tego przedziału czasowego. Dzięki temu odnowienia mogą być rozłożone w czasie, a w przypadku szczególnych zdarzeń mogą być celowo przyspieszone.

ARI jest standardowym rozszerzeniem, ale nie jest automatyczną funkcją każdego zainstalowanego klienta lub panelu hostingowego. Let’s Encrypt może oferować nowe, kompatybilne wstecznie funkcje ACME w istniejącym punkcie końcowym; to, czy konkretna instalacja z nich korzysta, zależy od jej wersji i implementacji. W przypadku większych zasobów należy zatem sprawdzić, czy klient wysyła zapytania do ARI, przestrzega przedziału czasowego i nie synchronizuje ponownie odnowień.

Let’s Encrypt przypisuje ponadto zamówienia do profili certyfikatów. W przypadku braku wyraźnego wyboru profilu domyślnym jest profil klasyczny, którego okres ważności wynosi obecnie 90 dni. Profil tlsserver ma 45-dniowy okres ważności, krótsze terminy dla otwartych autoryzacji i zleceń oraz maksymalnie 25 nazw DNS. shortlived wykorzystuje również krótkie okresy ważności obiektów, jest ważny przez około 160 godzin i obsługuje identyfikatory DNS oraz IP.

Wybór profilu również wymaga obsługi po stronie klienta; nie należy go wywodzić wyłącznie z dokumentacji serwera. Profile różnią się między sobą nie tylko czasem działania i identyfikatorami, ale także innymi właściwościami. Aplikacje i narzędzia do inwentaryzacji nie mogą zatem milcząco zakładać ani jednolitego przebiegu procesu, ani obecności nazwy wspólnej (Common Name) w każdym certyfikacie.

Z matematycznego punktu widzenia stosunek 90 dni do około 160 godzin wynosi około 13,5. Nie wynika z tego żadne zmierzone obciążenie, ale jasna konsekwencja planistyczna: każda usterka podczas składania zamówienia, dystrybucji lub ponownego załadunku powoduje, że certyfikatów o krótkim okresie ważności znacznie wcześniej krytyczne. Mają one sens jedynie w przypadku systemów, których cały łańcuch dostaw jest monitorowany, a ich odnowienie nie wymaga ręcznej interwencji. W przypadku odnowień koordynowanych przez ARI w serwisie Let’s Encrypt obowiązują szczególne zasady dotyczące limitów wywołań, zgodnie z udokumentowanymi warunkami.

Macierz wyzwań i bezpieczne delegowanie DNS

Wybór wyzwania zależy od dostępnej infrastruktury, a nie od ogólnego rankingu. Wyzwanie HTTP-01 wymaga publicznie dostępnej odpowiedzi na porcie 80, DNS-01 – kontrolowanego wpisu TXT, a TLS-ALPN-01 – kontroli nad zakończeniem połączenia TLS na porcie 443. Nazwy z symbolami wieloznacznymi można zweryfikować wyłącznie w ramach wyzwania DNS-01.

W związku z tym strona internetowa z jednym serwerem często dobrze radzi sobie z HTTP-01. Jeśli jednak rekordy DNS typu A lub AAAA wskazują na kilka systemów, każdy faktycznie osiągnięty cel musi dostarczyć oczekiwany zasób. W przeciwnym razie wynik zależy od tego, do którego punktu końcowego dotrze proces walidacji. Moduł równoważenia obciążenia lub centralnie synchronizowany magazyn wyzwań eliminuje ten problem tylko wtedy, gdy obejmuje wszystkie ścieżki.

W przypadku modelu DNS-01 należy ustawić jako Uprawnienia minimalne Należy dążyć do tego, aby klient ACME mógł zmieniać wyłącznie niezbędne wpisy wyzwania. To, jakie ograniczenie jest faktycznie możliwe, zależy od interfejsu API i modelu uprawnień dostawcy DNS; nie każda usługa zezwala na przyznawanie uprawnień dla pojedynczej nazwy TXT. Jeśli pozostaje jedynie szeroki zakres dostępu, należy przenieść proces walidacji do oddzielnego systemu lub delegować osobną strefę wyzwań. Dane dostępowe należy przechowywać w zabezpieczonym repozytorium, oddzielnie od certyfikatów i kluczy konta ACME.

W przypadku rozległych stref oddzielna strefa wyzwań może jeszcze bardziej ograniczyć uprawnienia. Delegowanie _acme-challenge Za pomocą rekordów CNAME lub NS dane walidacyjne są przenoszone do oddzielnej strefy administracyjnej. Klient otrzymuje wówczas uprawnienia do wprowadzania zmian wyłącznie w tej strefie. Przed uruchomieniem w środowisku produkcyjnym należy sprawdzić zawartość rekordów TXT oraz rozdzielczość DNS: poprawna odpowiedź API nie wystarczy, jeśli serwery rozdzielające nie widzą jeszcze delegacji lub rekordu.

Niezawodna automatyzacja odnawiania i dystrybucji

Wytrzymałe Zarządzanie certyfikatami nie kończy się na pobraniu certyfikatu. W środowisku rozproszonym centralny moduł ACME uruchamia proces walidacji i bezpiecznie przechowuje certyfikat oraz klucz prywatny. Dopiero potem artefakty są dystrybuowane do punktów końcowych TLS, gdzie są weryfikowane i kontrolowane przed aktywacją. Klucz certyfikatu użyty w CSR musi różnić się od klucza uwierzytelniającego konta ACME; sposób, w jaki oba klucze są następnie oddzielnie przechowywane, autoryzowane i poddawane rotacji, należy określić w koncepcji operacyjnej.

Poniższa tabela przedstawia zalecaną koncepcję działania łańcucha dostaw. Specyfikacja RFC 8555 wymaga, aby klucz publiczny zawarty w CSR nie odpowiadał żadnemu znanemu kluczowi konta, a w szczególności nie był zgodny z kluczem konta używanym do uwierzytelniania zlecenia finalizacji. Konkretny podział organizacyjny dotyczący przechowywania, uprawnień dostępu i rotacji opiera się na tym wymogu protokołu. Hak wdrożeniowy Certbota jest przeznaczony do działań podejmowanych po pomyślnym wygenerowaniu certyfikatu. Zabezpieczenie transmisji, weryfikacja miejsca docelowego oraz zewnętrzna weryfikacja TLS muszą być dostosowane do danej infrastruktury.

W przypadku wprowadzania zmian w integracjach z Panelem lub DNS nie należy traktować łańcucha produkcyjnego jako pojedynczego systemu. Zwłaszcza w przypadku zarządzania za pośrednictwem Aktualizacje Plesk dla dostawców usług hostingowych Dostępne funkcje zależą od typu panelu, rozszerzeń i podłączonych usług. Konkretne możliwości klienta ACME, na przykład w zakresie dodatkowych rozszerzeń protokołu, również zależą od wersji i należy je sprawdzić w konkretnej konfiguracji.

W przypadku Certbota hook wdrożeniowy może uruchomić ostatni krok, ponieważ jest on wykonywany dopiero po pomyślnym odnowieniu certyfikatu. Poniższy wzór zakłada, że ścieżka lokalna wskazuje na sprawdzony, uruchamialny skrypt bez danych uwierzytelniających. Skrypt powinien idempotentny pracować, rejestrować błędy i ponownie ładować wyłącznie te usługi, które korzystają z odnowionego certyfikatu.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

Kod wyjścia z certbot renew nie stanowi potwierdzenia nowego certyfikatu: nawet jeśli nie było potrzeby odnawiania certyfikatu, polecenie może zakończyć się statusem 0. System monitorowania musi zatem samodzielnie ustalić, jaki certyfikat faktycznie dostarcza publiczny punkt końcowy, kiedy wygasa oraz czy ponowne załadowanie zakończyło się powodzeniem.

CAA, profile i certyfikaty dla adresów IP

Rekord CAA to Balustrada wystawowa: Określa, które urzędy certyfikacyjne mogą wydawać certyfikaty dla danej domeny. Ponadto polityka może określać dozwoloną metodę walidacji oraz, za pomocą parametru accounturi określić przewidziane konto ACME. Aktualny klucz konta służy do uwierzytelniania dostępu do tego konta, ale można go zmienić w ramach procesu zmiany klucza ACME. Powiązanie z kontem nie zastępuje zatem ani zabezpieczenia aktualnego klucza konta, ani kompleksowego systemu uprawnień.

Poniższy wpis w pliku Record zezwala na korzystanie z Let’s Encrypt dla danej domeny wyłącznie w przypadku weryfikacji DNS-01. Rozwiązanie to sprawdza się tylko wtedy, gdy weryfikacja DNS-01 jest skonfigurowana automatycznie, a strefa wyzwania jest niezawodnie zarządzana. Kto w przyszłości zamierza korzystać z HTTP-01 dla pojedynczej strony internetowej lub TLS-ALPN-01 dla serwera proxy odwrotnego, świadomie blokuje wydanie certyfikatu poprzez zastosowanie przedstawionego ograniczenia.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

Pojedynczy wiersz niekoniecznie opisuje całość Polityka CAA w tej strefie. Kilka rekordów tego samego typu działa addytywnie: jeśli jeden z nich zezwala na wydanie certyfikatu, zezwolenie to pozostaje w mocy pomimo istnienia innych rekordów o bardziej restrykcyjnych warunkach. W przypadku certyfikatów z symbolami wieloznacznymi należy ponadto sprawdzić, czy issuewild-istnieją rekordy. W przypadku braku takich rekordów obowiązuje issue również dla symboli wieloznacznych; istniejące issuewild-Wpisy te regulują natomiast wydawanie symboli wieloznacznych oddzielnie. Decydujące znaczenie ma zatem zawsze pełny, obowiązujący zestaw rekordów dla sprawdzanej nazwy.

Certyfikaty dla publicznych adresów IP to zupełnie inna sprawa niż certyfikaty domenowe. Let’s Encrypt obsługuje identyfikatory IP w profilu shortlived; jako metody walidacji można rozważyć HTTP-01 i TLS-ALPN-01. Metoda DNS-01 nie pozwala na walidację adresu IP. Krótki okres ważności wynoszący około 160 godzin wymaga zatem ciągłego, zautomatyzowanego odnawiania, dystrybucji i kontroli dostarczania.

Profil „shortlived” nadaje się zatem np. do interfejsów dostępnych bezpośrednio przez adres IP tylko wtedy, gdy każdy etap działa bez konieczności ręcznej interwencji. Nie jest to skrócona wersja przeznaczona dla systemów obsługiwanych sporadycznie. Ponadto używany klient ACME oraz środowisko docelowe muszą obsługiwać wybrany profil oraz wybrane wyzwanie; dostępność w usłudze ACME nie oznacza, że każda wersja klienta je obsługuje.

Monitorowanie i diagnostyka błędów najpierw w środowisku stagingowym

Wykrywanie błędów w ACME zaczyna się od faktycznie stosowanej procedury walidacji, a nie od ponownego złożenia zamówienia na certyfikat. Do wprowadzania zmian w kliencie, routingu, zaporze sieciowej lub DNS nadaje się oddzielny punkt końcowy środowiska testowego Let’s Encrypt. Środowisko testowe ma własne, znacznie wyższe limity, ale nie jest nieograniczone; certyfikaty testowe wydane w tym środowisku nie są publicznie uznawane za wiarygodne. Chociaż nowe funkcje protokołu mogą być dostępne w punkcie końcowym ACME, należy jednak osobno sprawdzić, czy są one obsługiwane przez zainstalowanego klienta.

W przypadku błędu HTTP-01 należy najpierw sprawdzić, czy dana domena jest publicznie dostępna przez port 80 oraz czy żądany plik znajduje się pod adresem /.well-known/acme-challenge/ do systemu docelowego. Kilka rekordów typu A lub AAAA utrudnia przeprowadzenie testu: każdy faktycznie dostępny punkt końcowy musi udostępnić odpowiedni plik wyzwania. Typowymi przyczynami są nieprawidłowe trasowanie wirtualnego hosta, proxy umieszczone przed serwerem, reguła zapory sieciowej lub niezsynchronizowane kontenery.

Natomiast TLS-ALPN-01 wymaga kontroli nad zakończeniem połączenia TLS na porcie 443. W przypadku błędu należy sprawdzić, który moduł równoważenia obciążenia lub serwer proxy przyjmuje połączenie, czy dostarcza certyfikat wymagany do wyzwania oraz czy standardowa usługa TLS nie zastępuje tego procesu. Pomyślnie wygenerowany lokalny plik certyfikatu nie stanowi dowodu na to, że publicznie dostępny punkt końcowy faktycznie go wykorzystuje.

W przypadku DNS-01 nazwa i treść rekordu TXT znajdują się pod _acme-challenge należy sprawdzać osobno. Rekord musi być opublikowany w strefie delegowanej lub docelowej; ponadto łańcuch delegacji musi być poprawny, jeśli stosowana jest oddzielna strefa testowa. Powtarzające się nieudane próby spowodowane błędami w pisowni, zmianami, które nie są jeszcze widoczne, lub nieprawidłową delegacją należy najpierw przeanalizować w środowisku testowym.

Skuteczne Monitoring Nie tylko monitoruje datę wygaśnięcia w magazynie modułu ACME. Niezależnie sprawdza dostarczoną nazwę hosta, pozostały okres ważności certyfikatu tam przedstawionego oraz powodzenie ponownego załadowania po aktualizacji. Powiadomienie powinno zostać wysłane również w przypadku niepowodzenia odnowienia lub gdy punkt końcowy nadal dostarcza stary certyfikat pomimo pomyślnego wystawienia nowego. W przypadku planowanych zmian dotyczących serwerów hostingowych artykuł uzupełnia Bezpieczne planowanie aktualizacji cPanel i WHM niezbędne planowanie operacyjne.

Limity stawek i odnowienia w portfelu

W portfelu certyfikatów limity transakcji stanowią warunek projektowy Automatyzacja SSL. Codzienne wymuszone odświeżania lub zadania uruchamiane w tym samym czasie generują niepotrzebne zlecenia i mogą powodować przekroczenie limitów. Dotyczy to zwłaszcza sytuacji, gdy błąd infrastruktury dotyczy wielu domen jednocześnie: powtórzenia nie usuwają ani brakujących plików challenge, ani nieprawidłowych ustawień DNS, a jedynie zwiększają liczbę nieudanych walidacji. Błędy należy zatem wyeliminować przed kolejnym uruchomieniem w środowisku produkcyjnym.

Informacje dotyczące odnowienia ACME, w skrócie ARI, zastępuje sztywne lokalne wartości progowe oknem odnowienia zalecanym przez serwer ACME dla istniejącego certyfikatu. Klient obsługujący ARI pobiera informacje o odnowieniu i wybiera losowy moment w ramach tego okna. Harmonogram może regularnie uruchamiać klienta, ale sam nie analizuje informacji ARI. Klient musi uwzględnić zalecane okno i Retry-After uwzględniać, a także w przypadku błędów przestrzegać odpowiednich odstępów czasu między kolejnymi próbami i powtórzeniami. Częstsze uruchomienia harmonogramu nie mogą zatem prowadzić do niekontrolowanych powtórzeń zadań, które zakończyły się niepowodzeniem.

W przypadku Let’s Encrypt odnowienia koordynowane przez ARI mogą być wyłączone z ograniczeń częstotliwości (Rate Limits) zgodnie z udokumentowanymi warunkami. Nowe zlecenie musi między innymi zawierać co najmniej jeden identyfikator certyfikatu, który ma zostać zastąpiony, a certyfikat ten nie może być już wcześniej zastąpiony za pośrednictwem ARI. Nie jest to ogólne zezwolenie na dowolne nowe zlecenia: zmiany w zakresie certyfikatu należy traktować oddzielnie pod względem technicznym i operacyjnym.

W szczególności skrócona lub zmieniona lista SAN nie oznacza automatycznie odnowienia dotychczasowego certyfikatu. Zlecenie zawierające tylko część dotychczasowych nazw może spowodować wygenerowanie odrębnego certyfikatu, podczas gdy stary certyfikat pozostaje nadal ważny. W związku z tym wykaz powinien zawierać identyfikator certyfikatu, pełną listę identyfikatorów, przypisane punkty końcowe oraz sposób odnowienia. Przed planowaną zmianą listy SAN należy zdecydować, które usługi zostaną przekształcone oraz kiedy usunięte zostaną certyfikaty, które nie są już potrzebne.

W przypadku wielu procesów jednoznaczny podział odpowiedzialności zapobiega powielaniu zleceń dotyczących tej samej pozycji. Warto zastosować centralny moduł planowania lub skoordynowaną blokadę, przejrzyste protokoły oraz stopniowane powtórzenia po wystąpieniu błędu. Losowy wybór w ramach okna ARI nie zastępuje tego mechanizmu sterowania, a przede wszystkim ogranicza równoczesność regularnych odświeżeń.

Wybór odpowiedniego modelu operacyjnego w zależności od ryzyka

W przypadku pojedynczej, publicznie dostępnej strony internetowej model HTTP-01 jest zazwyczaj najprostszym rozwiązaniem. Serwer WWW musi niezawodnie obsługiwać port 80 i dostarczać plik wyzwania w oczekiwanej ścieżce. Model ten nie jest kompatybilny z symbolami wieloznacznymi i staje się niestabilny, gdy kilka niezależnych celów odpowiada na tę samą domenę. Dlatego ma on sens przede wszystkim wtedy, gdy routing sieciowy, przechowywanie certyfikatów i dostarczanie połączeń TLS są skupione w jednym, ściśle kontrolowanym miejscu.

DNS-01 to model odpowiedni dla symboli wieloznacznych, dynamicznych subdomen i rozproszonych punktów końcowych TLS. Warunkiem koniecznym jest nie tylko dostęp do DNS, ale także możliwość bezpiecznej automatyzacji zmiany wymaganego rekordu TXT. Jak najbardziej ściśle ograniczony token lub delegowana strefa wyzwania (challenge zone) zmniejsza skutki włamania do systemu. To, jaki poziom szczegółowości można osiągnąć, zależy od interfejsu API DNS. Delegacje muszą być udokumentowane jako zależności produkcyjne, monitorowane oraz wyposażone w ścieżkę przywracania.

TLS-ALPN-01 jest przeznaczony dla operatorów, którzy chcą precyzyjnie sterować terminacją TLS na porcie 443, na przykład na serwerze proxy odwrotnym lub w urządzeniu równoważącym obciążenie. Metoda ta nie stanowi uniwersalnego zamiennika dla HTTP-01 ani nie obsługuje symboli wieloznacznych. Jej praktyczna użyteczność zależy dodatkowo od konkretnej implementacji klienta i serwera proxy. Przed wdrożeniem należy zatem sprawdzić, czy oprogramowanie jest w stanie wygenerować wyzwanie, dostarczyć je, a po zakończeniu procesu prawidłowo je usunąć.

Das Profil shortlived nadaje się wyłącznie do systemów z pełną automatyzacją typu end-to-end. Let’s Encrypt określa w tym przypadku czas trwania na około 160 godzin oraz identyfikatory DNS i IP; w porównaniu ze standardowym profilem obejmującym 90 dni powoduje to, z matematycznego punktu widzenia, znaczny wzrost wymaganej częstotliwości odnawiania. Każdy etap – od złożenia zamówienia po dystrybucję, odświeżenie i kontrolę zewnętrzną – musi zatem działać niezawodnie. Wybór profilu wymaga ponadto, aby używany klient ACME faktycznie obsługiwał dany profil.

Niezależnie od modelu, profesjonalne Zarządzanie certyfikatami pełny wykaz zasobów, bezpiecznie zarządzane klucze oraz dostęp do DNS z minimalnymi uprawnieniami. Klucz konta służy do uwierzytelniania klienta w ramach konta ACME; klucz prywatny użyty w CSR należy do tożsamości TLS. RFC 8555 zabrania wykorzystywania publicznego klucza konta w certyfikacie: klucz w CSR nie może w szczególności pokrywać się z kluczem konta, który uwierzytelnia zlecenie finalizacji. Oddzielne przechowywanie, przyznawanie uprawnień i rotacja tych klas kluczy, a także odwołalne uprawnienia dostępu oraz sprawdzona ścieżka powrotu do poprzedniego certyfikatu stanowią część koncepcji zarządzania uprawnieniami i planu awaryjnego.

Pomyślne zakończenie operacji ACME nie może być jedynym kryterium powodzenia. Kontrola dostarczania musi sprawdzić poza pracownikiem, który certyfikat przedstawia prawdziwy punkt końcowy TLS. W przypadku etapów dystrybucji i ponownego ładowania odpowiednie są działania uruchamiane wyłącznie po pomyślnym odnowieniu certyfikatu; w Certbotie przewidziano w tym celu hook wdrożeniowy. Jego skrypt powinien być idempotentny, rejestrować błędy i ponownie ładować wyłącznie te usługi, które faktycznie korzystają z odnowionego certyfikatu.