Mianowicie na niektórych komputerach z jakichś powodów nie potrafi zweryfikować domeny.
Na zrzucie ekranu widać po lewej certyfikat widoczny we Firefoxie na wirtualnym Windows, Linux openSUSE, wszystko jest również ok pod Androidem, Windows Phone i starym iOS 7.
Nie mam już pomysłu gdzie może być problem, a raczej jak go zlokalizować.
Może Wy macie jakieś pomysły? Już miałem styczność z dziesiątkami SSLi i nigdy nie widziałem czegoś takiego…
Tam, gdzie jest problem z certyfikatami, sprawdź opcje firefoxa, zaawansowane, certyfikaty, wyświetl certyfikaty. Jeśli z jakiegoś powodu w zakładce serwery będą jakieś stare, nieaktualne certyfikaty, to w systemach jest problem, bo firefox “czyta” certyfikaty serwerów nie zaktualizowanych w systemie. W windowsie widoczne są w kluczach HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
W windowsie są poprawki rozwiązujące problemy z certyfikatami.
Znowuż w zakładce organy certyfikacji przeglądnij nieaktualne, skoro jest problem.
Na linuxie - nie wiem jak to rozwiązać. Ale to nie problem z firefoxami.
W about:config mam:
security.tls.version.min 3 - TSL 1.2
security.tls.version.max 4 TSL 1.3
services.sync.prefs.sync.security.tls.version.max;true
services.sync.prefs.sync.security.tls.version.min;true
jeszcze to ustawienie - zglaszanie aktualnego URL i pobieranie wstępne certyfikatu SSL:
browser.ssl_override_behavior;2
W ustawieniach Firefox nie ma w zaawansowanych żadnych nieprawidłowych certyfikatów z tej domeny.
W Linuxie w systemie widnieją jedynie certyfikaty Firefoxa (cert8.db w katalogu z profilem) oraz baza zaufanych dostawców certyfikatów (/etc/ssl/certs/ca-bundle.crt).
Zmieniłem w about:config 2 pierwsze wartości (były u mnie 1 i 3), 2 pozostałe już takie były.
Natomiast na Linuxie na hoście (nie wirtualce), gdzie w przeglądarkach jest wszystko ok, próbowałem pobrać stronę wgetem
$ wget -v "https://XXX"
--2017-02-20 09:08:28-- XXXX
Translacja XXXl (XXX)... XXX
Łączenie się z XXX (XXX)|XXXX|:443... połączono.
BŁĄD: błąd kontroli certyfikatu dla XXX, wystawionego przez `/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G2':
Błąd lokalnej kontroli centrum certyfikacji.
Aby połączyć się z XXX w sposób niebezpieczny, można użyć `--no-check-certificate'.
Na hoście urzędy certyfikujące są również w /etc/ssl/certs/, ale porozrzucane w plikach *.pem. W obu przypadkach widnieje 7 wpisów GeoTrust.
[quote]Your certificate chain is incomplete. You need to add a SSLCertificateChainFile line, and the file needs to include the “RapidSSL SHA256 CA - G3” intermediate certificate.
Firefox trusts the Geotrust global CA, but without sending it the intermediate cert as well, it doesn’t know who signed your certificate so doesn’t trust it.[/quote]
Prawdopodobnie nie masz ustawienia SSLCertificateChainFile w konfiguracji apache (w przypadku nginxa wskazuj jako certyfikat SSL cały chain - nie sam certyfikat). Firefox ufa Geotrust, ale jeśli nie przesyłasz chain’a, nie wie do końca kto podpisał twój certyfikat.
A jak pobrać właściwy SSLCertificateChainFile, jeśli sprzedawca SSLa wysyła tylko sam certyfikat?
DODANE:
W tej problematycznej domenie jest “RapidSSL certificate chain” i jest użyty w konfiguracji Apache.
Ale jeszcze pokombinuje, bo wg instrukcji opcja pobrania certyfikatu pośredniczącego jest, ale w panelu nie ma (może sprzedawca zmienił panel i o czymś zapomniał).
SSLCertificateChainFile jest prawidłowy, ale z zewnątrz za diabła ani przeglądarki Androida ani co najmniej 2 Firefoxy go nie widzą i stąd ten problem. OpenSSL twierdzi tak samo.
Tester również twierdzi, że nie ma Intermediatów.
Ale co ciekawe zwraca taką informację
You have 2 errors
Intermediate certificate missing.
RapidSSL SHA256 CA - G2 | Download certificate
Intermediate certificate missing.
RapidSSL SHA256 CA - G2 | Download certificate
Po kliknięciu Download certificate mam te same intermediaty. To nie jest dziwne?
Sam nie wiem co jest skopane. Inne certyfikaty od tego samego wystawcy i sprzedawcy na tym samym serwerze działają. Będę jeszcze kombinował z instalacją darmowego SSLa oraz przeniesienia certyfikatu ta inny serwer. Przecież to niemożliwe, że sprzedali lipny SSL… (aktualnie już 2 spośród dziesiątek SSLi).
Na takie tematy ja widze jedną odpowiedź może was to przerazi, zmrozi krew wzyłach, ale nie raz przekonałem się iż przegladarka Edge przez wielu tka wyśmiewana z takimi rzeczami radzi sobie duzo lepiej niż tez wszystkie darmowe razem wziete.
Właśnie problem w tym, że sobie nie radzi, bo wyświetla info, że wszystko jest ok. A z tego co widzę, to faktycznie z jakichś powodów intermediata nie znajduje.
Z tym SSLem to albo jest błąd w samym certyfikacie albo błąd w oprogramowaniu serwera (Apache).
Problem został rozwiązany.
A powód to ślepota i zmyłka ze strony przeglądarek (w końcu tylko jakaś część miała problem).
Trzeba dokładnie sprawdzać konfigurację Apache (wirtualne hosty) dla SSL. Była ona skopiowana z głównego konfiga ale z okresu, gdy w aliasie nie było domeny, dla której był certyfikat. Potem została zaktualizowana głownego konfiga (dodane aliasy), ale dla SSLa już nie. Sory za zamieszanie…
I tak nie wiem czemu tylko we Firefox dla Linux Rosa (Chrome i Opera były ok), Chrome 50+ na Androida 5 i 6 i na kilku komputerach był problem.
W firefoxie to będą ustawienia:
Nie wczytuj niezabezpieczonych zawartości security.mixed_content.block_active_content false
Nie wczutuj zawartości częściowo szyfrowanej security.mixed_content.block_display_content false
Jako niezabezpieczone, a nie jako niebezpieczne.
Ale to już poruszasz inny temat oprogramowania klienckiego, który rozpoczęła m.in. aktualizacja Chrome do wersji 56
