Windows 2012 R2 neden kendinden imzalı sertifikama güvenmiyor?


9

Bir test ortamında, şu anda yakında dağıtılması gereken bazı şeyleri test etmekten beklemekteyim (aslında zaten, ancak son tarihlerin nasıl gittiğini biliyorsunuz ...) çünkü Windows, izole test ortamı. Güvenlik / bölümlendirme nedenlerinden ötürü "gerçek" sertifika ve bazı DNS hileleriyle ilgili sorunu bir kenara atabilirim.

Zimbra adlı Linux tabanlı bir e-posta sunucusuna bağlanmaya çalışıyorum; otomatik olarak oluşturulan, kendinden imzalı bir OpenSSL sertifikası kullanıyor. Google'ın açtığı sayfalar özellikle IIS kendinden imzalı sertifikalara sahip IIS web sitelerine atıfta bulunurken, bunu oluşturma yönteminin gerçekten önemli olduğunu düşünmüyorum.

Burada ve burada bulduğum talimatlara göre , bu sertifikayı yerel bilgisayarın Güvenilen Kök Sertifika Yetkilisi deposuna yüklemek basit bir mesele olmalıdır. Bunu da yaptığım gibi, sertifikayı manuel olarak kopyalayıp doğrudan MMC ek bileşeni aracılığıyla içe aktarıyorum. Çıkışlar ve yeniden başlatmalar hiçbir şeyi değiştirmez.

İşte her zaman aldığım sertifika hatası: resim açıklamasını buraya girin

Ve işte Sertifikasyon Yolu (spoiler: sadece sertifikanın kendisi): resim açıklamasını buraya girin

Son olarak, yerel bilgisayarın sertifika deposunda güvenli bir şekilde saklanan sertifika, tam olarak bulduğum talimatların olması gerektiği gibi: resim açıklamasını buraya girin

Linux tabanlı bir sunucuya bağlanırken Server 2012 R2'yi kullanırken bu yönergeler özellikle Vista'ya (ikincisi işletim sisteminden bahsetmez) ve IIS'ye başvurur; içe aktarma sihirbazında bazı farklılıklar var (benimki her ikisini de denememe rağmen mevcut kullanıcı veya yerel sistem için içe aktarma seçeneği var), bu yüzden belki burada yapmam gereken farklı bir şey var mı? Daha önce güvenmesini söylediğim sertifikaya gerçekten güvenmesini sağlamak için değiştirilmesi gereken bir yerde bir ayar var mı?

Windows Server 2012 R2'nin kendinden imzalı bir sertifikaya güvenmesini sağlamanın doğru yolu nedir?


Sorununuz yeniden oluşturulamıyor. IIS'nin "Kendinden İmzalı Sertifika Oluştur" seçeneğini kullanır ve Kişisel depoya yüklemeyi seçerseniz (Web Hosting mağazasını da denedim), hiçbir sorun yoktur. Sertifikayı nasıl oluşturdunuz? IIS veya Sertifika Yetkilisi MMC ek bileşeninden mi?

Hedef mağazayı açıkça seçmeyi denediniz mi (mmc konsolu içinden içe aktarma)?
JoaoCC

@SujaySarma Bu bir IIS web sitesi için değil, Zimbra adlı bir Linux uygulaması içindir. Kendinden imzalı bir OpenSSL sertifikasıdır.
Kromey

@ user1703840 Evet, hedef mağazayı açıkça belirledim ve Windows'un hem MMC hem de IE'deki sertifika alma sihirbazı aracılığıyla otomatik olarak seçmesine izin verdim. Her iki durumda da aynı sonuçlar.
Kromey

Ha? Linux nereden geldi? Sorunuzun tamamı ve gönderdiğiniz bağlantılar (ekran görüntüleriniz dahil) Windows Server 2012 R2 ve IIS ile ilgilidir. Lütfen açıkla.

Yanıtlar:


1

Aldığınız hata, güvenilir bir kök sertifika değil, güvenilir bir sertifika zincirini doğrulayamıyor olmasıdır . Zincirin herhangi bir parçası kırık, güvenilmeyen veya eksikse, böyle bir hata alırsınız. Güvenilmeyen, kendinden imzalı bir kök ile aldığım hatabu: Bu CA kök sertifikasına güvenilmiyor. Güven özelliğini etkinleştirmek için, bu sertifikayı Güvenilen Kök Sertifika Yetkilileri deposuna yükleyin. Ancak sizin için güvenilir bir kök sertifikayı doğrulayamayacağını söylüyor. Bu, otomatik imzalama işlemi sırasında, openssl'ye sertifikayı farklı bir kökle (otomatik imzalama ile değil) imzalamasını söylemiş olabilir veya kök CA olarak ayarlanmamış olabilir. İlkse, onunla imzalandığı köke güvenmelisiniz. İkincisi ise, openssl.conf dosyasında birkaç özellik ayarlama meselesidir.


Ekran görüntüleri, sertifikanın Güvenilen Kök CA'ya yüklendiğini ve ayrıca tüm zincirin sertifikanın kendisi olduğunu gösterir - köktür ve bu nedenle Güvenilen Kök CA'da olmak yeterli olmalıdır. Soru, neden olmasın?
Kromey

Kök olmayabilir, güvenilir kök deposuna eklenmediğini söylüyorum. Hata bu konuda garip olan şeydir - bir CA olması gerekiyorsa , güvenilir bir CA'ya kadar doğrulayamayacağını söylememelidir - bu yüzden aslında bir kök olmadığını, ancak ile imzalandığını öneriyorum başka bir sertifika.
Flashbang

sertifikayı almaya çalıştığınız kutuda bu komutu çalıştırmayı openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -sha256 -nodesve bu sertifikayı güvenilir kök CA deposuna aktarmayı deneyin . (elbette Zimbra tarafından kullanılan sertifika ve anahtar olacak şekilde yapılandırmanın yanı sıra).
Flashbang

Ne demek istediğini anlıyorum. Üzgünüm, yanlış anladım. Ancak kök değilse, Sertifika Yolu penceresinde görünmemelidir? Her halükarda, ne yazık ki, bunu daha fazla test edemiyorum - yasal sertifikamı ele geçirmeyi başardım ve hostsdosyada hack'le birlikte bu şekilde çalıştım .
Kromey

Sertifikanız, ekran görüntüsünü temel alan bir kök CA'dan geliyor. İdp.godaddy.com için sertifika ayrıntılarına bakarsanız , tüm yol sunulur ve bunu karşılaştırma olarak kullanabilirsiniz. MMC'deki sertifikanın özelliklerine bakarsanız, sertifika amaçlı sunucu kimlik doğrulaması içeriyor mu? (İkinci ekran görüntüsünde sertifikayı sağ tıklayın ve özellikleri seçin).
John Auld

1

Ne çalışabilirim diye veren bir otorite olduğu için WS2k12 sertifikayı, hakkında hiçbir şey bilmediği bir ana bilgisayara doğrulamaya çalıştığı için zmaster'ı Güvenilir bir kaynak CA olarak eklemeniz gerekir. Üretim yönteminin önemli olmadığı, ancak doğrulanabilir bir kaynak olduğu konusunda haklısınız. Bunun yaşadığınız etki var: WS2k12, yalnızca $ Random_issuing_authority adına sahip olduğu için bir sertifikaya güvenmiyor, sertifikayı doğrulayabilmesi gerekiyor.


Kendinden imzalı bir sertifikadır - sertifikayı Güvenilen Kök CA deposuna yerleştirerek, tanımlayıcıya güveniyor olursunuz.
Chris McKeown

Bir şeyi kaçırmadıkça, tam olarak bunu yaptım - Trusted Root CA mağazasında zmaster'ın sertifikasını gösteren üçüncü ekran görüntüsüne bakın.
Kromey

0

Ben de aynı sorun vardı, benim çözüm dovecot tarafından kullanılan posta sunucusu için .crt ve .key dosyalarını güncelleştirmek oldu. Postadaki Exim4'te güncellenmiş bir sertifika / anahtar kümesi vardı, ancak dovecot hala eski sertifika / anahtar kümesine işaret ediyordu.

Eski sertifika / anahtar çifti çoğu durumla iyi çalıştı, ancak outlook.com veya MS Outlook 2013 ile iyi çalışmadı.

Outlook.com ile ilgili sorunlar son zamanlarda exim4 sertifikasını yükseltmeme neden oldu - şimdi dovecot [ve web posta sunucusu] da yeni sertifika (ve anahtar) dosyalarını kullanıyor. Posta sunucusunun kendisi de son zamanlarda [eski Debian squeeze-lts'ten wheezy'ye yükseltildi], eski kurulum eski sertifika / anahtar kümesi ile her şey yolundaydı, ancak yükseltmeden sonra yeni sertifika / anahtar kümesi oluşturmam gerekiyordu. MS ürünleri posta sunucusuyla düzgün çalışır.


0

Bence sorun, kaynaklara nasıl eriştiğinizdir. Yerel ağınız için tam alan adı yerine ana bilgisayar adını kullanabilirsiniz. Ancak sertifikanız tam alan adına göre düzenlenir.


Bu sorunun zaten kabul edilmiş bir cevabı var.
BE77Y

-1

Güvenilen Kök Sertifika Yetkililerine ve Güvenilir Yayıncılara sertifika yükleyin.

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.