แก้ไขข้อผิดพลาดการเข้ารหัสเซิร์ฟเวอร์ SQL - โซลูชันเพียงคลิกเดียว

อ่านข้อผิดพลาด - มันเป็นปัญหาความน่าเชื่อถือ ไม่ใช่ปัญหาเครือข่าย

เครือข่ายของคุณใช้งานได้ปกติ และเซิร์ฟเวอร์กำลังทำงานอยู่ การเชื่อมต่อไปถึง SQL Server เซิร์ฟเวอร์เสนอช่องทางที่เข้ารหัสสำหรับการเข้าสู่ระบบ และพีซีของคุณปฏิเสธเนื่องจากใบรับรองที่พิสูจน์ตัวตนของเซิร์ฟเวอร์นั้นลงนามโดยไม่มีใครที่พีซีของคุณเชื่อถือ SSMS ข้อผิดพลาดแบบเต็มแสดงคือ:

ตามค่าเริ่มต้น SQL Server จะป้องกันการเข้าสู่ระบบด้วยใบรับรองที่ลงนามด้วยตนเองที่เซิร์ฟเวอร์สร้างขึ้นเอง ใบรับรองที่ลงนามด้วยตนเองจะเข้ารหัสการรับส่งข้อมูล แต่ไม่สามารถพิสูจน์ได้ว่าเซิร์ฟเวอร์คือเซิร์ฟเวอร์ของคุณจริงๆ ดังนั้นไคลเอนต์ที่ต้องการการเข้ารหัสที่ตรวจสอบแล้วจึงปฏิเสธใบรับรองนั้น การแก้ไขอย่างตรงไปตรงมาทุกครั้งคือหนึ่งในสองสิ่ง: ทำให้ไคลเอ็นต์ยอมรับเซิร์ฟเวอร์นี้โดยเจตนา (ขั้นตอนที่ 2 และ 3) หรือมอบใบรับรองที่ไคลเอ็นต์เชื่อถือด้วยตนเอง (ขั้นตอนที่ 4)

Quick Client Fix ใน SSMS - ใบรับรองเซิร์ฟเวอร์ที่เชื่อถือได้

นี่คือเส้นทางด่วนที่แสดงในวิดีโอ มันไม่เปลี่ยนแปลงอะไรเลยบนเซิร์ฟเวอร์ มันบอกให้การเชื่อมต่อนี้ยอมรับใบรับรองของเซิร์ฟเวอร์โดยไม่ตรวจสอบว่าใครเป็นผู้ลงนาม ในหน้าต่าง SSMS เชื่อมต่อกับเซิร์ฟเวอร์ คลิก ตัวเลือก เพื่อเปิดแท็บพิเศษ ไปที่แท็บ คุณสมบัติการเชื่อมต่อ ตั้งค่าการเข้ารหัสเป็น บังคับ (หรือปล่อยไว้ตามที่เสนอ) ทำเครื่องหมาย เชื่อถือใบรับรองเซิร์ฟเวอร์ และคลิก เชื่อมต่อ การเข้าสู่ระบบจะต้องผ่านทันที

การแก้ไขเดียวกันภายในสตริงการเชื่อมต่อแอป

หากแอปพลิเคชันล้มเหลวแทนที่จะเป็น SSMS สวิตช์เดียวกันนั้นจะอยู่ในสตริงการเชื่อมต่อ เพิ่มการตั้งค่าทั้งสองอย่างชัดเจน - Encrypt=True เปิดช่องทางที่ได้รับการป้องกัน และ TrustServerCertificate=True เป็นการสะกดสตริงการเชื่อมต่อของช่องทำเครื่องหมาย SSMS:

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

ใช้ชื่อเซิร์ฟเวอร์ ฐานข้อมูล และการเข้าสู่ระบบของคุณเองแทนค่าตัวอย่าง ข้อเสียเปรียบจะเหมือนกับช่องทำเครื่องหมายในขั้นตอนที่ 2 ทุกประการ โดยมีอันตรายเพิ่มเติมประการหนึ่ง นั่นคือ เมื่อรวมเข้ากับการกำหนดค่าของแอปพลิเคชันที่จัดส่ง เช็คที่ข้ามไปจะมีผลกับผู้ใช้ทุกคน โดยมองไม่เห็นและถาวร เก็บไว้ในการกำหนดค่าการพัฒนาและการจัดเตรียม และในการใช้งานจริงถือเป็นเวลาที่ยืมมาจนกว่าจะมีใบรับรองเซิร์ฟเวอร์ในขั้นตอนที่ 4

การแก้ไขที่เหมาะสม - มอบใบรับรองจริงแก่เซิร์ฟเวอร์

การซ่อมแซมแบบถาวรจะเกิดขึ้นเพียงครั้งเดียวบนเซิร์ฟเวอร์ และหลังจากนั้นไคลเอ็นต์ทุกเครื่องจะเชื่อมต่ออย่างเคร่งครัดโดยไม่มีช่องทำเครื่องหมายและไม่มีคำเตือน ขั้นแรก ให้รับใบรับรองสำหรับชื่อ DNS แบบเต็มของเซิร์ฟเวอร์ (เช่น sql01.company.local) จากผู้ออกใบรับรองภายในของคุณหรือ CA สาธารณะ พร้อมการใช้งาน การตรวจสอบสิทธิ์เซิร์ฟเวอร์ นำเข้าพร้อมคีย์ส่วนตัวไปยังที่เก็บใบรับรอง Local Computer บนเครื่อง SQL Server จากนั้นคลิกขวาที่ใบรับรอง เลือก งานทั้งหมด → จัดการคีย์ส่วนตัว และให้สิทธิ์ อ่าน แก่บัญชีบริการ SQL Server บนคีย์ส่วนตัว เปิด SQL Server Configuration Manager ขยาย SQL Server Network Configuration คลิกขวาที่ Protocols for MSSQLSERVER เลือก Properties และเลือกใบรับรองบนแท็บ Certificate บนแท็บ ธง คุณยังสามารถตั้งค่า ForceEncryption เป็น ใช่ เพื่อให้ไคลเอ็นต์ทุกเครื่องจำเป็นต้องเข้ารหัส เริ่มบริการ SQL Server ใหม่ - การเปลี่ยนแปลงจะไม่ทำอะไรเลยจนกว่าคุณจะดำเนินการ

ตรวจสอบการแก้ไขด้วยวิธีที่เข้มงวด

การเข้าสู่ระบบที่ประสบความสำเร็จอย่างเงียบๆ พิสูจน์ได้น้อยกว่าที่ผู้คนคิด เนื่องจากชุดค่าผสมการตั้งค่าบางอย่างเชื่อมต่อกันโดยไม่มีการป้องกันที่แท้จริง พิสูจน์ทั้งสองครึ่ง ขั้นแรก เชื่อมต่อใหม่จากไคลเอ็นต์ด้วยวิธีที่เข้มงวด: เชื่อมต่อโดยใช้ชื่อ DNS ของเซิร์ฟเวอร์ - ชื่อภายในใบรับรอง - ตั้งค่าการเข้ารหัสเป็นบังคับ และปล่อย ใบรับรองเซิร์ฟเวอร์ที่เชื่อถือได้ ไว้โดยไม่เลือก การเข้าสู่ระบบควรสำเร็จโดยไม่มีคำเตือน จากนั้น ในเซสชันเดียวกันนั้น ให้ถามเซิร์ฟเวอร์ว่าการเชื่อมต่อได้รับการเข้ารหัสจริงหรือไม่โดยการเรียกใช้แบบสอบถามนี้ใน SSMS:

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

encrypt_option ที่แสดง TRUE คือเกรดที่ผ่าน FALSE ด้วยการเข้าสู่ระบบที่ใช้งานได้หมายความว่าการเชื่อมต่อสำเร็จโดยการลดการป้องกัน และงานยังไม่เสร็จสิ้น การทดสอบที่ผ่านนั้นคือเส้นชัยที่แท้จริง ไคลเอนต์ที่กำหนดค่าอย่างถูกต้อง รวมถึงเวอร์ชัน SSMS ในอนาคต ตอนนี้เชื่อมต่อกับการตรวจสอบความถูกต้องเต็มรูปแบบและไม่มีการตั้งค่าพิเศษ