Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

인증서 유효성 검사

디지털 인증서 유효성 검사 이해

IKE 협상 중에 SRX 시리즈 방화벽의 PKI 데몬은 VPN 피어로부터 받은 X509 인증서의 유효성을 검사합니다. 수행되는 인증서 유효성 검사는 RFC 5280, 인터넷 X.509 공개 키 인프라 인증서 및 인증서 해지 목록(CRL) 프로필에 지정되어 있습니다. 기본 인증서 및 인증서 체인 유효성 검사에는 서명 및 날짜 유효성 검사와 해지 검사가 포함됩니다. 이 항목에서는 PKI 데몬이 수행하는 추가 디지털 인증서 유효성 검사에 대해 설명합니다.

정책 검증

X509 인증서에는 선택적 정책 유효성 검사 필드가 포함될 수 있습니다. 정책 유효성 검사 필드가 있는 경우, 최종 엔티티(EE) 인증서 및 중간 인증 기관(CA) 인증서를 포함한 전체 인증서 체인에 대해 정책 유효성 검사가 수행됩니다. 정책 유효성 검사는 루트 인증서에 적용되지 않습니다. 정책 유효성 검사는 EE 및 중간 CA 인증서에 공통 정책이 있는지 확인합니다. 유효성을 검사할 인증서 체인에 대한 공통 정책이 없으면 인증서 유효성 검사가 실패합니다.

정책 검증 전에 자체 서명된 루트 인증서, 중간 CA 인증서 및 EE 인증서를 포함하는 인증서 체인을 구축해야 합니다. 정책 유효성 검사는 자체 서명된 루트 인증서에서 발급한 중간 CA 인증서로 시작하여 EE 인증서를 통해 계속됩니다.

다음 선택적 인증서 필드는 정책 유효성 검사에 사용됩니다.

  • policy-oids

  • requireExplicitPolicy

  • skipCerts

이러한 필드는 다음 섹션에서 설명합니다.

SRX 시리즈 방화벽에 구성된 정책 OID

경우에 따라 피어에서 알려진 정책 개체 식별자(OID)가 있는 인증서만 수락하는 것이 바람직할 수 있습니다. 이 선택적 구성을 사용하면 피어로부터 수신한 인증서 체인에 SRX 시리즈 방화벽에 구성된 하나 이상의 정책 OID가 포함된 경우에만 인증서 검증이 성공할 수 있습니다.

SRX 시리즈 방화벽에서 정책 OID는 [] 계층 수준의 구성 문을 사용하여 IKE(Internet Key Exchange) 정책에서 구성됩니다.policy-oidsedit security ike policy policy-name certificate 최대 5개의 정책 OID를 구성할 수 있습니다. 피어의 인증서가 성공적으로 검증되려면 피어의 인증서 체인에 SRX 시리즈 방화벽에서 구성된 정책 OID 중 하나 이상이 포함되어야 합니다. 인증서의 필드는 선택 사항입니다.policy-oids SRX 시리즈 방화벽에서 정책 OID를 구성하지만 피어의 인증서 체인에 정책 OID가 포함되어 있지 않으면 인증서 검증이 실패합니다.

SRX 시리즈 방화벽에 구성된 정책 OID 없음

SRX 시리즈 방화벽에 정책 OID가 구성되지 않은 경우, 인증서 체인에서 필드가 발견될 때마다 정책 검증이 시작됩니다.requireExplicitPolicy 인증서에는 하나 이상의 인증서 정책 OID가 포함될 수 있습니다. 정책 유효성 검사가 성공하려면 인증서 체인에 공통 정책 OID가 있어야 합니다.

그림 1 에서는 루트 CA, 3개의 중간 CA 및 EE에 대한 인증서로 구성된 인증서 체인을 보여 줍니다. Int-CA-2에 대한 CA 인증서에는 필드가 포함되어 있으므로 정책 유효성 검사는 Int-CA-2로 시작하여 EE-1까지 계속됩니다.requireExplicitPolicy Int-CA-2에 대한 인증서에는 정책 OID P1, P2 및 P3이 포함되어 있습니다. Int-CA-3에 대한 인증서에는 정책 OID P2, P3 및 P4가 포함되어 있습니다. EE-1에 대한 인증서에는 정책 OID P2 및 P5가 포함되어 있습니다. 정책 OID P2는 유효성을 검사하는 인증서에 공통적이므로 정책 유효성 검사가 성공합니다.

그림 1: requireExplicitPolicy 필드를 사용한 정책 유효성 검사requireExplicitPolicy 필드를 사용한 정책 유효성 검사

중간 CA 인증서의 옵션 필드는 현재 CA 인증서를 포함하여 정책 검증에서 제외될 인증서 수를 나타냅니다.skipCerts 이 0이면 현재 인증서에서 정책 유효성 검사가 시작됩니다.skipCerts 이 1이면 현재 인증서가 정책 유효성 검사에서 제외됩니다.skipCerts 필드 값은 모든 중간 CA 인증서에서 확인됩니다.skipCerts 제외되는 현재 인증서 수보다 낮은 값이 발견되면 더 낮은 값이 사용됩니다.skipCertsskipCerts

그림 2 에서는 루트 CA, 4개의 중간 CA 및 EE로 구성된 인증서 체인을 보여 줍니다. Int-CA-1의 값은 12이며, Int-CA-1에 대한 인증서를 포함하여 12개의 인증서를 건너뜁니다.skipCerts 그러나 체인의 모든 중간 CA 인증서에서 값이 확인됩니다.skipCerts Int-CA-2의 값은 2로, 12보다 작으므로 이제 2개의 인증서를 건너뜁니다.skipCerts Int-CA-4의 값은 2보다 큰 5이므로 Int-CA-4 값은 무시됩니다.skipCertsskipCerts

그림 2: skipCerts 필드를 사용한 정책 검증skipCerts 필드를 사용한 정책 검증

SRX 시리즈 방화벽에서 정책 OID가 구성되면 인증서 필드 및 는 무시됩니다.requireExplicitPolicyskipCerts

경로 길이 검증

인증서 유효성 검사에는 루트 CA, 하나 이상의 선택적 중간 CA 및 EE 인증서를 포함하는 인증서 체인이 포함될 수 있습니다. 중간 CA의 수는 배포 시나리오에 따라 증가할 수 있습니다. 경로 길이 유효성 검사는 인증서 유효성 검사와 관련된 중간 인증서의 수를 제한하는 메커니즘을 제공합니다. 는 X509 인증서의 선택적 필드입니다.path-length 값 은 인증서 유효성 검증에 허용되는 자체 서명되지 않은 중간 CA 인증서의 수를 나타냅니다.path-length 일반적으로 EE 인증서인 마지막 인증서는 경로 제한에 포함되지 않습니다. 루트 인증서에 0 값이 포함되어 있으면 중간 CA 인증서가 허용되지 않습니다.path-length 값이 1이면 0개 또는 1개의 중간 CA 인증서가 있을 수 있습니다.path-length

path-length 는 인증서 체인의 여러 CA 인증서에 존재할 수 있습니다. 경로 길이 유효성 검사는 항상 자체 서명된 루트 인증서로 시작됩니다. 경로 제한은 체인의 각 중간 인증서에서 1씩 감소합니다. 중간 인증서에 현재 경로 제한보다 작은 값이 포함되어 있으면 새 제한이 적용됩니다.path-length 반면, 값이 현재 경로 제한보다 크면 무시됩니다.path-length

그림 3 은(는) 루트 CA, 4개의 중간 CA 및 EE로 구성된 인증서 체인을 보여줍니다. Root-CA의 값은 10이므로 인증서 유효성 검사에 허용되는 자체 서명되지 않은 중간 CA 인증서의 초기 경로 제한은 10입니다.path-length Int-CA-1에서 경로 제한은 10-1 또는 9입니다. Int-CA-1의 값은 4로, 경로 제한 9보다 작으므로 새 경로 제한은 4가 됩니다. Int-CA-2에서 경로 제한은 4-1 또는 3입니다. Int-CA-2의 값은 경로 제한 3보다 큰 5이므로 무시됩니다.path-lengthpath-length Int-CA-3에서 경로 제한은 3-1 또는 2입니다. Int-CA-3의 값은 20으로, 경로 제한 2보다 크므로 무시됩니다.path-length

그림 3: 경로 길이 검증경로 길이 검증

키 사용

EE 또는 CA 인증서의 키 사용 필드는 인증서에 포함된 키의 용도를 정의합니다.

  • EE 인증서의 경우, 키 사용 필드가 있지만 인증서에 또는 플래그가 포함되어 있지 않으면 인증서가 거부됩니다.digitalSignaturenonrepudiation 키 사용 필드가 없으면 키 사용을 선택하지 않습니다.

  • CA 인증서의 경우 인증서 또는 CRL 서명 유효성 검사에 키를 사용할 수 있습니다. PKI 데몬은 X509 인증서 유효성 검사와 CRL 다운로드를 모두 담당하므로 인증서 또는 CRL의 유효성을 검사하기 전에 키 사용을 확인해야 합니다.

    인증서 서명 유효성 검사에서 플래그는 CA 인증서를 인증서 서명 유효성 검사에 사용할 수 있음을 나타냅니다.keyCertSign 이 플래그를 설정하지 않으면 인증서 유효성 검사가 종료됩니다.

    CRL 서명 검증의 1단계 협상에서 참가자는 CRL(인증서 해지 목록)을 확인하여 IKE 교환 중에 받은 인증서가 여전히 유효한지 확인합니다. 인증서 해지 검사로 CRL을 사용하여 구성된 CA 프로필에 대해 CRL이 주기적으로 다운로드됩니다. 다운로드한 CRL 파일은 디바이스에 다운로드하기 전에 확인해야 합니다. 확인 단계 중 하나는 CA 인증서를 사용하여 CRL 서명의 유효성을 검사하는 것입니다. 다운로드한 CRL은 CA 인증서의 개인 키로 서명되며 디바이스에 저장된 CA 인증서의 공개 키로 확인해야 합니다. CA 인증서의 키 사용 필드에는 다운로드한 CRL을 확인하기 위한 플래그가 포함되어야 합니다.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은 자체 서명된 Root-CA 인증서의 주체 DN인 CA-Root입니다.

그림 4: 발급자 및 주체 DN 유효성 검사발급자 및 주체 DN 유효성 검사

발행자 또는 주제 DN에 대한 검색은 속성 값에 대해 다음 규칙을 따라야 합니다.

  • 서로 다른 ASN.1 형식(예: PrintableString 및 BMPString)으로 인코딩된 특성 값은 서로 다른 문자열을 나타내는 것으로 간주됩니다.

  • PrintableString 형식으로 인코딩된 특성 값은 대/소문자를 구분하지 않습니다. 이러한 속성 값은 선행 및 후행 공백을 제거하고 하나 이상의 연속 공백의 내부 부분 문자열을 단일 공백으로 변환한 후 비교됩니다.

  • PrintableString 이외의 형식으로 인코딩된 특성 값은 대/소문자를 구분합니다.

예: SRX 시리즈 방화벽에서 정책 OID를 구성하여 디지털 인증서 검증

경우에 따라 피어에서 알려진 정책 개체 식별자(OID)가 있는 인증서만 수락하는 것이 바람직할 수 있습니다. 이 선택적 구성을 사용하면 피어로부터 수신한 인증서 체인에 SRX 시리즈 방화벽에 구성된 하나 이상의 정책 OID가 포함된 경우에만 인증서 검증이 성공할 수 있습니다. 이 예에서는 SRX 시리즈 방화벽의 IKE(Internet Key Exchange) 정책에서 정책 OID를 구성하는 방법을 보여줍니다.

SRX 시리즈 방화벽에 구성된 정책 OID 중 하나 이상이 피어의 인증서 또는 인증서 체인에 포함되어 있는지 확인해야 합니다. 피어 인증서의 필드는 선택 사항입니다.policy-oids IKE(Internet Key Exchange) 정책에서 정책 OID를 구성하고 피어의 인증서 체인에 정책 OID가 포함되어 있지 않으면 피어에 대한 인증서 유효성 검사가 실패합니다.

요구 사항

시작하기 전에:

  • SRX 시리즈 방화벽에 Junos OS 릴리스 12.3X48-D10 이상을 사용하고 있는지 확인합니다.

  • IPsec VPN 터널을 구성합니다. 자동 키 IKE(Internet Key Exchange)를 사용한 IPSec VPN 구성 개요의 내용을 참조하십시오.자동 키 IKE(Internet Key Exchange)를 사용한 IPSec VPN 구성 개요 전체 IKE(Internet Key Exchange) 1단계 및 2단계 VPN 터널 구성은 이 예에 표시되지 않습니다.

개요

이 예는 정책 OID 2.16.840.1.101.3.1.48.2 및 5.16.40.1.101.3.1.55.2가 지정된 IKE 정책 구성을 보여줍니다. IKE(Internet Key Exchange) 정책 ike_cert_pol은 표시되지 않은 IKE(Internet Key Exchange) 제안 ike_cert_prop 참조합니다. SRX 시리즈 방화벽의 로컬 인증서는 lc-igloo-root입니다.

구성

절차

CLI 빠른 구성

이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣은 다음, 구성 모드에서 commit을 입력합니다.

단계별 절차

다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. 이를 수행하는 방법에 대한 지침은 CLI 사용자 가이드구성 모드에서 CLI 편집기 사용을 참조하십시오.

인증서 검증을 위한 정책 OID 구성하기:

  1. IKE(Internet Key Exchange) 정책을 구성합니다.

결과

구성 모드에서 show security ike policy ike_cert_pol 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.

검증

구성이 올바르게 작동하고 있는지 확인합니다.

CA 인증서 확인

목적

디바이스에 구성된 CA 인증서를 표시합니다.

작업

운영 모드에서 show security pki ca-certificate ca-profile ca-tmp 명령을 입력합니다.

정책 OID 검증 확인

목적

피어의 인증서가 성공적으로 검증되면 IKE 및 IPsec 보안 연결이 설정됩니다. 피어 인증서의 유효성 검사에 실패하면 IKE 보안 연결이 설정되지 않습니다.

작업

운영 모드에서 및 명령을 입력합니다.show security ike security-associationsshow security ipsec security-associations

의미

show security ike security-associations 명령은 모든 활성 IKE(Internet Key Exchange) 1단계 SA를 나열합니다. SA가 나열되어 있지 않은 경우, 1단계 설정에 문제가 있는 것입니다. 이 경우 시스템 로그에서 PKID_CERT_POLICY_CHECK_FAIL 메시지를 확인합니다. 이 메시지는 피어의 인증서 체인에 SRX 시리즈 방화벽에 구성된 정책 OID가 포함되어 있지 않음을 나타냅니다. 피어의 인증서 체인에 있는 값을 SRX 시리즈 방화벽에 구성된 값으로 확인합니다.policy-oids

피어의 인증서 체인에 선택적 필드인 필드가 포함되어 있지 않을 수도 있습니다.policy-oids 이 경우 SRX 시리즈 방화벽에 구성된 정책 OID가 있으면 인증서 검증이 실패합니다.