기본 공개 키 기반 구조 (PKI) 구축하기

소개

본 실습에서는 인터넷 보안, 특히 HTTPS 의 기반이 되는 공개 키 기반 구조 (Public Key Infrastructure, PKI) 의 기본 사항을 탐구합니다. PKI 는 디지털 인증서를 생성, 관리, 배포, 사용, 저장 및 취소하고 공개 키 암호화를 관리하는 데 필요한 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합입니다.

openssl 명령줄 도구를 사용하여 PKI 의 핵심 기능을 수행하는 실습 경험을 하게 됩니다. 여러분은 자체 인증 기관 (Certificate Authority, CA) 역할을 수행하고, 웹 서버용 인증서를 발급하며, 신뢰 체인 (chain of trust) 을 검증하고, 마지막으로 인증서를 취소할 것입니다. 모든 작업은 ~/project 디렉토리 내에서 수행됩니다.

PKI 기본 사항 이해하기

이 단계에서는 PKI 의 기본 개념을 다룹니다. 이 단계에서는 실행할 명령이 없으며, 실습을 시작하기 전에 탄탄한 이론적 기반을 구축하는 것이 목표입니다.

공개 키 기반 구조 (Public Key Infrastructure, PKI)

PKI 는 전자 통신 보안을 강화하기 위해 설계된 프레임워크입니다. 이는 **인증 기관 (Certificate Authority, CA)**을 통해 공개 키 암호화를 사용하여 공개 키를 해당 사용자 신원과 바인딩 (결합) 합니다. 이러한 바인딩은 등록 및 발급 절차를 통해 확립됩니다.

인증 기관 (Certificate Authority, CA)

인증 기관은 디지털 인증서를 발급하는 신뢰할 수 있는 주체입니다. CA 는 인증서 소유자 (subject) 와 해당 인증서에 의존하는 당사자 모두에게 신뢰받는 제 3 자 역할을 합니다. CA 의 주요 역할은 주어진 사용자에게 바인딩된 공개 키에 디지털 서명하고 이를 게시하는 것입니다.

디지털 인증서 (Digital Certificate)

디지털 인증서는 다음을 포함하는 전자 문서입니다 (종종 X.509 표준을 따름).

소유자의 공개 키.
소유자의 식별 정보 (이름 또는 호스트 이름 등).
발급자 (CA) 정보 및 디지털 서명.
유효 기간 (시작일 및 종료일).
고유한 일련번호.

CA 의 인증서 서명은 인증서에 포함된 공개 키가 인증서에 명시된 주체에 속함을 증명합니다.

신뢰 체인 (Trust Chain)

신뢰 체인 (또는 인증서 체인) 은 최종 개체 인증서 (예: example.com용) 에서 시작하여 루트 CA 인증서로 끝나는 일련의 인증서입니다.

루트 CA 인증서 (Root CA Certificate): 이는 궁극적인 권한인 루트 CA 의 자체 서명된 인증서입니다. 이러한 인증서는 브라우저 또는 운영 체제의 "신뢰 저장소 (trust store)"에 미리 설치되어 있습니다.
중간 CA 인증서 (Intermediate CA Certificate(s)): 대규모 CA 는 루트 키를 보호하기 위해 중간 CA 를 사용하여 최종 사용자에게 인증서를 발급하는 경우가 많습니다. 중간 인증서는 루트 CA 에 의해 서명됩니다.
최종 개체 인증서 (End-Entity Certificate): 이는 특정 서버나 사용자에게 발급된 인증서입니다. 이는 중간 CA(또는 더 간단한 설정에서는 루트 CA) 에 의해 직접 서명됩니다.

브라우저가 서버 인증서를 수신하면 발급자의 인증서를 확인하여 서명을 검증합니다. 이 체인을 따라 이미 신뢰 저장소에 있는 루트 CA 에 도달할 때까지 확인합니다. 체인이 유효하고 모든 서명이 일치하면 해당 서버는 신뢰할 수 있는 것으로 간주됩니다.

다음 단계에서는 자체 루트 CA 를 생성하게 됩니다.

인증 기관 (CA) 생성

이 단계에서는 인증 기관 (CA) 역할을 수행하고 그 기반 구성 요소인 개인 키 (private key) 와 자체 서명된 루트 인증서 (self-signed root certificate) 를 생성합니다. 모든 명령어는 터미널에서 실행되며, 모든 파일은 현재 디렉토리인 ~/project에 생성됩니다.

먼저 CA 의 개인 키를 생성합니다. 이 키는 PKI 에서 가장 중요한 비밀 정보이며, CA 가 발급하는 모든 인증서에 서명하는 데 사용됩니다.

openssl genpkey -algorithm RSA -out ca.key

다음으로, 자체 서명된 루트 인증서를 생성합니다. 루트 인증서는 궁극적인 신뢰 앵커 (anchor of trust) 이므로 자체 서명됩니다. 즉, 서명해 줄 상위 기관이 없습니다.

인증서를 생성하기 위해 다음 명령을 실행합니다. -subj 인수를 사용하여 대화형이 아닌 방식으로 인증서의 주체 정보를 제공합니다.

openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.pem -subj "/C=US/ST=California/L=MountainView/O=MyLab/CN=MyLabRootCA"

이 명령을 분석해 보겠습니다.

req: 인증서 서명 요청 (CSR) 및 인증서 생성 유틸리티입니다.
-x509: CSR 대신 자체 서명된 인증서를 출력합니다.
-new: 새 인증서를 생성합니다.
-nodes: "No DES"의 약자로, 개인 키에 암호 구문 (passphrase) 으로 암호화하지 않음을 의미합니다. 이는 실습의 단순화를 위한 것입니다.
-key ca.key: 서명에 사용할 개인 키를 지정합니다.
-sha256: 서명에 SHA-256 해시 알고리즘을 사용합니다.
-days 365: 인증서의 유효 기간을 365 일로 설정합니다.
-out ca.pem: 새 인증서의 출력 파일을 지정합니다.
-subj "/C=.../CN=...": 주체 세부 정보를 제공합니다. CN(Common Name) 은 주요 식별자이며, CA 의 경우 그 이름이 됩니다.

이제 CA 개인 키 (ca.key) 와 루트 인증서 (ca.pem) 를 갖게 되었습니다. 새 CA 인증서의 내용을 검사할 수 있습니다.

openssl x509 -in ca.pem -text -noout

출력을 스크롤하여 Issuer(발급자) 필드와 Subject(주체) 필드가 동일한지 확인하여 자체 서명되었음을 확인할 수 있습니다.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Subject Public Key Info:
            ...

서버 인증서 발급

이 단계에서는 서버 소유자를 시뮬레이션하여 인증서를 요청합니다. 서버용 개인 키와 인증서 서명 요청 (CSR) 을 생성한 다음, 이전 단계에서 만든 CA 를 사용하여 CSR 에 서명하고 유효한 인증서를 발급합니다.

먼저 서버용 개인 키를 생성합니다. 이 키는 서버 자체 내에서 비밀로 유지되어야 합니다.

openssl genpkey -algorithm RSA -out server.key

다음으로 인증서 서명 요청 (CSR) 을 생성합니다. CSR 은 공개 키와 조직 이름 및 도메인 이름과 같이 인증서에 포함될 기타 정보를 담고 있는 인코딩된 텍스트 블록입니다. CSR 은 서명을 위해 CA 로 전송됩니다.

openssl req -new -key server.key -out server.csr -subj "/C=US/ST=California/L=MountainView/O=MyWebServer/CN=example.com"

서버 인증서의 경우 CN(Common Name) 이 서버의 도메인 이름 (이 경우 example.com) 과 일치해야 한다는 점에 유의하십시오.

이제 CA 역할을 수행하여 CA 의 개인 키 (ca.key) 로 서버의 CSR(server.csr) 에 서명합니다. 이 작업을 통해 최종 서버 인증서 (server.crt) 가 생성됩니다.

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out server.crt -days 300 -sha256

새로운 옵션들을 검토해 보겠습니다.

x509 -req: OpenSSL 에게 CSR 을 처리하도록 지시합니다.
-in server.csr: 입력 CSR 파일입니다.
-CA ca.pem: 발급자로 사용할 CA 의 인증서입니다.
-CAkey ca.key: 서명에 사용할 CA 의 개인 키입니다.
-CAcreateserial: CA 가 발급하는 모든 인증서가 고유한 일련번호를 갖도록 보장하는 데 필요한 일련번호 파일 (ca.srl) 을 생성하고 관리합니다.
-days 300: 서버 인증서의 유효 기간입니다. 이는 CA 인증서의 유효 기간보다 짧아야 합니다.

마지막으로 새로 생성된 서버 인증서를 검사합니다.

openssl x509 -in server.crt -text -noout

출력에서 Issuer(발급자) 필드와 Subject(주체) 필드를 관찰하십시오. Issuer는 귀하의 CA(MyLabRootCA) 여야 하고, Subject는 귀하의 서버 (example.com) 여야 합니다. 이는 인증서가 귀하의 CA 에 의해 올바르게 발급되었음을 확인시켜 줍니다.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
        ...
    Signature Algorithm: sha256WithRSAEncryption
         ...

인증서 체인 검증

이 단계에서는 인증서 체인을 검증하는 방법을 배웁니다. 이는 클라이언트 (예: 웹 브라우저) 가 서버 인증서의 신뢰성을 판단하기 위해 수행하는 프로세스입니다. 클라이언트는 해당 인증서가 자신이 신뢰하는 CA 에 의해 서명되었는지 확인합니다.

이 확인 작업을 수행하기 위해 openssl verify 명령어를 사용할 수 있습니다. 신뢰하는 CA 를 알려주기 위해 루트 인증서를 제공해야 합니다.

server.crt를 ca.pem 루트 인증서와 대조하여 검증하려면 다음 명령을 실행합니다.

openssl verify -CAfile ca.pem server.crt

출력 결과는 다음과 같아야 합니다.

server.crt: OK

이 OK 상태는 다음을 확인시켜 줍니다.

server.crt 인증서가 ca.pem의 공개 키에 해당하는 개인 키로 실제로 서명되었습니다.
인증서가 만료되지 않았습니다.

이제 검증자가 신뢰하는 CA 목록에 우리의 CA 가 없을 경우 어떤 일이 발생하는지 살펴보겠습니다. -CAfile 옵션 없이 verify 명령을 실행하여 이를 시뮬레이션할 수 있습니다.

openssl verify server.crt

이번에는 명령이 다음과 유사한 오류와 함께 실패할 것입니다.

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 20 at 0 depth lookup: unable to get local issuer certificate
error server.crt: verification failed

"unable to get local issuer certificate" 오류는 시스템이 기본 신뢰 저장소에서 발급자 (MyLabRootCA) 의 인증서를 찾을 수 없었음을 의미합니다. 이는 클라이언트가 신뢰 체인을 구축하기 위해 루트 CA 인증서를 보유하는 것이 왜 필수적인지를 보여줍니다.

인증서 폐지 시뮬레이션

이 단계에서는 인증서를 폐기하는 방법을 배웁니다. 폐기 (Revocation) 는 인증서의 개인 키가 손상되었거나, 인증서가 자연 만료 전에 더 이상 필요하지 않을 때 사용되는 중요한 프로세스입니다. 이는 인증서 폐기 목록 (CRL, Certificate Revocation List) 을 사용하여 관리됩니다.

CRL 은 CA 가 발급하는 디지털 서명된 목록으로, 폐기된 모든 인증서의 일련번호를 포함합니다. 클라이언트는 CRL 을 다운로드하여 수신한 인증서가 여전히 유효한지 확인할 수 있습니다.

폐기를 관리하기 위해 openssl은 CA 의 데이터베이스 파일 (index.txt 및 serial) 을 어디서 찾을 수 있는지 알기 위해 작은 구성 파일이 필요합니다. 이 실습을 위한 설정 스크립트는 이미 필요한 디렉터리 (my-ca) 와 파일을 생성했습니다. 이제 구성 파일을 생성합니다.

cat 명령을 사용하여 my-ca.conf를 생성합니다.

cat << EOF > my-ca.conf
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = ./my-ca
database = \$dir/index.txt
serial = \$dir/serial
private_key = ca.key
certificate = ca.pem
default_md = sha256
policy = policy_anything
crl_extensions = crl_ext
default_crl_days = 30

[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ crl_ext ]
authorityKeyIdentifier=keyid:always
EOF

이 구성 파일은 OpenSSL 이 인증 기관 (CA) 으로 작동하는 방법을 알려줍니다. 각 섹션의 역할은 다음과 같습니다.

default_ca = CA_default: 기본 CA 구성 섹션을 가리킵니다.
dir = ./my-ca: 데이터베이스 파일용 CA 작업 디렉터리
database = $dir/index.txt: 인증서 데이터베이스 (발급/폐기된 인증서 추적)
serial = $dir/serial: 고유한 인증서 ID 를 위한 일련번호 파일
private_key = ca.key: 인증서 서명을 위한 CA 의 개인 키
certificate = ca.pem: CA 자체의 인증서 파일
default_md = sha256: 서명에 사용되는 해시 알고리즘 (SHA-256)
policy = policy_anything: 인증서 유효성 검사 규칙
crl_extensions = crl_ext: CRL 형식 지정 옵션
default_crl_days = 30: CRL 유효 기간 (30 일)
countryName = optional: 국가 코드
stateOrProvinceName = optional: 주/도
localityName = optional: 도시/위치
organizationName = optional: 조직 이름
organizationalUnitName = optional: 부서
commonName = supplied: 도메인/서버 이름 (필수)
emailAddress = optional: 이메일 주소
authorityKeyIdentifier=keyid:always: 검증을 위해 CRL 에 CA 식별자를 포함합니다.

이 구성 파일은 CA 의 "운영 설명서"입니다. OpenSSL 에게 키를 찾을 위치, 인증서를 저장하는 방법, 인증서 발급 및 폐기에 따를 규칙을 알려줍니다.

이제 서버 인증서 (server.crt) 를 폐기합니다. 이 명령은 인증서의 일련번호를 조회하여 index.txt 데이터베이스 파일에 폐기된 것으로 표시합니다.

openssl ca -config my-ca.conf -revoke server.crt

폐기가 확인되는 출력을 보게 될 것입니다.

폐기 후에는 업데이트된 CRL 을 생성하고 게시해야 합니다.

openssl ca -config my-ca.conf -gencrl -out my-ca.crl

이것은 폐기된 인증서 목록을 포함하는 파일 my-ca.crl을 생성합니다.

마지막으로, 서버 인증서를 다시 검증해 보겠지만, 이번에는 CRL 도 제공할 것입니다. 올바른 검증 프로세스는 폐기 여부를 확인해야 합니다.

openssl verify -CAfile ca.pem -CRLfile my-ca.crl -crl_check server.crt

이제 명령이 다음과 같은 명확한 메시지와 함께 실패합니다.

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 23 at 0 depth lookup: certificate revoked
error server.crt: verification failed

"certificate revoked" 오류는 우리의 폐기 프로세스가 성공했음을 확인시켜 줍니다. 클라이언트는 CRL 을 확인할 때 example.com에 대한 인증서가 더 이상 신뢰할 수 없음을 올바르게 식별했습니다.

요약

축하합니다! 공개 키 기반 구조 (PKI) 에 대한 기본 실습을 성공적으로 완료했습니다. 디지털 통신을 보호하는 기본 작업에 대한 실질적인 경험을 얻었습니다.

이 실습에서 다음 사항을 배웠습니다.

PKI, 인증 기관 (CA), 신뢰 체인의 핵심 개념 이해하기.
개인 키와 자체 서명 인증서를 생성하여 간단한 루트 CA 직접 구축하기.
CA 키로 인증서 서명 요청 (CSR, Certificate Signing Request) 에 서명하여 서버 인증서 발급하기.
openssl verify 명령을 사용하여 인증서의 신뢰 체인 검증하기.
인증서 폐기 목록 (CRL, Certificate Revocation List) 을 생성하고 사용하여 인증서를 폐기하고 폐기된 상태 확인하기.

이러한 기술은 보안 시스템을 관리하고 인터넷에서 신뢰가 어떻게 확립되는지 이해하기 위한 구성 요소입니다.

암호학의 기본 공개 키 기반 구조 (PKI)

소개