Permintaan dibatalkan: Tidak dapat membuat saluran aman SSL / TLS

Kami tidak dapat terhubung ke server HTTPS menggunakan WebRequestkarena pesan kesalahan ini:

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

Kami tahu bahwa server tidak memiliki sertifikat HTTPS yang valid dengan jalur yang digunakan, tetapi untuk mem-bypass masalah ini, kami menggunakan kode berikut yang telah kami ambil dari pos StackOverflow lain:

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

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

Masalahnya adalah server tidak pernah memvalidasi sertifikat dan gagal dengan kesalahan di atas. Adakah yang tahu apa yang harus saya lakukan?

Saya harus menyebutkan bahwa seorang kolega dan saya melakukan tes beberapa minggu yang lalu dan itu bekerja dengan baik dengan sesuatu yang mirip dengan apa yang saya tulis di atas. Satu-satunya "perbedaan utama" yang kami temukan adalah bahwa saya menggunakan Windows 7 dan dia menggunakan Windows XP. Apakah itu mengubah sesuatu?

Saya akhirnya menemukan jawabannya (saya belum mencatat sumber saya tetapi dari pencarian);

Sementara kode berfungsi di Windows XP, di Windows 7, Anda harus menambahkan ini di awal:

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

Dan sekarang, ia bekerja dengan sempurna.

TAMBAHAN

Seperti yang disebutkan oleh Robin French; jika Anda mendapatkan masalah ini saat mengonfigurasi PayPal, harap perhatikan bahwa mereka tidak akan mendukung SSL3 mulai Desember, 3 2018. Anda harus menggunakan TLS. Inilah halaman Paypal tentang hal itu.

Solusi untuk ini, dalam .NET 4.5 adalah

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Jika Anda tidak memiliki .NET 4.5 maka gunakan

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Pastikan pengaturan ServicePointManager dibuat sebelum HttpWebRequest dibuat, jika tidak maka tidak akan berfungsi.

Bekerja:

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

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

Gagal:

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

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

Masalah yang Anda alami adalah bahwa pengguna aspNet tidak memiliki akses ke sertifikat. Anda harus memberikan akses menggunakan winhttpcertcfg.exe

Contoh tentang cara mengatur ini adalah di: http://support.microsoft.com/kb/901183

Di bawah langkah 2 dalam informasi lebih lanjut

EDIT: Di versi IIS yang lebih baru, fitur ini terintegrasi dengan alat pengelola sertifikat - dan dapat diakses dengan mengklik kanan sertifikat dan menggunakan opsi untuk mengelola kunci pribadi. Lebih detail di sini: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

Kesalahannya bersifat umum dan ada banyak alasan mengapa negosiasi SSL / TLS mungkin gagal. Yang paling umum adalah sertifikat server yang tidak valid atau kedaluwarsa, dan Anda menanganinya dengan memberikan kait validasi sertifikat server Anda sendiri, tetapi tidak selalu menjadi satu-satunya alasan. Server mungkin memerlukan otentikasi timbal balik, mungkin dikonfigurasikan dengan serangkaian sandi yang tidak didukung oleh klien Anda, mungkin ada waktu melayang terlalu besar untuk jabat tangan agar berhasil dan banyak alasan lainnya.

Solusi terbaik adalah dengan menggunakan set alat pemecahan masalah SChannel. SChannel adalah penyedia SSPI yang bertanggung jawab untuk SSL dan TLS dan klien Anda akan menggunakannya untuk jabat tangan. Lihatlah Alat dan Pengaturan TLS / SSL .

Juga lihat Cara mengaktifkan pencatatan acara Schannel .

Saya mengalami masalah ini untuk mencoba https://ct.mob0.com/Styles/Fun.png , yang merupakan gambar yang didistribusikan oleh CloudFlare di CDN-nya yang mendukung hal-hal gila seperti SPDY dan sertifikat SSL pengalihan aneh.

Alih-alih menentukan Ssl3 seperti dalam jawaban Simons saya bisa memperbaikinya dengan turun ke Tls12 seperti ini:

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

Setelah berjam-jam dengan masalah yang sama, saya menemukan bahwa akun ASP.NET yang dijalankan oleh layanan klien tidak memiliki akses ke sertifikat. Saya memperbaikinya dengan masuk ke Kumpulan Aplikasi IIS tempat aplikasi web berjalan, masuk ke Pengaturan Lanjutan, dan mengubah identitas dari LocalSystemakun NetworkService.

Solusi yang lebih baik adalah membuat sertifikat berfungsi dengan NetworkServiceakun default tetapi ini berfungsi untuk pengujian fungsional cepat.

Pendekatan dengan pengaturan

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Tampaknya baik-baik saja, karena Tls1.2 adalah versi terbaru dari protokol aman. Tapi saya memutuskan untuk melihat lebih dalam dan menjawab apakah kita benar-benar perlu untuk melakukan hardcode.

Spesifikasi: Windows Server 2012R2 x64.

Dari internet dikatakan bahwa .NetFramework 4.6+ harus menggunakan Tls1.2 secara default. Tetapi ketika saya memperbarui proyek saya menjadi 4,6 tidak ada yang terjadi. Saya telah menemukan beberapa info yang mengatakan bahwa saya perlu secara manual melakukan beberapa perubahan untuk mengaktifkan Tls1.2 secara default

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

Tetapi pembaruan windows yang diusulkan tidak berfungsi untuk versi R2

Tetapi yang membantu saya adalah menambahkan 2 nilai ke dalam registri. Anda dapat menggunakan skrip PS berikutnya sehingga akan ditambahkan secara otomatis

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

Itulah yang saya cari. Tapi saya tetap tidak bisa menjawab pertanyaan mengapa NetFramework 4.6+ tidak mengatur ini ... Nilai protokol secara otomatis?

Sesuatu yang tidak dimiliki jawaban aslinya. Saya menambahkan beberapa kode lagi untuk membuatnya menjadi bukti.

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

Kemungkinan lain adalah impor sertifikat yang tidak benar pada kotak. Pastikan untuk memilih kotak centang yang dilingkari. Awalnya saya tidak melakukannya, jadi kode waktu atau melemparkan pengecualian yang sama seperti kunci pribadi tidak dapat ditemukan.

Pengecualian "Permintaan dibatalkan: Tidak dapat membuat saluran aman SSL / TLS" dapat terjadi jika server mengembalikan respons HTTP 401 yang tidak sah ke permintaan HTTP.

Anda dapat menentukan apakah ini terjadi dengan mengaktifkan penelusuran tingkat System.Net jejak untuk aplikasi klien Anda, seperti yang dijelaskan dalam jawaban ini .

Setelah konfigurasi pendataan di tempat, jalankan aplikasi dan mereproduksi kesalahan, kemudian lihat output logging untuk baris seperti ini:

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

Dalam situasi saya, saya gagal menetapkan cookie tertentu yang diharapkan oleh server, yang mengarah ke server menanggapi permintaan dengan kesalahan 401, yang pada gilirannya menyebabkan pengecualian "Tidak dapat membuat saluran aman SSL / TLS".

Kemungkinan penyebab The request was aborted: Could not create SSL/TLS secure channelkesalahan lainnya adalah ketidaksesuaian antara nilai-nilai cipher_suites yang dikonfigurasi PC klien Anda, dan nilai-nilai yang dikonfigurasikan oleh server sebagai yang bersedia dan dapat diterima . Dalam hal ini, ketika klien Anda mengirim daftar nilai cipher_suites yang dapat diterima dalam pesan "klien Halo" handshaking / negosiasi SSL, server melihat bahwa tidak ada nilai yang diberikan yang dapat diterima, dan dapat mengembalikan "Peringatan" "respons alih-alih melanjutkan ke langkah" Server Hello "dari jabat tangan SSL.

Untuk menyelidiki kemungkinan ini, Anda dapat mengunduh Microsoft Message Analyzer , dan menggunakannya untuk menjalankan jejak negosiasi SSL yang terjadi saat Anda mencoba dan gagal membuat koneksi HTTPS ke server (di aplikasi C # Anda).

Jika Anda dapat membuat koneksi HTTPS yang berhasil dari lingkungan lain (mis. Mesin Windows XP yang Anda sebutkan - atau mungkin dengan menekan URL HTTPS di browser non-Microsoft yang tidak menggunakan pengaturan cipher suite OS, seperti Chrome atau Firefox), jalankan jejak Analyzer Pesan lain di lingkungan itu untuk menangkap apa yang terjadi ketika negosiasi SSL berhasil.

Mudah-mudahan, Anda akan melihat beberapa perbedaan antara dua pesan Halo Klien yang akan memungkinkan Anda menentukan dengan tepat bagaimana dengan negosiasi SSL yang gagal menyebabkannya gagal. Maka Anda harus dapat membuat perubahan konfigurasi ke Windows yang akan membuatnya berhasil. IISCrypto adalah alat yang hebat untuk digunakan untuk ini (bahkan untuk PC klien, meskipun nama "IIS").

Dua kunci registri Windows berikut ini mengatur nilai-nilai cipher_suites yang akan digunakan PC Anda:

• HKLM \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptography \ Configuration \ Local \ SSL \ 00010002

Berikut ini adalah artikel lengkap tentang bagaimana saya menyelidiki dan memecahkan contoh berbagai Could not create SSL/TLS secure channelmasalah ini: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Akar pengecualian ini dalam kasus saya adalah bahwa pada suatu titik dalam kode berikut ini disebut:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Ini sangat buruk. Tidak hanya menginstruksikan .NET untuk menggunakan protokol tidak aman, tetapi ini berdampak pada setiap permintaan WebClient baru (dan yang serupa) yang dibuat sesudahnya di dalam appdomain Anda. (Perhatikan bahwa permintaan web yang masuk tidak terpengaruh di aplikasi ASP.NET Anda, tetapi permintaan WebClient baru, seperti berbicara dengan layanan web eksternal, adalah).

Dalam kasus saya, itu sebenarnya tidak diperlukan, jadi saya bisa menghapus pernyataan itu dan semua permintaan web saya yang lain mulai berfungsi dengan baik lagi. Berdasarkan bacaan saya di tempat lain, saya belajar beberapa hal:

• Ini adalah pengaturan global di appdomain Anda, dan jika Anda memiliki aktivitas bersamaan, Anda tidak dapat secara andal mengaturnya ke satu nilai, melakukan tindakan Anda, dan kemudian mengembalikannya. Tindakan lain mungkin terjadi selama jendela kecil itu dan terkena dampak.
• Pengaturan yang benar adalah membiarkannya default. Ini memungkinkan .NET untuk terus menggunakan apa pun yang merupakan nilai default paling aman seiring berjalannya waktu dan Anda memutakhirkan kerangka kerja. Mengaturnya ke TLS12 (yang paling aman pada penulisan ini) akan berfungsi sekarang tetapi dalam 5 tahun mungkin mulai menyebabkan masalah misterius.
• Jika Anda benar-benar perlu menetapkan nilai, Anda harus mempertimbangkan untuk melakukannya di aplikasi atau appdomain khusus yang terpisah dan menemukan cara untuk membicarakannya dengan kumpulan utama Anda. Karena ini adalah nilai global tunggal, mencoba mengelolanya dalam kumpulan aplikasi yang sibuk hanya akan menimbulkan masalah. Jawaban ini: https://stackoverflow.com/a/26754917/7656 menyediakan solusi yang memungkinkan melalui proxy khusus. (Catatan saya belum menerapkannya secara pribadi.)

Saya punya masalah ini karena web.config saya punya:

<httpRuntime targetFramework="4.5.2" />

dan tidak:

<httpRuntime targetFramework="4.6.1" />

Seperti yang Anda tahu ada banyak alasan ini mungkin terjadi. Kupikir aku akan menambahkan penyebab yang aku temui ...

Jika Anda mengatur nilai WebRequest.Timeoutke 0, ini adalah pengecualian yang dilemparkan. Di bawah ini adalah kode yang saya miliki ... (Kecuali alih-alih hard-kode 0untuk nilai batas waktu, saya memiliki parameter yang secara tidak sengaja diatur ke 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 ...

The jawaban atas sebagai mungkin akan cukup bagi kebanyakan orang. Namun, dalam beberapa keadaan, Anda bisa terus mendapatkan kesalahan "Tidak dapat membuat saluran aman SSL / TLS" bahkan setelah memaksa TLS 1.2. Jika demikian, Anda mungkin ingin berkonsultasi artikel bermanfaat iniuntuk langkah pemecahan masalah tambahan. Untuk meringkas: terlepas dari masalah versi TLS / SSL, klien dan server harus menyetujui "suite sandi." Selama fase "jabat tangan" dari koneksi SSL, klien akan mendaftar suite-cipher yang didukung untuk server untuk memeriksa daftar sendiri. Tetapi pada beberapa mesin Windows, cipher-suites umum tertentu mungkin telah dinonaktifkan (tampaknya karena upaya yang bermaksud baik untuk membatasi permukaan serangan), mengurangi kemungkinan klien & server menyetujui paket cipher. Jika mereka tidak setuju, maka Anda mungkin melihat "kode peringatan fatal 40" di penampil acara dan "Tidak dapat membuat saluran aman SSL / TLS" di program .NET Anda.

Artikel tersebut menjelaskan cara membuat daftar semua cipher suites yang berpotensi didukung mesin dan mengaktifkan suites suites tambahan melalui Windows Registry. Untuk membantu memeriksa suite sandi mana yang diaktifkan pada klien, coba kunjungi halaman diagnostik ini di MSIE. (Menggunakan pelacakan System.Net dapat memberikan hasil yang lebih pasti.) Untuk memeriksa cipher suites mana yang didukung oleh server, coba alat online ini (dengan asumsi server dapat diakses melalui internet). Seharusnya tanpa mengatakan bahwa suntingan Registry harus dilakukan dengan hati-hati , terutama di mana jaringan terlibat. (Apakah mesin Anda VM yang di-host dari jarak jauh? Jika Anda memutuskan jaringan, apakah VM akan dapat diakses sama sekali?)

Dalam kasus perusahaan saya, kami mengaktifkan beberapa suite "ECDHE_ECDSA" tambahan melalui penyuntingan Registri, untuk memperbaiki masalah langsung dan menjaga dari masalah di masa depan. Tetapi jika Anda tidak dapat (atau tidak mau) mengedit Registry, maka banyak solusi (tidak harus cantik) muncul di pikiran. Misalnya: program .NET Anda dapat mendelegasikan lalu lintas SSL ke program Python yang terpisah (yang mungkin dapat berfungsi dengan baik, karena alasan yang sama bahwa permintaan Chrome mungkin berhasil ketika permintaan MSIE gagal pada mesin yang terpengaruh).

Salah satu penyebab terbesar masalah ini adalah versi .NET Framework yang aktif. Versi runtime .NET framework memengaruhi protokol keamanan mana yang diaktifkan secara default.

Tampaknya tidak ada dokumentasi resmi tentang cara kerjanya secara khusus di versi yang berbeda, tetapi tampaknya default ditentukan lebih atau kurang sebagai berikut:

• .NET Framework 4.5 dan sebelumnya - SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - Default Sistem (OS)

(Untuk versi yang lebih lama, jarak tempuh Anda mungkin agak beragam berdasarkan pada mana .NET runtimes diinstal pada sistem. Misalnya, mungkin ada situasi di mana Anda menggunakan kerangka kerja yang sangat lama dan TLS 1.0 tidak didukung, atau menggunakan 4.6. x dan TLS 1.3 tidak didukung)

Dokumentasi Microsoft sangat menyarankan untuk menggunakan 4.7+ dan standar sistem:

Kami menyarankan Anda:

• Targetkan .NET Framework 4.7 atau versi yang lebih baru pada aplikasi Anda. Target .NET Framework 4.7.1 atau versi yang lebih baru pada aplikasi WCF Anda.
• Jangan menentukan versi TLS. Konfigurasikan kode Anda untuk membiarkan OS memutuskan versi TLS.
• Lakukan audit kode menyeluruh untuk memverifikasi Anda tidak menentukan versi TLS atau SSL.

Untuk situs ASP.NET , periksa versi .NET framework di <httpRuntime>elemen Anda , karena ini menentukan runtime mana yang sebenarnya digunakan oleh situs Anda:

<httpRuntime targetFramework="4.5" />

Lebih baik:

<httpRuntime targetFramework="4.7" />

Yang ini bekerja untuk saya di webclient MVC

    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;
        }
    }

Jika klien adalah mesin windows, kemungkinan alasannya adalah protokol tls atau ssl yang diperlukan oleh layanan tidak diaktifkan.

Ini dapat diatur dalam:

Panel Kontrol -> Jaringan dan Internet -> Opsi Internet -> Lanjutan

Gulir pengaturan ke bawah ke "Keamanan" dan pilih di antara

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

Dalam kasus saya, akun layanan yang menjalankan aplikasi tidak memiliki izin untuk mengakses kunci pribadi. Setelah saya memberikan izin ini, kesalahan hilang

1. mmc
2. sertifikat
3. Perluas ke pribadi
4. pilih sertifikat
5. klik kanan
6. Semua tugas
7. Kelola kunci pribadi
8. Menambahkan

Jika Anda menjalankan kode dari Visual Studio, coba jalankan Visual Studio sebagai administrator. Memperbaiki masalah untuk saya.

Saya telah berjuang dengan masalah ini sepanjang hari.

Ketika saya membuat proyek baru dengan .NET 4.5 akhirnya saya berhasil.

Tetapi jika saya turun ke 4.0 saya mendapatkan masalah yang sama lagi, dan itu tidak dapat dipulihkan untuk proyek itu (bahkan ketika saya mencoba untuk meningkatkan ke 4,5 lagi).

Aneh tidak ada pesan kesalahan lain tetapi "Permintaan dibatalkan: Tidak dapat membuat saluran aman SSL / TLS." muncul untuk kesalahan ini

System.Net.WebException: Permintaan dibatalkan: Tidak dapat membuat saluran aman SSL / TLS.

Dalam kasus kami, kami menggunakan vendor perangkat lunak sehingga kami tidak memiliki akses untuk mengubah kode .NET. Rupanya .NET 4 tidak akan menggunakan TLS v 1.2 kecuali jika ada perubahan.

Perbaikan untuk kami adalah menambahkan kunci SchUseStrongCrypto ke registri. Anda dapat menyalin / menempelkan kode di bawah ini ke file teks dengan ekstensi .reg dan jalankan. Ini berfungsi sebagai "tambalan" kami terhadap masalah.

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

Coba ini:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Ini diperbaiki untuk saya, tambahkan Layanan Jaringan ke izin. Klik kanan pada sertifikat> Semua Tugas> Kelola Kunci Pribadi ...> Tambah ...> Tambahkan "Layanan Jaringan".

Masalahnya bagi saya adalah bahwa saya mencoba untuk menggunakan IIS sebagai layanan web, saya menginstal sertifikat di server, tetapi pengguna yang menjalankan IIS tidak memiliki izin yang benar pada sertifikat.

Bagaimana cara memberi ASP.NET akses ke kunci pribadi dalam sertifikat di toko sertifikat?

Saya mengalami masalah yang sama dan menemukan jawaban ini berfungsi dengan baik untuk saya. Kuncinya adalah 3072. Tautan ini memberikan detail tentang perbaikan '3072'.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

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

Dalam kasus saya, dua umpan diperlukan perbaikan:

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

Pertanyaan ini dapat memiliki banyak jawaban karena ini tentang pesan kesalahan umum. Kami mengalami masalah ini pada beberapa server kami, tetapi tidak pada mesin pengembangan kami. Setelah mencabut sebagian besar rambut kami, kami menemukan itu adalah bug Microsoft.

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

Pada dasarnya, MS mengasumsikan Anda menginginkan enkripsi yang lebih lemah, tetapi OS ditambal untuk hanya mengizinkan TLS 1.2, jadi Anda menerima ketakutan "Permintaan dibatalkan: Tidak dapat membuat saluran aman SSL / TLS."

Ada tiga perbaikan.

1) Patch OS dengan pembaruan yang tepat: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Tambahkan pengaturan ke file app.config / web.config Anda.

3) Tambahkan pengaturan registri yang sudah disebutkan dalam jawaban lain.

Semua ini disebutkan dalam artikel basis pengetahuan yang saya posting.

Kemungkinan lain adalah bahwa kode yang dieksekusi tidak memiliki premis yang diperlukan.

Dalam kasus saya, saya mendapatkan kesalahan ini saat menggunakan debugger Visual Studio untuk menguji panggilan ke layanan web. Visual Studio tidak berjalan sebagai Administrator, yang menyebabkan pengecualian ini.

Ini terjadi pada saya di satu situs saja, dan ternyata hanya tersedia cipher RC4. Dalam upaya sebelumnya untuk mengeraskan server, saya telah menonaktifkan cipher RC4, setelah saya mengaktifkan kembali masalah ini terpecahkan.