Ayusin ang Error sa Pag-encrypt ng SQL Server - Isang Pag-click na Solusyon

Basahin ang Error - Ito ay Problema sa Pagtitiwala, Hindi Problema sa Network

Maayos ang iyong network at tumatakbo ang server. Nakarating ang koneksyon sa SQL Server, nag-alok ang server ng naka-encrypt na channel para sa pag-login, at tinanggihan ito ng iyong PC dahil ang sertipiko na nagpapatunay sa pagkakakilanlan ng server ay nilagdaan ng walang pinagkakatiwalaan ng iyong PC. Ang buong error na ipinapakita ng SSMS ay:

Bilang default, pinoprotektahan ng SQL Server ang pag-log in gamit ang isang self-signed certificate na nilikha nito mismo. Ang isang self-sign na certificate ay nag-e-encrypt ng trapiko, ngunit hindi nito mapapatunayan na ang server ay talagang iyong server, kaya tinatanggihan ito ng mga kliyente na humihiling ng na-verify na pag-encrypt. Ang bawat tapat na pag-aayos ay isa sa dalawang bagay: gawin ang kliyente na tanggapin ang partikular na server na ito nang may alam (Mga Hakbang 2 at 3), o bigyan ang server ng isang sertipiko na pinagkakatiwalaan ng mga kliyente sa kanilang sarili (Hakbang 4).

Ang Mabilis na Pag-aayos ng Kliyente sa SSMS - Sertipiko ng Trust Server

Ito ang mabilis na ruta na ipinakita sa video. Wala itong pagbabago sa server; sinasabi nito sa isang koneksyon na tanggapin ang sertipiko ng server nang hindi tinitingnan kung sino ang pumirma nito. Sa window ng SSMS Connect to Server, i-click ang Options para buksan ang mga karagdagang tab, pumunta sa tab na Connection Properties, itakda ang encryption sa Mandatory (o iwanan ito bilang inaalok), lagyan ng check ang Trust server certificate, at i-click ang Connect. Ang pag-login ay dumaan kaagad.

Ang Parehong Pag-aayos sa loob ng String ng Koneksyon ng App

Kung nabigo ang isang application sa halip na SSMS, nabubuhay ang parehong switch sa string ng koneksyon nito. Idagdag ang dalawang setting nang tahasan - Ino-on ng Encrypt=True ang protektadong channel, at ang TrustServerCertificate=True ay ang connection-string spelling ng SSMS checkbox:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Gamitin ang iyong sariling pangalan ng server, database at pag-login bilang kapalit ng mga halimbawang halaga. Ang trade-off ay eksaktong kapareho ng checkbox sa Hakbang 2, na may dagdag na panganib: inilagay sa configuration ng isang naipadalang application, ang nilaktawan na tseke ay nalalapat sa bawat user, nang hindi nakikita at permanente. Panatilihin ito sa mga configuration ng pag-develop at pagtatanghal, at sa produksyon ay ituring ito bilang hiram na oras hanggang sa mailagay ang certificate ng server sa Hakbang 4.

Ang Wastong Pag-aayos - Bigyan ang Server ng Tunay na Sertipiko

Nangyayari ang permanenteng pag-aayos nang isang beses, sa server, at pagkatapos ay mahigpit na kumokonekta ang bawat kliyente nang walang checkbox at walang babala. Kumuha muna ng certificate para sa buong DNS name ng server (halimbawa sql01.company.local) mula sa iyong internal na awtoridad sa certificate o isang pampublikong CA, na may Server Authentication na paggamit. I-import ito, kasama ang pribadong key nito, sa tindahan ng sertipiko ng Local Computer sa makina ng SQL Server. Pagkatapos ay i-right-click ang certificate, piliin ang Lahat ng Mga Gawain → Pamahalaan ang Mga Pribadong Key, at bigyan ng pahintulot ang SQL Server service account na Read sa pribadong key. Buksan ang SQL Server Configuration Manager, palawakin ang SQL Server Network Configuration, i-right-click ang Protocols for MSSQLSERVER, piliin ang Properties, at piliin ang certificate sa tab na Certificate. Sa tab na Mga Flags maaari mo ring itakda ang ForceEncryption sa Oo upang ang bawat kliyente ay kinakailangang mag-encrypt. I-restart ang serbisyo ng SQL Server - ang pagbabago ay walang magagawa hanggang sa gawin mo.

I-verify ang Ayusin ang Mahigpit na Paraan

Ang isang pag-login na tahimik na nagtagumpay ay nagpapatunay na mas mababa kaysa sa iniisip ng mga tao, dahil ang ilang mga kumbinasyon ng setting ay kumokonekta nang walang tunay na proteksyon. Patunayan ang parehong kalahati. Una, muling kumonekta mula sa isang kliyente sa mahigpit na paraan: kumonekta gamit ang pangalan ng DNS ng server - ang pangalan sa loob ng certificate - itakda ang encryption sa Mandatory at iwanan ang Trust server certificate na walang marka. Ang pag-login ay dapat magtagumpay nang walang babala. Pagkatapos, sa parehong session, tanungin ang server kung ang koneksyon ay aktwal na naka-encrypt sa pamamagitan ng pagpapatakbo ng query na ito sa SSMS:

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

Ang encrypt_option na nagpapakita ng TRUE ay ang passing grade. Ang FALSE na may gumaganang login ay nangangahulugan na ang koneksyon ay nagtagumpay sa pamamagitan ng pagbaba ng proteksyon, at ang trabaho ay hindi tapos. Ang pagpasa sa pagsubok na iyon ay ang tunay na linya ng pagtatapos: anumang wastong na-configure na kliyente, kabilang ang mga hinaharap na bersyon ng SSMS, ngayon ay kumokonekta nang may ganap na pagpapatunay at walang mga espesyal na setting.