정보보안핵심 · 17분 읽기
전자서명과 PKI 인증서 읽기
전자서명은 데이터와 서명키의 관계를 검증한다. PKI는 공개키를 이름과 연결하고 그 연결을 신뢰하는 체계를 제공한다.
개념부터 찾아보기
정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.
이 노트에서 설명할 수 있게 되는 것
- 인증서 체인의 각 서명을 어떤 공개키로 검증하는지 설명한다.
- 신뢰 경로 검증과 서버 이름 검증을 분리한다.
- 만료·체인 누락·키 불일치를 관찰 증거로 구분한다.
먼저 알면 좋은 개념대칭키·공개키와 DES·AES의 내부 구조
01개념과 구성 요소
- 인증서공개키·이름·기간·용도 등의 내용을 발급자의 서명으로 묶은 자료다.
- 신뢰 경로서버 인증서, 중간 , 가 신뢰하는 앵커를 연결하며 자체 서명만으로 신뢰가 생기지는 않는다.
- 검증의 두 축서명 경로가 유효한지와 지금 접속하는 이름에 맞는지를 함께 판단한다.
02서버 키가 인증서로 발급되고 검증되는 순서
- 키와 생성서버가 키 쌍을 만들고 공개키·요청 이름 등을 에 담아 개인키로 서명한다. 개인키 자체는 에 넣지 않는다.
- 발급 요건 검증는 도메인 등 정책상 필요한 요건을 확인한다. 서명만으로 도메인 통제권이 증명되지는 않는다.
- 인증서 발급가 실제 발급할 TBS 내용을 구성하고 발급자 개인키로 서명한다.
- 인증서 전달서버는 연결에서 리프와 필요한 중간 인증서를 제시한다. 신뢰 앵커는 클라이언트의 신뢰 정책에서 온다.
- 경로와 이름 검증클라이언트가 발급 관계·기간·용도·제약·요청 이름을 검증한다.
- 개인키 소유 확인의 CertificateVerify 같은 연결별 증명으로 상대가 인증서와 대응하는 개인키를 가졌는지 확인한다.
03공개키 파일만으로는 소유자를 알 수 없다
- 공개키와 소유자공개키로 서명을 검증할 수 있다는 것과 그 공개키가 의도한 서버의 것이라는 것은 서로 다른 사실이다. 공격자가 공개키와 서명을 모두 자신의 것으로 바꾸면 그 조합의 수학적 검증은 성공할 수 있다.
- 인증서의 결합인증서는 공개키, 사용 대상의 이름, 유효기간과 용도 등을 하나로 묶고 발급자가 그 내용에 서명함으로써 이 문제를 다룬다.
- 신뢰 경로·이름웹 인증서의 신뢰는 단순히 “서명되어 있다”에서 나오지 않는다. 가 신뢰하는 까지 발급 관계가 이어지는지와 지금 접속하려는 서비스 이름에 맞는지를 함께 판단한다.
- 보증 범위인증서는 해당 사이트의 프로그램이 취약점 없이 작성되었다거나 운영자가 모든 행위를 정당하게 한다는 보증서는 아니다.
04전자서명은 데이터와 개인키의 관계다
- 서명·검증는 메시지를 알고리즘이 정한 방식으로 해시·인코딩하고 개인키로 서명한다. 는 메시지·서명·공개키로 그 관계가 유효한지 검사한다.
- 무결성과 기밀성전송 중 메시지가 바뀌면 원래 서명과의 검증 관계가 깨진다. 서명된 원문은 공개되어도 되므로 서명만으로 기밀성이 생기지 않는다.
- 서명 알고리즘 서명에는 PSS 같은 구체적인 인코딩 방식이 있고 ECDSA·EdDSA는 의 암호화·복호화 방향 전환으로 설명할 수 없다. 은 알고리즘별 서명·검증 절차이며 일반 암호화의 방향을 바꾼 연산으로 통일할 수 없다.
- ECDSA 서명값ECDSA에서 서명마다 사용하는 값의 재사용과 품질 문제가 개인키에 영향을 줄 수 있다는 점도 키 보관과 별도로 존재한다.
05X.509 인증서의 세 부분과 주요 필드
- TBS 구조인증서는 크게 TBSCertificate, 서명 알고리즘, 서명 값으로 읽는다. TBS는 to be signed, 즉 서명 대상 본문이다.
- 발급자 서명주체의 공개키를 바꾸거나 ·유효기간을 변경하면 TBS 바이트가 달라지므로 원래 발급자 서명으로 검증되지 않는다. 서명 값은 주체의 공개키가 아니라 발급자의 개인키로 만들어졌다는 점이 중요하다.
- 주체 키와 서명 알고리즘인증서에 표시된 주체 공개키 알고리즘과 인증서 서명 알고리즘은 별개다. 주체 키는 서버가 이후 개인키 소유를 증명할 때 대응하는 키이고, 발급자 서명은 인증서 내용을 검증하는 근거다.
- Serial NumberSerial Number는 발급자와 함께 해당 인증서를 식별하는 데 쓰이며 전 세계 모든 를 통틀어 단독으로 유일한 식별자라고 가정하지 않는다.
| 필드 | 읽어야 할 의미 |
|---|---|
| Subject / Issuer | 발급받은 주체 / 서명한 발급자 |
| Subject Public Key Info | 주체 공개키와 알고리즘 |
| Validity | Not Before와 Not After |
| 사용 가능한 이름·IP 식별자 | |
| 여부와 경로 제약 | |
| / | 키 작업과 인증서 사용 목적 |
| Signature Algorithm / Value | 발급자 서명 방식과 결과 |
06CSR에서 발급된 인증서가 되기까지
- 키 쌍·서버는 먼저 키 쌍을 만들고 공개키와 요청할 Subject· 정보를 에 담는다. 도 요청자의 개인키로 서명되어 공개키와 대응하는 개인키를 가진다는 근거를 제공한다.
- 발급는 요청한 도메인·조직 등 발급 정책에 필요한 정보를 별도로 검증하고 실제 발급할 TBS를 구성한 뒤 개인키로 서명한다.
- 도메인 검증의 서명은 도메인 소유권 검증 전체를 대신하지 않는다. 누군가 자기 키로 다른 이름을 적은 요청을 만들 수 있기 때문이다.
- 확장과 개인키또한 요청된 확장을 가 무조건 그대로 발급하는 것도 아니다. 서버 개인키는 인증서와 에 포함하지 않으며 에 넘겨야만 발급 가능한 구조가 아니다.
- 서버 배치서버에는 발급된 인증서와 대응 개인키, 전달할 중간 체인을 연결한다.
07루트·중간 CA·서버 인증서의 검증 방향
- 체인 검증일반적인 체인에서 루트 는 중간 인증서를 서명하고 중간 는 서버 인증서를 서명한다. 클라이언트는 서버 인증서를 중간 공개키로 검증한 뒤 상위 발급 관계를 따라 로컬 신뢰 앵커까지 경로를 만든다.
- 중간 인증서 전달서버는 필요한 중간 인증서를 제공하지만 신뢰 앵커 자체는 의 정책과 저장소에서 온다.
- 루트 신뢰 결정루트 인증서가 자체 서명되어 있다는 사실만으로 신뢰되지는 않는다. 자체 서명은 서명 구조의 특징이고, 신뢰 저장소에 등록되어 있다는 것은 운영상 신뢰 결정이다.
- 신뢰 저장소중간 를 사용하면 루트 개인키를 일상적인 서버 인증서 발급에서 분리할 수 있다. 운영체제·브라우저·Java 런타임이 서로 다른 신뢰 저장소를 사용하면 같은 서버에 대한 결과도 달라질 수 있다.
08서명 체인과 서버 이름은 동시에 맞아야 한다
- 이름·와일드카드 이름으로 접속하면 의 dNSName과 비교한다. *.example.com은 api.example.com 같은 한 단계 이름과 맞을 수 있지만 example.com 자체나 v1.api.example.com까지 자동 포함하지 않는다.
- IP 이름 검증IP로 접속한 경우에는 그 IP를 위한 표현과 일치해야 하며 이름을 갖는 인증서라는 이유만으로 대체되지 않는다.
- 체인과 이름체인 검증은 이 공개키에 대한 발급 관계를 신뢰할 수 있는지 묻고 이름 검증은 그 신뢰가 지금 요청한 서비스에 해당하는지 묻는다. 공격자가 다른 도메인의 정상 인증서를 제시했다면 체인은 정상일 수 있어도 이름이 맞지 않으므로 연결을 받아들이면 안 된다.
- 현대 서비스 이름 검증에서는 CN만 입력하고 을 빠뜨린 구성을 정상적인 이름 검증 방법으로 기대하지 않는다.
수업 원본 자료
원본에서 읽는 인증서 체인과 사용 조건
원본 크기로 보기 ↗이 자료에서 읽어낼 것
- 루트→중간 CA→서버 인증서의 화살표는 발급 서명 방향이다. 검증자는 반대로 발급자 공개키를 찾아간다.
- 신뢰 저장소 연결과 SAN·기간·용도·폐기 상태가 별도 조건으로 표시되어 있다. 서버가 루트를 보내는 행위가 신뢰를 새로 만들지 않는다.
09유효기간·용도·CA 제약·폐기 상태
- 시각과 유효기간유효기간은 클라이언트의 시간 판단과 연결된다. 시간이 크게 어긋나면 정상 발급된 인증서를 아직 유효하지 않거나 만료된 것으로 볼 수 있다.
- 용도·제약는 역할을 허용하는지를, 와 는 키 작업과 서버 인증 같은 용도를 제한한다. 서명만 맞는 일반 서버 인증서를 임의로 하위 인증서 발급 처럼 사용할 수 없는 이유다.
- ·폐기는 만료 전에 신뢰를 중단하는 절차다. 은 폐기 목록을, 는 상태 확인 방식을 제공한다.
- 클라이언트 정책실제 클라이언트의 조회 방식과 실패 시 정책이 다르므로 폐기되었다는 사실만으로 모든 소프트웨어가 같은 순간에 연결을 거부한다고 단정하지 않는다. 키 유출 시에는 기존 인증서의 처리뿐 아니라 새 개인키 생성과 배포도 함께 필요하다.
원리 심화
10체인 서명 외에 경로가 만족해야 할 제약
- 역할의 와 의 keyCertSign은 인증서 발급에 사용할 키인지 판단하는 제약이다.
- Path LengthpathLenConstraint는 뒤따를 수 있는 비자체발급 중간 의 수를 제한한다. 최종 서버 인증서는 그 중간 수에 포함하지 않는다.
- 이름 제약Name Constraints는 하위 인증서에서 허용·제외할 이름 공간을 제한할 수 있다. 상위 의 유효한 서명만으로 제약을 무시할 수 없다.
- Critical 확장이해하지 못하는 critical 확장을 무시하면 발급자가 요구한 제한을 우회할 수 있으므로 경로 검증에서 처리해야 한다.
- 키 식별AKI·SKI는 발급자 키와 주체 키를 연결하는 단서다. 이름 문자열이 같다는 사실과 실제 서명에 사용된 키가 같다는 사실은 다르다.
예제로 추적
11pathLenConstraint=0인 중간 CA의 가상 경로
- 경로 A신뢰 앵커 R→중간 I→서버 S로 이어지고 I의 =true, pathLenConstraint=0이라고 가정한다.
- 서버 발급I 뒤에는 최종 S만 있으므로 중간 길이 제한 0 자체를 위반하지 않는다. 다른 검증 조건은 여전히 필요하다.
- 경로 BI가 다른 비자체발급 중간 J를 만들고 J가 S를 발급하면 R→I→J→S가 된다.
- 길이 위반I 아래에 J라는 중간 가 하나 있으므로 I의 pathLenConstraint=0 조건과 맞지 않는다.
- 판정 구분서명이 모두 수학적으로 맞아도 경로 제약 때문에 거부할 수 있다. 서명 오류와 정책·제약 오류는 다른 실패다.
검증·예외
12같은 인증서가 일부 클라이언트에서만 실패할 때
- 앵커 집합운영체제·브라우저·런타임별 신뢰 저장소와 배포된 루트가 같은지 확인한다.
- 서버 체인서버가 제공한 중간 인증서의 순서·누락·대체 경로를 확인한다. 다른 PC의 캐시가 누락을 우연히 가릴 수도 있다.
- 요청 식별자실제 접속 이름·SNI·을 대조한다. 같은 IP의 다른 가상 호스트에 접속했다면 다른 인증서가 반환될 수 있다.
- 정책 차이허용 알고리즘·시간·용도·폐기 확인 정책을 비교한다. 검증을 끄고 성공했다는 결과는 어느 조건이 틀렸는지 설명하지 못한다.
13PEM·DER·PKCS#12는 파일을 해석하는 단서다
- 는 인증서의 바이너리 인코딩이고 은 와 경계 표시로 표현한 텍스트 형식이다. .crt와 .cer 확장자만 보고 실제 인코딩을 확정할 수 없다.
- PKCS#12PKCS#12 컨테이너는 인증서·개인키·체인을 함께 담을 수 있어 단순 공개 인증서 파일처럼 취급하면 안 된다.
- 제품의 파일 역할에서 http_ca.crt는 HTTP 서버 인증서를 검증할 인증서, http.p12는 HTTP용 인증 자료, transport.p12는 노드 간 용 자료의 역할을 가진다.
- 내용 확인이는 제품 설정의 예이며 HTTP 통신과 노드 간 통신이 서로 다른 인증 경계를 가질 수 있다는 원리를 배우는 데 의미가 있다. 파일명만으로 실제 안에 든 키·체인·암호화 상태를 확정하지 않는다.
14개인키 소유 증명은 인증서 전달 다음에 있다
- 인증서 복사 가능성인증서 파일은 공개해도 되므로 다른 사람이 복사할 수 있다. 따라서 연결 상대가 인증서를 보내기만 했다고 그 공개키와 대응하는 개인키를 가졌다고 판단하지 않는다.
- CertificateVerify의 CertificateVerify는 현재 핸드셰이크 문맥에 대한 서명으로 이 관계를 증명한다. 서명은 인증서 본문을, 서버 서명은 이번 연결의 문맥을 보호한다.
- 개인키 사용 경계개인키가 유출되면 공격자는 정상 소유자와 같은 서명을 만들 수 있으므로 HSM·TPM 같은 키 사용 경계, 접근권한과 감사가 중요해진다. 서명 검증 성공은 그 키 기준의 결과이며 현실의 사람·조직과 시점에 대한 판단은 발급·등록·키 관리의 증거를 함께 사용한다.
15실패 메시지를 인증서 구조에 연결하기
- ·체인 오류알 수 없는 는 신뢰 경로가 로컬 기준에 연결되지 않은 경우이고, 불완전한 체인은 필요한 중간 인증서가 누락되어 경로를 만들지 못한 경우일 수 있다. 이름 불일치는 연결은 도달했지만 요청한 서비스 식별자와 인증서가 맞지 않는 문제다.
- 키 쌍 불일치인증서와 개인키가 다른 키 쌍이면 서버 시작이나 개인키 소유 증명 단계에서 실패할 수 있다.
- 갱신 후 경로 차이갱신 뒤 간헐적으로 실패한다면 여러 백엔드 중 일부만 교체되었거나 실행 가 이전 파일을 유지하는 경우도 설명할 수 있다. 이때 인증서 지문··기간·발급자와 실제 접속 경로를 연결하면 같은 파일을 수정했다는 사실과 현재 제공되는 인증서의 차이를 드러낼 수 있다.
- 오류 분류인증서 구조를 알면 모든 실패를 막연히 SSL 오류라고 묶을 필요가 없다.
설명과 함께 보는 보조 도식
처리 과정
모식도 · 인증서 체인의 검증 방향
제공된 인증서의 서명과 로컬 신뢰 근거를 연결한다.
01리프 인증서서비스 이름과 공개키
02중간 CA리프 서명을 검증할 공개키
03신뢰 앵커검증자가 사전에 신뢰한 기준
04서비스 검증경로·기간·용도·이름 판단
01
리프 서명 검사
중간 CA 공개키로 리프 인증서를 검증한다.
전체 단계를 한 번에 읽기
- 01
리프 서명 검사
중간 CA 공개키로 리프 인증서를 검증한다.
- 02
신뢰 경로 구성
중간 CA에서 로컬 신뢰 앵커까지 경로를 확인한다.
- 루트 수신
- 자동 신뢰를 뜻하지 않음
- 03
적용 조건 검사
유효기간·제약·접속 이름을 함께 확인한다.
- 결과
- 각 조건을 모두 만족해야 허용
LEARN THROUGH PRACTICE
브라우저 인증서 경고를 체인·이름·기간으로 나누기
HTTPS 경고를 무조건 암호화 실패로 해석하지 않고 신뢰 검증의 실패 지점을 찾는다.
실습 구성과 전제
- 자신이 관리하는 실습 HTTPS 서버와 서버 인증서·중간 ·실습 파일을 준비한다.
- 아래 도해와 브라우저 경고는 검증 원리와 실제 오류의 비교 자료이며 같은 서버의 연속 실행 증거가 아니다.
브라우저가 어떤 검증에서 멈췄는지 읽는다
- 오류 코드와 접속 이름을 먼저 기록한다. NET::ERR_CERT_AUTHORITY_INVALID는 신뢰 가능한 발급 경로를 만들지 못했음을 조사할 출발점이다.
- 원인은 신뢰 저장소에 없는 , 누락된 중간 인증서 등일 수 있다. 화면 하나로 개인키 손상이나 서버 침해를 확정하지 않는다.
원본 크기로 보기 ↗- 주소는 HTTPS로 시작하지만 브라우저에 '연결이 비공개로 설정되어 있지 않습니다'가 표시된다.
- 오류 코드가 NET::ERR_CERT_AUTHORITY_INVALID이므로 단순 HTTP 미사용 여부와 CA 신뢰 문제를 구분해야 한다.
확인 기준경고를 무시해 접속하는 것을 해결로 기록하지 않는다.
인증서 필드와 체인을 따로 검사한다
- Subject·Issuer는 표시 이름이며, 실제 서버 이름 비교에는 을 본다. 기간은 현재 시계와 Not Before·Not After를 비교한다.
- 신뢰 앵커는 클라이언트가 신뢰하도록 설정한 값이다. 서버가 루트 인증서를 함께 보낸다는 사실만으로 신뢰가 생기지 않는다.
shellopenssl x509 -in server.pem -noout -subject -issuer -dates -ext subjectAltName openssl verify -CAfile lab-root.pem -untrusted intermediates.pem -verify_hostname lab.example server.pem보유한 인증서 파일을 로컬에서 검사하는 예시. lab.example은 실제 시험 이름으로 바꾼다.
원본 크기로 보기 ↗- 체인은 Root CA→Intermediate CA→서버 인증서로 그려져 있다.
- 검증 항목은 서명 체인 외에 서버 이름·기간·용도 제한·폐기 상태를 포함한다.
확인 기준체인 검증 성공과 이름 검증 성공을 각각 기록한다.
수정한 조건만 재시험한다
- 누락된 중간 인증서를 보완했다면 서버가 보내는 체인을 다시 확인한다. 실습 신뢰를 추가했다면 그 클라이언트의 신뢰 저장소 변경 범위를 기록한다.
- 이름이나 만료 조건까지 동시에 바꾸면 어느 변경이 경고를 없앴는지 알기 어렵다. 각 실패 조건을 분리해 재시험한다.
확인 기준체인··기간이 모두 맞는 상태에서만 정상으로 판정한다.
실습에서 확인한 동작 원리
- HTTPS 사용과 인증서 신뢰 성공은 별개다.
- 오류 코드를 검증 조건에 연결하면 불필요한 설정 변경을 줄일 수 있다.
READ · OBSERVE · CONNECT
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
RFC 5280: Basic Constraints와 인증 경로
중간 의 ·pathLenConstraint를 읽고 서명 유효성과 체인 정책 유효성을 나누어 판단할 수 있다.
읽으면서 확인할 것
- pathLenConstraint=0이 제한하는 중간 수
- 최종 인증서와 비자체발급 중간 의 구분
- 6절의 경로 검증과 신뢰 앵커 입력
학습 확인
이해했는지 확인하기
- 공개 인증서와 개인키 파일의 역할·접근권한을 구분한다.
- SAN·유효기간·용도·신뢰 경로를 확인한다.
- 갱신 실패와 키 유출 시 처리 절차를 확인한다.