Przed nami kolejna duża zmiana w świecie certyfikatów SSL. Od jutra tj. od 1 maja 2018 wszystkie certyfikaty SSL będą musiały być wydawane w zgodzie z ideą Certificate Transparency (CT).

Wpis ten jest niejako aktualizacją tego wpisu. Na tamten moment zakładano, że CT będzie wymagane dla wszystkich certyfikatów od października 2017 roku. Później przesunięto tę datę i o tym w tym wpisie.

O Certificate Transparency

Certyfikaty SSL wydawane są przez wiele urzędów certyfikacji na całym świecie. Mimo, że stosują on szereg zabezpieczeń i procedur które sprawić mają, że proces wydawania certyfikatów przebiegał będzie bezbłędnie, to zdarza się, że coś pójdzie nie tak. Konsekwencją jest wtedy najczęściej błędnie wydany certyfikat który może być wykorzystywany do wykradania prywatnych danych nas wszystkich.

Między innymi przed takimi zagrożeniami ustrzec ma nas CT. Nie zapobiegnie on co prawda błędnemu wydaniu certyfikatu, ale może sprawić, że taki certyfikat zostanie bardzo szybko namierzony i możliwe będzie podjęcie działań (np. unieważnienie), które zablokują jego wykorzystanie w złym celu.

Założenia CT

CT zaczęło być szeroko stosowane z początkiem 2015 roku kiedy to Google zaczęło wymagać, aby każdy certyfikat SSL typu extended validation (EV) przed wydaniem przez zaufany urząd certyfikacji trafił najpierw do kilku tzw. serwerów logów CT i tym samym dotarł do szerszego grona odbiorców – innymi słowy stał się transparenty, lub może bardziej po polsku: przejrzysty. Brak spełnienia tego wymogu przez urzędy certyfikacji skutkował brakiem zielonego paska w Chrome.

Jak wspomniałem, idea CT polega na tym, żeby każdy wydany przez zaufany urząd certyfikacji certyfikat SSL był publicznie dostępny już w momencie jego wydania. Realizowane jest do poprzez przechowywanie certyfikatów na specjalnych serwerach, których główną właściwością jest to, że można do nich jedynie dodawać certyfikaty, a nie można ich modyfikować czy usuwać.

Każdy zainteresowany może tak tworzoną bazę certyfikatów przeszukiwać i weryfikować poprawność wydawanych certyfikatów SSL. Istnieje już co najmniej kilka implementacji dzięki którym możemy w łatwy sposób znaleźć certyfikaty wystawione dla danej domeny. Jedna z najlepszych to crt.sh.

Nowa polityka Certificate Transparency w Chrome

CT od samego początku jest pomysłem Google. Wszystko co do tej pory związane jest z CT dzieje się za sprawą Google. Nie inaczej jest tym razem.

Nowa polityka Google zakłada, że wszystkie certyfikaty tj. oprócz EV, także domain validation (DV) i organization validation (OV) wydane po 30 kwietnia 2018 roku muszą być logowane na serwerach logów CT. W przeciwnym wypadku Chrome zamiast załadować stronę wyświetli odpowiedni komunikat błędu uznając certyfikat SSL za niezaufany. Biorąc pod uwagę popularność przeglądarki Chrome wydaje się mało prawdopodobne, żeby któryś z urzędów certyfikacji nie spełniał tego wymagania już od 1 maja.

Co zrobić, żeby być zgodnym?

Jeżeli masz certyfikat SSL wydany do końca kwietnia 2018 to nic. Zmiana dotyczy jedynie certyfikatów wydawanych od 1 maja 2018.

Jeżeli będziesz generował nowy certyfikat SSL po 30 kwietnia 2018 to upewnij się, że zawiera on wymaganą liczbę tzw. signed certificate timestamp (SCT), czyli potwierdzeń, że dany certyfikat trafił do odpowiedniej ilości serwerów logów CT.

Tutaj mała uwaga. SCTs mogą zostać przekazane przeglądarce na trzy sposoby:

• poprzez rozszerzenie w certyfikacie;
• poprzez rozszerzenie protokołu TLS;
• poprzez OCSP stapling.

Zdecydowanie najpopularniejszy obecnie jest pierwszy ze sposobów, więc w dalszej części wpisu nie będę opisywał pozostałych dwóch.

Gdzie sprawdzić SCTs i jaka jest ich wymagana ilość?

Informacje o SCTs można znaleźć jednym z rozszerzeń certyfikatu SSL.

Od niedawna w przystępnej formie wyświetla je m.in. Windows. Po otworzeniu certyfikatu należy przejść do jego szczegółów i znaleźć rozszerzenie Lista SCT w którym znajdziemy listę SCTs dodanych do certyfikatu. Poszczególne SCTs są od siebie oddzielone i można policzyć ich liczbę.

Lista SCT

Alternatywnie można podejrzeć certyfikat za pomocą polecenia OpenSSL:

openssl x509 -noout -text -in certyfikat.pem

i szukać rozszerzenia CT Precertificate SCTs. Tutaj także widoczny jest podział poszczególnych SCTs i można je łatwo zliczyć.

CT Precertificate SCTs

Certyfikat SSL wydany na krócej niż 15 miesięcy powinien mieć przynajmniej 2 SCTs, a certyfikat SSL wydany na 15 lub więcej miesięcy (nie dłużej jednak niż na 27 miesięcy) powinien zawierać przynajmniej 3 SCTs.

Sama liczba SCTs to jednak nie wszystko. Warunkiem dodatkowym do poprawnego działania certyfikatu w Chrome jest to, aby przynajmniej 1 SCT pochodził z serwera CT zarządzanego przez Google i żeby przynajmniej 1 SCT pochodził z serwera CT niezarządzanego przez Google. Na przykład certyfikat wydany na 1 rok nie będzie akceptowany przez Chrome jeżeli oba SCTs pochodziły będą z serwerów niezarządzanych przez Google.

W przypadku braku spełniania powyższych wymagań Chrome zwróci bład:

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Co ważne, sprawdzanie SCTs dla wszystkich certyfikatów wydanych po 30 kwietnia 2018 wejdzie w życie wraz z  68 wersją Chrome. Wydanie tej wersji zaplanowane jest na koniec lipca 2018.

Szczegóły na temat polityki CT w Chrome oraz listę serwerów CT (wraz z ich właścicielami) można znaleźć tutaj.