기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# AWS Private CA란 무엇인가요?
AWS Private CA 를 사용하면 온프레미스 CA 운영에 대한 투자 및 유지 관리 비용 없이 루트 및 하위 CAs를 포함한 프라이빗 인증 기관(CA) 계층 구조를 생성할 수 있습니다. 사설 CA는 다음과 같은 시나리오에서 유용한 최종 엔터티 X.509 인증서를 발급할 수 있습니다.
+ 암호화된 TLS 통신 채널 생성
+ 사용자, 컴퓨터, API 엔드포인트 및 IoT 디바이스 인증
+ 암호화 서명 코드
+ 인증서 해지 상태를 얻기 위한 온라인 인증서 상태 프로토콜(OCSP) 구현
AWS Private CA 작업은에서 AWS Management Console, AWS Private CA API를 사용하여 또는를 사용하여 액세스할 수 있습니다 AWS CLI.
**Topics**
+ [의 리전별 가용성 AWS Private Certificate Authority](#PcaRegions)
+ [와 통합된 서비스 AWS Private Certificate Authority](#PcaIntegratedServices)
+ [에서 지원되는 암호화 알고리즘 AWS Private Certificate Authority](#supported-algorithms)
+ [의 RFC 5280 규정 준수 AWS Private Certificate Authority](#RFC-compliance)
+ [에 대한 요금 AWS Private Certificate Authority](#PcaPricing)
+ [에 대한 용어 및 개념 AWS Private CA](PcaTerms.md)
## 의 리전별 가용성 AWS Private Certificate Authority
대부분의 AWS 리소스와 마찬가지로 사설 인증 기관(CAs)은 리전 리소스입니다. 하나 이상의 리전에서 사설 CA를 사용하려면 이러한 리전에서 CA를 생성해야 합니다. 리전 간에 사설 CA를 복사할 수 없습니다. AWS Private CA에 대한 리전별 가용성을 확인하려면 *AWS 일반 참조* 또는 [AWS 리전 표](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)에서 [AWS 리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#pca_region)를 방문하세요.
**참고**
ACM은 현재 AWS Private CA 가 아닌 일부 리전에서 사용할 수 있습니다.
## 와 통합된 서비스 AWS Private Certificate Authority
AWS Certificate Manager 를 사용하여 프라이빗 인증서를 요청하는 경우 해당 인증서를 ACM과 통합된 모든 서비스와 연결할 수 있습니다. 이는 AWS Private CA 루트에 연결된 인증서와 외부 루트에 연결된 인증서 모두에 적용됩니다. 자세한 내용은 AWS Certificate Manager 사용 설명서의 [통합 서비스를](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) 참조하세요.
또한 프라이빗 CA를 Amazon Elastic Kubernetes Service에 통합하여 Kubernetes 클러스터 내에서 인증서 발급을 제공할 수 있습니다. 자세한 내용은 [를 사용하여 Kubernetes 보호 AWS Private Certificate Authority](PcaKubernetes.md) 단원을 참조하십시오.
**참고**
Amazon Elastic Kubernetes Service는 ACM 통합 서비스가 아닙니다.
AWS Private CA API 또는를 사용하여 인증서를 AWS CLI 발급하거나 ACM에서 프라이빗 인증서를 내보내는 경우 원하는 위치에 인증서를 설치할 수 있습니다.
## 에서 지원되는 암호화 알고리즘 AWS Private Certificate Authority
AWS Private CA 는 프라이빗 키 생성 및 인증서 서명을 위해 다음과 같은 암호화 알고리즘을 지원합니다.
**지원되는 알고리즘**
| 프라이빗 키 알고리즘 | 서명 알고리즘 |
| --- | --- |
| ML\$1DSA\$144 ML\$1DSA\$165 ML\$1DSA\$187 RSA\$12048 RSA\$13072 RSA\$14096 EC\$1prime256v1 EC\$1secp384r1 EC\$1secp521r1 SM2(중국 리전 전용) | ML\$1DSA\$144ML\$1DSA\$165ML\$1DSA\$187 SHA256WITHRSASHA384WITHRSASHA512WITHRSASHA256WITHECDSA SHA384WITHECDSASHA512WITHECDSASM3WITHSM2 |
이 목록은 콘솔, API 또는 명령줄을 AWS Private CA 통해에서 직접 발급한 인증서에만 적용됩니다. 가에서 CA를 사용하여 인증서를 AWS Certificate Manager 발급 AWS Private CA하면 이러한 알고리즘을 일부만 지원합니다. 자세한 내용은 AWS Certificate Manager 사용 설명서의 [프라이빗 인증서 요청을](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html) 참조하세요.
**참고**
RSA 또는 ECDSA의 경우 지정된 서명 알고리즘 패밀리는 CA 프라이빗 키의 키 알고리즘 패밀리와 일치해야 합니다.
ML-DSA의 경우 해시 함수는 알고리즘 자체의 일부로 정의됩니다. ML-DSA에서 다른 해시 함수를 선택하는 옵션은 없습니다. APIs와의 이전 버전과의 호환성을 유지하기 위해 키 알고리즘 및 서명 알고리즘에 동일한 값이 사용됩니다.
## 의 RFC 5280 규정 준수 AWS Private Certificate Authority
AWS Private CA 는 [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280)에 정의된 특정 제약 조건을 적용하지 않습니다. 반대의 상황도 마찬가지입니다. 사설 CA에 해당되는 특정한 추가 제약 조건이 적용됩니다.
**적용**
+ [날짜 이후에 적용되지 않음](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5) [RFC 5280에](https://datatracker.ietf.org/doc/html/rfc5280) 따라 AWS Private CA 는 CA 인증서 발급 날짜 `Not After`보다 `Not After`일 늦은 날짜의 인증서 발급을 금지합니다.
+ [Basic constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9). AWS Private CA enforces 가져온 CA 인증서의 기본 제약 조건 및 경로 길이를 적용합니다.
기본 제약 조건은 인증서에 의해 식별된 리소스가 CA인지 여부와 인증서를 발급할 수 있는지 여부를 나타냅니다. AWS Private CA 로 가져온 CA 인증서에는 기본 제약 조건의 확장이 포함되어야 하며 확장은 `critical`로 표시되어야 합니다 . `critical` 플래그 외에도 다음과 같은 이유로 검증 예외와 함께 실패하여 기본 제약 조건을 set. AWS Private CA enforces로 설정해야 `CA=true` 합니다.
+ 확장은 CA 인증서에 포함되지 않습니다.
+ 확장은 `critical`로 표시되어 있지 않습니다.
경로 길이([pathLenConstraint](PcaTerms.md#terms-pathlength))는 가져온 CAs 인증서에서 다운스트림으로 존재할 수 있는 하위 CA 수를 결정합니다.는 다음과 같은 이유로 검증 예외와 함께 실패하여 경로 길이를 AWS Private CA 적용합니다.
+ CA 인증서를 가져오면 CA 인증서 또는 체인의 CA 인증서에서 경로 길이 제약 조건을 위반할 수 있습니다.
+ 인증서를 발급하면 경로 길이 제약 조건을 위반할 수 있습니다.
+ [이름 제약 조건은](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10) 인증 경로의 후속 인증서에 있는 모든 제목 이름이 위치해야 하는 이름 공간을 나타냅니다. 주체 고유 이름 및 주체 대체 이름에 제한이 적용됩니다.
**적용되지 않음**
+ [인증서 정책](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4). 인증서 정책은 CA가 인증서를 발급하는 조건을 규제합니다.
+ [anyPolicy를 금지합니다](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.14). CAs에 발급된 인증서에 사용됩니다.
+ [발급자 대체 이름](https://datatracker.ietf.org/doc/html/rfc5280#section-section-4.2.1.7)입니다. CA 인증서 발급자와 추가 자격 증명을 연결할 수 있습니다.
+ [정책 제약 조건](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.11). 이러한 제약 조건은 CA의 하위 CA 인증서 발급 능력을 제한합니다.
+ [정책 매핑.](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.5) CA 인증서에 사용됩니다. 하나 이상의 OIDs 각 페어에는 issuerDomainPolicy와 subjectDomainPolicy가 포함됩니다.
+ [Subject Directory 속성입니다](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.8). 주제의 식별 속성을 전달하는 데 사용됩니다.
+ [주체 정보 액세스](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.2). 확장이 표시되는 인증서의 주체에 대한 정보 및 서비스에 액세스하는 방법입니다.
+ [보안 주체 키 식별자(SKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2) 및 [인증 기관 키 식별자(AKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1). RFC는 CA 인증서에 SKI 확장이 포함되도록 요구합니다. CA에서 발급한 인증서에는 CA 인증서의 SKI. AWS does와 일치하는 AKI 확장이 포함되어야 합니다. CA 인증서에 SKI가 포함되어 있지 않으면 발급된 최종 엔터티 또는 하위 CA 인증서 AKI가 대신하여 발급자 퍼블릭 키의 SHA-1 해시가 됩니다.
+ [SubjectPublicKeyInfo](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1) 및 [보안 주체 대체 이름(SAN)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6). AWS Private CA 은 인증서를 발급할 때 유효성 검사를 수행하지 않고 제공된 CSR에서 SucjectPublicKeyInfo 및 SAN 확장을 복사합니다.
## 에 대한 요금 AWS Private Certificate Authority
계정에는 사설 CA를 생성한 시점부터 각 사설 CA에 대한 월별 요금이 청구됩니다. 발급한 각 인증서에 대해서도 요금이 청구됩니다. 이 요금에는 ACM에서 내보내는 인증서와 AWS Private CA API 또는 AWS Private CA CLI에서 생성하는 인증서가 포함됩니다. 삭제한 프라이빗 CA에 대해서는 요금이 부과되지 않습니다. 그러나 사설 CA를 복원하면 삭제부터 복원까지의 기간에 대한 요금이 청구됩니다. 액세스할 수 없는 프라이빗 키를 가진 프라이빗 인증서는 무료입니다. 여기에는 Elastic Load Balancing, CloudFront, API Gateway와 같은 [통합 서비스](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)와 함께 사용되는 인증서가 포함됩니다.
최신 AWS Private CA 요금 정보는 [AWS Private Certificate Authority 요금을](https://aws.amazon.com/private-ca/pricing/) 참조하세요. [AWS 요금 계산기](https://calculator.aws/#/createCalculator/certificateManager)를 사용하여 비용을 추정할 수도 있습니다.
# 에 대한 용어 및 개념 AWS Private CA
다음 용어와 개념은 작업 시 도움이 될 수 있습니다 AWS Private Certificate Authority.
**Topics**
+ [신뢰](#terms-trust)
+ [TLS 서버 인증서](#terms-tlscert)
+ [인증서 서명](#terms-signing)
+ [인증 기관](#terms-ca)
+ [루트 CA](#terms-rootca)
+ [CA 인증서](#terms-ca-cert)
+ [루트 CA 인증서](#terms-root)
+ [최종 엔터티 인증서](#terms-endentity)
+ [자체 서명된 인증서](#terms-selfsignedcert)
+ [프라이빗 인증서](#terms-pca-cert)
+ [인증서 경로](#terms-certpath)
+ [경로 길이 제약](#terms-pathlength)
## 신뢰
웹 브라우저가 웹 사이트의 자격 증명을 신뢰하려면 브라우저가 웹 사이트의 인증서를 확인할 수 있어야 합니다. 하지만 브라우저는 CA 루트 인증서로 알려진 소수의 인증서만 신뢰합니다. 인증 기관(CA)으로 알려진 신뢰할 수 있는 타사는 웹 사이트의 자격 증명을 확인하고 서명된 디지털 인증서를 웹 사이트 운영자에게 발행합니다. 그러면 브라우저는 디지털 서명을 점검하여 웹 사이트의 자격 증명을 확인할 수 있습니다. 확인에 성공하면 브라우저는 주소 표시줄에 자물쇠 아이콘을 표시합니다.
## TLS 서버 인증서
HTTPS 트랜잭션에서는 서버를 인증하기 위해 서버 인증서가 필요합니다. 서버 인증서는 인증서의 퍼블릭 키를 인증서의 보안 주체와 바인딩하는 X.509 v3 데이터 구조입니다. TLS 인증서는 인증 기관(CA)이 서명을 합니다. 여기에는 서버 이름, 유효 기간, 퍼블릭 키, 서명 알고리즘 등이 포함됩니다.
## 인증서 서명
디지털 서명은 인증서에 대한 암호화된 해시입니다. 서명은 인증서 데이터의 무결성을 확인하는 데 사용됩니다. 사설 CA는 다양한 크기의 인증서 내용에 대해 SHA256과 같은 암호화 해시 함수를 사용하여 서명을 생성합니다. 이 해시 함수는 효과적으로 위조 불가한 고정 크기 데이터 문자열을 생성합니다. 이 문자열을 해시라고 합니다. 그런 다음 CA는 개인 키로 해시 값을 암호화하고 암호화된 해시를 인증서와 연결합니다.
## 인증 기관
인증 기관(CA) 는 디지털 인증서를 발급하고 필요한 경우 해지합니다. 가장 일반적인 유형의 인증서는 ISO X.509 표준을 기반으로 합니다. X.509 인증서는 인증서 보안 주체의 ID를 확인하고 해당 ID를 공개 키에 바인딩합니다. 보안 주체는 사용자, 애플리케이션, 컴퓨터 또는 기타 장치일 수 있습니다. CA는 인증서 내용을 해시한 다음, 인증서의 퍼블릭 키와 관련된 프라이빗 키로 해당 해시를 암호화하여 인증서를 서명합니다. 보안 주체의 자격 증명을 확인해야 하는 웹 브라우저와 같은 클라이언트 애플리케이션은 공개 키를 사용하여 인증서 서명을 해독합니다. 그런 다음 인증서 내용을 해시하고 해시된 값을 해독된 서명과 비교하여 일치하는지 확인합니다. 인증서에 대한 자세한 내용은 [인증서 서명](#terms-signing) 섹션을 참조하세요.
AWS Private CA 를 사용하여 프라이빗 CA를 생성하고 프라이빗 CA를 사용하여 인증서를 발급할 수 있습니다. 프라이빗 CA는 조직 내에서 사용할 수 있는 프라이빗 SSL/TLS 인증서만 발급합니다. 자세한 내용은 [프라이빗 인증서](#terms-pca-cert) 단원을 참조하십시오. 또한 프라이빗 CA를 사용하려면 인증서가 필요합니다. 자세한 내용은 [CA 인증서](#terms-ca-cert) 단원을 참조하십시오.
## 루트 CA
인증서 발급의 기반이 되는 암호화 구성 요소 및 신뢰 루트입니다. 루트 CA는 인증서 서명(발급)을 위한 프라이빗 키와 루트 CA를 식별하고 프라이빗 키를 CA 이름에 바인딩하는 루트 인증서로 구성됩니다. 루트 인증서는 환경 내에 있는 각 엔터티의 신뢰 저장소에 배포됩니다. 관리자는 신뢰하는 CA만 포함하도록 신뢰 저장소를 구성합니다. 관리자는 해당 환경에 있는 엔터티의 운영 체제, 인스턴스 및 호스트 컴퓨터 이미지로 신뢰 저장소를 업데이트하거나 빌드합니다. 리소스는 상호 연결을 시도할 때 각 엔터티가 제시하는 인증서를 확인합니다. 클라이언트는 인증서의 유효 기간을 검사하고 인증서에서 신뢰 저장소에 설치된 루트 인증서까지의 체인이 존재하는지 여부를 확인합니다. 이러한 조건이 충족되면 리소스 간에 “핸드셰이크”가 수행됩니다. 이러한 핸드셰이크는 각 엔터티의 신원을 암호로 상대에게 증명하고, 이들 간에 암호화된 통신 채널(TLS/SSL)을 생성합니다.
## CA 인증서
인증 기관(CA) 인증서는 CA의 자격 증명 확인 및 인증서에 포함된 퍼블릭 키와 바인딩합니다.
AWS Private CA 를 사용하여 프라이빗 루트 CA 또는 프라이빗 하위 CA를 생성할 수 있으며, 각 CA는 CA 인증서로 지원됩니다. 하위 CA 인증서는 신뢰 체인에서 보다 상위에 있는 또 다른 CA 인증서에 의해 서명됩니다. 그러나 루트 CA의 경우 인증서는 자체 서명됩니다. 외부 루트 기관(예: 온프레미스에서 호스팅됨)을 설정할 수도 있습니다. 그런 다음 루트 기관을 사용하여 AWS Private CA에서 호스팅하는 하위 루트 CA 인증서에 서명할 수 있습니다.
다음 예제에서는 AWS Private CA X.509 CA 인증서에 포함된 일반적인 필드를 보여줍니다. CA 인증서의 경우 `Basic Constraints` 필드의 `CA:` 값은 `TRUE`로 설정된다는 점에 유의하십시오.
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4121 (0x1019)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Seattle, O=Example Company Root CA, OU=Corp, CN=www.example.com/emailAddress=corp@www.example.com
Validity
Not Before: Feb 26 20:27:56 2018 GMT
Not After : Feb 24 20:27:56 2028 GMT
Subject: C=US, ST=WA, L=Seattle, O=Examples Company Subordinate CA, OU=Corporate Office, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c0: ... a3:4a:51
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
F8:84:EE:37:21:F2:5E:0B:6C:40:C2:9D:C6:FE:7E:49:53:67:34:D9
X509v3 Authority Key Identifier:
keyid:0D:CE:76:F2:E3:3B:93:2D:36:05:41:41:16:36:C8:82:BC:CB:F8:A0
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
6:bb:94: ... 80:d8
```
## 루트 CA 인증서
인증 기관(CA)는 일반적으로 명확하게 정의된 상위-하위 관계에 있는 여러 다른 CA가 포함된 계층 구조 내에 존재합니다. 하위 또는 종속 CA는 상위 CA에서 인증되어 인증서 체인을 생성합니다. 계층 구조의 최상위에 있는 CA를 루트 CA라고 하며 해당 인증서를 루트 인증서라고 합니다. 이 인증서는 일반적으로 자체 서명됩니다.
## 최종 엔터티 인증서
최종 엔터티 인증서는 서버, 인스턴스, 컨테이너 또는 디바이스 같은 리소스를 식별합니다. CA 인증서와 달리 최종 엔터티 인증서를 사용해 인증서를 발급할 수 없습니다. 최종 엔터티 인증서의 다른 일반적인 용어는 "클라이언트" 또는 "잎" 인증서입니다.
## 자체 서명된 인증서
상위 CA 대신 발급자가 서명한 인증서입니다. CA에서 유지 관리하는 안전한 루트에서 발급된 인증서와 달리, 자체 서명된 인증서는 자체 루트의 역할을 하므로 유선 암호화를 제공하는 데는 사용할 수 있지만, ID를 확인하는 데는 사용할 수 없기 때문에 해지가 불가능하다는 심각한 한계가 있습니다. 보안 관점에서는 용납할 수 없습니다. 그러나 조직은 쉽게 생성할 수 있고, 전문 지식이나 인프라가 필요하지 않으며, 많은 애플리케이션에서 수용한다는 점에서 이를 사용합니다. 자체 서명된 인증서를 발급하기 위한 컨트롤은 없습니다. 이러한 인증서는 만료 날짜를 추적할 수 있는 방법이 없으므로 인증서를 사용하는 조직은 인증서 만료로 인한 가동 중단이라는 커다란 위험 부담을 안게 됩니다.
## 프라이빗 인증서
AWS Private CA 인증서는 조직 내에서 사용할 수 있지만 퍼블릭 인터넷에서는 신뢰할 수 없는 프라이빗 SSL/TLS 인증서입니다. 이를 사용하여 클라이언트, 서버, 애플리케이션, 서비스, 장치 및 사용자와 같은 리소스를 식별할 수 있습니다. 암호화된 보안 통신 채널을 구축할 때 각 리소스는 다음과 같은 인증서와 암호화 기술을 사용하여 다른 리소스에 대한 자격 증명을 증명합니다. 내부 API 엔드포인트, 웹 서버, VPN 사용자, IoT 디바이스 및 기타 여러 애플리케이션은 프라이빗 인증서를 사용하여 보안 운영에 필요한 암호화된 통신 채널을 설정합니다. 기본적으로 프라이빗 인증서는 공개적으로 신뢰되지 않습니다. 내부 관리자는 프라이빗 인증서를 신뢰하고 인증서를 배포하도록 애플리케이션을 명시적으로 구성해야 합니다.
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e8:cb:d2:be:db:12:23:29:f9:77:06:bc:fe:c9:90:f8
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=WA, L=Seattle, O=Example Company CA, OU=Corporate, CN=www.example.com
Validity
Not Before: Feb 26 18:39:57 2018 GMT
Not After : Feb 26 19:39:57 2019 GMT
Subject: C=US, ST=Washington, L=Seattle, O=Example Company, OU=Sales, CN=www.example.com/emailAddress=sales@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00...c7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Authority Key Identifier:
keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65
X509v3 Subject Key Identifier:
C6:6B:3C:6F:0A:49:9E:CC:4B:80:B2:8A:AB:81:22:AB:89:A8:DA:19
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://NA/crl/12345678-1234-1234-1234-123456789012.crl
Signature Algorithm: sha256WithRSAEncryption
58:32:...:53
```
## 인증서 경로
인증서에 의존하는 클라이언트는 최종 엔터티 인증서에서 중간 인증서 체인을 통해 신뢰할 수 있는 루트까지의 경로가 존재하는지 확인합니다. 클라이언트는 경로에 있는 각 인증서가 유효한지(해지되지 않았는지) 확인합니다. 또한 최종 엔터티 인증서가 만료되지 않았는지, 무결성을 갖추고 있는지(변조 또는 수정되지 않았는지), 인증서의 제약 조건이 적용되는지 확인합니다.
## 경로 길이 제약
CA 인증서에 대한 기본 제약 조건 *pathLenConstraint*는 아래 체인에 존재할 수 있는 하위 CA 인증서 수를 설정합니다. 예를 들어 경로 길이 제한 조건이 0인 CA 인증서에는 하위 CA가 있을 수 없습니다. 경로 길이 제한 조건이 있는 CA는 그 아래에 최대 1개의 하위 CA 수준을 가질 수 있습니다. [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)에서는 이를 “유효한 인증 경로에서 이 인증서를 따를 수 있는 자체 발급되지 않은 중간 인증서의 최대 수”로 정의합니다. 경로 길이 값에는 최종 엔터티 인증서가 제외되지만 검증 체인의 “길이” 또는 “깊이”에 대한 비공식 언어에는 최종 엔터티 인증서가 포함될 수 있어 혼란을 야기할 수 있습니다.