Kendinden imzalı sertifika ile test sunucusuna SSL/TLS bağlantısı kurmaya çalışıyorum. Güvenli olmayan kanal üzerinden iletişim sorunsuz çalıştı.
İşte bu çözümleri temel alarak yazdığım örnek kodum: https://stackoverflow.com/questions/12553277/allowing-untrusted-ssl-certificates-with-httpclient https://stackoverflow.com/questions/2675133/c-sharp-ignore-certificate-errors https://stackoverflow.com/questions/15205814/net-client-connecting-to-ssl-web-api
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;
var c = new HttpClient();
var r = c.GetAsync("https://10.3.0.1:8443/rest/v1").Result;
if (r.IsSuccessStatusCode)
{
Log.AddMessage(r.Content.Get<string>());
}
else
{
Log.AddMessage(string.Format("{0} ({1})", (int)r.StatusCode, r.ReasonPhrase));
}
Bunu da denedim:
var handler = new WebRequestHandler();
handler.ServerCertificateValidationCallback = delegate { return true; };
var c = new HttpClient(handler);
...
ve bu
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
ama her seferinde bir istisna yaşıyorum:
InnerException: System.Net.Http.HttpRequestException
_HResult=-2146233088
_message=An error occurred while sending the request.
HResult=-2146233088
IsTransient=false
Message=An error occurred while sending the request.
InnerException: System.Net.WebException
_HResult=-2146233079
_message=The request was aborted: Could not create SSL/TLS secure channel.
HResult=-2146233079
IsTransient=false
Message=The request was aborted: Could not create SSL/TLS secure channel.
Source=System
StackTrace:
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
InnerException:
Neyi yanlış yapıyorum? Neden bu sunucuya bağlanamıyorum (geçersiz-kendinden imzalı sertifikaya sahip)
ServerCertificateValidationCallback ile doğru yapıyorsunuz. Karşılaştığınız sorun bu değil. Karşılaştığınız sorun büyük olasılıkla SSL/TLS protokolünün sürümüdür.
Örneğin, sunucunuz yalnızca SSLv3 ve TLSv10 sunuyorsa ve istemcinizin TLSv12'ye ihtiyacı varsa, bu hata mesajını alırsınız. Yapmanız gereken şey, hem istemci hem de sunucunun ortak bir protokol sürümünü desteklediğinden emin olmaktır.
Mümkün olduğunca çok sayıda sunucuya bağlanabilen bir istemciye ihtiyaç duyduğumda (mümkün olduğunca güvenli olmak yerine) bunu kullanıyorum (doğrulama geri çağrısını ayarlamakla birlikte):
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
Aynı sorunu daha bugün çözdük ve yapmanız gereken tek şey .NET'in çalışma zamanı sürümünü artırmak
4.5.2 yukarıdaki sorunla bizim için çalışmadı, 4.6.1 ise iyiydi
NET sürümünü tutmanız gerekiyorsa, o zaman
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
Hala bu sorunla karşılaşan herkes için bir takip olarak - çözümde belirtildiği gibi ServicePointManager.SecurityProfile seçeneklerini ekledim:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
Yine de aynı "İstek iptal edildi: SSL/TLS güvenli kanal oluşturulamadı" hatasını almaya devam ettim. HTTPS SOAP API arayüzlerine sahip bazı eski ses sunucularına bağlanmaya çalışıyordum (yani sesli posta, IP telefon sistemleri vb... yıllar önce kuruldu). Bunlar en son yıllar önce güncellendikleri için yalnızca SSL3 bağlantılarını destekliyorlar.
SecurityProtocols listesine SSl3'ü dahil etmenin burada işe yarayacağı düşünülebilir, ancak işe yaramadı. Bağlantıyı zorlayabilmemin tek yolu SADECE Ssl3 protokolünü dahil etmek ve başka hiçbir protokolü dahil etmemekti:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
Sonra bağlantı gerçekleşiyor - bana bir hata gibi görünüyor ama bu durum yıllardır piyasada olan bu sunucular için sağladığım araçlarda yakın zamana kadar hata vermeye başlamamıştı - Microsoft'un başka bir alternatif olmadığı sürece TLS bağlantılarını zorlamak için bu davranışı güncelleyen sistem değişiklikleri yapmaya başladığına inanıyorum.
Her neyse - eğer hala bazı eski sitelerde/sunucularda bu sorunla karşılaşıyorsanız, denemeye değer.