2026-09-29 · BADANIA · Zespół Offensive Technology

Opóźnienia we wpisach Certificate Transparency: co pokazuje 1.3M certyfikatów

Krótka odpowiedź: Przeanalizowaliśmy publiczną historię Certificate Transparency (CT) dla około 700 domen o dużym natężeniu ruchu i porównaliśmy zadeklarowany początek ważności każdego certyfikatu (NotBefore) z momentem, w którym faktycznie pojawił się on w logu CT. Spośród 1.29 miliona zarejestrowanych certyfikatów od 2013 do połowy 2026 roku, 19.6% potrzebowało ponad dwóch pełnych dni, aby pojawić się w CT, a 15.0% ponad tygodnia. Następnie podzieliliśmy dane według daty 15 czerwca 2026 roku, kiedy to Chrome Root Program zaczął wymagać, aby ostateczny wystawiony certyfikat, a nie tylko precertyfikat, posiadał kwalifikujący się wpis w logu CT. Po tej dacie odsetek opóźnień powyżej 48 godzin spada do 1.7% a odsetek opóźnień powyżej tygodnia spada do 0.8%, w tej samej populacji, mierzonej w ten sam sposób. Mediana dla certyfikatów była niska już przed wprowadzeniem wymogu. Zmienił się długi ogon, czyli certyfikaty, które wcześniej pozostawały niezarejestrowane przez dni, tygodnie lub miesiące. Każda prezentowana tu liczba pochodzi z pasywnego odczytu publicznego logu. Z żadnym hostem się nie łączono, niczego nie skanowano. Oto jak dokładnie to zmierzyliśmy, którzy wystawcy najszybciej zlikwidowali opóźnienia oraz czego te dane dowodzą, a czego nie.

Dwie liczby, jedna zmiana polityki

System Certificate Transparency powstał po to, aby proces wystawiania certyfikatów był jawny i oparty na rejestrze append-only: każdy publicznie zaufany CA rejestruje wystawiane certyfikaty, dzięki czemu każdy, właściciel domeny, przeglądarka czy badacz, może sprawdzić, co zostało wygenerowane dla danej nazwy. Haczyk tkwił zawsze w słowie „ostatecznie”. CA musiał rejestrować precertyfikat i osadzać podpisane znaczniki czasu przed wystawieniem ostatecznego certyfikatu już od 2018 roku, a branżowy standard Maximum Merge Delay określa maksymalny czas na włączenie przesłanego precertyfikatu do logu, zwykle około 24 godzin. Jednak do tego roku nie istniał żaden analogiczny termin na zarejestrowanie ostatecznego certyfikatu. Certyfikat mógł być podpisany, opatrzony datą i już wdrożony na produkcji, podczas gdy jego własny wpis w logu pojawiał się z opóźnieniem dni, tygodni, a w co najmniej jednym niezależnie opisanym przypadku, nawet miesięcy.

Warto uważnie przyjrzeć się medianie: prawie się nie zmieniła, spadając z 1.0 godziny przed wprowadzeniem wymogu do 0.975 godziny po. To nie błąd w danych, lecz rzeczywisty kształt rozkładu. Większość certyfikatów od większości wystawców była rejestrowana w ciągu godziny na długo przed pojawieniem się jakichkolwiek regulacji. To, co wymóg wyraźnie zlikwidował, to długi ogon: mniejszość certyfikatów, które wcześniej czekały dniami lub tygodniami bez publicznego wpisu w logu. Średnie opóźnienie pokazuje to jeszcze dobitniej, spadając z około 64 dni przed cezurą do 6.7 godziny po niej, ponieważ średnia jest silnie zaburzana przez wartości odstające, które mediana ukrywa.

Mechanizm: termin dla precertyfikatów i brak terminu dla reszty

Pierwotny projekt Certificate Transparency zakładał rejestrowanie precertyfikatu, czyli obiektu zastępczego z rozszerzeniem typu poison extension, który pozwala CA uzyskać Signed Certificate Timestamps przed podpisaniem właściwego certyfikatu. Wiele publicznych logów CT musi zaakceptować i włączyć taki precertyfikat w ramach określonego Maximum Merge Delay, rzędu jednej doby, a przeglądarki egzekwują przestrzeganie tego wymogu przez logi od 2018 roku. Ta część procesu zawsze działała na czas, dzięki czemu branża mogła twierdzić, że wymóg CT jest w zasadzie spełniony.

Luką była druga część: nic nie zmuszało CA do przekazania ostatecznego, wystawionego certyfikatu do logu w określonym czasie. CA mógł pobrać SCT z precertyfikatu, osadzić je, wystawić certyfikat i wdrożyć go na produkcji, wszystko w pełni poprawnie, podczas gdy właściwy wpis certyfikatu w CT czekał. Jeden z niezależnie opisanych przypadków dotyczy certyfikatu wildcard wystawionego przez DigiCert dla dużej platformy, w którym różnica między datą wystawienia a pojawieniem się w CT wynosiła około trzech miesięcy (nie weryfikowaliśmy tego konkretnego przypadku niezależnie, należy traktować go jako anegdotę ilustrującą problem, a nie dowód). Nasze własne dane pokazują to samo zjawisko w skali całej populacji: przed wprowadzeniem wymogu znaczny odsetek certyfikatów od kilku dużych CA czekał ponad tydzień bez publicznego wpisu w logu. Jest to dokładnie ta luka, w którą uderza czerwcowa polityka Chrome z 2026 roku, wymagając, aby sam ostateczny certyfikat posiadał kwalifikujący się wpis w logu.

Którzy wystawcy zlikwidowali opóźnienia i w jakim stopniu

Wymieniamy tutaj urzędy certyfikacji, a nie domeny, których certyfikaty analizowaliśmy. Praktyki logowania stosowane przez CA to informacje leżące w interesie publicznym, podobnie jak w naszym wcześniejszym badaniu, w którym sprawdzaliśmy, które CA są autoryzowane przez domeny do wystawiania certyfikatów. Dla każdego wystawcy z reprezentatywną próbką po obu stronach daty granicznej, oto odsetek certyfikatów zarejestrowanych ponad 48 godzin po NotBefore, przed i po 15 czerwca 2026 roku:

Wyróżniają się dwie kwestie. Po pierwsze, Let’s Encrypt i Sectigo były bliskie zera jeszcze przed wprowadzeniem wymogu, co pokrywa się z faktem, że obie te instytucje prowadzą zautomatyzowane na wielką skalę procesy wystawiania, w których „wystaw i zarejestruj” stanowi niemal pojedynczą, atomową operację. Po drugie, urzędy certyfikacji mające największe pole do poprawy, czyli DigiCert, Amazon i Google Trust Services, zanotowały gwałtowny spadek, redukując odsetek opóźnionych wpisów od około czterech do siedmiu razy. Nie dla każdego wystawcy byliśmy w stanie zbudować wiarygodne zestawienie przed i po: GlobalSign, dawna marka COMODO oraz ZeroSSL miały w naszej próbce zbyt mało certyfikatów po wprowadzeniu wymogu (mniej niż kilkadziesiąt) albo żadna z monitorowanych przez nas domen nie odnowiła u nich certyfikatu po 15 czerwca 2026 roku. Wynika to z ograniczeń naszej próby domen, a nie z oceny samych wystawców.

Jak to zmierzyliśmy

Sceptyk powinien być w stanie odtworzyć to badanie od zera, dlatego przedstawiamy całą metodologię bez pomijania szczegółów.

• Badana populacja. Około 700 domen z listy top 1,000 Tranco, zebranych w ramach kilku naszych ostatnich badań pasywnego DNS. Dla każdej domeny pobraliśmy pełną historię Certificate Transparency z serwisu crt.sh, który zwraca wszystkie zarejestrowane certyfikaty dla danej domeny i jej subdomen, począwszy od 2013 roku.
• Metryka. Dla każdego zarejestrowanego certyfikatu porównaliśmy pole not_before (zadeklarowany początek ważności certyfikatu) z entry_timestamp (momentem odnotowania wpisu przez crt.sh). Różnica stanowi raportowane przez nas opóźnienie. Usunęliśmy duplikaty według wewnętrznego ID wpisu w crt.sh i odrzuciliśmy nieliczne wpisy o nieprawdopodobnej rozbieżności (ponad pięć lat), uznając je za błędy zegara lub parsowania, a nie realne zachowania przy wystawianiu.
• Podział danych. Pogrupowaliśmy wszystkie certyfikaty w zależności od tego, czy wartość NotBefore przypadała przed, czy w dniu lub po 15 czerwca 2026 roku, czyli dacie wejścia w życie wymogu Chrome Root Program dotyczącego posiadania kwalifikującego się wpisu CT przez ostateczny certyfikat. Nasze zbuforowane dane obejmują okres do 24 lipca 2026 roku, więc okno po wprowadzeniu wymogu to około sześć pierwszych tygodni obowiązywania nowej zasady, a nie pełny rok. Dane po wprowadzeniu wymogu należy traktować jako wstępny odczyt, który z czasem powinien się ustabilizować, a nie jako w pełni ukształtowany trend.
• Czego nie robiliśmy. Nigdy nie wnioskowaliśmy o certyfikat, nie łączyliśmy się z serwerem www ani niczego nie skanowaliśmy. Odczyt publicznego logu CT to zwykłe zapytanie, a nie aktywne sondowanie, dokładnie według zasady, którą stosujemy w każdym realizowanym przez nas projekcie.
• Co zachowaliśmy. Zagregowane liczby, mediany i percentyle dla poszczególnych wystawców i okresów. W wynikach nie ma nazw domen ani subdomen, nie zbieraliśmy też żadnych danych osobowych. Nazwy domen i publiczne metadane certyfikatów nie stanowią danych osobowych.

Czego to nie dowodzi

Rzetelne ograniczenia, ponieważ liczba pozbawiona kontekstu i zastrzeżeń to zwykły marketing.

• Okno po wprowadzeniu wymogu jest krótkie. Sześć tygodni danych wystarczy, by pokazać kierunek zmian, ale nie by uznać je za trwałe. Część poprawy może wynikać z początkowej, wzmożonej dyscypliny, która z czasem może osłabnąć. Planujemy to zweryfikować ponownie.
• Nie dla każdego wystawcy mamy wiarygodny obraz po zmianie. Kilka dużych CA miało w naszej próbie 700 domen po prostu zbyt mało certyfikatów wystawionych po wejściu w życie wymogu, aby rzetelnie przedstawić dane. Szersza próba domen pozwoliłaby uzupełnić te braki.
• Wartość NotBefore nie jest idealnym odzwierciedleniem momentu faktycznego podpisania certyfikatu. CA może ustawić NotBefore nieznacznie w przeszłości ze względu na tolerancję przesunięcia zegara (clock-skew). Taka praktyka może nieznacznie zawyżać wyliczone przez nas opóźnienie nawet dla CA logującego wpisy natychmiast, jednak nie tłumaczy rozbieżności mierzonych w dniach czy tygodniach.
• To pomiar opóźnień, a nie wykrywanie nieprawidłowo wystawionych certyfikatów (misissuance). Certyfikat zarejestrowany z opóźnieniem nie jest dowodem na to, że został wystawiony błędnie, a jedynie na to, że publiczny ślad audytowy nie nadążał za jego użyciem. Ryzykiem jest sama luka w audycie: przez cały czas, gdy certyfikat nie jest zarejestrowany, nikt monitorujący CT pod kątem własnej domeny go nie zobaczy.
• Badana populacja faworyzuje domeny o dużym natężeniu ruchu. Lista top 1,000 Tranco opiera się na organizacjach o dużych zasobach i wiodących sieciach CDN. Sposób wystawiania certyfikatów dla długiego ogona mniejszych witryn, które często korzystają z tych samych dużych CA, ale za pośrednictwem innych narzędzi automatyzacji, może wyglądać inaczej.

Dlaczego to ma znaczenie

Główna wartość Certificate Transparency dla właściciela domeny polega na możliwości monitorowania publicznego logu pod kątem własnej nazwy i wykrycia nieoczekiwanego certyfikatu, zanim zostanie użyty przeciwko niemu. Działa to tylko wtedy, gdy rejestracja następuje niemal równocześnie z wystawieniem. Certyfikat, który czeka na rejestrację przez miesiąc, to certyfikat, który działał w środowisku produkcyjnym, był uznawany przez każdą przeglądarkę i pozostawał niewidoczny dla każdego monitorującego CT przez dokładnie ten czas. Luka, którą ten wymóg zamyka, nie jest niczym egzotycznym. To po prostu różnica między „formalnie spełniamy wymogi Certificate Transparency” a „rzeczywiście widzisz, co wystawiliśmy, bezzwłocznie, za każdym razem”. Dane pokazują, że najszybsi wystawcy w branży, w tym Let’s Encrypt i Sectigo, traktowali to jako pojedynczy, atomowy krok na długo przed wprowadzeniem jakichkolwiek wymogów. Pozostali wyraźnie nadrabiają zaległości, odkąd Chrome Root Program przekształcił to z dobrej praktyki w twardy wymóg. To ten sam schemat, który zaobserwowaliśmy, badając kto rzeczywiście weryfikuje produkcyjne logi CT: elementy tego ekosystemu, które są egzekwowane, rozwijają się szybko, a te, do których jedynie się zachęca, pozostają w tyle.

Opóźnienia w logach Certificate Transparency: szybkie odpowiedzi

Czym jest opóźnienie w logach Certificate Transparency?

To różnica czasu między zadeklarowanym początkiem ważności certyfikatu TLS (NotBefore) a momentem, w którym faktycznie pojawia się on w publicznym logu CT. Krótki odstęp oznacza, że publiczny ślad audytowy nadąża za procesem wystawiania. Długi odstęp oznacza, że ważny, gotowy do użycia certyfikat istniał przez pewien czas bez jakiegokolwiek publicznego śladu.

Czy Chrome wymaga rejestrowania wszystkich certyfikatów w CT?

Polityka Chrome Root Program wymaga, aby ostateczny wystawiony certyfikat, a nie tylko precertyfikat, posiadał kwalifikujący się wpis w logu CT w przypadku certyfikatów wystawionych 15 czerwca 2026 roku lub później. Certyfikaty wystawione po tej dacie bez takiego wpisu nie są uznawane przez Chrome za zaufane. Rejestrowanie precertyfikatów było wymagane już od 2018 roku.

Dlaczego certyfikat mógł być ważny, zanim został zarejestrowany w logu?

CT wymaga zarejestrowania precertyfikatu przed wystawieniem ostatecznego certyfikatu, a reguły Maximum Merge Delay (około 24 godzin) ograniczają czas trwania tej operacji. Do czasu wprowadzenia polityki Chrome w czerwcu 2026 roku nie było analogicznego terminu na zarejestrowanie samego certyfikatu ostatecznego, przez co mógł być on podpisany, opatrzony datą i używany, podczas gdy jego własny wpis w logu pojawiał się z opóźnieniem, niekiedy sięgającym miesięcy.

Jak to zmierzono?

Pasywnie. Przeanalizowaliśmy publiczną historię CT za pośrednictwem crt.sh dla około 700 domen z listy top 1,000 Tranco, porównując wartość NotBefore każdego certyfikatu ze znacznikiem czasu wpisu w logu. Z żadnym hostem się nie łączono, nie odpytywano DNS ani niczego nie skanowano. Wynikiem jest 1.29 miliona wpisów w logach z lat 2013 do połowy 2026 roku, podzielonych według daty wejścia wymogu 15 czerwca 2026 roku.

Powiązane artykuły

• Certificate Transparency w erze post-quantum: 43% logów static-CT podpisuje już za pomocą ML-DSA-44.
• Ile czołowych domen ogranicza wystawianie certyfikatów?
• Co dowodzą certyfikaty.