인증서 체인 생성 및 관리

루트 CA는 궁극적인 신뢰 앵커 역할을 하는 자체 서명 인증서입니다. 루트 CA 개인 키는 오프라인(망분리 시스템 또는 HSM)에 보관해야 합니다. 키가 손상되면 전체 PKI의 신뢰가 무너지기 때문입니다. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem"은 10년 동안 유효한 자체 서명 루트 인증서를 생성합니다.

중간 CA는 루트 CA가 서명하며 일상적인 인증서 발급에 사용됩니다. 먼저 중간 키와 CSR을 생성합니다: "openssl req -new -key intermediate_key.pem -out intermediate.csr". 그런 다음 루트 CA가 다음 명령으로 서명합니다: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

최종 엔터티 인증서(리프 인증서)는 특정 서버 또는 클라이언트를 위해 중간 CA가 서명합니다. 주체 대체 이름(SAN)을 포함한 서버 키와 CSR을 생성한 다음, 중간 CA로 서명합니다: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

루트 CA 개인 키는 오프라인으로 보관하며, 소수의 중간 CA 인증서에 서명할 때만 사용합니다. 일상적인 인증서 발급은 온라인 중간 CA가 수행합니다. 중간 CA가 손상되더라도 루트를 손상시키지 않고 해당 중간 CA를 폐지하고 교체할 수 있습니다. 루트 키는 온라인에 노출된 적이 없으므로 안전하게 유지됩니다.

"openssl ca" 명령은 "openssl x509 -req"보다 더 완전한 CA 작업 흐름을 제공합니다. 인증서 데이터베이스(index.txt)를 유지하고, 일련번호 파일에서 일련번호를 할당하며, CRL 생성을 처리합니다. 인증서 정책과 경로 길이 제한을 정의하는 CA별 섹션이 포함된 적절한 openssl.cnf 설정 파일이 필요합니다.

웹 서버용 완전한 인증서 체인 파일에는 최종 엔터티 인증서와 그 뒤를 잇는 중간 CA 인증서가 순서대로 들어가며, 루트 바로 앞에서 끝납니다. 브라우저에 루트 저장소가 미리 설치되어 있으므로 루트 인증서는 포함하지 않습니다. 연결 순서는 "cat server_cert.pem intermediate_cert.pem > chain.pem"입니다. 순서가 잘못되면 TLS 핸드셰이크가 실패합니다.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem"은 전체 체인을 검증합니다. "-untrusted" 플래그는 체인에 포함되어 있지만 아직 신뢰되지 않은 중간 인증서를 제공합니다. 검증에 성공하면 출력은 "server_cert.pem: OK"입니다. 일반적인 오류는 중간 인증서가 없거나 인증서가 만료되었음을 나타냅니다.

자주 발생하는 인증서 체인 문제는 다음과 같습니다: 중간 인증서 누락(서버가 리프 인증서만 전송), 잘못된 연결 순서(리프가 먼저 와야 함), 만료된 중간 인증서(리프 인증서 만료만 모니터링하므로 쉽게 놓침), 신뢰 저장소에 없는 자체 서명 인증서, 이름 불일치(인증서 SAN이 호스트 이름과 일치하지 않음). 이러한 문제는 모두 "openssl s_client -showcerts"로 진단할 수 있습니다.

PKCS#12(.pfx 또는 .p12)는 개인 키, 최종 엔터티 인증서 및 중간 인증서를 하나의 암호화된 파일로 묶는 컨테이너 형식입니다. 다음과 같이 생성합니다: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". IIS, .NET, Java 키 저장소 및 많은 엔터프라이즈 애플리케이션에서 필요로 합니다.

PEM은 Base64로 인코딩된 ASCII 형식이며 사람이 읽을 수 있고, 하나의 파일에 여러 객체를 담을 수 있습니다. Apache, nginx 및 OpenSSL 도구에서 사용됩니다. DER은 이진 형식으로 파일마다 하나의 객체만 포함하며, Java(JKS 가져오기), Android 및 일부 엔터프라이즈 도구에서 사용됩니다. PKCS#12/PFX는 여러 객체를 담는 암호화된 이진 컨테이너로, Windows와 IIS에서 사용됩니다. 배포하기 전에 대상 시스템이 요구하는 형식을 확인하십시오.

최신 CA는 발급한 모든 인증서를 전달하기 전에 Certificate Transparency(CT) 로그에 기록해야 합니다. 내부 사용을 위해 개인 CA를 만들 때는 CT 기록이 필요하지 않습니다. 그러나 공개용 인증서는 Chrome이 신뢰하려면 SCT가 포함되어 있어야 합니다. 개인 CA는 CT 요구 사항 없이 자체 정책을 사용할 수 있습니다.

nginx 서버용 TLS 인증서 체인 파일을 구성할 때 올바른 연결 순서는 무엇입니까?

루트 CA는 자체 서명되며 오프라인으로 보관하고 중간 CA에만 서명합니다. 중간 CA가 일상적인 발급을 처리합니다. 체인 파일에는 리프 인증서와 중간 인증서가 이 순서로 포함되며 루트는 생략합니다. "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem"으로 검증합니다. PKCS#12 번들은 Windows와 Java에서 사용할 키와 인증서를 묶습니다. 잘못된 체인 순서는 배포 실패의 흔한 원인이며 s_client -showcerts로 진단할 수 있습니다.