SQL Server 암호화 오류 수정 - 원클릭 솔루션
SQL Server는 연결한 다음 서버의 인증서를 신뢰할 수 없기 때문에 로그인을 거부합니다. 이는 네트워크 문제가 아니며 데이터가 사라진 것이 아닙니다. 이는 신뢰 문제입니다. 비디오에 표시된 순서대로 수정 사항(빠른 클라이언트 측 옵션, 앱 연결 문자열 내부의 동일한 스위치, 서버 자체의 적절한 수정 사항)을 진행하세요.
📑챕터
- 로그인 오류 - "신뢰할 수 없는 기관에서 인증서 체인을 발급했습니다."
- 오류의 실제 의미 - 암호화가 필요하며 서버 인증서가 해당 신원을 증명할 수 없습니다.
- 빠른 클라이언트 수정 - SSMS 연결 창에서 서버 인증서 신뢰
- 애플리케이션 연결 문자열 내부의 동일한 수정
- 적절한 수정 - 클라이언트가 스스로 신뢰하는 실제 인증서를 서버에 제공
- 수정 사항 확인 - 엄격한 방식으로 다시 연결하고 암호화가 실제로 켜져 있음을 증명
📋 개요 및 단계별 가이드
오류 읽기 - 네트워크 문제가 아니라 신뢰 문제입니다.
네트워크 상태가 양호하고 서버가 실행 중입니다. 연결이 SQL Server에 도달했고 서버가 로그인을 위해 암호화된 채널을 제공했지만 서버의 ID를 증명하는 인증서에 PC가 신뢰하는 사람이 서명하지 않았기 때문에 PC가 이를 거부했습니다. SSMS가 표시하는 전체 오류는 다음과 같습니다.
기본적으로 SQL Server는 자체적으로 생성한 자체 서명된 인증서를 사용하여 로그인을 보호합니다. 자체 서명된 인증서는 트래픽을 암호화하지만 서버가 실제로 귀하의 서버임을 증명할 수 없으므로 검증된 암호화를 요구하는 클라이언트는 이를 거부합니다. 모든 정직한 수정은 두 가지 중 하나입니다. 즉, 클라이언트가 이 특정 서버를 고의로 수락하도록 하거나(2단계 및 3단계), 클라이언트가 스스로 신뢰하는 인증서를 서버에 제공합니다(4단계).
SSMS의 빠른 클라이언트 수정 - 신뢰 서버 인증서
영상에 나오는 빠른 경로입니다. 서버에서는 아무것도 변경되지 않습니다. 누가 서명했는지 확인하지 않고 서버의 인증서를 수락하도록 이 연결에 지시합니다. SSMS 서버에 연결 창에서 옵션을 클릭하여 추가 탭을 열고 연결 속성 탭으로 이동하여 암호화를 필수로 설정(또는 제안된 대로 유지)하고 서버 인증서 신뢰를 선택한 다음 연결을 클릭하세요. 바로 로그인이 진행됩니다.
앱 연결 문자열 내부의 동일한 수정 사항
SSMS 대신 애플리케이션이 실패하면 동일한 스위치가 해당 연결 문자열에 존재합니다. 두 설정을 명시적으로 추가합니다. Encrypt=True는 보호된 채널을 켜고 TrustServerCertificate=True는 SSMS 확인란의 연결 문자열 철자입니다.
Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;
예제 값 대신 자신의 서버 이름, 데이터베이스 및 로그인을 사용하십시오. 트레이드 오프는 2단계의 확인란과 정확히 동일하며 한 가지 추가 위험이 있습니다. 즉, 배송된 애플리케이션의 구성에 포함되어 건너뛴 검사가 모든 사용자에게 눈에 보이지 않게 영구적으로 적용됩니다. 개발 및 준비 구성에서는 이를 유지하고 프로덕션에서는 4단계의 서버 인증서가 마련될 때까지 대여 시간으로 처리합니다.
암호화가 설정되었습니다. 암호화를 언급하지 않은 연결 문자열은 자체 서명된 인증서가 유효성 검사를 통과할 수 없는 서버에 대해 암호화를 요구하기 시작했습니다. 데이터베이스에 대해서는 아무것도 변경되지 않았습니다. 문자열 내부의 계약이 그랬습니다. 설정을 명시적으로 작성한다는 것은 다음 드라이버 업데이트가 뒤에서 앱의 동작을 변경할 수 없다는 것을 의미합니다.적절한 수정 - 서버에 실제 인증서 제공
영구 복구는 서버에서 한 번 발생하며 이후 모든 클라이언트는 확인란이나 경고 없이 엄격하게 연결됩니다. 먼저 서버 인증을 사용하여 내부 인증 기관이나 공용 CA로부터 서버의 전체 DNS 이름(예: sql01.company.local)에 대한 인증서를 받으세요. 개인 키와 함께 이를 SQL Server 시스템의 로컬 컴퓨터 인증서 저장소로 가져옵니다. 그런 다음 인증서를 마우스 오른쪽 버튼으로 클릭하고 모든 작업 → 개인 키 관리를 선택한 다음 SQL Server 서비스 계정에 개인 키에 대한 읽기 권한을 부여합니다. SQL Server 구성 관리자를 열고 SQL Server 네트워크 구성을 확장한 다음 MSSQLSERVER용 프로토콜을 마우스 오른쪽 버튼으로 클릭하고 속성을 선택한 다음 인증서 탭에서 인증서를 선택하세요. 플래그 탭에서 ForceEncryption을 예로 설정하여 모든 클라이언트가 암호화하도록 할 수도 있습니다. SQL Server 서비스를 다시 시작합니다. 변경할 때까지는 변경 사항이 적용되지 않습니다.
엄격한 방법으로 수정 확인
일부 설정 조합은 실제 보호 없이 연결되기 때문에 조용히 성공한 로그인은 사람들이 생각하는 것보다 적습니다. 두 반쪽을 모두 증명하십시오. 먼저 엄격한 방법으로 클라이언트에서 다시 연결합니다. 서버의 DNS 이름(인증서 내부 이름)을 사용하여 연결하고 암호화를 필수로 설정하고 신뢰할 수 있는 서버 인증서를 선택 해제된 상태로 둡니다. 경고 없이 로그인이 성공해야 합니다. 그런 다음 동일한 세션에서 SSMS에서 다음 쿼리를 실행하여 연결이 실제로 암호화되었는지 서버에 물어보세요.
SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;
TRUE를 나타내는 encrypt_option은 합격 점수입니다. 작동 중인 로그인의 FALSE는 보호를 삭제하여 연결이 성공했으며 작업이 완료되지 않았음을 의미합니다. 통과한 테스트가 실제 결승선입니다. 향후 SSMS 버전을 포함하여 올바르게 구성된 모든 클라이언트는 이제 특별한 설정 없이 전체 검증을 통해 연결됩니다.
🏷️주제 검색 변수 및 키워드
🎙️ 전체 대본 — 탭하여 펼치기
__TOK_24__
__TOK_25__
__TOK_26__
❓ 자주 묻는 질문
이 튜토리얼은 100% 무료로 따라할 수 있나요?
__TOK_27__
초보자도 이 가이드를 따라갈 수 있나요?
__TOK_28__
막힐 경우 어디에 질문을 할 수 있나요?
__TOK_29__