이 글의 목적은 원격 데스크톱(RDP) 연결 시 발생하는 “An authentication error has occurred. The function requested is not supported. This could be due to CredSSP encryption oracle remediation.” 오류의 근본 원인을 정리하고, Windows 10·11 및 Windows Server 환경에서 안전하게 문제를 해결하는 실무 절차를 단계별로 제시하는 것이다.
1. CredSSP 암호화 오라클 오류 개요
원격 데스크톱 연결 시 다음과 같은 메시지가 나타나면서 접속이 차단되는 경우가 많다.
An authentication error has occurred. The function requested is not supported. This could be due to CredSSP encryption oracle remediation. 이 오류는 단순 “RDP 접속 불가” 현상이 아니라, CredSSP(Credential Security Support Provider) 프로토콜의 취약점(CVE-2018-0886)에 대한 보안 업데이트가 적용된 이후, 클라이언트와 서버의 보안 수준이 맞지 않을 때 발생하는 현상이다.
핵심은 클라이언트와 서버가 서로 다른 CredSSP 보안 수준(Encryption Oracle Remediation 정책)을 기대하고 있을 때 RDP 세션이 차단된다는 점이다. 예를 들어, 클라이언트는 최신 보안 업데이트가 적용되어 높은 보안 수준을 요구하지만, 서버는 구버전 상태로 낮은 보안 수준만 지원하면 양측이 협상을 못 하고 위 오류가 발생한다.
2. 해결 전략 요약
이 오류를 해결하는 기본 전략은 다음 네 단계로 정리할 수 있다.
- 클라이언트와 서버 모두 최신 보안 업데이트 적용
가장 안전하고 권장되는 방법이다. OS별 최신 누적 업데이트를 설치하면 대부분의 CredSSP 호환성 문제는 자동으로 해소된다. - Encryption Oracle Remediation 정책 확인 및 조정
그룹 정책(GPEDIT) 또는 로컬 보안 정책(SECPOL), 도메인 GPO에서 클라이언트·서버 각각의 CredSSP 정책이 어떤 값으로 설정되어 있는지 확인하고, 호환되도록 조정한다. - 불가피할 때만 임시로 보안 수준 완화
서버에 접속해 업데이트를 적용해야 하는데 다른 수단이 전혀 없을 경우, 클라이언트 측 정책만 한시적으로 완화(Vulnerable)해서 접속한 뒤 즉시 서버를 업데이트하고 다시 원래 수준으로 되돌린다. - Home 에디션 등에서 레지스트리로 수동 설정
gpedit.msc가 없는 Windows Home 버전 등에서는 레지스트리의 AllowEncryptionOracle 값을 직접 수정해 동일한 효과를 낼 수 있다.
주의 : 보안 수준을 완화(Vulnerable)하는 방법은 어디까지나 “임시 우회” 용도이다. 서버를 패치하고 문제가 해결되면 반드시 다시 안전한 수준으로 되돌려야 한다.
3. 사전 점검: 업데이트 및 버전 확인
3-1. 클라이언트·서버 Windows 업데이트 적용
먼저 클라이언트 PC와 원격 서버 OS에 최신 업데이트가 설치되어 있는지 확인한다. CredSSP 취약점 패치는 2018년 이후 각 OS의 누적 업데이트에 포함되어 배포되었으며, 현재 지원 중인 Windows 10·11, 최신 Windows Server는 모두 해당 패치를 포함하고 있다.
- Windows 10·11 설정 → Windows 업데이트 → 업데이트 확인 → 가능한 모든 중요한·권장 업데이트 설치 후 재부팅한다.
- Windows Server (2012 R2, 2016, 2019, 2022 등) 서버 관리자 또는 Windows Update(또는 WSUS, SCCM 등 중앙 관리 시스템)를 통해 최신 누적 업데이트를 적용한다.
업데이트 후에도 같은 오류가 발생한다면, 정책 값이 충돌하고 있을 가능성이 높으므로 다음 단계에서 정책 설정을 확인해야 한다.
3-2. CredSSP 관련 파일 버전 확인(심화)
정밀 진단이 필요하다면 다음과 같이 CredSSP 관련 DLL 버전을 확인할 수도 있다.
탐색기에서 C:\Windows\System32\TSpkg.dll 파일의 속성 → 자세히 → 파일 버전 확인 기업 환경에서는 마이크로소프트 권장 버전 이상인지, 취약한 버전이 남아있지 않은지 패치 관리 시스템에서 일괄 확인하는 것이 좋다.
4. 그룹 정책으로 Encryption Oracle Remediation 설정 변경
Windows Pro·Enterprise·Education 및 대부분의 Windows Server 에디션에서는 로컬 그룹 정책 편집기(gpedit.msc)를 이용해 CredSSP 보안 수준을 제어할 수 있다.
4-1. gpedit.msc에서 정책 위치
- Win + R →
gpedit.msc입력 후 엔터 - 다음 경로로 이동한다.
컴퓨터 구성 └ 관리 템플릿 └ 시스템 └ 자격 증명 위임 └ 암호화 오라클 수정 (Encryption Oracle Remediation) - 암호화 오라클 수정 정책을 더블클릭하여 설정을 변경한다.
4-2. Encryption Oracle Remediation 보호 수준
해당 정책을 사용(Enabled)으로 설정하면 아래 세 가지 보호 수준 중 하나를 선택할 수 있다. 이 값은 내부적으로 레지스트리의 AllowEncryptionOracle 값과 매핑된다.
| 보호 수준(Policy) | 레지스트리 값(AllowEncryptionOracle) | 설명 | 권장 사용 상황 |
|---|---|---|---|
| Force Updated Clients | 0 | 최신 CredSSP 업데이트가 적용된 클라이언트만 허용한다. 구버전 클라이언트는 RDP 연결이 차단된다. | 조직 내 모든 PC·서버가 최신 업데이트를 적용한 안정적인 환경 |
| Mitigated | 1 | 업데이트된 클라이언트와 서버만 연결하도록 요구하되, 일부 호환성 시나리오를 허용하는 완화 모드이다. | 점진적으로 패치 적용 중인 과도기 환경 |
| Vulnerable | 2 | 구버전 CredSSP를 사용하는 클라이언트·서버 간 연결도 허용한다. 보안상 취약하다. | 서버를 당장 패치할 수 없고, RDP로만 접속 가능한 긴급 상황에서 한시적 사용 |
주의 : Force Updated Clients/ Mitigated는 비교적 안전하지만, Vulnerable 값은 중간자 공격 등 원격 코드 실행 공격에 노출될 수 있다. 오직 서버 패치를 완료하기 위한 “임시 우회용”으로만 사용해야 한다.
4-3. 오류 재현 시 대표적인 조합
- 클라이언트: 업데이트 적용 + 정책 Force Updated Clients (0)
서버: 업데이트 미적용 또는 취약한 CredSSP 버전
⇒ 클라이언트가 서버를 신뢰하지 못해 RDP 연결이 차단되고, 암호화 오라클 수정 오류가 표시된다. - 서버: 업데이트 적용 + 정책 Force Updated Clients (0)
클라이언트: 업데이트 미적용
⇒ 서버가 구버전 클라이언트의 접속을 거부하면서 동일한 유형의 인증 오류가 발생한다.
4-4. 실무 권장 정책 설정
- 가능한 경우 클라이언트와 서버 모두 최신 업데이트 적용 후, Force Updated Clients 또는 최소한 Mitigated 수준으로 유지한다.
- 서버를 아직 패치하지 못했지만, 접속해서 패치를 진행해야 할 때
- 클라이언트의 Encryption Oracle Remediation 정책을 Enabled + Vulnerable로 설정한다.
- 서버에 접속해 업데이트 및 재부팅을 완료한다.
- 작업 완료 후 즉시 클라이언트 정책을 원래 수준(Force Updated Clients 또는 Mitigated)으로 복원한다.
5. 로컬 보안 정책(secpol.msc) 활용
서버 OS에서는 로컬 보안 정책 편집기(secpol.msc)로도 유사한 설정을 확인하는 경우가 있다. 다만 CredSSP 자체는 주로 그룹 정책 템플릿에서 제어하므로, 도메인 환경에서는 도메인 GPO 우선으로 관리하는 것이 바람직하다.
- Win + R →
secpol.msc실행 - 보안 설정, 로컬 정책, 사용자 권한 할당, 보안 옵션 등을 검토해, 도메인에서 내려오는 GPO와 충돌하는 설정이 없는지 확인한다.
실제 CredSSP Encryption Oracle Remediation 값 자체는 레지스트리와 그룹 정책에서 관리되므로, secpol.msc는 주로 다른 보안 정책과의 충돌 여부를 확인하는 용도로 활용하는 것이 효율적이다.
6. Windows Home 버전: 레지스트리로 AllowEncryptionOracle 설정
Windows Home 에디션에는 gpedit.msc가 포함되어 있지 않다. 이 경우 레지스트리를 직접 수정해 동일한 효과를 얻을 수 있다.
6-1. 레지스트리 편집기에서 수동 수정
- Win + R →
regedit입력 → 엔터 - 다음 경로로 이동한다.
HKEY_LOCAL_MACHINE └ SOFTWARE └ Microsoft └ Windows └ CurrentVersion └ Policies └ System └ CredSSP └ Parameters - Parameters 키가 없다면 새 키로 생성한다.
- 오른쪽 빈 공간에서 마우스 우클릭 → 새로 만들기 → DWORD(32비트) 값 선택 → 이름을
AllowEncryptionOracle로 지정한다. - 해당 값을 더블클릭하여 원하는 값을 설정한다.
- 0 = Force Updated Clients
- 1 = Mitigated
- 2 = Vulnerable
- 값을 변경한 뒤 PC를 재부팅한다.
주의 : 레지스트리 편집은 오타나 잘못된 편집 시 시스템 부팅에 문제가 생길 수 있다. 반드시 레지스트리 백업 또는 시스템 복원 지점을 만들어 둔 후 수정하는 것이 안전하다.
6-2. 명령줄로 한 번에 설정(추천)
관리자 권한 명령 프롬프트 또는 Windows 터미널에서 다음 명령으로 값을 바로 추가·수정할 수 있다.
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters ^ /v AllowEncryptionOracle /t REG_DWORD /d 2 /f 위 예시는 값을 2(Vulnerable)로 설정하여 구버전 서버에 대한 접속을 허용하는 예이다. 서버 업데이트를 완료했다면, 동일 명령에서 /d 값을 0 또는 1로 바꿔 다시 실행하여 보안 수준을 강화해야 한다.
6-3. PowerShell을 이용한 설정
New-Item -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP" -Force | Out-Null New-Item -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" `
-Name "AllowEncryptionOracle" -Value 2 -Type DWord
이 역시 마찬가지로 값 2는 임시 우회용이며, 서버가 패치된 이후에는 더 이상 사용하지 않는 것이 좋다.
7. 원격 서버를 직접 만질 수 없을 때의 현실적인 절차
실제 현장에서는 원격 서버가 IDC, 클라우드(Azure, AWS, 기타 호스팅사) 등에 있고, RDP 외에는 별도의 관리 채널이 없는 경우가 많다. 이때는 다음과 같은 단계로 접근하는 것이 실무적이다.
- 클라이언트 백업 및 보안 점검
해당 PC에 최신 백신, EDR 등이 정상 동작하는지 확인하고, 중요 데이터는 미리 백업해 둔다. - 클라이언트의 Encryption Oracle Remediation를 임시로 Vulnerable(2)로 변경
gpedit 또는 레지스트리로 설정 변경 후 재부팅한다. - 서버에 RDP 접속
접속이 허용되면 즉시 서버 OS 업데이트, 재부팅을 수행한다. 가능하다면 원격 콘솔, 클라우드 관리 포털을 통해도 상태를 확인한다. - 서버 업데이트 완료 확인
서버 Windows 업데이트 이력과 빌드 번호를 확인해 최신 상태인지 점검한다. - 클라이언트 보안 수준 복원
AllowEncryptionOracle 값을 0 또는 1로 돌리거나, 정책을 Force Updated Clients 또는 Mitigated로 조정한 뒤 재부팅한다. - 마지막으로 RDP 재접속 테스트
이제는 보안 완화 없이도 오류 없이 접속되는지 확인한다.
8. 같은 오류 메시지를 유발할 수 있는 다른 원인
CredSSP 암호화 오라클 수정 오류 문구가 포함되어 있더라도, 실제 원인은 다른 요소일 수 있다. 실무에서는 다음 항목도 함께 확인하는 것이 좋다.
- 사용자 암호 만료 일부 환경에서는 암호가 만료되었는데 정책상 RDP에서 암호 변경을 허용하지 않아, 유사한 인증 오류로 보일 수 있다. 도메인 환경이라면 로컬 로그인 또는 VPN 후 암호를 변경한 뒤 다시 접속해 본다.
- NLA(Network Level Authentication) 문제 NLA를 강제했는데, 클라이언트가 필요한 프로토콜 또는 인증 구성을 지원하지 못할 때 유사한 오류가 발생한다. 테스트 목적이라면 서버 시스템 속성 → 원격 탭에서 일시적으로 NLA 요구를 해제 후 재시도할 수 있다. 단, 외부 네트워크에 직접 노출된 서버에서 NLA를 끄는 것은 위험하다.
- 방화벽·중간 보안 장비 IDS/IPS, SSL Inspection 장비, RDP 게이트웨이 어플라이언스 등 중간 장비가 트래픽을 변조할 경우, CredSSP 협상이 실패해서 오류가 뜰 수 있다.
- 서드파티 RDP 클라이언트 오래된 서드파티 RDP 클라이언트는 최신 CredSSP를 지원하지 않을 수 있다. 이 경우 최신 버전으로 업그레이드하거나 Windows 기본 mstsc.exe를 사용하는 것이 좋다.
9. 보안 측면 모범 사례
CredSSP 암호화 오라클 오류를 단순히 “불편한 오류”로만 보지 말고, 조직의 RDP 보안 수준을 점검하는 계기로 활용하는 것이 좋다.
- 정기적인 패치 관리 클라이언트·서버 OS, RDP 게이트웨이, 관련 보안 솔루션에 대해 월간 패치 윈도우를 운영하고, 테스트 환경에서 사전 검증 후 운영 환경에 배포한다.
- Vulnerable 모드 상시 사용 금지 Encryption Oracle Remediation를 항상 Vulnerable로 두면 공격자에게 불필요한 공격 표면을 제공하는 것과 같다. 임시 조치 후에는 반드시 원복한다.
- RDP 접근 최소화 VPN, 점프 서버, 프라이빗 네트워크를 통해서만 RDP 포트(기본 3389)에 접근하도록 설계하고, 인터넷에 직접 노출된 RDP는 피하는 것이 원칙이다.
- 다단계 인증(MFA) 도입 가능하면 RDP 게이트웨이나 VPN에 MFA를 도입해 계정 탈취 시도에 대비한다.
- 로그·감사 활성화 이벤트 뷰어의 보안 로그, 터미널 서비스 관련 로그, IDS/IPS 로그 등에서 RDP 인증 실패 패턴을 모니터링해 이상 징후를 조기에 찾는다.
10. 현장에서 바로 쓰는 점검 체크리스트
| 순서 | 점검 항목 | 위치/도구 | 내용 | 완료(✔) |
|---|---|---|---|---|
| 1 | 클라이언트 OS 업데이트 | 설정 → Windows 업데이트 | 최신 누적 업데이트 설치 및 재부팅 | |
| 2 | 서버 OS 업데이트 | 서버 관리자 / Windows Update / 클라우드 포털 | 해당 서버에 최신 보안·누적 업데이트 적용 | |
| 3 | 클라이언트 Encryption Oracle 정책 확인 | gpedit.msc 또는 레지스트리 | Force Updated Clients 또는 Mitigated 사용 여부 확인 | |
| 4 | 서버 측 정책 확인 | 도메인 GPO / 로컬 GPO | 서버가 구버전 클라이언트를 허용해야 하는지 검토 후 정책 조정 | |
| 5 | 불가피할 때 한시적 Vulnerable 설정 | gpedit.msc 또는 레지스트리 | 서버 패치 작업을 위해 일시적으로 완화 후 작업 완료 즉시 복원 | |
| 6 | 암호 만료·계정 잠김 여부 확인 | 도메인 컨트롤러 / 로컬 사용자 관리 | 사용자 암호·계정 상태 문제를 먼저 배제 | |
| 7 | NLA 설정 확인 | 시스템 속성 → 원격 | 테스트 목적 외에는 NLA 비활성화를 지양 | |
| 8 | 최종 RDP 접속 테스트 | mstsc.exe 또는 RDP 클라이언트 | 오류 메시지 없이 정상 연결 확인 |
FAQ
Q1. Windows 11에서도 CredSSP 암호화 오라클 수정 오류가 발생하는가?
발생할 수 있다. CredSSP 취약점 자체는 과거 이슈이지만, 여전히 클라이언트·서버 간 보안 수준이 맞지 않을 경우 Windows 11에서도 동일한 오류 메시지가 나타날 수 있다. 특히 Windows 11 클라이언트가 최신 업데이트로 높은 보안 수준을 요구하고, 구버전 Windows Server가 패치되지 않은 상태라면 오류가 발생한다.
Q2. Encryption Oracle Remediation를 항상 Vulnerable로 두면 안 되는가?
안 된다. Vulnerable 값은 구버전 CredSSP 구현을 그대로 허용하기 때문에, 원격 코드 실행·중간자 공격 위험이 높다. 운영 환경에서 상시 사용하면 보안 사고 발생 시 책임 소지가 될 수 있으며, 마이크로소프트도 권장하지 않는다. 반드시 임시 우회 용도로만 사용하고, 서버 패치가 끝나는 즉시 보안 수준을 강화해야 한다.
Q3. 도메인 환경에서 로컬 gpedit 설정이 적용되지 않는다.
도메인에 가입된 PC·서버는 도메인 GPO가 로컬 GPO보다 우선한다. 도메인 컨트롤러에서 그룹 정책 관리 콘솔(GPMC)을 열어, 도메인 또는 OU에 링크된 GPO에 Encryption Oracle Remediation 설정이 있는지 확인하고, 필요 시 해당 GPO를 수정해야 한다. 로컬 gpedit에서 값을 바꿔도 도메인 GPO가 덮어쓰면 실제 동작은 도메인 GPO 설정을 따른다.
Q4. 클라우드(예: Azure VM)에서 이 오류가 발생할 때도 동일하게 해결하면 되는가?
원리는 동일하다. 다만 클라우드 공급사의 관리 포털에서 제공하는 콘솔 연결, 복구 모드, 스냅샷 등을 활용해 서버 OS를 업데이트하거나, 필요 시 이미지를 교체하는 방안도 고려할 수 있다. 기본적으로는 클라이언트·서버 모두 최신 패치 적용 후 Encryption Oracle Remediation 정책을 안전한 수준으로 유지하는 것이 해결책이다.
Q5. RDP 대신 다른 프로토콜로 우회하는 것이 더 안전한가?
RDP 자체는 적절한 패치와 보안 설정, 네트워크 설계가 이루어진다면 충분히 안전하게 운영할 수 있다. 다만 직접 인터넷에 노출된 RDP 포트 사용은 가급적 피하고, VPN이나 게이트웨이, 점프 서버를 통해 내부에서만 사용하도록 설계하는 것이 좋다. 프로토콜을 바꾸기보다는, 패치·정책·네트워크 아키텍처를 보안 관점에서 재점검하는 것이 우선이다.