PKI 문제는 “공개키로 암호화하고 개인키로 복호화한다”는 한 문장으로 풀 수 없습니다. 기밀성, 전자서명, 공개키의 소유자 확인, 인증서 상태 확인은 서로 다른 단계입니다. 메시지 보호와 신원 확인 흐름을 분리해서 보세요.

암호화, 전자서명, 인증서는 해결하는 질문이 다릅니다

기술핵심 질문대표 처리
공개키 암호누구만 내용을 읽게 할 것인가수신자의 공개키로 보호하고 수신자의 개인키로 복호화하는 구조를 검토
전자서명누가 만들었고 바뀌지 않았는가서명자의 개인키로 서명하고 공개키로 검증
인증서이 공개키가 정말 그 주체의 것인가발급자의 서명으로 주체·공개키·유효기간·제약을 연결

전자서명 표준은 서명 생성과 검증을 통해 데이터 무결성과 서명자 인증을 지원합니다. 전자서명을 단순히 ‘개인키로 암호화’라고 설명하면 목적과 검증 절차를 놓칩니다.근거 원문

인증서는 이름과 공개키만 담는 파일이 아닙니다

X.509 인증서에는 주체, 발급자, 일련번호, 유효기간, 공개키 정보, 서명 알고리즘과 확장 필드가 포함될 수 있습니다. 확장 필드의 Basic Constraints, Key Usage, Subject Alternative Name 같은 값은 인증서가 CA로 동작할 수 있는지, 어떤 용도에 쓰이는지, 어떤 이름에 유효한지를 판단하는 데 사용됩니다. 근거 원문

인증 경로는 종단 인증서에서 신뢰 앵커까지 연결합니다

  1. 종단 인증서서버·사용자처럼 실제 주체의 이름과 공개키를 담는다.
  2. 중간 CA상위 CA의 신뢰를 이어받아 종단 인증서를 발급할 수 있다.
  3. 신뢰 앵커운영체제·브라우저·조직이 별도로 신뢰하기로 한 루트 기준점이다.
  4. 경로 검증서명, 유효기간, 이름·정책·제약과 상태를 경로 전체에서 확인한다.

루트 인증서가 항상 서버에서 전송돼야 하는 것은 아닙니다. 검증자는 자신이 가진 신뢰 저장소의 신뢰 앵커와 서버가 제공한 인증서 체인을 조합할 수 있습니다. 시험 답안에서는 “루트 CA까지 서명만 따라간다”보다 “신뢰 앵커까지 유효한 인증 경로를 구성하고 제약을 검증한다”고 쓰는 편이 정확합니다.

CRL과 OCSP는 만료 전 폐기 상태를 확인하는 방식이 다릅니다

방식확인 구조주의할 점
CRLCA가 폐기 인증서 목록을 서명해 배포목록 갱신 시점과 배포 지연을 고려
OCSP특정 인증서의 상태를 온라인 응답자에게 질의응답 상태·서명·유효 시간과 응답자 신뢰를 확인

OCSP는 인증서 상태를 묻는 프로토콜이지 인증서의 모든 경로·이름·용도를 대신 검증하는 서비스가 아닙니다. 응답이 good이라고 해서 인증서 전체 검증이 자동으로 성공하는 것은 아닙니다.근거 원문

WORKED EXAMPLE

서명은 맞지만 접속을 거부해야 하는 경우

문제

서버 인증서의 CA 서명은 유효하다. 그러나 접속한 호스트 이름은 인증서의 Subject Alternative Name에 없고 인증서 유효기간도 끝났다. 이 인증서를 신뢰할 수 있는가?

약한 답

CA 서명이 맞으므로 신뢰할 수 있다.

개선한 답

신뢰할 수 없다. 발급자 서명이 유효해도 호스트 이름 일치와 유효기간 검증에 실패한다. 인증 경로·용도·폐기 상태도 별도로 확인해야 한다.

  1. 01서명 확인

    인증서가 선언한 발급자의 공개키로 서명을 검증합니다.

  2. 02대상 확인

    접속 이름이 인증서의 허용 이름과 일치하는지 확인합니다.

  3. 03시간·상태 확인

    유효기간과 CRL·OCSP 등 폐기 상태를 정책에 따라 확인합니다.

판별 포인트인증서 검증은 서명 하나가 아니라 경로·대상·시간·용도·상태의 결합 판단입니다.

CA와 RA도 역할을 분리해 씁니다

CA는 인증서를 발급·서명하고 인증서 생명주기를 관리하는 중심 역할입니다. RA는 운영 구조에 따라 신청자의 신원 확인이나 등록 업무를 위임받을 수 있지만, 모든 PKI에 같은 형태로 반드시 존재한다고 단정하면 안 됩니다. 문제에 제시된 조직 구조와 책임을 먼저 읽으세요.

인증과 권한 위임을 연결해서 보고 싶다면 인증·MFA·SSO 글을, 공개키·해시·전자서명의 기초는 정보보호론 암호학 글에서 이어서 확인하세요.