개념 사전/정보보안 / 암호·인증서
개념 사전 · 관리체계

PKI와 X.509 인증서

공개키 기반구조 · Public Key Infrastructure

PKI는 공개키가 누구의 어떤 용도인지 인증서와 신뢰 체인으로 관리하는 체계다. 인증서 전달 뒤에는 이름·용도·유효기간·발급 경로와 실제 개인키 소유를 각각 검증한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 공개키를 서비스 이름이나 주체에 연결한다.
  • 발급·갱신·폐기와 신뢰 앵커 배포를 관리한다.
  • 와 이 의존하는 신뢰 경로를 검증한다.

02어떤 순서로 동작하나

  1. 키와 생성

    서버가 키 쌍을 만들고 공개키·요청 이름 등을 에 담아 개인키로 서명한다. 개인키 자체는 에 넣지 않는다.

  2. 발급 요건 검증

    는 도메인 등 정책상 필요한 요건을 확인한다. 서명만으로 도메인 통제권이 증명되지는 않는다.

  3. 인증서 발급

    가 실제 발급할 TBS 내용을 구성하고 발급자 개인키로 서명한다.

  4. 인증서 전달

    서버는 연결에서 리프와 필요한 중간 인증서를 제시한다. 신뢰 앵커는 클라이언트의 신뢰 정책에서 온다.

  5. 경로와 이름 검증

    클라이언트가 발급 관계·기간·용도·제약·요청 이름을 검증한다.

  6. 개인키 소유 확인

    의 CertificateVerify 같은 연결별 증명으로 상대가 인증서와 대응하는 개인키를 가졌는지 확인한다.

03먼저 알아둘 용어와 구성요소

검증자가 사전에 신뢰하기로 정한 기준 공개키·인증서.
인증서가 표현하는 이름 등의 주체 대체 이름.
해당 인증서가 인지와 경로 길이 제약을 나타내는 확장.
공개키와 신청 정보를 담고 개인키로 서명한 인증서 발급 요청.
Certificate Authority; 인증서를 발급하고 서명하는 인증기관.
공개키 인증서와 확장 필드 구조를 정의하는 표준 계열.
공개키가 서명·키 암호화 등 어느 용도에 허용되는지 나타내는 확장.
Extended ; 서버 인증 등 더 구체적인 사용 목적을 나타내는 확장.
인증기관이 공표하는 폐기된 인증서 목록.
특정 인증서의 상태 정보를 질의·응답하는 프로토콜.
인증서 등의 이진 ASN.1 표현과 이를 ·경계 표시로 감싼 텍스트 표현.
LEARN THROUGH PRACTICE

브라우저 인증서 경고를 체인·이름·기간으로 나누기

HTTPS 경고를 무조건 암호화 실패로 해석하지 않고 신뢰 검증의 실패 지점을 찾는다.

실습 구성과 전제

  • 자신이 관리하는 실습 HTTPS 서버와 서버 인증서·중간 ·실습 파일을 준비한다.
  • 아래 도해와 브라우저 경고는 검증 원리와 실제 오류의 비교 자료이며 같은 서버의 연속 실행 증거가 아니다.

  1. 브라우저가 어떤 검증에서 멈췄는지 읽는다

    • 오류 코드와 접속 이름을 먼저 기록한다. NET::ERR_CERT_AUTHORITY_INVALID는 신뢰 가능한 발급 경로를 만들지 못했음을 조사할 출발점이다.
    • 원인은 신뢰 저장소에 없는 , 누락된 중간 인증서 등일 수 있다. 화면 하나로 개인키 손상이나 서버 침해를 확정하지 않는다.
    HTTPS 인증서와 브라우저 표시원본 크기로 보기 ↗
    • 주소는 HTTPS로 시작하지만 브라우저에 '연결이 비공개로 설정되어 있지 않습니다'가 표시된다.
    • 오류 코드가 NET::ERR_CERT_AUTHORITY_INVALID이므로 단순 HTTP 미사용 여부와 CA 신뢰 문제를 구분해야 한다.
    확인 기준

    경고를 무시해 접속하는 것을 해결로 기록하지 않는다.

  2. 인증서 필드와 체인을 따로 검사한다

    • Subject·Issuer는 표시 이름이며, 실제 서버 이름 비교에는 을 본다. 기간은 현재 시계와 Not Before·Not After를 비교한다.
    • 신뢰 앵커는 클라이언트가 신뢰하도록 설정한 값이다. 서버가 루트 인증서를 함께 보낸다는 사실만으로 신뢰가 생기지 않는다.
    shell
    openssl 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→서버 인증서로 그려져 있다.
    • 검증 항목은 서명 체인 외에 서버 이름·기간·용도 제한·폐기 상태를 포함한다.
    확인 기준

    체인 검증 성공과 이름 검증 성공을 각각 기록한다.

  3. 수정한 조건만 재시험한다

    • 누락된 중간 인증서를 보완했다면 서버가 보내는 체인을 다시 확인한다. 실습 신뢰를 추가했다면 그 클라이언트의 신뢰 저장소 변경 범위를 기록한다.
    • 이름이나 만료 조건까지 동시에 바꾸면 어느 변경이 경고를 없앴는지 알기 어렵다. 각 실패 조건을 분리해 재시험한다.
    확인 기준

    체인··기간이 모두 맞는 상태에서만 정상으로 판정한다.

실습에서 확인한 동작 원리

  • HTTPS 사용과 인증서 신뢰 성공은 별개다.
  • 오류 코드를 검증 조건에 연결하면 불필요한 설정 변경을 줄일 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

핸드셰이크의 암호화 경계와 인증 실패 위치 찾기

메시지 순서를 패킷 관찰 가능 범위와 연결하고, 인증서 오류가 발생하는 단계를 설명한다.

실습 구성과 전제

  • 자신의 실습 서버에 정상 HTTPS 연결을 한 번 만들고 PCAP를 저장한다.
  • 전체 핸드셰이크 도해를 기준으로 하되 재개 연결·PSK· 1.2는 별도로 구분한다.

  1. 암호화되기 전 협상 필드를 찾는다

    • 에서 ClientHello와 ServerHello의 supported_versions, cipher suite, key_share를 비교한다. 구버전 호환 필드만 보고 1.2라고 단정하지 않는다.
    • ClientHello는 제안, ServerHello는 선택 결과다. 양쪽이 합의한 키 공유로 이후 핸드셰이크 보호 키를 도출한다.
    text
    tls.handshake.type == 1 || tls.handshake.type == 2

    표시 필터 예시. 저장된 자신의 실습 PCAP에서 사용한다.

    TLS 1.3 핸드셰이크 · TLS 1.3 Handshake의 전체 흐름원본 크기로 보기 ↗
    • ClientHello와 ServerHello 다음에 'Handshake 암호화 키 생성' 경계가 표시된다.
    • CertificateVerify와 Finished는 서로 다른 메시지로 그려져 있어 키 소유 증명과 핸드셰이크 무결성 확인을 나누어 읽을 수 있다.
    확인 기준

    같은 .stream에서 협상 버전과 키 공유를 확인한다.

  2. 안 보이는 메시지와 실패한 메시지를 구분한다

    • 에서는 ServerHello 뒤의 인증서 메시지도 보통 암호화돼 보인다. 키 로그가 없는 캡처에서 Certificate가 보이지 않는다는 이유만으로 서버가 인증서를 생략했다고 단정하지 않는다.
    • 실습 클라이언트의 브라우저 오류와 패킷 시각을 연결한다. 인증서 경고는 전송 암호화의 유무와 다른 판단이다.
    HTTPS 인증서와 브라우저 표시원본 크기로 보기 ↗
    • HTTPS 주소에서도 CA 신뢰 오류가 표시된다.
    • 경고 화면에는 협상 cipher suite나 Finished 성공 여부가 나타나지 않는다. 이 정보는 패킷·클라이언트 진단으로 보완해야 한다.
    확인 기준

    캡처 가시성 한계와 실제 인증 실패를 보고서에서 분리한다.

  3. 인증 성공 후 애플리케이션 동작을 확인한다

    • 핸드셰이크가 끝나도 HTTP 인가나 로그인 성공이 보장되지는 않는다. 연결 성립→서버 신뢰→애플리케이션 응답을 각각 판정한다.
    • 복호화 가능한 실습 PCAP에서는 정상 요청의 응답을 확인하고, 키 로그 파일은 학습 후 별도로 보호·정리한다.
    확인 기준

    성공과 HTTP 상태 코드를 같은 항목으로 합치지 않는다.

실습에서 확인한 동작 원리

  • 의 암호화 경계는 ServerHello 이후에 생긴다.
  • 신뢰 오류·복호화 자료 부재·애플리케이션 오류는 다른 현상이다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

인증서 준비 오류에서 대시보드와 이벤트 분석까지

설치 명령의 실행, 웹 화면 표시, 보안 이벤트 분석을 서로 다른 성공 조건으로 나누어 구성을 확인한다.

실습 구성과 전제

  • 자신이 관리하는 격리 에서 공식 배포본의 인증서 준비 스크립트와 설치 버전을 확인한다.
  • 아래 터미널과 로그인 화면은 구성 과정의 서로 다른 자료다. 같은 시각에 모든 구성 요소가 정상 동작했다는 증거로 묶지 않는다.

  1. 실행 거부가 난 위치를 파일 권한에서 찾기

    • ./파일은 커널에 그 파일의 직접 실행을 요청한다. 실행 비트, 상위 디렉터리 접근권, 마운트의 noexec, 보안 정책 등이 실행 허용에 영향을 준다.
    • bash 파일은 Bash가 파일 내용을 읽는 방식이다. 두 호출의 차이는 인증서 내용의 문제가 아니라 실행 경로의 문제를 좁히는 단서이며, 신뢰하지 않는 스크립트에 우회 실행을 적용하면 안 된다.
    bash
    ls -l ./wazuh-certs-tool.sh
file ./wazuh-certs-tool.sh
findmnt -T ./wazuh-certs-tool.sh

    원인 확인용 읽기 명령. 인증서 생성이나 권한 변경을 자동 실행하지 않는다.

    Wazuh 방화벽 연계 · Wazuh 와 방화벽 연계원본 크기로 보기 ↗
    • ./wazuh-certs-tool.sh -A 다음에 Permission denied가 표시되어, 이 호출로 인증서 생성이 완료되었다고 볼 수 없다.
    • 다음 줄은 bash로 같은 스크립트를 지정한다. 화면에 최종 생성 목록이 없으므로 재호출 자체와 생성 성공을 구분한다.
    확인 기준

    권한·마운트·스크립트 출처를 확인한 뒤 공식 설치 단계의 생성 파일과 종료 결과를 별도로 검사한다.

  2. 로그인 화면을 TLS와 애플리케이션 두 층으로 읽기

    • HTTPS 접속은 Dashboard의 웹 서비스에 도달했음을 보여 주지만, 인증서의 신뢰 체인·접속 이름·유효기간 검사는 별도다. 주소창의 경고를 비밀번호 오류로 해석하지 않는다.
    • 로그인 양식이 보이는 단계는 아직 인증 전이다. Indexer의 저장 상태나 Agent 연결 수는 로그인 이후 해당 관리 화면과 서비스 상태로 확인해야 한다.
    Wazuh 설치와 관리자 접속 · Wazuh/Audit원본 크기로 보기 ↗
    • Wazuh 로그인 양식과 가려진 비밀번호 입력란이 보인다. 인증 성공 후의 이벤트 목록은 아직 나타나지 않는다.
    • 브라우저 주소창에는 연결에 대한 주의 표시가 있다. 화면만으로 원인을 한 가지로 확정할 수 없어 인증서 세부 정보 확인이 필요하다.
    확인 기준

    인증서 검증 결과와 웹 로그인 결과를 따로 기록한다. 로그인 화면만으로 수집·분석·저장 전 구간 정상이라고 판정하지 않는다.

  3. Decoder와 Rule까지 한 이벤트를 따라가기

    • Server에서 -logtest에 승인된 샘플 한 줄을 입력하면 사전 해석, Decoder 필드 추출, Rule 일치 결과를 순서대로 볼 수 있다. 규칙을 고치기 전에 어떤 필드가 만들어졌는지 확인한다.
    • 이 도구의 성공은 분석 엔진의 해당 입력 시험이다. 실제 Agent가 같은 형식의 로그를 보내는지, 경보가 Indexer에 저장되는지는 이벤트 식별값과 시각으로 추가 추적한다.
    bash
    sudo /var/ossec/bin/wazuh-logtest

    설치된 Server에서 분석 시험기를 여는 예. 입력에는 비밀값을 제거한 실습 로그를 사용한다.

    확인 기준

    Phase별 결과와 실제 경보 문서의 rule.id·agent·시각을 비교한다. 실습 출력이 없는 단계는 재현 과제로 남긴다.

실습에서 확인한 동작 원리

  • 실행 권한· 신뢰·사용자 로그인·보안 이벤트 수집은 실패 위치가 서로 다르다.
  • 단일 로그의 규칙 일치와 실제 파이프라인 끝의 검색 성공을 각각 검증해야 탐지 누락을 좁힐 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 경로 A: 신뢰 앵커 R→중간 I→서버 S로 이어지고 I의 =true, pathLenConstraint=0이라고 가정한다.
  • 서버 발급: I 뒤에는 최종 S만 있으므로 중간 길이 제한 0 자체를 위반하지 않는다. 다른 검증 조건은 여전히 필요하다.
  • 경로 B: I가 다른 비자체발급 중간 J를 만들고 J가 S를 발급하면 R→I→J→S가 된다.
  • 길이 위반: I 아래에 J라는 중간 가 하나 있으므로 I의 pathLenConstraint=0 조건과 맞지 않는다.
  • 판정 구분: 서명이 모두 수학적으로 맞아도 경로 제약 때문에 거부할 수 있다. 서명 오류와 정책·제약 오류는 다른 실패다.

05혼동하기 쉬운 점과 확인 기준

  • 앵커 집합: 운영체제·브라우저·런타임별 신뢰 저장소와 배포된 루트가 같은지 확인한다.
  • 서버 체인: 서버가 제공한 중간 인증서의 순서·누락·대체 경로를 확인한다. 다른 PC의 캐시가 누락을 우연히 가릴 수도 있다.
  • 요청 식별자: 실제 접속 이름·SNI·을 대조한다. 같은 IP의 다른 가상 호스트에 접속했다면 다른 인증서가 반환될 수 있다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

전자서명과 PKI 인증서 읽기전자서명은 데이터와 서명키의 관계를 검증한다. PKI는 공개키를 이름과 연결하고 그 연결을 신뢰하는 체계를 제공한다.상세 노트 읽기 →
READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

표준

RFC 5280: Basic Constraints와 인증 경로

중간 의 ·pathLenConstraint를 읽고 서명 유효성과 체인 정책 유효성을 나누어 판단할 수 있다.

읽으면서 확인할 것
  • pathLenConstraint=0이 제한하는 중간 수
  • 최종 인증서와 비자체발급 중간 의 구분
  • 6절의 경로 검증과 신뢰 앵커 입력

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.