PKI와 X.509 인증서: 신뢰 체인·CRL·OCSP를 검증하는 방법

1장 개념과 보호 목표#

PKI는 공개키와 신원 정보를 연결하고 인증서의 발급·검증·폐기를 관리하는 기반입니다. X.509 인증서는 공개키와 주체 정보 등을 담고 발급자가 서명합니다. 인증서를 가지고 있다는 사실만으로 상대를 신뢰할 수는 없습니다.

2장 원리와 구분#

검증자는 신뢰할 수 있는 루트까지 서명 체인을 확인하고 유효기간, 이름 일치, 키 사용 목적과 제약조건을 점검합니다. 웹 서버 이름 검증은 SAN을 기준으로 수행합니다. CRL은 폐기 목록을 배포하고 OCSP는 인증서 상태를 질의하는 방식입니다. 상태 조회 실패를 허용할지 차단할지는 가용성과 위협을 고려해 정책으로 정해야 합니다.

3장 비교와 판단 기준#

확인 항목	판단 내용	실패 시 영향
신뢰 체인	발급자 서명과 신뢰 루트	위조·잘못된 발급자
이름	서버 이름과 SAN	다른 서버 접속
유효기간·용도	현재 시간·키 사용·EKU	만료·잘못된 용도
폐기 상태	CRL·OCSP와 정책	유출 키 계속 신뢰

4장 인증서에는 어떤 정보가 들어갈까#

X.509 인증서는 공개키와 주체에 관한 정보, 발급자, 유효기간, 용도와 제약, 서명 등을 연결합니다. 웹 서버 검증에는 이름이 중요한데 실제 접속 호스트와 SAN의 규칙을 대조해야 합니다. 화면의 발급자 이름이 익숙하다는 이유만으로 해당 사이트가 인증된다고 볼 수 없습니다.

주체와 공개키
발급자와 서명 알고리즘
유효기간
SAN·키 용도·경로 제약 등의 확장
발급자의 서명

5장 서버·중간 CA·루트의 관계#

서버 인증서는 중간 CA가 발급하고 중간 CA는 상위 CA에 연결될 수 있습니다. 검증자는 신뢰 저장소의 앵커까지 경로를 구성하고 각 단계의 서명·제약을 확인합니다. 서버가 제시한 순서나 파일 이름을 그대로 믿는 것이 아닙니다.

flowchart TB
 R["신뢰 저장소의 루트·앵커"] --> I["제약을 만족한 중간 CA"]
 I --> S["서버 인증서"]
 S --> K["서버 공개키와 허용 이름"]
 K --> V["해당 연결의 상대 인증"]

6장 자기 서명과 신뢰는 다른 개념이다#

자기 서명 인증서는 자신의 키로 서명되어 있습니다. 이 서명만으로 외부의 검증자가 믿을 이유는 생기지 않습니다. 루트의 신뢰는 운영체제·조직 정책과 안전한 배포로 설정됩니다. 사설 CA 환경도 신뢰 앵커의 등록·회수·접근 통제가 필요합니다.

검증 오류를 해결하려고 받은 인증서를 무조건 신뢰 저장소에 추가하면 공격자가 제시한 키를 앵커로 만들 수 있습니다. 발급 경로와 관리자의 신뢰 설정을 구분해야 합니다.

7장 이름 검증을 빼먹으면 어떤 문제가 생길까#

정당한 CA가 발급한 다른 도메인의 인증서도 체인은 통과할 수 있습니다. 접속한 호스트 이름을 확인하지 않으면 의도한 상대가 아닌데도 허용할 수 있습니다. 체인의 유효성과 이름 일치는 각각 필요한 검증입니다.

IP 주소로 접속하거나 별칭·로드밸런서 도메인을 사용하는 경우 실제 검증 이름과 인증서의 SAN이 맞는지 확인합니다. 편의를 위해 이름 검증을 끄는 설정은 운영에서 제거하고 정상 이름 구성을 사용합니다.

8장 유효기간과 시스템 시각#

인증서의 시작·종료 시각과 검증 시스템의 시각이 맞아야 합니다. 시각 오차는 정상 인증서를 만료 또는 아직 유효하지 않은 것으로 판단하게 만들 수 있습니다. 시간 동기화와 만료 경보를 인증서 관리에 연결합니다.

갱신이 완료되어도 실제 배포가 끝났다고 볼 수 없습니다. 여러 노드·프록시·리전·백업 경로에서 새 인증서를 제공하는지 외부 관측으로 확인해야 합니다.

9장 키 용도와 CA 제약#

인증서가 어떤 역할에 사용될 수 있는지는 확장과 정책의 영향을 받습니다. 서버 인증용·클라이언트 인증용·CA 역할을 같은 파일 형식이라는 이유로 무제한 바꿔 쓰지 않습니다. 경로 제약과 용도 검증은 라이브러리에서 활성화하고 실제 동작을 시험합니다.

유효한 서명 체인이 있다는 사실만으로 현재 용도에 적합한 인증서라는 결론을 내리면 안 됩니다. 구체적인 애플리케이션 정책과 프로토콜의 조건을 함께 봅니다.

10장 CRL과 OCSP의 상태 정보#

CRL은 폐지 정보 목록, OCSP는 상태 확인의 응답을 사용하는 방식입니다. 응답의 진본·유효기간·캐시·통신 실패와 클라이언트의 실패 정책을 확인합니다. 상태 서비스가 응답하지 않으면 무조건 안전하다는 결론도, 무조건 폐지되었다는 결론도 정확하지 않습니다.

flowchart LR
 C["검증할 인증서"] --> P["상태 확인 정책"]
 P --> R["CRL 또는 OCSP 정보"]
 R --> V["서명·신선도·상태 검증"]
 V --> D["정책에 따른 연결 판단"]

11장 개인키 노출과 인증서 폐지를 연결한다#

인증서 자체는 공개 정보지만 연결된 개인키는 비밀입니다. 개인키가 소스·CI 로그·백업·지원 자료로 노출될 수 있는 경로를 조사합니다. 사고 시 새 키 생성·재발급·폐지·배포·관련 세션 영향을 연결해야 합니다.

기존 인증서 파일을 지우는 것만으로 공격자가 가진 개인키를 무효화하지는 못합니다. 상대 검증자의 상태 확인 정책과 남아 있는 배포 경로도 영향 범위에 포함합니다.

12장 인증서 갱신 자동화의 실패 경로#

발급 계정 권한·도메인 검증·비밀 저장·배포 권한·서비스 재적용을 따로 확인합니다. 발급 성공 이후 배포 실패, 일부 노드의 미갱신, 체인 누락과 경보 미수신을 시험해야 합니다. 자동화의 상태 메시지를 외부 실제 인증서와 대조합니다.

시험	기대 결과
다른 호스트 이름	이름 검증 실패
만료 인증서	정책에 따른 거부
미신뢰 앵커	신뢰 경로 실패
잘못된 용도	용도 검증 실패
일부 노드의 옛 인증서	갱신 누락 탐지

13장 인증서 인증 이후에도 업무 인가는 필요하다#

상호 TLS로 클라이언트 인증서를 확인했어도 그 주체가 모든 API를 호출하도록 허용하지 않습니다. 인증서의 신원과 서비스 계정·조직·업무 권한을 연결합니다. 키 회수와 권한 변경 뒤 기존 연결이 어떻게 처리되는지도 시험합니다.

PKI는 공개키를 신뢰할 상대와 연결하는 체계입니다. 데이터 내용의 진실성·애플리케이션 입력 안전성·운영자의 모든 행위까지 보증하는 체계로 확대하지 않아야 합니다.

14장 적용 사례와 운영 방법#

인증서 자동 갱신에서는 발급 성공뿐 아니라 실제 서버의 새 인증서 적용을 확인합니다. 신뢰 루트 변경, 중간 인증서 누락, 기기 시간 오차도 장애 원인이 됩니다. 개인키가 유출되면 인증서 교체와 폐기, 영향을 받은 서비스의 키 교체를 함께 수행합니다.

15장 인증서 신뢰 체인#

flowchart TD
 R["신뢰 저장소의 Root CA"] -->|"서명 검증"| I["Intermediate CA"]
 I -->|"서명 검증"| S["서버 인증서"]
 S --> N["SAN·기간·용도 확인"]
 N --> V["폐기 상태·정책 확인"]

16장 인증서는 공개키와 이름의 연결을 확인하는 자료#

인증서 검증에는 서명 체인만 확인하는 것보다 많은 단계가 있습니다. 신뢰 앵커, 유효기간, 이름 일치, 키 용도, 경로 제약과 적용 정책을 확인해야 합니다. 서버 인증서의 SAN과 접속한 호스트 이름을 비교하지 않으면 신뢰하는 CA가 발급한 다른 사이트의 인증서도 받아들이는 오류가 생길 수 있습니다.

루트 인증서는 보통 스스로 서명하지만 자기 서명 자체가 신뢰의 근거는 아닙니다. 운영체제·조직 정책으로 신뢰 앵커에 포함되어야 합니다. 중간 인증서를 다운로드하거나 서버가 제시한 목록을 받아도 검증 경로와 정책을 확인해야 하며 임의의 인증서를 루트처럼 등록하면 안 됩니다.

17장 인증서 갱신은 발급 이후 배포까지 검증한다#

웹 서버를 여러 대 운영하면 발급 성공 뒤 일부 노드에 오래된 인증서가 남을 수 있습니다. 외부에서 각 경로의 인증서와 체인을 관측하고 만료·갱신 실패를 경보로 연결합니다. 개인키 파일의 권한과 로드밸런서·백업 사본도 같은 범위에 넣습니다.

CRL과 OCSP는 폐지 상태 확인 수단이며 접근 실패 때의 동작과 캐시·응답 유효기간은 클라이언트 정책에 따라 달라집니다. OCSP 응답이 없다고 무조건 안전 또는 무조건 폐지라고 단정하지 말고, 사용하는 프로그램에서 실제 검증·실패 정책을 시험해야 합니다.

18장 적용 전 확인할 사항#

체인·SAN·유효기간·EKU를 검증한다
개인키 접근 권한과 자동 갱신 결과를 감시한다
폐기 확인 실패와 만료 시 운영 절차를 마련한다

19장 자주 묻는 질문#

자체 서명 인증서는 언제나 위험한가요?#

신뢰할 수 있는 경로로 인증서나 공개키를 배포하고 관리하는 폐쇄 환경에서는 사용할 수 있습니다. 검증을 끄는 방식으로 사용하는 것이 문제입니다.

자기 서명 인증서는 항상 암호화가 약한가요?#

암호화 강도와 신뢰 경로는 다른 문제입니다. 사설 환경에서 신뢰 앵커를 안전하게 배포하면 사용할 수 있지만 이름·키·수명주기 검증도 필요합니다.

인증서 유효기간 안이면 개인키 유출에도 안전한가요?#

유효기간은 키 탈취를 막지 않습니다. 키 유출 시 회수·폐지·재발급과 관련 세션·시스템 영향을 함께 조사해야 합니다.