이 글의 목적은 IKEv2 VPN 연결 시 발생하는 인증서 신뢰 실패, certificate not trusted 오류의 원인과 해결 절차를 체계적으로 정리하여 Windows, iOS, Android, macOS 환경에서 실무자가 재현 가능한 방식으로 문제를 진단하고 복구할 수 있도록 돕는 것이다.
1. IKEv2 VPN과 인증서 신뢰 구조 이해
IKEv2 VPN은 IPsec 터널의 인증 단계에서 X.509 인증서를 사용하여 서버와 클라이언트의 신원을 검증한다. 이때 운영체제는 인증서 체인과 신뢰할 수 있는 루트 인증기관(CA) 목록을 기반으로 인증서의 유효성을 판단한다. 루트 CA 또는 중간 CA가 클라이언트 시스템에서 신뢰되지 않거나, 서버 인증서 자체에 문제가 있으면 certificate validation failure, certificate not trusted 오류가 발생한다.
1-1. 서버·클라이언트·루트 인증서 관계
클라이언트 ── 인증서 체인 검증 ──> 서버 인증서 ▲ │ (서명 검증) 중간 CA 인증서 (선택적) ▲ │ 루트 CA 인증서 (신뢰 anchor) 일반적인 IKEv2 VPN 구성에서는 다음 세 가지 종류의 인증서가 사용된다.
- 루트 CA 인증서: 자체 서명(self-signed)된 최상위 인증서로, 클라이언트 OS의 Trusted Root Certification Authorities 저장소에 있어야 한다.
- 중간 CA 인증서: 루트 CA와 서버 인증서 사이에 위치하는 중간 서명 체인이다.
- 서버 인증서: VPN 게이트웨이(방화벽, 라우터, Windows RRAS 등)에 설치되는 인증서로, 클라이언트가 접속하는 FQDN(예: vpn.example.com)에 대해 발급되어야 한다.
클라이언트 인증서 기반 IKEv2를 구성한 경우에는 사용자의 PC·모바일에 클라이언트 인증서와 해당 키를 발급·설치하고, 서버에서 이를 검증한다. 구성에 따라 사용자 인증(EAP) 또는 머신 인증(컴퓨터 인증서)을 사용할 수 있다.
1-2. IKEv2에서 중요하게 보는 인증서 속성
- Subject / Subject Alternative Name(SAN): VPN 접속 시 사용하는 FQDN과 일치해야 한다.
- Key Usage: 디지털 서명(Digital Signature) 등 필요한 용도가 포함되어야 한다.
- Extended Key Usage(EKU):
- 서버 인증서: Server Authentication (1.3.6.1.5.5.7.3.1)
- 클라이언트 인증서: Client Authentication (1.3.6.1.5.5.7.3.2)
- Validity(유효기간): Not Before, Not After 범위 내에 있어야 한다.
- 서명 알고리즘(Signature Algorithm): OS가 지원하는 알고리즘(SHA-256 with RSA 등)을 사용해야 한다. 오래된 Windows 버전은 특정 ECDSA 조합에서 오류 13806을 발생시킨 사례가 있다.
2. 자주 발생하는 IKEv2 인증서 신뢰 실패 유형
다음 표는 실무에서 자주 보고되는 IKEv2 VPN 인증서 관련 오류 패턴을 정리한 것이다.
| 증상 / 메시지 | 환경 | 주요 원인 | 대응 방향 |
|---|---|---|---|
| "The certificate is not trusted" "The certificate has expired" | Windows 기본 VPN, 기타 VPN 클라이언트 | 루트·중간 CA 누락, 시스템 시간 불일치, 만료된 인증서 | 루트/중간 CA 설치, 시간 동기화, 서버 인증서 재발급 |
| 서버 인증서 이름 불일치 오류 "certificate name mismatch" | Windows, iOS, Android 공통 | VPN 접속 주소가 인증서 CN/SAN과 불일치(IP로 접속, 다른 FQDN 사용) | 인증서 SAN에 올바른 FQDN 포함, 접속 주소를 FQDN으로 통일 |
| 오류 코드 13806 "IKE failed to find valid machine certificate" | Windows 10/11, 서버는 IPsec 게이트웨이 | 머신 인증용 인증서 없음 또는 EKU/스토어 위치 불일치, 일부 버전의 ECDSA 관련 문제 | 로컬 컴퓨터\개인 스토어에 적절한 머신 인증서 설치, RSA-SHA256 기반 템플릿 사용 검토 |
| 오류 코드 13801 "IKE authentication credentials are unacceptable" | Windows + strongSwan, 기타 IPsec 서버 | 클라이언트 인증서 EKU 불일치, 잘못된 CA, 비호환 암호 스위트 | 클라이언트 인증서 템플릿 재검토, 올바른 루트 CA 사용, IKEv2 암호 스위트 재조정 |
| 서버 인증서 유효하지만 "not trusted"로 표시 | macOS, iOS, Android 브라우저·VPN 설정 화면 | 자체 서명 또는 사내 CA 사용 시 루트 CA 미설치 | 루트 CA를 디바이스에 설치 후 "항상 신뢰" 또는 VPN 용도로 신뢰 설정 |
3. Windows 클라이언트 기준 IKEv2 인증서 점검 절차
다음 절차는 Windows 10/11 내장 IKEv2 VPN 클라이언트에서 certificate not trusted, 13806, 13801과 같은 인증서 신뢰 오류가 발생했을 때 단계적으로 점검하는 방법이다.
3-1. 정확한 오류 코드·로그 확인
- 이벤트 뷰어 실행 후 다음 경로로 이동한다.
- Windows 로그 → 보안 또는 시스템
- 응용 프로그램 및 서비스 로그 → Microsoft → Windows → RasClient
- 이벤트 ID 13801, 13806, 800 등과 함께 표시되는 메시지를 확인한다.
- 오류 코드가 인증서 관련인지(IKE 인증 자격 증명, 유효한 머신 인증서 없음 등) 또는 암호 스위트 협상 실패(NO_PROPOSAL_CHOSEN 등)인지 구분한다.
3-2. 서버 인증서 체인 상태 확인
다음 명령을 사용하여 서버 인증서 체인을 확인할 수 있다.
certutil -verify <server-cert.cer> 또는 mmc에서 Certificates (Local Computer) 스냅인을 추가하여 다음을 확인한다.
- 서버 인증서가 Personal → Certificates에 존재하는지
- 해당 인증서에 private key가 존재하는지(열면 "You have a private key that corresponds to this certificate" 표시)
- Certification Path 탭에서 루트까지 체인이 끊김 없이 "This certificate is OK"로 표시되는지
3-3. 클라이언트에서 루트·중간 CA 설치 확인
- 서버에 설치된 루트 CA, 중간 CA 인증서를 Base-64 형식 CER로 내보낸다.
- 클라이언트 PC에서 인증서를 더블클릭하여 설치 마법사를 실행하고, 다음 저장소를 선택한다.
- 루트 CA → Trusted Root Certification Authorities
- 중간 CA → Intermediate Certification Authorities
- 명령줄에서 다음과 같이 확인한다.
certutil -store root certutil -store CA 목록에 기대하는 CA의 Subject 이름이 표시되는지 확인한다.
3-4. 머신 인증서(컴퓨터 인증서) 사용 시 점검
Windows IKEv2에서 머신 인증(컴퓨터 인증서)을 사용하는 경우, 인증서는 로컬 컴퓨터 저장소에 설치되어 있어야 한다.
- mmc → Certificates (Local Computer) → Personal → Certificates에서 머신 인증서를 찾는다.
- 해당 인증서 속성에서 EKU를 확인한다.
- "Server Authentication"만 있고 "Client Authentication"이 없다면, 클라이언트 인증으로 사용할 수 없다.
- PowerShell로도 확인할 수 있다.
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, EnhancedKeyUsageList, NotAfter 머신 인증에 사용할 인증서에 Client Authentication EKU가 포함되어 있는지, 유효기간이 남아 있는지 확인한다.
3-5. VPN 연결 설정과 인증서 이름 일치 여부 확인
- Windows 설정 → 네트워크 및 인터넷 → VPN → 해당 IKEv2 연결 → 고급 옵션을 열고, 서버 이름 또는 주소가 무엇인지 확인한다.
- 서버 인증서의 Subject 또는 SAN에 동일한 FQDN이 포함되어 있는지 확인한다. IP로 접속하면서 인증서는 FQDN으로 발급된 경우 이름 불일치로 인증 실패가 발생할 수 있다.
- 가능하면 접속 주소는 FQDN을 사용하고, 인증서의 SAN에 해당 FQDN을 반드시 포함하도록 한다.
3-6. 시스템 시간·CRL/OCSP 점검
- 클라이언트와 서버의 시스템 시간이 NTP 등으로 동기화되어 있는지 확인한다.
- 조직에서 CRL 또는 OCSP를 사용하는 경우, 클라이언트가 해당 URL에 정상적으로 접속할 수 있어야 한다.
- 테스트 목적으로 certutil 또는 브라우저에서 CRL URL을 열어보면 네트워크 또는 방화벽 차단 여부를 확인할 수 있다.
4. 서버 인증서 재발급 베스트 프랙티스
사내용 CA 또는 공인 CA를 사용하여 IKEv2 VPN 서버 인증서를 재발급할 때 다음 사항을 지키면 불필요한 trust failure를 줄일 수 있다.
4-1. 올바른 템플릿 선택
- Microsoft CA 환경에서는 "RAS and IAS Server" 또는 IKEv2용으로 설계된 커스텀 템플릿을 사용하는 것이 일반적이다.
- EKU에 Server Authentication이 포함되어 있는지, 필요시 Client Authentication도 포함할지 검토한다.
- 키 길이는 최소 2048비트 RSA, 서명 알고리즘은 SHA-256 이상을 권장한다.
4-2. Subject / SAN 설계
- Subject의 CN에는 대표 FQDN(예: cn=vpn.example.com)을 지정한다.
- SAN에는 다음 항목을 포함하는 것이 일반적이다.
- DNS 이름: vpn.example.com, 추가 도메인 필요 시 함께 포함
- VPN 클라이언트가 IP 주소로 접속하도록 설정한 경우, SAN에 IP를 포함하지 않으면 일부 구현에서 경고 또는 오류가 발생할 수 있다.
4-3. 체인과 키 내보내기
- 서버 인증서는 개인 키 포함(PFX) 형식으로 내보내어 게이트웨이에 설치한다.
- 루트·중간 CA는 별도의 CER 형식으로 내보내어 클라이언트에 배포한다.
- 게이트웨이(방화벽, 라우터) 설정에서 올바른 서버 인증서를 선택했는지 확인한다. 동일 장비에 여러 인증서가 있을 경우 잘못된 것을 참조해 certificate validation failure가 발생하는 사례가 있다.
5. AD 도메인 환경에서 CA 인증서 자동 배포
조직이 Active Directory를 사용하는 경우, 그룹 정책(GPO)을 통해 루트·중간 CA를 자동 배포하는 것이 가장 안정적이다.
- 도메인 컨트롤러에서 Group Policy Management를 실행한다.
- 도메인 또는 특정 OU에 대한 GPO를 생성·편집한다.
- Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies로 이동한다.
- Trusted Root Certification Authorities 및 Intermediate Certification Authorities에서 Import를 통해 CA 인증서를 추가한다.
- 도메인 구성원 PC에서 그룹 정책을 갱신한다.
gpupdate /force - 재부팅 후 클라이언트에서 certmgr.msc 또는 mmc 스냅인을 이용해 CA가 적용되었는지 확인한다.
6. 모바일(iOS, Android, macOS)에서 인증서 신뢰 설정
모바일 OS는 사내용 CA를 기본적으로 신뢰하지 않기 때문에, IKEv2 VPN을 구성할 때는 장치별로 루트 CA를 설치·신뢰 설정해야 한다.
6-1. iOS / iPadOS
- 루트 CA cer 파일을 메일 또는 MDM을 통해 기기로 전송한다.
- 파일을 탭하면 프로파일 설치 화면이 표시된다.
- 설치 후 설정 → 일반 → 정보 → 인증서 신뢰 설정 메뉴에서 해당 루트 CA를 찾아 전체 신뢰로 전환한다.
- VPN 설정에서 IKEv2 프로필을 생성하고, 원격 ID와 서버 주소에 VPN FQDN을 입력하여 인증서 이름과 일치시키도록 한다.
6-2. Android
- 루트 CA 파일을 기기에 복사하고 알림 또는 파일 앱에서 탭하여 설치한다.
- 용도를 "VPN 및 앱"으로 선택하여 신뢰 범위를 지정한다.
- Android 버전 및 제조사에 따라 설정 메뉴 구조가 다를 수 있으므로, 보안 또는 암호화/자격증명 메뉴에서 인증서가 설치되었는지 확인한다.
6-3. macOS
- 루트 CA를 더블클릭하여 Keychain Access에 추가한다.
- 시스템 키체인(System)에서 해당 인증서를 더블클릭 후, Trust 섹션의 "When using this certificate"를 Always Trust로 설정한다.
- 네트워크 환경설정에서 IKEv2 VPN을 추가하고, 서버 주소가 인증서 이름과 일치하는지 확인한다.
7. 보안 및 운영 관점 체크리스트
인증서 신뢰 오류를 단순히 "안 뜨게" 만드는 것에 그치지 않고, 전체 설계를 재점검하는 것이 중요하다. 다음 체크리스트를 참고하여 환경을 검토한다.
| 점검 항목 | 질문 | 권장 상태 |
|---|---|---|
| CA 구조 | 루트·중간 CA 구성과 배포 전략이 문서화되어 있는가? | AD GPO 또는 MDM으로 중앙 관리, 수동 설치 최소화 |
| 암호 정책 | RSA 키 길이, 서명 알고리즘, IKEv2 암호 스위트가 최신 가이드라인에 맞는가? | 최소 2048비트 RSA, SHA-256 이상, 불필요하게 약한 스위트 비활성화 |
| 인증 방식 | 사용자별 인증서, 머신 인증, EAP 계정 중 어떤 조합을 사용하는가? | 보안 요구 수준에 따라 MFA·클라이언트 인증서를 병행하는 구성을 우선 고려 |
| 운영 절차 | 인증서 만료 전 교체·배포 일정이 수립되어 있는가? | 만료 60~90일 전 알림 및 교체 테스트 절차 확보 |
| 로그 분석 | 인증서 신뢰 오류 발생 시 Event ID와 VPN 서버 로그를 정기적으로 분석하는가? | 표준 운영 절차(SOP)에 포함하여 1차 진단을 자동화하거나 매뉴얼화 |
FAQ
Q1. 공인 인증기관에서 발급받은 인증서인데도 IKEv2에서 신뢰 실패가 발생할 수 있는가?
그럴 수 있다. 클라이언트 OS가 해당 공인 CA를 기본적으로 신뢰하더라도, 서버에 설치한 인증서의 EKU가 서버 인증에 적합하지 않거나, VPN 접속 주소와 인증서 이름이 맞지 않거나, 중간 CA 체인을 서버가 제대로 전달하지 않으면 IKEv2 단계에서 검증이 실패할 수 있다. 따라서 공인 CA 발급 인증서라 하더라도 EKU, Subject/SAN, 체인 구성을 모두 점검해야 한다.
Q2. 자체 서명(self-signed) 서버 인증서를 그대로 신뢰하도록 설정해도 되는가?
테스트 환경이나 소규모 내부용에서는 가능하지만, 보안 관점에서는 별도의 루트 CA를 만들고 서버 인증서는 그 루트 CA로 서명하는 방식이 더 안전하다. 자체 서명 서버 인증서를 직접 신뢰 목록에 추가하면 인증서 관리가 장기적으로 어려워지고, 여러 서버를 운영할 때 일관성이 떨어진다.
Q3. 오류 코드 13806이 뜰 때 무조건 ECDSA를 RSA로 바꾸어야 하는가?
항상 그런 것은 아니다. 일부 구버전 Windows에서 특정 ECDSA 조합과 IKEv2 설정이 맞지 않아 13806 오류가 보고된 사례가 있지만, 최신 패치가 적용된 환경에서는 ECDSA도 정상 동작한다. 다만 혼합 환경이나 구버전 OS를 함께 지원해야 한다면, 호환성 측면에서 RSA-SHA256 기반 인증서를 사용하는 것이 운영상 유리한 경우가 많다.
Q4. Windows에서 "서버 인증서가 요청된 용도로 유효하지 않다"는 메시지가 나오는 이유는 무엇인가?
서버 인증서의 Extended Key Usage에 Server Authentication이 포함되어 있지 않거나, VPN 서버가 클라이언트 인증서 등을 잘못 서버 인증서로 참조하는 경우 발생한다. 이 경우 올바른 템플릿으로 서버 인증서를 다시 발급하고, VPN 게이트웨이 설정에서 해당 인증서를 명시적으로 선택해야 한다.
Q5. 클라이언트에 루트 CA를 설치했는데도 여전히 certificate not trusted가 뜨는 경우는?
루트 CA는 올바르게 설치되었지만 중간 CA가 누락되었거나, 클라이언트가 중간 CA를 다운받을 수 없는 환경일 수 있다. 이 경우 서버에 전체 체인(서버 인증서 + 중간 CA)을 함께 설치하고, 게이트웨이가 TLS 핸드셰이크 또는 IKEv2 인증 단계에서 체인을 제대로 전송하도록 설정해야 한다.