İstek iptal edildi: SSL / TLS güvenli kanalı oluşturulamadı


432

WebRequestBu hata mesajı nedeniyle bir HTTPS sunucusuna bağlanamıyoruz :

The request was aborted: Could not create SSL/TLS secure channel.

Sunucunun kullanılan yolla geçerli bir HTTPS sertifikası olmadığını biliyoruz, ancak bu sorunu atlamak için başka bir StackOverflow yayınından aldığımız aşağıdaki kodu kullanıyoruz:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

Sorun, sunucunun sertifikayı asla doğrulamaması ve yukarıdaki hatayla başarısız olmasıdır. Ne yapmam gerektiğine dair bir fikri olan var mı?


Bir meslektaşım ve ben birkaç hafta önce testler yaptık ve yukarıda yazdıklarıma benzer bir şeyle iyi çalıştığını belirtmeliyim. Bulduğumuz tek "büyük fark" Windows 7 kullanıyorum ve Windows XP kullanıyor. Bu bir şeyi değiştirir mi?



51
2018 ve bu soru 308.056 kez görüntülendi, ancak yine de bunun için uygun bir düzeltme yok !! Bu sorunu rastgele alıyorum ve burada veya başka bir iş parçacığında bahsedilen düzeltmelerin hiçbiri sorunumu çözmedi.
Nigel Fds

3
@NigelFds Hata The request was aborted: Could not create SSL/TLS secure channelçok genel bir hata . Temel olarak "SSL / TLS / HTTPS bağlantı başlatması pek çok olası nedenden biri nedeniyle başarısız oldu" diyor. Belirli bir durumda düzenli olarak alırsanız, en iyi seçeneğiniz bu durum hakkında spesifik ayrıntılar veren belirli bir soru sormaktır. Ve daha fazla bilgi için Olay Görüntüleyicisi'ne bakın. Ve / veya daha fazla ayrıntı almak için bazı .NET istemci tarafı hata ayıklamayı etkinleştirin (sunucu sertifikasına güvenilmiyor mu? Bir şifre uyuşmazlığı var mı? SSL / TLS protokol sürümü uyuşmazlığı? Vb.).
MarnixKlooster ReinstateMonica

4
@MarnixKlooster Bunların hepsini zaten kontrol ettim, Tekrar deniyormuşum gibi sertifika ile ilgili bir sorun olamaz, işe yarıyor. Ve bu soruyu, biri gelip yinelenen bir şey olarak işaretlemeden SO'ya sorabileceğimden şüpheliyim.
Nigel Fds

1
Bu konuyla belki 4. kez mücadele ediyorum. Çalıştığım aynı kod tabanı, üretimde ve aynı zamanda bazı diğer geliştiricilerin dev ortamında iyi çalışıyor. Geçen sefer, bir kayıt defteri değeri eklemem istendi Bilgisayar \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongCrypto [DWORD] = 1. Ve bir süre çalıştı. Bir süre farklı bir projede çalışmaya başladım ve şimdi bu projeye geri döndüm ve bu kayıt defteri anahtarı düzeltmesiyle bile istek yine başarısız oluyor. Çok sinir bozucu.
Miguel

Yanıtlar:


598

Sonunda cevabı buldum (kaynağımı not etmedim ama bir aramadaydı);

Kod Windows XP'de çalışırken, Windows 7'de bunu başlangıçta eklemeniz gerekir:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

Ve şimdi, mükemmel çalışıyor.


EK

Robin French'in belirttiği gibi; PayPal'ı yapılandırırken bu sorunu yaşıyorsanız, 3 Aralık 2018 tarihinden itibaren SSL3'ü desteklemeyeceklerini lütfen unutmayın. TLS kullanmanız gerekecektir. İşte bununla ilgili Paypal sayfası .


5
SecurityProtocolType.Tls12'ye gitmek bu sorunu benim için düzeltti. Cevabımı aşağıda görebilirsiniz.
Bryan Legend

24
SSLv3 18 yaşında ve şimdi POODLE istismarına açık - @LoneCoder SecurityProtocolType.Tls12'nin SecurityProtocolType.Ssl3
gary

4
Bunun için bir istismar bulunana kadar SecurityProtocolType.Tls aslında daha iyi bir alternatif olabilir (tüm siteler yazma olarak Tls12'yi desteklemez)
gary

3
PayPal, SSL3'ü devre dışı bırakmak ve TLS1.2'yi uygulamak için 30 Haziran 2017 tarihini belirlemiştir. Zaten sandbox ortamlarında uygulandı paypal-knowledge.com/infocenter/…
Robin French

11
Bunu da görün . Özel olarak tek bir türe ayarlamanız gerekmez, sadece ekleyebilirsiniz. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
Nae

153

Bunun çözümü, .NET 4.5'te

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

.NET 4.5'iniz yoksa

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

10
Teşekkür ederim! .Net 4.0 kullanmam gerekiyor ve bunu nasıl çözeceğimi bilmiyordum. Burada işe yarıyor gibi görünüyor. :)
Fabiano

Windows Server 2008R2'de (ve muhtemelen 2012'de de)
çalışmıyor

@billpg, daha kesin cevap için bunu okuyun
Vikrant

VB türleri için (bu cevap Google'da ServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
ConfusionTowers

@Andrej Z .net framework 4 üzerinde çalışıyor. Teşekkürler.
az fav

107

HttpWebRequest oluşturulmadan önce ServicePointManager ayarlarının yapıldığından emin olun, aksi takdirde çalışmaz.

İşler:

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

başarısız:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

4
Yukarıda bahsettiğiniz İşler ve Başarısızlıklar arasındaki fark nedir?
Chandy Kunhu

5
Muhteşem. İsteğim sadece ikinci denemeden sonra işe yaradı, ki bu mantıklı değildi ve daha sonra postanızı gördüm, güvenlik protokolünü istekten önce taşıdı ve voilà, düzeltildi. Thanks @ hogarth45
deanwilliammills

2
Kesinlikle! ServicePointManager'ı istek oluşturulmadan hemen önce yerleştirdiğimde, benim için çalıştı, Teşekkürler dostum, Günümü kurtardın.

1
Mükemmel ... bu harika
Maryam Bagheri

1
Bizim durumumuzda, istek ilk kez başarısız oldu ve daha sonra çalıştı. Bu tam olarak bu cevapta belirtilen nedenden kaynaklanıyordu!
Mohammad Dehghan

34

Sorun, aspNet kullanıcısının sertifikaya erişiminin olmamasıdır. Winhttpcertcfg.exe dosyasını kullanarak erişim izni vermelisiniz

Bunu nasıl ayarlayacağınıza ilişkin bir örnek: http://support.microsoft.com/kb/901183

Daha fazla bilgi için 2. adımda

DÜZENLEME: IIS'nin daha yeni sürümlerinde, bu özellik sertifika yöneticisi aracında yerleşik olarak bulunur ve sertifikaya sağ tıklanarak ve özel anahtarları yönetme seçeneği kullanılarak erişilebilir. Daha fazla ayrıntı burada: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791


Winhttpcertcfg.exe çalıştırmayı denedim ... Windows 7'de olduğumu unutmayın. Bir şey değiştirebilir mi?
Simon Dugré

İlgili olup olmadığından emin değilim, ancak bu yazı bana VS'den bu çağrıyı yaparken VS'yi yönetici olarak çalıştırma fikrini verdi ve bu benim için sorunu düzeltti.
PFranchise

2
Windows 7 ve sonraki sürümlerde, sertifikanın "Özel Anahtarları Yönet" için Geçerli Kullanıcı yerine Yerel Bilgisayar deposunda olması gerekir
Lukos

1
Evet, bu benim sorunumdu. mmc.exe kullanın, sertifikalar ek bileşenini ekleyin (benim için 'yerel bilgisayar' seçtim). Sertifikaya, tüm görevlere sağ tıklayın, özel anahtarları yönetin. 'Herkes' ekle (yerel geliştiriciler için bu en kolay - prod açıkça belli ki IIS web sitesi uygulama havuzuna / kullanıcısına ihtiyaç duyar)
Ian Yates

@LIan Yates, bu çözüm sadece benim için çalıştı (y)
Usman Younas

31

Hata geneldir ve SSL / TLS anlaşmasının başarısız olmasının birçok nedeni olabilir. En yaygın olanı geçersiz veya süresi dolmuş bir sunucu sertifikasıdır ve kendi sunucu sertifikası doğrulama kancanızı sağlayarak bununla ilgilenmiş olursunuz, ancak bunun tek nedeni olması gerekmez. Sunucu karşılıklı kimlik doğrulaması gerektirebilir, istemciniz tarafından desteklenmeyen bir şifre paketiyle yapılandırılabilir, el sıkışmasının başarılı olması için çok büyük bir zaman kayması ve daha birçok neden olabilir.

En iyi çözüm, SChannel sorun giderme araçları setini kullanmaktır. SChannel, SSL ve TLS'den sorumlu SSPI sağlayıcısıdır ve müşteriniz bunu el sıkışması için kullanacaktır. TLS / SSL Araçlarına ve Ayarlarına göz atın .

Ayrıca bkz . Schannel olay günlüğünü etkinleştirme .


Nerede yolu için Schannel event loggingde , Windows 7-8-10 ?
PreguntonCojoneroCabrón

C # programlı TLS / SSL sorun gidermek ?
Kiquenet

27

SPDY ve garip yönlendirme SSL sertifikaları gibi çılgın şeyleri destekleyen CDN'de CloudFlare tarafından dağıtılan bir görüntü olan https://ct.mob0.com/Styles/Fun.png ' i vurmaya çalışırken bu sorunu yaşadım .

Simons cevabında olduğu gibi Ssl3 belirtmek yerine, Tls12'ye şu şekilde gidip bunu düzeltebiliyorum:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Teşekkürler Lone ... duruma bağlı olarak birçok farklı olasılık olasılığına sahip olmak çılgınca ... Ve görebildiğim gibi, bunun gerçek bir belgesi yok. Aynı sorunu yaşayabilecek birine işaret ettiğin için teşekkürler.
Simon Dugré

Bu benim için çalıştı. Office LAN'dan ev ağıma geçiş yaptığımda Hatayla karşılaştım. Aynı kod, aynı dizüstü bilgisayar!
Amal

Hatayı her zaman (tüm isteklerde) veya bazen alıyor musunuz?
PreguntonCojoneroCabrón

24

Aynı sorunla uzun saatler sonra istemci hizmeti altında çalıştığı ASP.NET hesabının sertifika erişiminin olmadığını buldum. Web uygulamasının çalıştığı IIS Uygulama Havuzuna gidip Gelişmiş Ayarlar'a girip Kimliği LocalSystemhesabından değiştirerek düzelttim NetworkService.

Daha iyi bir çözüm, sertifikanın varsayılan NetworkServicehesapla çalışmasını sağlamaktır, ancak bu hızlı fonksiyonel test için işe yarar.


3
Bu cevabın daha fazla oyu olmalı. Bir haftalık araştırmadan sonra, bu benim için işe yarayan tek çözüm. Teşekkürler!!
user224567893

Bu benim için çalıştı. mükemmel teşekkürler.
Emy İstatistikleri

18

Ortamda yaklaşım

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Tamam görünüyor, çünkü Tls1.2 güvenli protokolün en son sürümüdür. Ama daha derine bakmaya karar verdim ve cevaplamalıyız gerçekten kodlamamıza gerek var.

Özellikler: Windows Server 2012R2 x64.

İnternetten .NetFramework 4.6+ uygulamasının varsayılan olarak Tls1.2'yi kullanması gerektiği söylenir. Ama projemi 4.6'ya güncellediğimde hiçbir şey olmadı. Tls1.2'yi varsayılan olarak etkinleştirmek için elle bazı değişiklikler yapmam gerektiğini söyleyen bazı bilgiler buldum

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Ancak önerilen Windows güncellemesi R2 sürümünde çalışmıyor

Ama bana yardımcı olan, kayıt defterine 2 değer eklemektir. Sonraki PS betiğini kullanarak otomatik olarak eklenecek

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Aradığım şey bu. Ama yine de NetFramework 4.6+ neden bu ayarlamıyor sorusuna cevap veremiyorum ... Protokol değeri otomatik olarak?


17

Orijinal cevabın sahip olmadığı bir şey. Kurşun geçirmez hale getirmek için biraz daha kod ekledim.

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

8
Eklenen SSL3 protokolünü önermem.
Peter de Bruijn

SSL3'te 'Kaniş' adı verilen ciddi bir güvenlik sorunu var.
Peter de Bruijn

@PeterdeBruijn Tls and Tls11olan obsoletes ?
Kiquenet

1
@Kiquenet - evet. Haziran 2018 itibarıyla PCI (Ödeme Kartı Endüstrileri) TLS1.2'den düşük protokollere izin vermeyecektir. (Bu başlangıçta 06/2017 için planlandı, ancak bir yıl ertelendi)
GlennG

SSL / TLS ailesinde beş protokol vardır : SSL v2, SSL v3, TLS v1.0, TLS v1.1 ve TLS v1.2 : github.com/ssllabs/research/wiki/… SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes Yalnızca geçerli bir seçenek ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12mi olacak ?
Kiquenet

14

Başka bir olasılık da kutuda uygunsuz sertifika ithalatıdır. Çevrili onay kutusunu seçtiğinizden emin olun. Başlangıçta yapmadım, bu yüzden kod zaman aşımına uğradı veya özel anahtar olarak aynı istisnayı alamadı.

sertifika içe aktarma iletişim kutusu


Bir istemci, bir istemci programını kullanmak için sertifikayı yeniden yüklemeye devam etti. Programı kullanmadan önce sertifikayı tekrar tekrar kurmaları gerekir. Bu cevabın bu sorunu çözeceğini umuyorum.
Pangamma

11

Sunucu HTTP isteğine bir HTTP 401 Yetkisiz yanıtı döndürüyorsa "İstek iptal edildi: SSL / TLS güvenli kanalı oluşturulamadı" özel durumu oluşabilir .

Bunun olup olmadığını, bu yanıtta açıklandığı gibi istemci uygulamanız için izleme düzeyi System.Net günlüğünü açarak belirleyebilirsiniz .

Bu günlüğe kaydetme yapılandırması gerçekleştikten sonra uygulamayı çalıştırın ve hatayı yeniden oluşturun, ardından günlük çıktısında şöyle bir satır olup olmadığına bakın:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

Benim durumumda, sunucunun beklediği belirli bir çerez ayarlayamıyordum, sunucunun 401 hatasıyla isteğe yanıt vermesine neden oldu, bu da "SSL / TLS güvenli kanal oluşturulamadı" istisnasına yol açtı.


1
Benim görev zamanlayıcı her gün (değil hafta sonu) yürütün. Aynı hatayı alıyorum, ama bazen ( 2 errors in 2 months). Hatayı aldığımda, birkaç dakika sonra tekrar manuel olarak deniyorum ve her şey yolunda.
Kiquenet

10

The request was aborted: Could not create SSL/TLS secure channelHatanın bir diğer olası nedeni, istemci PC'nizin yapılandırılmış cipher_suites değerleri ile sunucunun istekli ve kabul edebilecek şekilde yapılandırıldığı değerler arasındaki uyumsuzluktur . Bu durumda, istemciniz ilk SSL el sıkışma / görüşme "İstemci Merhaba" iletisinde kabul edebileceği cipher_suites değerleri listesini gönderdiğinde, sunucu sağlanan değerlerin hiçbirinin kabul edilemez olduğunu görür ve bir "Uyarı "SSL el sıkışmasının" Sunucu Merhaba "adımına geçmek yerine yanıt.

Bu olasılığı araştırmak için Microsoft Message Analyzer'ı indirebilirsiniz ve sunucuya (C # uygulamanızda) HTTPS bağlantısı kurmayı denediğinizde ve başarısız olduğunuzda oluşan SSL anlaşmasında bir iz çalıştırmak için kullanabilirsiniz.

Başka bir ortamdan başarılı bir HTTPS bağlantısı kurabiliyorsanız (örn. Bahsettiğiniz Windows XP makinesi) veya muhtemelen HTTPS URL'sini işletim sisteminin şifreleme paketi ayarlarını kullanmayan Microsoft dışındaki bir tarayıcıda vurarak Chrome veya Firefox) kullanıyorsanız, SSL anlaşması başarılı olduğunda neler olduğunu yakalamak için o ortamda başka bir Message Analyzer izlemesi çalıştırın.

Umarız, başarısız olan SSL görüşmesinin başarısız olmasına neden olan şeyin tam olarak ne olduğunu belirlemenizi sağlayacak iki Müşteri Merhaba mesajı arasında bir fark görürsünüz. Ardından, Windows'ta başarılı olmasına izin verecek yapılandırma değişiklikleri yapabilmeniz gerekir. IISCrypto bunun için harika bir araçtır ("IIS" adına rağmen istemci bilgisayarlar için bile).

Aşağıdaki iki Windows kayıt defteri anahtarı, bilgisayarınızın kullanacağı cipher_suites değerlerini yönetir:

  • HKLM \ Software \ Policies \ Microsoft \ Kriptografi \ Configuration \ SSL \ 00010002
  • HKLM \ SYSTEM \ CurrentControlSet \ Control \ Kriptografi \ Configuration \ Local \ SSL \ 00010002

Could not create SSL/TLS secure channelSorunun bu çeşitliliğinin bir örneğini nasıl araştırdığımı ve çözdüğümü gösteren tam bir yazı : http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html


1
Benim durumumda, bu cevap yardımcı olur. Ayrıca, istemci bilgisayarımın bazı şifre paketlerini kaçırdığından şüphelendiğim için , gerçekten bir başlangıç ​​yapmadan önce bu Windows Güncellemesini doğrudan şansımı denemek için yükledim ( support.microsoft.com/en-hk/help/3161639 , Windows'u yeniden başlatmaya ihtiyaç duyuyor) Message Analyzer arandı ve şanslı olduğum ortaya çıktı ve sorunumu çözdü, kendime bir arama kaydetti.
sken130

1
Firefox gibi tarayıcılarda bir HTTPS bağlantısını test ettiğinizde, herhangi bir Windows Update tarafından sağlananlardan farklı bir şifre alsanız bile, Windows Update'in denenmeye değer olduğunu unutmayın, çünkü yeni şifrelerin yüklenmesi şifre anlaşmasını etkileyecektir istemci bilgisayar ve sunucu arasında, böylece bir eşleşme bulma umudunu artırmak.
sken130

Benim sorunum için noktaya cevap. Yapmam gereken değişiklikleri bulmama yardımcı olan iki şey var. 1. Web sunucusu tarafından desteklenen Cipher Suites: ssllabs.com/ssltest 2. Farklı Windows sürümlerinin desteklediği Cipher Suites: docs.microsoft.com/en-us/windows/win32/secauthn/…
Paul B.

10

Benim durumumda bu istisnanın kökü kodun bir noktasında aşağıdaki çağrılıyor olmasıydı:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Bu gerçekten kötü. .NET'e yalnızca güvenli olmayan bir protokol kullanması talimatını vermekle kalmaz, bu da daha sonra uygulama alanınızda yapılan her yeni WebClient (ve benzeri) isteği etkiler. (Gelen web isteklerinin ASP.NET uygulamanızdan etkilenmediğini, ancak harici bir web hizmetiyle konuşmak gibi yeni WebClient isteklerinin gerçekleştiğini unutmayın).

Benim durumumda, aslında gerekli değildi, bu yüzden sadece ifadeyi silebilirdim ve diğer tüm web isteklerim tekrar çalışmaya başladı. Başka bir yerde okumaya dayanarak birkaç şey öğrendim:

  • Bu, alan adınızdaki global bir ayardır ve eşzamanlı etkinliğiniz varsa güvenilir bir şekilde bir değere ayarlayamaz, eyleminizi gerçekleştiremez ve ardından geri ayarlayamazsınız. Bu küçük pencere sırasında başka bir eylem gerçekleşebilir ve etkilenebilir.
  • Doğru ayar, varsayılan olarak bırakılmasıdır. Bu, .NET'in zaman geçtikçe ve çerçeveleri yükselttiğinizde en güvenli varsayılan değer olan her şeyi kullanmaya devam etmesini sağlar. TLS12'ye (bu yazıdan en güvenli olanı) ayarlamak şimdi işe yarayacak, ancak 5 yıl içinde gizemli sorunlara neden olabilir.
  • Gerçekten bir değer ayarlamanız gerekiyorsa, değeri ayrı bir özel uygulamada veya uygulama alanında yapmayı ve bu değerle ana havuzunuz arasında konuşmanın bir yolunu bulmalısınız. Tek bir global değer olduğundan, yoğun bir uygulama havuzunda yönetmeye çalışmak yalnızca sorun yaratacaktır. Bu cevap: https://stackoverflow.com/a/26754917/7656 , özel bir proxy aracılığıyla olası bir çözüm sunar. (Not: Ben şahsen uygulamadım.)

2
Genel kuralınızın aksine, varsayılan çalıştırmaya izin vermek yerine TLS 1.2'ye ayarlamanız GEREKİRDİĞİNDE bir istisna olduğunu ekleyeceğim. .NET 4.6'dan daha eski bir çerçevedeyseniz ve sunucunuzda güvenli olmayan protokolleri (SSL veya TLS 1.0 / 1.1) devre dışı bıraktıysanız, programı TLS 1.2'ye zorlamadığınız sürece istek veremezsiniz.
Paul

10

Bu sorun yaşadım çünkü web.config dosyamda şunlar vardı:

<httpRuntime targetFramework="4.5.2" />

ve yok:

<httpRuntime targetFramework="4.6.1" />

Aynı sorunu yaşadım ve daha ayrıntılı bir cevap ekledim , bu da bu konunun daha fazla içeri girip çıktı.
JLRishe

9

Anlayacağınız gibi, bunun olmasının birçok nedeni vardır. Karşılaştığım nedeni ekleyeceğimi düşündüm ...

Eğer değerini ayarlarsanız WebRequest.Timeoutiçin 0, bu durum özel durum olduğunu. Aşağıda kod vardı ... ( 0Zaman aşımı değeri için bir sabit kodlu dışında , yanlışlıkla ayarlanmış bir parametre vardı 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

2
Vaov! Bundan bahsettiğiniz için teşekkürler. İlk etapta buna inanamadım ve tonlarca farklı şey denedim. Son olarak, zaman aşımını 10 saniyeye ayarlayın ve kural dışı durum ortadan kalktı! Bu benim için bir çözüm. (y)
derFunk

9

En çok oy alan cevap muhtemelen çoğu insan için yeterli olacaktır. Ancak, bazı durumlarda, TLS 1.2'yi zorladıktan sonra bile "SSL / TLS güvenli kanalı oluşturulamadı" hatası almaya devam edebilirsiniz. Öyleyse, danışmak isteyebilirsiniz bu yararlı makaleyeek sorun giderme adımları için. Özetlemek gerekirse: TLS / SSL sürüm sorunundan bağımsız olarak, istemci ve sunucunun bir "şifre takımı" üzerinde anlaşması gerekir. SSL bağlantısının "el sıkışma" aşaması sırasında, istemci sunucunun kendi listesini kontrol etmesi için desteklenen şifre paketlerini listeler. Ancak bazı Windows makinelerinde, bazı ortak şifre paketleri devre dışı bırakılmış olabilir (görünüşte saldırı yüzeyini sınırlamaya yönelik iyi niyetli girişimler nedeniyle), istemci ve sunucunun bir şifre paketini kabul etme olasılığını azaltır. Kabul edemezlerse, olay görüntüleyicide "önemli uyarı kodu 40" ve .NET programınızda "SSL / TLS güvenli kanal oluşturulamadı" ifadesini görebilirsiniz.

Yukarıda bahsedilen makalede, bir makinenin potansiyel olarak desteklenen tüm şifre paketlerinin nasıl listeleneceği ve Windows Kayıt Defteri aracılığıyla ek şifre paketlerinin nasıl etkinleştirileceği açıklanmaktadır. İstemcide hangi şifre paketlerinin etkinleştirildiğini kontrol etmeye yardımcı olmak için MSIE'de bu tanı sayfasını ziyaret etmeyi deneyin . (System.Net izlemenin kullanılması daha kesin sonuçlar verebilir.) Sunucu tarafından hangi şifre paketlerinin desteklendiğini kontrol etmek için bu çevrimiçi aracı deneyin (sunucunun Internet'e erişilebildiği varsayılarak). Kayıt defteri düzenlemelerinin , özellikle ağ oluşturma söz konusu olduğunda dikkatli yapılması gerektiğini söylemeden geçmelidir . (Makineniz uzakta barındırılan bir sanal makine mi?

Şirketimin durumunda, acil bir sorunu düzeltmek ve gelecekteki sorunlara karşı korumak için Kayıt Defteri düzenleme yoluyla birkaç ek "ECDHE_ECDSA" paketini etkinleştirdik. Ancak, Kayıt Defterini düzenleyemezseniz (veya düzenlemezseniz), çok sayıda geçici çözüm (mutlaka hoş değil) akla gelir. Örneğin: .NET programınız SSL trafiğini ayrı bir Python programına devredebilir (bu da çalışabilir, aynı nedenle Chrome istekleri MSIE isteklerinin etkilenen bir makinede başarısız olması durumunda başarılı olabilir).


9

Bu sorunun en büyük nedenlerinden biri etkin .NET Framework sürümüdür. .NET framework çalışma zamanı sürümü, varsayılan olarak hangi güvenlik protokollerinin etkinleştirildiğini etkiler.

Farklı sürümlerde özel olarak nasıl çalıştığına dair herhangi bir yetkili belge yok gibi görünüyor, ancak varsayılanlar aşağıdaki gibi az çok belirlenmiş görünüyor:

  • .NET Framework 4.5 ve öncesi - SSL 3.0, TLS 1.0
  • .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
  • .NET Framework 4.7+ - Sistem (OS) Varsayılanları

(Daha eski sürümlerde, kilometreniz, sistemde yüklü olan .NET çalışma zamanlarına bağlı olarak biraz değişebilir. Örneğin, çok eski bir çerçeve kullandığınız ve TLS 1.0'ın desteklenmediği veya 4.6'nın kullanıldığı bir durum olabilir. x ve TLS 1.3 desteklenmez)

Microsoft'un belgeleri 4.7+ sürümünü kullanmanızı önerir ve sistem varsayılanları:

Aşağıdakileri yapmanızı öneririz:

  • Uygulamalarınızdaki .NET Framework 4.7 veya sonraki sürümlerini hedefleyin. WCF uygulamalarınızda .NET Framework 4.7.1 veya sonraki sürümlerini hedefleyin.
  • TLS sürümünü belirtmeyin. Kodunuzu, işletim sisteminin TLS sürümüne karar vermesini sağlayacak şekilde yapılandırın.
  • TLS veya SSL sürümü belirtmediğinizi doğrulamak için kapsamlı bir kod denetimi yapın.

ASP.NET siteleri için , <httpRuntime>siteniz tarafından hangi çalışma zamanının gerçekten kullanıldığını belirlediğinden , öğenizdeki .NET framework sürümünü kontrol edin :

<httpRuntime targetFramework="4.5" />

Daha iyi:

<httpRuntime targetFramework="4.7" />

8

Bu benim için MVC webclient çalışıyor

    public string DownloadSite(string RefinedLink)
    {
        try
        {
            Uri address = new Uri(RefinedLink);

            ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

            System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

            using (WebClient webClient = new WebClient())
            {
                var stream = webClient.OpenRead(address);
                using (StreamReader sr = new StreamReader(stream))
                {
                    var page = sr.ReadToEnd();

                    return page;
                }
            }

        }
        catch (Exception e)
        {
            log.Error("DownloadSite - error Lin = " + RefinedLink, e);
            return null;
        }
    }

2
ServerCertificateValidationCallback geçersiz kılınırken yeni güvenlik açığı olur mu?

7

İstemcinin bir Windows makinesi olması durumunda, olası bir neden, hizmet için gereken tls veya ssl protokolünün etkinleştirilmemesidir.

Bu ayarlanabilir:

Denetim Masası -> Ağ ve İnternet -> İnternet Seçenekleri -> Gelişmiş

Ayarları "Güvenlik" e kaydırın ve

  • SSL 2.0 kullan
  • SSL 3.0 kullan
  • TLS 1.0 kullan
  • TLS 1.1 kullan
  • TLS 1.2 kullan

resim açıklamasını buraya girin


hepsini işaretlemede herhangi bir sorun var mı?
Nigel Fds

hiçbir sorun, bildiğim kadarıyla ... dışında ssl artık tavsiye edilmez ... yeterince güvenli kabul edilmez.
cnom

Powershell'de programlı olarak nasıl yapılır ?
Kiquenet

Bu, Windows'un eski sürümlerini etkileyen bir şey, Biraz araştırma yapın, şu anda hangi güvenlik seçeneklerinin kullanıldığını öğrenin. Bugün itibariyle bu bağlantıya bakın: tecadmin.net/enable-tls-on-windows-server-and-iis
Tod

7

Benim durumumda, uygulamayı çalıştıran hizmet hesabının özel anahtara erişim izni yoktu. Bu izni verdikten sonra hata ortadan kalktı

  1. mmc
  2. sertifikalar
  3. Kişiselleştir
  4. sertifika seç
  5. sağ tık
  6. Tüm görevler
  7. Özel anahtarları yönet
  8. Ekle

7

Kodunuzu Visual Studio'dan çalıştırıyorsanız, Visual Studio'yu yönetici olarak çalıştırmayı deneyin. Sorun benim için düzeltildi.


Ne yazık ki benim için değil!
benedict_w

Benim durumumda yardımcı olan tek kişi bu! Teşekkürler!!!
alexander ostrikov

6

Bütün gün bu sorunla mücadele ettim.

.NET 4.5 ile yeni bir proje oluşturduğumda sonunda işe koyuldum.

Ama eğer 4.0'a düşürdüysem aynı problemi tekrar aldım ve bu proje için geri dönüşümsüzdü (tekrar 4.5'e yükseltmeye çalıştığımda bile).

"İstek iptal edildi: SSL / TLS güvenli kanalı oluşturulamadı." Dışında garip başka bir hata mesajı yok . bu hata için geldi


5
Bunun çalışmasının nedeni, farklı .NET sürümlerinin farklı SSL / TLS protokol sürümlerini desteklemesi olabilir. Daha fazla bilgi: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
Jon Schneider

4

System.Net.WebException: İstek iptal edildi: SSL / TLS güvenli kanalı oluşturulamadı.

Bizim durumumuzda, bir yazılım satıcısı kullandığımız için .NET kodunu değiştirme erişimimiz yoktu. Görünüşe göre .NET 4, bir değişiklik olmadığı sürece TLS v 1.2 kullanmayacaktır.

Bizim için düzeltme, kayıt defterine SchUseStrongCrypto anahtarını ekliyordu. Aşağıdaki kodu .reg uzantılı bir metin dosyasına kopyalayıp yapıştırabilir ve yürütebilirsiniz. Soruna bizim "yama" olarak görev yaptı.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

3
İşte hızlı düzenleme için PS: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

2
İşte hızlı düzenleme için PS: New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

4

Bunu dene:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Bu satırı ekledim. Bazen başarısız oluyor ve aynı hatayı alıyorumSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Joseph Katzman

4

Bu benim için düzeltildi, izinlere Ağ Hizmeti ekleyin. Sertifikayı sağ tıklayın> Tüm Görevler> Özel Anahtarları Yönet ...> Ekle ...> "Ağ Hizmeti" ekle.


3

Benim için sorun, IIS üzerinde bir web hizmeti olarak dağıtmaya çalışıyordum, sertifikayı sunucuya yükledim, ancak IIS'yi çalıştıran kullanıcının sertifika üzerinde doğru izinleri yoktu.

ASP.NET'in sertifika deposundaki bir sertifikadaki özel anahtara erişmesine nasıl izin verilir?


Evet, aynen. Düzeltmek için Nick Gotch'ın cevabının söylediklerini yaptım: uygulama havuzu kimliğini LocalSystem olarak değiştirdi. Bu benim için çözdü.
Judah Gabriel Himango

1
Bunun için teşekkürler
Denis Pitcher

3

Aynı sorunu yaşıyordum ve bu cevabın benim için düzgün çalıştığını gördüm . Anahtar 3072'dir. Bu bağlantı '3072' düzeltmesiyle ilgili ayrıntıları sağlar.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

Benim durumumda iki feed'in düzeltilmesi gerekiyordu:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

3

Bu sorunun genel bir hata mesajı ile ilgili olduğu için birçok cevabı olabilir. Bu sorunu bazı sunucularımızda gördük, ancak geliştirme makinelerimizde değil. Saçlarımızın çoğunu çıkardıktan sonra, Microsoft'un bir hata olduğunu gördük.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Esasen MS, daha zayıf şifreleme istediğinizi varsayar, ancak işletim sistemi yalnızca TLS 1.2'ye izin verecek şekilde yamalı, bu nedenle "İstek iptal edildi: SSL / TLS güvenli kanalı oluşturulamadı."

Üç düzeltme var.

1) İşletim sistemini uygun güncellemeyle yamalayın: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) app.config / web.config dosyanıza bir ayar ekleyin.

3) Başka bir yanıtta daha önce bahsedilen bir kayıt defteri ayarı ekleyin.

Bunların tümü, gönderdiğim bilgi bankası makalesinde belirtilmiştir.


Ayrıca, uygulamanızda yalnızca bir kez ServicePointManager.SecurityProtocol ayarladığınızdan emin olun. Uygulamamızda SSL3 olarak ayarlanan isteğe bağlı derlemeler ile oldukça karmaşık olan ikinci bir çağrı keşfettik ve bu da aynı hata mesajını attı.
Michael Silver

3

Başka bir olasılık da, yürütülmekte olan kodun gerekli premisyonlara sahip olmamasıdır.

Benim durumumda, bir web hizmetine bir çağrıyı test etmek için Visual Studio hata ayıklayıcısını kullanırken bu hatayı aldım. Visual Studio, bu özel duruma neden olan Yönetici olarak çalışmıyordu.


2

Bu benim için sadece bir sitede oluyordu ve sadece RC4 şifresinin mevcut olduğu ortaya çıktı. Sunucuyu sertleştirmek için önceden bir çabada, RC4 şifresini devre dışı bırakmıştım, bu yeniden etkinleştirdikten sonra sorun çözüldü.


1
Yanıtta bağlantıları kullanmayın, çünkü gelecekte çalışmayabilirler, cevabınızın içindeki en alakalı yönleri
Rodrigo López
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.