30 maja 2020 roku zaobserwowaliśmy niezwykłą sytuację w infrastrukturze publicznego klucza internetu: dwa z głównych certyfikatów wygasły jednocześnie, co oznaczało, że każda z certyfikujących jednostek SSL wygasła.
Zasadniczo nie jest to nic niezwykłego. Certyfikaty wygasają stale (zwykle w ciągu roku lub nawet w 90 dni, jeśli używasz usługi Let’s Encrypt), a certyfikaty organów certyfikacji wygasają po kilku latach. Jednak 30 maja wygasająca certyfikacja ujawniła podstawowy problem, który spowodował, że nasza API nie była dostępna dla niektórych naszych klientów.
30 maja, gdy wygasły certyfikaty wydane przez organy certyfikacji, otrzymaliśmy zgłoszenia od użytkowników, że wystąpił problem z certyfikatem naszego serwisu. To była niespodziewana wiadomość, ponieważ starannie sprawdzamy, czy nasze certyfikaty są aktualne i nie wygasnąją w najbliższej przyszłości. Szybka kontrola w przeglądarce potwierdziła również, że wszystko wydawało się normalne i że API działało poprawnie.
Przeglądając statystyki naszej infrastruktury, zauważyliśmy, że liczba wywołań API spadła, ale wcale nie była ona zbliżona do zeru, jak mogłoby się spodziewać w przypadku całkowitego awarii SSL. Gdy rzeczy nie działają w pełni, często łatwiej jest zauważyć, czego nie ma, niż w sytuacjach, gdy niektóre rzeczy działają, a inne nie.
Pełna analiza w końcu wykazała, że podobne problemy wystąpiły również w innych serwisach internetowych. Wkrótce udało nam się ustalić przyczynę: https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
- Certyfikat naszej jednostki certyfikującej Sectigo RSA Organization Validation Secure Server CA był ważny.
- W ścieżce 1 certyfikat root USERTrust RSA Certification Authority był ważny, a cały łańcuch był ważny.
- W ramach etapu 2 certyfikat naszej głównej jednostki certyfikującej, USERTrust RSA Certification Authority, wygasł w dniu 30 maja o godzinie 10:48 UTC.
- Certyfikat Root Certificate Authority AddTrust External CA Root, który krzyżowo podpisywał certyfikat firmy USERTrust RSA, wygasł w dniu 30 maja o godzinie 10:48 UTC.
Było to ciekawe zagadnienie. Istniał prawidłowy sposób dostępu do certyfikowanej przez USERTrust RSA Authority, a także nieaktualny sposób dostępu. Przeglądarka była w stanie znaleźć prawidłową sekwencję, ale certyfikator nie był w stanie jej znaleźć. Test przeprowadzony przez Quality SSL Labs wykazał, że system działał poprawnie, a konfiguracja certyfikatu była prawidłowa.
Nasz zespół rozpoczął drugą zmianę naszego publicznego certyfikatu i próbował przywrócić usługę dla pozostałych klientów; zaraz po wdrożeniu potwierdził im, że mogą ponownie ją uzyskać. Incydent w końcu się zakończył i usługa została ponownie dostępna dla wszystkich klientów. Ale dlaczego niektórzy z naszych klientów w ogóle stracili dostęp, skoro nawet skaner SSL stwierdza, że certyfikat jest ważny?
Certyfikat był rzeczywiście ważny, a cały łańcuch certyfikacji został dość prawidłowo wygenerowany przez certyfikację Comodo/Sectigo (rozpoczynanie ważności certyfikatu w weekend nie jest dobrym rozwiązaniem). To, czego nie przewidywano, to sposób, w jaki biblioteki klienta będą radzić sobie z tą sytuacją – przede wszystkim OpenSSL, który obsługuje zdecydowaną większość HTTPS na świecie. Podczas analizy incydentu natknęliśmy się na interesujący błąd OpenSSL z 2014 roku, który brzmi następująco:
Nie używaj wygasłych certyfikatów, jeśli to możliwe.
Źródło: https://github.com/openssl/openssl/commit/0930251df814f3993bf2c598761e0c7c6d0d62a2
W przypadku wyszukiwania emitenta certyfikatu, jeśli aktualny kandydat wygasł, należy kontynuować wyszukiwanie. Wartość certyfikatu wygasłego zostanie zwrócona jedynie w przypadku braku ważnych certyfikatów.
Oznacza to, że przed wdrożeniem tej zmiany program OpenSSL, każdorazowo, gdy wykryje w łańcuchu nieprawidłowe certyfikaty, uznaje je za nieprawidłowe i odmawia połączenia. Po wdrożeniu tej zmiany program OpenSSL pomija wygasły certyfikat i szuka dalej dodatkowych certyfikatów, które mogą potwierdzić jego ważność. Ta niewielka zmiana dostosowuje się do struktury łańcucha certyfikatów – jedna certyfikacja może być podpisana przez kilka certyfikujących organów, z których niektóre są nadal ważne, a inne już nie. Wszystko wygląda świetnie, dlaczego więc ma to konsekwencje?
Jeśli się poszerzymy, to ta zmiana w OpenSSL to jedynie część wersji 1.1.1, a nie część wersji 1.0.x. Oznacza to, że dotyczy to wszystkich wersji systemu Ubuntu 16.04 i starszych, Debian 9 i starszych, CentOS 7 i starszych lub RedHat 7 i starszych, ale wszystkie te wersje są nadal ogólnie wspierane, przynajmniej z punktu widzenia bezpieczeństwa.
Ale dlaczego przeglądarki poprawnie weryfikowały certyfikaty? Przeglądarki są dostarczane z własnymi bibliotekami SSL/TLS oraz własnymi metodami weryfikacji PKI. Chrome jest dostarczane z BoringSSL, a Firefox z NSS, niezależnie od bibliotek SSL/TLS wbudowanego systemu operacyjnego; nie ma on tego samego problemu i jest aktualizowany znacznie częściej.
A teraz wreszcie mamy pełny obraz tego, co się wydarzyło i dlaczego dotyczyły one jedynie implementacji bazy danych niektórych klientów oraz dlaczego niektóre systemy miały przestarzałe pliki certyfikatów, które wymagały znacznie starszego podstawowego certyfikatu.
Co dalej? Kontaktujemy się z dotkniętymi klientami i wyjaśniamy, co się stało. Poprawiamy nasze narzędzie do sprawdzania certyfikatów, aby sprawdzić procedury w całej łańcuchu, a nie tylko nasze własne certyfikaty.
FAQ
Czy niedostępność usługi była spowodowana problemami na serwerach LOX24?
Nie, usługa nadal działała, ale nie była dostępna dla starszych systemów.
Czego powinienem zrobić, aby w przyszłości nie powtórzyć podobnej sytuacji z LOX24 lub innymi usługami?
Aktualizuj OpenSSL do co najmniej wersji 1.1.1 i LibreSSL do co najmniej 3.2.0. Aktualizuj również swoje pliki certyfikatów, w systemie Linux często pod nazwą „ca-certificates“.
Czy certyfikat od firmy LOX24 wygasł?
Nie, certyfikat firmy LOX24 nie wygasł i nadal jest ważny. To, co wygasło, to jedna z trzech wersji certyfikatów CA wydanych przez certyfikujące organy, które zatwierdziły nasz certyfikat.
Czy dotyczyło to jakiegoś innego dostawcy lub czy problem dotyczył wyłącznie platformy LOX24?
Niestety, istniało również wiele innych dostawców, których to dotyczyło: Heroku, Stripe, kernel.org, Datadog, Gandi.net i wiele innych.