이 페이지에서
디지털 인증서 검증 이해하기
MX 시리즈 디바이스는 Junos OS 릴리스 16.1R3을 응시하면서 디지털 인증서 검증을 지원합니다. IKE 협상 중에 MX 시리즈 디바이스의 PKI 데몬은 VPN 피어에서 수신한 X509 인증서를 검증합니다. 수행된 인증서 검증은 RFC 5280, 인터넷 X.509 공개 키 인프라 인증서 및 CRL(Certificate Revocation List) 프로필에 명시되어 있습니다. 기본 인증서 및 인증서 체인 검증에는 서명 및 날짜 검증과 해지 점검이 포함됩니다. 이 주제에서는 PKI 데몬이 수행하는 추가 디지털 인증서 검증에 대해 설명합니다.
정책 검증
X509 인증서에는 선택적 정책 검증 필드가 포함될 수 있습니다. 정책 검증 필드가 있는 경우, 최종 엔터티(EE) 인증서 및 CA(Intermediate Certificate Authority) 인증서를 포함한 전체 인증서 체인에 대해 정책 검증이 수행됩니다. 정책 검증은 루트 인증서에 적용되지 않습니다. 정책 검증은 EE 및 중간 CA 인증서가 공통 정책을 갖도록 보장합니다. 인증서 체인이 검증되는 공통 정책이 없으면 인증서 검증이 실패합니다.
정책 검증에 앞서 자체 서명된 루트 인증서, 중간 CA 인증서 및 EE 인증서를 포함하는 인증서 체인을 구축해야 합니다. 정책 검증은 자체 서명 루트 인증서가 발행한 중간 CA 인증서에서 시작하여 EE 인증서를 통해 계속됩니다.
정책 검증에 다음과 같은 선택적 인증서 필드가 사용됩니다.
policy-oids
설명 폴리시 필요
건너뛰기 자격증
이러한 필드는 다음 섹션에 설명되어 있습니다.
MX 시리즈 디바이스에 구성된 정책 OID
어떤 경우에는 피어의 알려진 정책 개체 식별자(OID)가 있는 인증서만 수락하는 것이 바람직할 수 있습니다. 이 선택적 구성을 사용하면 피어로부터 수신한 인증서 체인에 MX 시리즈 디바이스에 구성된 하나 이상의 정책 OID가 포함된 경우에만 인증서 검증이 성공할 수 있습니다.
MX 시리즈 디바이스에서 정책 OID는 [edit security ike policy policy-name certificate] 계층 수준의 구성 문을 가진 policy-oids IKE 정책에서 구성됩니다. 최대 5개의 정책 OID를 구성할 수 있습니다. 피어의 인증서가 성공적으로 검증되려면 피어의 인증서 체인에 MX 시리즈 디바이스에 구성된 정책 OID 중 하나 이상을 포함해야 합니다. 인증서의 정책 oids 필드는 선택 사항입니다. MX 시리즈 디바이스에서 정책 OID를 구성하지만 피어의 인증서 체인에 정책 OID가 포함되어 있지 않은 경우 인증서 검증이 실패합니다.
MX 시리즈 디바이스에 구성된 정책 OID 없음
MX 시리즈 디바이스에 정책 OID가 구성되지 않은 경우 인증서 체인에서 필요한 ExplicitPolicy 필드가 발생할 때마다 정책 검증이 시작됩니다. 인증서에는 하나 이상의 인증서 정책 OID가 포함될 수 있습니다. 정책 검증이 성공하려면 인증서 체인에 공통 정책 OID가 있어야 합니다.
그림 1 은 루트 CA, 3개의 중간 CA 및 EE에 대한 인증서로 구성된 인증서 체인을 보여줍니다. Int-CA-2에 대한 CA 인증서에는 요구ExplicitPolicy 필드가 포함되어 있습니다. 따라서 정책 검증은 Int-CA-2에서 시작하여 EE-1을 통해 계속됩니다. Int-CA-2의 인증서에는 정책 OID P1, P2 및 P3가 포함됩니다. Int-CA-3의 인증서에는 정책 OID P2, P3 및 P4가 포함됩니다. EE-1 인증서에는 정책 OID P2 및 P5가 포함됩니다. 정책 OID P2는 검증되는 인증서에 공통적이기 때문에 정책 검증이 성공합니다.
중간 CA 인증서의 선택적 skipCerts 필드는 정책 검증에서 제외해야 하는 현재 CA 인증서를 포함한 인증서 수를 나타냅니다. 건너뛰기 인증 이 0이면 정책 검증은 현재 인증서에서 시작됩니다. skipCerts 가 1인 경우, 현재 인증서는 정책 검증에서 제외됩니다. skipCerts 필드 값은 모든 중간 CA 인증서에서 확인됩니다. 현재 제외할 인증서 수보다 낮은 skipCerts 값이 발생하면, 더 낮은 skipCerts 값이 사용됩니다.
그림 2 는 루트 CA, 4개의 중간 CA 및 EE로 구성된 인증서 체인을 보여줍니다. Int-CA-1의 skipCerts 값은 12이며, Int-CA-1 인증서를 포함한 12개의 인증서를 건너뜁니다. 그러나 건너뛰기 자격증 값은 체인의 모든 중간 CA 인증서에서 확인됩니다. Int-CA-2의 skipCerts 값은 12보다 낮은 2이므로 이제 2개의 인증서를 건너뜁니다. Int-CA-4의 skipCerts 값은 5이며 이는 2보다 크므로 Int-CA-4 skipCerts 값은 무시됩니다.
정책 검증
MX 시리즈 디바이스에서 정책 OID가 구성되면 인증서 필드에 는 ExplicitPolicy가 필요하며 건너뛰기 인증 은 무시됩니다.
경로 길이 검증
인증서 검증에는 루트 CA, 하나 이상의 선택적 중간 CA 및 EE 인증서를 포함하는 인증서 체인이 포함될 수 있습니다. 구축 시나리오에 따라 중간 SA의 수가 증가할 수 있습니다. 경로 길이 검증은 인증서 검증에 관련된 중간 인증서의 수를 제한하는 메커니즘을 제공합니다. path-length 는 X509 인증서의 선택적 필드입니다. 경로 길이 값은 인증서 검증에 허용된 비-자체 서명된 중간 CA 인증서 수를 나타냅니다. 일반적으로 EE 인증서인 마지막 인증서는 경로 제한에 포함되지 않습니다. 루트 인증서에 경로 길이 값이 0인 경우 중간 CA 인증서는 허용되지 않습니다. 경로 길이 값이 1인 경우, 0 또는 1개의 중간 CA 인증서가 있을 수 있습니다.
경로 길이는 인증서 체인의 여러 CA 인증서에 존재할 수 있습니다. 경로 길이 검증은 항상 자체 서명된 루트 인증서로 시작됩니다. 경로 제한은 체인의 각 중간 인증서에서 1로 감소합니다. 중간 인증서에 현재 경로 제한보다 적은 경로 길이 값이 포함된 경우 새로운 제한이 적용됩니다. 한편, 경로 길이 값이 현재 경로 제한보다 크면 무시됩니다.
그림 3 은 루트 CA, 4개의 중간 CA 및 EE로 구성된 인증서 체인을 보여줍니다. 루트-CA의 경로 길이 값은 10이므로 인증서 검증에 허용되는 비-자체 서명 중간 CA 인증서의 초기 경로 제한은 10입니다. Int-CA-1에서 경로 제한은 10-1 또는 9입니다. Int-CA-1의 경로 길이 값은 4이며, 이는 경로 제한 9보다 적으므로 새 경로 제한이 4가 됩니다. Int-CA-2에서 경로 제한은 4-1 또는 3입니다. Int-CA-2의 경로 길이 값은 5이며, 이는 경로 제한 3보다 크므로 무시됩니다. Int-CA-3에서 경로 제한은 3-1 또는 2입니다. Int-CA-3의 경로 길이 값은 20이며, 이는 경로 제한 2보다 크므로 무시됩니다.
주요 사용량
EE 또는 CA 인증서의 키 사용 필드는 인증서에 포함된 키의 목적을 정의합니다.
EE 인증서
EE 인증서의 경우, 주요 사용 필드가 존재하지만 인증서에 디지털 서명 또는 비 거부 플래그가 포함되어 있지 않은 경우 인증서가 거부됩니다. 키 사용 필드가 없는 경우 키 사용이 확인되지 않습니다.
CA 인증서
키는 인증서 또는 CRL 서명 검증에 사용할 수 있습니다. PKI 데몬은 X509 인증서 검증 및 CRL 다운로드를 모두 담당하므로 인증서 또는 CRL을 검증하기 전에 핵심 사용량을 확인해야 합니다.
인증서 서명 검증
KeyCertSign 플래그는 CA 인증서를 인증서 서명 검증에 사용할 수 있음을 나타냅니다. 이 플래그가 설정되지 않으면 인증서 검증이 종료됩니다.
CRL 서명 검증
1단계 협상에서 참가자는 CRL(인증서 해지 목록)을 확인하여 IKE 교환 중에 수신된 인증서가 여전히 유효한지 확인합니다. CRL은 인증서 해지 검사로 CRL로 구성된 CA 프로필에 대해 주기적으로 다운로드됩니다. 다운로드한 CRL 파일은 디바이스로 다운로드하기 전에 확인해야 합니다. 검증 단계 중 하나는 CA 인증서를 사용하여 CRL 서명을 검증하는 것입니다. 다운로드한 CRL은 CA 인증서의 개인 키로 서명되며 디바이스에 저장된 CA 인증서의 공용 키로 확인되어야 합니다. 다운로드한 CRL을 확인하기 위해 CA 인증서의 주요 사용 필드에 는 CRLSign 플래그가 포함되어야 합니다. 이 플래그가 없는 경우 CRL은 폐기됩니다.
발급자 및 주체 고유 이름 검증
피어로부터 수신한 인증서와 CA 서버에서 다운로드한 CRL 파일에 대해 서명 검증이 수행됩니다. 서명 검증에는 인증서 내 발급자의 고유 이름(DN) 또는 확인 중인 CRL을 기반으로 CA 데이터베이스에서 CA 인증서를 찾는 작업이 포함됩니다.
그림 4 는 발행자 DN을 기반으로 하는 CA 인증서에 대한 조회를 보여줍니다. EE 인증서에서 발행자 DN은 CA-1이며, 이는 체인에서 중간 CA 인증서의 제목 DN입니다. 중간 CA 인증서에서 발행자 DN은 CA-Root이며, 이는 체인에서 자체 서명된 Root-CA 인증서의 제목 DN입니다. CRL에서 발행자 DN은 CA-Root이며, 이는 자체 서명된 루트-CA 인증서의 주제 DN입니다.
발행자 또는 제목 DN에 대한 조회는 속성 값에 대해 다음 규칙을 따라야 합니다.
다른 ASN.1 유형(예: PrintableString 및 BMPString)으로 인코딩된 속성 값은 다른 문자열을 나타내는 것으로 가정됩니다.
PrintableString 유형으로 인코딩된 속성 값은 대소문자 구분이 아닙니다. 이러한 속성 값은 선행 및 마지막 공백을 제거하고 하나 이상의 연속된 공백의 내부 서브스트링을 단일 공간으로 변환한 후 비교됩니다.
PrintableString 이외의 유형으로 인코딩된 속성 값은 대소문자 구분입니다.