Dzisiaj o tym jak błąd w aplikacji wykorzystywanej przez Urząd Certyfikacji spowodował w najlepszym wypadku kilkugodzinną niedostępność wielu stron z zainstalowanym certyfikatem SSL.

Unieważnione certyfikaty pośrednie?

GlobalSign to jeden z największych urzędów certyfikacji z którego usług korzystają miliony użytkowników na całym świecie.

Rano 13 października strony WWW z zainstalowanym certyfikatem SSL GlobalSign’a zaczęły masowo zgłaszać błędy. Szczegóły zwracane przez przeglądarki wskazywały, że problem dotyczy certyfikatów pośrednich (wystawców certyfikatów końcowych). Przekaz był jasny: ERR_CERT_REVOKED. Certyfikaty pośrednie należące do GlobalSign’a zostały unieważnione (!!).

Certyfikat pośredni

Czy GlobalSign padł ofiarą włamania? Czy może jakaś grupa pracowników dokonała sabotażu? Nikt przy zdrowych zmysłach nie sądził przecież, że GlobalSign celowo unieważnił swoje certyfikaty pośrednie i tym samym wywołał awarię znacznej części internetu.

Spokojnie, to tylko unieważnienie certyfikatu krzyżowego

Żeby poznać przyczynę problemów musimy cofnąć się do 7 października. Wtedy to, GlobalSign unieważnił certyfikat krzyżowy (ang. cross-certificate) wystawiony przez certyfikat główny Root CA 2 R2. Przyczyną unieważnienia było zaprzestanie działalności (cessationOfOperation zgodnie z RFC 5280). W tym przypadku chodziło o zaprzestanie działalności tego konkretnego certyfikatu, nie był on po prostu już wykorzystywany.

Certyfikat krzyżowy wystawiany jest w celu ustanawiania wzajemnego zaufania pomiędzy certyfikatami głównymi urzędów certyfikacji (tzw. root CA). GlobalSign wykorzystał certyfikat krzyżowy do ustanowienia zaufania pomiędzy dwoma swoimi certyfikatami, Root CA 2 R2 a Root CA R1. Istotną informacją odnośnie certyfikatów krzyżowych jest to, że ich klucz publiczny i nazwa jest taka sama jak certyfikatu krzyżowo certyfikowanego (tutaj Root CA R1). Idealnie obrazuje to schemat przygotowany przez GlobaSign’a.

GlobalSign Cross Certificate

GlobalSign wygenerował więc listę CRL zawierającą numer seryjny wspomnianego certyfikatu krzyżowego (dla ciekawskich 040000000001444ef0464e) i opublikował za pomocą swojego CDNa (Content Distribution Network). W tym momencie nie wydarzyło się nic niepokojącego i nic nie zapowiadało nadchodzącej katastrofy.

Bomba z opóźnionym zapłonem

Nieszczęście zaczęło się prawie tydzień później. Wtedy to GlobalSign zaktualizował bazę danych usługi OCSP o unieważniony certyfikat krzyżowy.

Jak już mogliście dowiedzieć się z wcześniejszych wpisów OCSP to protokół pozwalający na sprawdzenie statusu certyfikatu w trybie online na zasadzie żądanie-odpowiedź. Jego zadanie jest identyczne jak list CRL, ma poinformować użytkownika o tym czy dany certyfikat jest ważny czy unieważniony. Protokół OCSP wykorzystywany jest między innymi do weryfikacji certyfikatów SSL.

Po zaktualizowaniu odpowiedzi OCSP nagle wszystkie certyfikaty pośrednie wystawione przez Root CA R1 zaczęły być traktowane jako unieważnione. Zgodnie z hierarchiczną strukturą rządzącą PKI, gdy certyfikat pośredni jest unieważniony to co znajduje się poniżej niego nie może być traktowane jako ważne. Dlatego też problem stał się odczuwalny między innymi dla milionów użytkowników Wikipedii.

Błąd certyfikatu na www.wikipedia.org (źródło: regmedia.co.uk)

W tym momencie można zadać sobie pytanie: jak to? Przecież unieważniony został tylko jeden certyfikat krzyżowy. Nawet sam GlobalSign w początkowej fazie analizy problemu zrzucił winę na niepoprawną interpretację unieważnienia przez przeglądarki. Prawda okazała się jednak inna.

Błąd w responderze OCSP

Weryfikacja odpowiedzi OCSP zwracana dla certyfikatów pośrednich pozwoliła na określenie przyczyny problemu. To OCSP GlobalSign’a zwracało status revoked dla wszystkich certyfikatów pośrednich wydanych spod Root CA R1. Przeglądarki nie mogły więc zachować się inaczej niż przekazać tę informację użytkownikom końcowym.

Co więc doprowadziło do awarii? Pamiętacie jeszcze opisaną wyżej właściwość certyfikacji krzyżowej? Ten sam podmiot i klucz publiczny certyfikatu krzyżowego i Root CA R1? Właśnie.

Błąd w logice aplikacji OCSP spowodował, że po otrzymaniu informacji o unieważnieniu certyfikatu krzyżowego uznała ona, że wszystkie certyfikaty pośrednie wydane spod krzyżowo certyfikowanego Root CA R1 należy traktować jako unieważnione. Dla aplikacji wyznacznikiem unikalności danego certyfikatu była nazwa podmiotu i klucz publiczny certyfikatu, a jak już wiemy w tym przypadku były one identyczne w obu certyfikatach.

Gdy tylko GlobalSign’owi udało się trafnie określić źródło problemu wycofał informację o unieważnieniu certyfikatu krzyżowego z bazy danych OCSP. Niestety dla GlobalSign’a, błędne odpowiedzi OCSP zostały zcache’owane po stronie dostawcy CDN i co gorsza lokalnie na komputerach użytkowników. O ile cache po stronie CDN udało się dosyć szybko wyczyścić to już użytkownicy końcowi mogli borykać się ze skutkami awarii nawet przez kilka dni (chyba, że udało im się wyczyścić cache zgodnie z zaleceniami GlobalSign’a).

Mały błąd, duża awaria

Jak widać czasami prosty błąd i brak przewidzenia zachowania aplikacji sytuacji nietypowej, a za taką uznać należy unieważnienie certyfikatu krzyżowego przez GlobalSigna, może mieć kolosalny wpływ na wielu użytkowników. Nikt nie mówił jednak, że właściwe zarządzanie PKI jest łatwe :-)

Mimo wszystko, GlobalSign’owi należą się słowa pochwały za profesjonalną reakcję. Dość szybkie określenie właściwej przyczyny błędu, sprawna współpraca z dostawcą CDN, bieżące informowanie o problemie za pośrednictwem m.in. Twittera, przygotowanie instrukcji postępowania dla użytkowników i zapisanie przebiegu sytuacji w zgrabnym raporcie to rzeczy warte uznania.