English
Deutsch
PolskiŁańcuchy certyfikatów: dlaczego strona otwiera się w przeglądarce, a zawodzi w curl
Management Summary
Certyfikaty witryn są cyfrowymi dowodami tożsamości. Pozwalają aplikacji sprawdzić, czy chronione połączenie prowadzi do właściwej strony. Zaufanie może opierać się na łańcuchu wystawców, uznawanych różnie przez poszczególne programy. Wyjaśnia to, dlaczego strona działa w przeglądarce, ale zawodzi w automatycznym narzędziu takim jak curl. Artykuł opisuje te różnice i powód, dla którego wyłączenie kontroli tożsamości ukrywa błąd zamiast przywracać wiarygodne połączenie.
Spis treści
Strona otwierająca się w przeglądarce przy błędzie curl daje użyteczną wskazówkę, lecz nie gotową diagnozę. Brak certyfikatu pośredniego to jedna z możliwych przyczyn. Podobny wynik mogą powodować różne magazyny zaufania, biblioteki TLS, trasy sieciowe, ustawienia proxy lub reguły walidacji.
Przesłana lista a zaufana ścieżka
Certyfikat końcowy identyfikuje witrynę. Magazyn zaufania zawiera certyfikaty, które klient już uznaje za zaufane. Serwer przedstawia certyfikat końcowy i zwykle certyfikaty pośrednie prowadzące do zaufanego wystawcy. Klient buduje i sprawdza ścieżkę na podstawie tego materiału oraz własnej konfiguracji zaufania. Lista przesłana przez serwer nie musi więc być identyczna ze zweryfikowaną ścieżką.
Certyfikat korzenia może zostać przesłany, ale samo przesłanie nie tworzy zaufania. TLS 1.3 dopuszcza pominięcie certyfikatu będącego kotwicą zaufania. Jeden przesłany certyfikat również nie dowodzi zawsze braku pośredniego: możliwe jest bezpośrednie wystawienie przez zaufany korzeń. Kilka certyfikatów nie stanowi dowodu poprawnej ścieżki.
Dlaczego klienci mogą się różnić
Niektóre systemy walidacji pobierają brakujących wystawców przez adres Authority Information Access (AIA) albo korzystają z lokalnie dostępnych certyfikatów pośrednich. Znaczenie mają dostępność, sieć i polityki. Windows dokumentuje konfigurowalne pobieranie; curl zależnie od kompilacji może używać Windows Schannel, usług zaufania Apple lub magazynów plikowych. Reguła „przeglądarki pobierają, curl nigdy” jest zbyt szeroka.
Przy porównaniu potrzebne są dokładny host, rozwiązany adres, wersja klienta, biblioteka TLS i konfiguracja CA. Proxy może przedstawiać inny certyfikat. Sukces przeglądarki nie dowodzi akceptacji przez magazyn lub polityki innej aplikacji.
Pliki i odnowienie
Certbot używa cert.pem dla certyfikatu końcowego, chain.pem dla pośrednich i fullchain.pem dla ich połączenia. Dokumentacja serwera określa, do którego ustawienia należy dany plik. To konwencje Certbota, a nie uniwersalne nazwy wszystkich urzędów certyfikacji.
Poprawnie odnowione pliki wymagają poprawnego wdrożenia. Kopie plików lub brak przeładowania usługi mogą pozostawić starą ścieżkę w użyciu. Po odnowieniu liczy się faktycznie dostępny endpoint. Brakuje dowodu, że konkretna pomyłka plików jest najczęstszą usterką TLS.
Oglądanie i weryfikacja to różne kroki
openssl s_client -connect example.com:443 -servername example.com \
-showcerts -verify_hostname example.com -verify_return_error < /dev/null
curl -vI https://example.com/-showcerts pokazuje certyfikaty przesłane przez serwer. -servername przekazuje żądaną nazwę hosta przez SNI, natomiast -verify_hostname osobno sprawdza nazwę. -verify_return_error przerywa po błędzie weryfikacji zamiast jedynie wypisywać diagnostykę. Brak konfiguracji CA sam może powodować błąd. Przykłady dla powłoki POSIX korzystają z zainstalowanej konfiguracji zaufania; nie są pełnym audytem polityk przeglądarki ani unieważnień.
curl domyślnie weryfikuje certyfikat i tutaj żąda nagłówków HTTP. Późniejszy błąd HTTP jest czymś innym niż błąd TLS. Opcja -k wyłącza ważną kontrolę i nie naprawia łańcucha.
Co zostało sprawdzone
Dziesięć izolowanych kontroli wykorzystało tymczasowe prywatne certyfikaty i serwer lokalny. Poprawna ścieżka oraz pasująca nazwa przeszły test. Brak pośredniego lub błędna nazwa powodowały niepowodzenie weryfikacji. Bez ścisłej opcji OpenSSL przypadek brakującego pośredniego mimo to kończył się kodem zero; z opcją kod wynosił jeden. Nie zmieniono systemowego magazynu zaufania ani nie kontaktowano się z zewnętrznymi stronami.
Testy potwierdziły też przykład symbolu wieloznacznego: *.example.test pasował do www.example.test, ale nie do samej domeny ani a.b.example.test. Współczesne reguły tożsamości usługi używają Subject Alternative Names zamiast zastępczego Common Name. Przekierowanie HTTPS nie naprawi błędnej nazwy początkowego hosta: TLS poprzedza odpowiedź HTTP.
Historyczna próbka dwunastu stron
Archiwalne zestawienie z 2 września 2026 obejmuje dwanaście hostów: sześć długości łańcucha równych trzy i sześć równych cztery. Dla tej próbki zapisano 90 dni ważności oraz od 31 do 88 dni pozostałych. Mediana wynosi 70, a średnia arytmetyczna około 61,9 dnia. To historyczny zapis, nie nowy pomiar ani jednolity okres dla całej branży.
Zestawienie nie zawiera oryginalnych łańcuchów PEM ani pełnych logów uzgadniania. Liczby nie potwierdzają więc niezależnie zawartości przesłanej przez każdy serwer. Rozrzut pozostałych dni nie dowodzi harmonogramu odnowień. Dzisiejsza obsługa TLS i podział wystawców wymagają nowego udokumentowanego pomiaru.
Interpretacja wyniku narzędzia
Inspektor TLS tej witryny sprawdza pierwszy wybrany adres z włączoną weryfikacją. Dopiero po niepowodzeniu podejmuje nieweryfikowaną próbę diagnostyczną. Udane połączenie pozwala wykonać osobne próby wersji protokołu. Wynik dotyczy tego adresu i klienta po stronie serwera, nie wszystkich endpointów CDN lub przeglądarek.
Etykiety diagnostyczne pomagają w analizie, ale nie dowodzą jednej przyczyny. Ogólny błąd weryfikacji może mieć różne źródła. „OCSP” w metadanych certyfikatu oznacza wskazany serwis odpowiedzi, nie pomyślną kontrolę unieważnienia. Nieudana próba starej wersji TLS może też wynikać z lokalnych ograniczeń albo błędu sieci.
Gdy endpoint nagle przestaje działać
Porównanie obejmuje rzeczywiście przesłany łańcuch, nazwę, daty ważności, zegar klienta i konfigurację zaufania. Istotne są również wdrożenie odnowionych plików, alternatywne endpointy i zmiany proxy. Aktualizacja magazynu CA może pomóc przy brakującym zaufanym korzeniu. Liczenie certyfikatów nie dowodzi jednak, że jest to jedyne rozwiązanie.
Źródła
Powiązane artykuły
