Gnu / Linux'un Windows tarafından kullanıma hazır bir sertifikaya güvenmesi nasıl sağlanır?


11

Bu SSL kontrolünde bildirildiği gibi, SSL zinciri bozuk bir sunucu var :

SSL kontrol raporu

Bu sunucunun kendisi üzerinde çözülmesi gereken bir sorun olduğunu biliyorum , ama bazen bu düzeltmek zor (sunucunun yöneticisi değilim).

Mesele şu ki, Windows'taki Chrome / Mozilla / Edge , site sertifikasına yine de güveniyor :

resim açıklamasını buraya girin

Ancak, Gnu / Linux dağıtımı (Docker içinde Ubuntu 18.04) sertifika edilir değil güvenilen:

curl: (60) SSL certificate problem: unable to get local issuer certificate

update-ca-certificatesGlobalsign Root sertifikasını denedim ve hatta aldım . update-ca-certificatesbu durumda yinelenen bir sertifika bildirdi. Her neyse, hiçbir şey işe yaramıyor.

Nasıl çoğaltılır

Docker'ı kullanma:

docker run -it ubuntu:18.04

# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it  # <---- "unable to get local issuer certificate"

Gnu / Linux'u bu sertifikaya nasıl güvenebilirim?

Not: Aynı sertifika başka bir sunucuya doğru bir şekilde dağıtıldı .


neden iniş vekili?
Udo G

1
Bu soruyu konu dışı olarak kapatmak için oy kullanıyorum çünkü OP kendini etkileyemeyeceği bir şey soruyor. Sunucu tarafında hiçbir şeyi değiştiremeyeceğini söyledi , bu yüzden muhtemelen istemci tarafı olmayan bir sorunu açıkladığı için bu muhtemelen süper kullanıcıya ait.
LinuxSecurityFreak

2
Özellikle istemci tarafı bir çözüm istiyorum. Sunucuyu etkileyemiyorum, ancak istemci O / S (Ubuntu) üzerinde tam denetime sahibim ve bu özel O / S kurulumunun, diğer O / S (Windows) gibi sertifikaya güvenmesini istiyorum. Bu, diğerleri için HTTPS sitesini düzeltmekle ilgili değildir.
Udo G


1
Sunucuyu denetlemezsiniz, ancak sorunu yine de sunucuyu denetleyen kişiye bildirebilirsiniz.
Michael Hampton

Yanıtlar:


11

Bunun gerçek çözümü, sunucunuzun sadece son varlık (sunucu) sertifikasını değil, zincirdeki tüm sertifikaları sunmasını sağlamaktır .

Sunucu yöneticinizi , bu iletinin sunucunun sertifika zincirini istemciye ilettiğini açıkça belirten RFC 5246 Bölüm 7.4.2'ye yönlendirin .


Yöneticiniz bunu herhangi bir nedenle reddederse / yapamazsa, alternatif seçeneğiniz curlhatalı biçimlendirilmiş el sıkışma ile çalışmaya çalışmaktır.

Curl posta listesindeki bir mesaja göre:

Birisi cURL ara sertifikayı destekleyip desteklemediğini onaylayabilir mi?

Evet öyle. Tüm ca sertifikalarının kök dizinine kadar bir sertifika zinciri vardır. Kıvrılma ile kullandığınız ca demeti, tüm zincir için certs'ten oluşmalıdır.

/ daniel.haxx.se

Kök CA'yı ve tüm ara sertifikaları bir pakete ekleyebilmeniz curlve --cacert <file>seçeneği kullanarak ona yönlendirebilmeniz gerekir .

Tarayıcınız çalışırken, doğru CA sertifikalarına oradan erişebilirsiniz. Sertifikalar sekmesinde (her tarayıcı için farklıdır, ancak eminim ki bunu anlayacaksınız), sertifika zincirini görüntüleyin. Kök CA ilk çift tıklayın G1 - Globalsign Kök CA ve üzerinde Ayrıntılar sekmesinde, tıklayın ... dosyaya kopyala . Farklı kaydedin root.cer. İle aynı yapın SHA256 - - G2 AlphaSSL CA ve olarak kaydedin issuing.cer. İkisini tek bir dosyada birleştirin (örneğin chain.cer) ve bunu argüman olarak kullanın -cacert.

@AB tarafından nazikçe belirtildiği gibi, eksik sertifika da burada bulunabilir .


Tarayıcılarınız CA sertifikalarını önbelleğe aldıkları için çalışır. Geçmişte, sertifikası sunucunuzun sertifikasıyla aynı CA tarafından verilen, doğru yapılandırılmış bir web sitesine gittiyseniz, tarayıcı tarafından önbelleğe alınır. Daha sonra yanlış yapılandırılmış sitenizi ziyaret ettiğinizde, tarayıcınız zinciri oluşturmak için önbelleğindeki CA sertifikalarını kullanır. Size göre, her şey yolunda gibi görünüyor, ancak sahne arkasında sunucu yanlış yapılandırılmış.

Windows, IE / Edge ve Chrome'un aynı önbelleği paylaşırken, Firefox kendi önbelleğini kullandığını unutmayın.

Yukarıdakilere ek olarak, IE / Edge ve Chrome (aynı kripto yığınını paylaştıklarından) AuthorityInformationAccess adı verilen sertifikalar içinde bir uzantı kullanacaktır . Bu, son varlık sertifikasının CA sertifikasının indirilebileceği bir URL sağlayan bir caIssuer seçeneğine sahiptir. Bu nedenle, bu tarayıcılardan biri önceki taramalardaki eksik sertifikaları önbelleğe almamış olsa bile, gerektiğinde alabilir. Firefox'un bunu yapmadığını unutmayın, bu nedenle bazen Firefox IE / Edge ve Chrome çalışıyor gibi göründüğünde sertifika hataları gösterebilir.


1
Bu benim sunucum değil, bu yüzden sunucu tarafındaki hiçbir şeyi değiştiremezsiniz. CA paketini curl.haxx.se/docs/caextract.html'den (Firefox sertifikaya güvendiğinden beri) kullanmayı denedim ve --cacert cacert.pemCURL yine de sertifikayı kabul etmiyor.
Udo G

1
Bu ise sunucu. Çalıştırdığınızda echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443, sunucunuz tarafından yalnızca bir sertifika sunulur. İki olmalıdır - son varlık sertifikası (sunulan) ve veren CA - Alfa SSL - SHA256 - G2 sertifikası. İkincisi sunucu tarafından gönderilmez, ancak gönderilmelidir.
garethTheRed

2
@garethTheRed: Sunucunun tüm sertifikaları sunmadığını anlıyorum, ancak sunucu kontrolüm altında değil ("sunucum değil" ile kastediyorum). Sadece yabancı bir sunucuda bir API'ye erişmeye çalışıyorum. Windows altında, tarayıcılarımdan hiçbiri sertifikadan şikayet etmiyor, sadece Linux / Debian / Ubuntu değil.
Udo G

@AB: çok teşekkürler! Bu sayfadaki tüm kök sertifikaları yüklemek sorunu çözdü . Ancak, bu manuel adımın neden gerekli olduğunu anlamak istiyorum.
Udo G

2
Eksik ara sertifika (@garethTheRed tarafından belirtildiği gibi) orada bulunabilir: support.globalsign.com/customer/portal/articles/… . OP başlangıçta sadece muhtemelen zaten mevcut olan kök sertifikasını eklemeye çalıştı , böylece hiçbir şey elde etmedi.
AB
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.