Jak mogę się upewnić, że stunnel wysyła wszystkie pośrednie certyfikaty CA?

Kilka komputerów, ale nie większość, odrzuca certyfikat SSL z mojego serwera. Problem polega na tym, że niektóre komputery odrzucają certyfikaty CA. Problem pojawia się w systemie Mac OS X 10.6, gdy nie jest w pełni zaktualizowany.

Według http://www.sslshopper.com/index.php?q=ssl-checker.html#hostname=beta.asana.com - nie ma problemu.

Według http://certlogik.com/sslchecker/ , nie są wysyłane żadne pośrednie certyfikaty.

Mój certyfikat pochodzi od Starfield Technologies i używam sf_bundle.crtstąd: certs.godaddy.com/anonymous/repository.seam

Obsługuję SSL na moim serwerze za pomocą stunnel z następującymi funkcjami stunnel.conf:

cert = $CODEZ/admin/production/proxy/asana.pem
CAfile = $CODEZ/admin/production/proxy/sf_bundle.crt
pid =
client = no

[<forwarded port>]
accept = 443
connect = 8443

Jakieś pomysły, co mogę robić źle?

Ta CAFileopcja konfiguruje urząd certyfikacji do użycia dla certyfikatów uwierzytelniania klienta; nie tego chcesz.

Zamiast tego chcesz utworzyć plik w certopcji, aby zawierał cały odpowiedni łańcuch certyfikatów. Będziesz chciał zapisać kopię zapasową tego pliku, a następnie utwórz nową; w zasadzie łącząc dwa pliki, sformatowane w ten sposób:

-----BEGIN CERTIFICATE-----
(certificate from asana.pem file pasted here)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(intermediate certificate here; copy-paste the top chunk from the bundle)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(root certificate here; copy-paste the bottom chunk from the bundle)
-----END CERTIFICATE-----

Zmusi to stunnel do przedstawienia klientom pełnego łańcucha certyfikatów.

Jeszcze jeden smakołyk; openssl s_clientkomenda jest bardzo przydatna do badania kwestii łańcucha certyfikatów i sprawdzanie jak usługa prezentuje swoje certyfikaty.

Edycja: Ok .. łańcuch pakietu certyfikatów ma trzy głębokości, ale łańcuch zaufania wygląda na dwie głębokości. Cos jest nie tak.

Najwyższy certyfikat („Starfield Secure Certification Authority”) jest podpisany przez wystawcę o nazwie „Starfield Class 2 Certification Authority” odciskiem palca zaczynającym się od ad7e1c28… ale drugi certyfikat w pakiecie, nazwany dokładnie tak samo jak podpisujący pierwszy certyfikat, który powinien być dokładnie tym samym certyfikatem, odciskiem palca rozpoczynającym się od 363e4734, a data ważności 10 lat wcześniej. Zatem trzeci (root) cert jest sygnatariuszem dołączonego certyfikatu pośredniego .. ale żadne z tych dwóch nie ma żadnego związku z pierwszym!

Jeśli to nie miało sensu, nie martw się. Podsumowanie: niechlujna praca, ktoś poważnie upuścił piłkę, budując ten pakiet certyfikatów. Najlepszym rozwiązaniem jest więc wyeksportowanie plików w formacie base-64 z przeglądarki, która pomyślnie sprawdza poprawność łańcucha, wklejając je do formatu, który tam wymieniłem.

Ponieważ jest to mylący bałagan z własnej winy, odgadłem twoją nazwę DNS i złapałem certyfikat i myślę, że powinien to być pełny łańcuch, którego potrzebujesz: http://pastebin.com/Lnr3WHc8

Qualys SSLLabs jest naprawdę przydatny do sprawdzania konfiguracji po zmianach.

https://www.ssllabs.com/ssldb/analyze.html

Sprawdza, czy masz

• włączone silne szyfry
• słabe szyfry wyłączone
• łańcuch certyfikatów jest kompletny i we właściwej kolejności

Dla każdego, kto boryka się z tym problemem, post Shane'a załatwił sprawę, chociaż musiałem również dołączyć plik CAFile. Również podczas tworzenia łańcucha pamiętaj, aby postępować zgodnie z instrukcjami nazywania plików zgodnie z tym artykułem

Aby określić nazwę pliku, której powinieneś użyć, możesz użyć programu c_hash, który jest dostarczany z OpenSSL (w /usr/local/ssl/misckatalogu):

c_hash some_certificate.pem
a4644b49.0 => some_certificate.pem

W powyższym przypadku zmienisz nazwę pliku na a4644b49.0.
(Zauważ, że jest to zero, a nie litera „O” po kropce w nazwie pliku).

Jeśli nie masz c_hashprogramu, możesz uruchomić odpowiednią komendę OpenSSL w celu ustalenia wartości skrótu:

openssl x509 -hash -noout -in some_certificate.pem
a4644b49

A jeśli napotykasz ten problem, bo próbujesz korzystać z gniazd sieciowych z Androidem Cordova, pamiętaj, aby ręcznie dodać wss do listy Cordova-białej listy, ponieważ * zawiera tylko http i https.