Certyfikat Przejrzystości (Certificate Transparency) to otwarta platforma programistyczna (framework) stworzona do ochrony oraz monitorowania braków w certyfikacji. Świeżo wydane certyfikaty dostają się do obiegu publicznego, często niezależne logi CT zostają wpisane do rejestru, przez co zachowany zostaje zabezpieczony kryptograficznie rekord certyfikatów TLS.
W ten sposób organy certyfikujące (CA) mogą podlegać znacznie większemu, publicznemu nadzorowi i kontroli. Potencjalnie szkodliwe certyfikaty, jak te, które naruszają Podstawowe Wymogi CA/B Forum mogą zostać znacznie sprawniej wykryte i cofnięte. Podmioty zajmujące się sprzedażą przeglądarek oraz opiekuni certyfikatów zaufanych są również uprawnieni do podejmowania gruntowniej popartych decyzji dot. problematycznych organów certyfikujących, którym mogą odmowić zaufania.
Logi CT są budowane w ramach struktury danych drzewa Merkla (Merkle tree). Węzły są oznaczane hashami kryptograficznymi ich węzłów potomnych. Liście (leaf nodes) zawierają hashe aktualnych części danych. Oznaczenie węzła głównego (root node) zależy jednakże od wszystkich pozostałych węzłów w drzewie.
W kontekście przejrzystości certyfikacji dane hashowane przez liście są certyfikatami wydawanymi obecnie przez różne CA. Obecność certyfikatu może zostać zweryfikowana przez dowód kontroli skutecznie generowany i weryfikowany w czasie działania logarytmicznego - logarithmic O(log n) time.
Pierwotnie, w 2013 roku przejrzystość certyfikacji służyła przeciwdziałaniu narażania CA (naruszenia DigiNotar w 2011 roku), wątpliwym decyzjom (incydent Trustwave subordinate root w 2012 roku) oraz technicznym problemom wydawniczym (emisja słabego, 512-bitowego certyfikatu przez Digicert Sdn Bhd w Malezji)
Gdy certyfikaty zostają dostarczone do rejestru CT, znacznik SCT (signed certificate timestamp) zostaje wygenerowany i zwrócony. Służy to jako dowód, że certyfikat został dostarczony i zostanie dodany do rejestru.
Wg specyfikacji podczas komunikacji serwery zgodne muszą dostarczać numery tych SCTów do klientów TLS. Może do tego dojść na kilka różnych sposobów:
signed_certificate_timestamp wysyłane podczas uzgadniania (handshake)status_request) i dostarczanie SignedCertificateTimestampList z jednym lub większą liczbą SCTsówPrzy rozszerzeniu certyfikatu X.509 o włączonych SCTsach decydują organy certyfikujące. Przy stosowaniu tego typu mechanizmu nie powinna istnieć potrzeba modyfikacji serwerów webowych.
W przypadku ostatnich metod serwery powinny być aktualizowane, aby móc wysyłać żądane dane. Korzyść stanowi fakt, że operator serwera może modyfikować źródła rejestru CT dostarczając SCTsy wysyłane przez rozszerzenie TLS/"zszytą" odpowiedź OCSP.
Google Chrome wymaga umieszczania rejestru CT dla wszystkich kwestii związanych z emisjami certyfkatów z datą notBefore po 30 kwietnia 2018 roku. Użytkownicy zostaną uchronieni przed odwiedzaniem stron używających niezgodnych certyfikatów TLS. Wcześniej Chrome wymagało umieszczania Rozszerzonej Walidacji (EV) oraz certyfikatów wydawanych przez Symantec.
Apple wymaga zróżnicowanej liczby SCTsów dla Safari i innych serwerów celem zaufania certyfikatom.
Firefox aktualnie ani nie sprawdza ani nie wymaga stosowania rejestru CT dla stron odwiedzanych przez użytkowników.
Nagłówek Expect-CT może zostać użyty do żądania, by przeglądarka zawsze wymuszała wymóg przejrzystości certyfikacji (np. w Chrome nawet, jeśli certyfikat został wydany z datą notBefore, przed kwietniem)
| Specyfikacja | Status | Komentarz |
|---|---|---|
| Certificate Transparency | IETF RFC |