Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지 내용
 

디지털 인증서

디지털 인증서에 대해 학습하고 디지털 인증서를 구성하는 방법에 대해 알아봅니다.

디지털 인증서는 CA라고 하는 신뢰할 수 있는 제3자를 통해 신원을 확인하는 전자적 수단입니다. 또는 자체 서명된 인증서를 사용하여 ID를 증명할 수 있습니다.

수동 인증서 처리에는 PKCS10 요청 생성, CA에 제출, 서명된 인증서 검색 및 주니퍼 네트웍스 디바이스에 인증서 수동 로드가 포함됩니다. 배포 환경에 따라 온라인 인증서 등록에 SCEP 또는 CMPv2를 사용할 수 있습니다.

보안 VPN 연결을 설정할 때 디지털 인증서를 사용하여 ID를 인증하려면 다음을 수행합니다.

  • 로컬 인증서를 얻으려는 CA 인증서를 얻은 다음 CA 인증서를 디바이스에 로드합니다. CA 인증서에는 잘못된 인증서를 식별하기 위한 CRL이 포함될 수 있습니다.

  • 이전에 CA 인증서를 로드한 CA에서 로컬 인증서를 가져온 다음 디바이스에 로컬 인증서를 로드합니다. 로컬 인증서는 각 터널 연결과 함께 주니퍼 네트웍스 디바이스의 ID를 설정합니다.

수동으로 디지털 인증서 생성: 구성 개요

디지털 인증서를 수동으로 얻으려면:

  1. 디바이스에서 키 쌍을 생성합니다. 자체 서명된 디지털 인증서를 참조하십시오.

  2. CA 프로필을 생성하거나 CA와 관련된 정보가 포함된 프로필을 생성합니다. 예: CA 프로필 구성을 참조하십시오.

  3. 로컬 인증서에 대한 CSR을 생성하여 CA 서버로 전송합니다. 예: 로컬 인증서에 대한 CSR을 수동으로 생성하여 CA 서버로 보내기를 참조하십시오.

  4. 디바이스에 인증서를 로드합니다. 예: CA 및 로컬 인증서를 수동으로 로드를 참조하십시오.

  5. 자동 재등록을 구성합니다. 예제: SCEP를 사용하여 로컬 인증서 자동 갱신을 참조하십시오.

  6. 필요한 경우 디바이스에 인증서의 CRL을 로드합니다. 예: 디바이스에 CRL 수동 로드를 참조하십시오.

  7. 필요한 경우 CRL 위치로 CA 프로필을 구성합니다. 예: CRL 위치를 사용하여 인증 기관 프로필 구성을 참조하십시오.

Junos OS의 디지털 인증서

소규모 네트워크의 경우 IPsec 구성에서 사전 공유 키를 사용하는 것으로 충분한 경우가 많습니다. 그러나 네트워크가 성장함에 따라 로컬 라우터와 모든 신규 및 기존 IPsec 피어에 새로운 사전 공유 키를 추가하는 것이 어려울 수 있습니다. 디지털 인증서 구현은 IPsec 네트워크를 확장하는 데 도움이 됩니다.

디지털 인증서 구현은 PKI를 사용하며, PKI를 사용하려면 공개 키와 개인 키로 구성된 키 쌍을 생성해야 합니다. 키는 난수 생성기로 생성되며 데이터를 암호화하고 해독하는 데 사용됩니다. 디지털 인증서를 사용하지 않는 네트워크에서 IPsec 지원 디바이스는 개인 키를 사용하여 데이터를 암호화하고 IPsec 피어는 공개 키를 사용하여 데이터를 해독합니다.

디지털 인증서를 사용하여 사용자와 IPsec 피어는 CA에 CA의 공개 키가 포함된 CA 인증서를 보내달라고 요청합니다. 그런 다음 공개 키와 일부 추가 정보가 포함된 로컬 디지털 인증서를 등록하도록 CA에 요청합니다. CA는 요청을 처리할 때 CA의 개인 키를 사용하여 로컬 인증서에 서명합니다. 그런 다음 로컬 라우터에 CA 인증서와 로컬 인증서를 설치하고 원격 디바이스에 CA 인증서를 로드한 후 피어와 IPsec 터널을 설정할 수 있습니다.

IPSec 피어와의 피어링 관계를 요청하면 피어는 로컬 인증서의 복사본을 받습니다. 피어에 이미 CA 인증서가 로드되어 있으므로 CA 인증서에 포함된 CA의 공개 키를 사용하여 CA의 개인 키로 서명된 로컬 인증서의 암호를 해독할 수 있습니다. 결과적으로 피어는 이제 공개 키의 복사본을 갖게 됩니다. 피어는 데이터를 보내기 전에 공개 키로 데이터를 암호화합니다. 로컬 라우터가 데이터를 수신하면 개인 키를 사용하여 데이터를 해독합니다.

Junos OS에서 디지털 인증서를 처음 사용할 수 있도록 다음 단계를 구현해야 합니다.

  • CA 및 로컬 디지털 인증서를 요청하도록 CA 프로필 구성: 프로필에는 CA 또는 등록 기관(RA)의 이름 및 URL과 일부 재시도 타이머 설정이 포함됩니다.

  • 인증서 해지 목록 지원 구성 - 인증서 해지 목록(CRL)에는 만료일 전에 취소된 인증서 목록이 포함됩니다. 참여하는 피어가 CRL을 사용하는 경우 CA는 가장 최근에 발급된 CRL을 획득하고 피어의 디지털 인증서의 서명과 유효성을 확인합니다. CRL을 수동으로 요청 및 로드하거나, CRL 처리를 자동으로 처리하도록 LDAP 서버를 구성하거나, 기본적으로 활성화된 CRL 처리를 비활성화할 수 있습니다.

  • CA에서 디지털 인증서 요청 - 요청은 온라인 또는 수동으로 수행할 수 있습니다. 온라인 CA 디지털 인증서 요청은 SCEP(단순 인증서 등록 프로토콜) 형식을 사용합니다. CA 인증서를 수동으로 요청하는 경우 인증서도 수동으로 로드해야 합니다.

  • 개인/공개 키 쌍 생성 - 공개 키는 로컬 디지털 인증서에 포함되며 개인 키는 피어에서 받은 데이터를 해독하는 데 사용됩니다.

  • 로컬 디지털 인증서 생성 및 등록 - 로컬 인증서는 SCEP를 사용하여 온라인으로 처리하거나 PKCS-10(Public-Key Cryptography Standards #10) 형식으로 수동으로 생성할 수 있습니다. 로컬 인증서 요청을 수동으로 만드는 경우 인증서도 수동으로 로드해야 합니다.

  • IPSec 구성에 디지털 인증서 적용 - 로컬 디지털 인증서를 활성화하려면 사전 공유 키 대신 디지털 인증서를 사용하도록 IKE 제안을 구성하고, IKE 정책에서 로컬 인증서를 참조하고, 서비스 집합에서 CA를 식별합니다.

필요에 따라 다음을 수행할 수 있습니다.

  • 자동으로 재등록하도록 디지털 인증서 구성 - Junos OS 릴리스 8.5부터 디지털 인증서에 대한 자동 재등록을 구성할 수 있습니다.

  • Monitor digital certificate events and delete certificates and requests(디지털 인증서 이벤트 모니터링 및 인증서 및 요청 삭제) - 운영 모드 명령을 실행하여 디지털 인증서를 사용하여 설정된 IPSec 터널을 모니터링하고 인증서 또는 요청을 삭제할 수 있습니다.

루트 CA 인증서 생성

CLI에서 자체 서명 인증서를 정의하려면 다음 세부 정보를 제공해야 합니다.

  • 인증서 식별자(이전 단계에서 생성됨)

  • 인증서의 FQDN

  • 인증서를 소유하는 엔터티의 전자 메일 주소

  • 일반 이름 및 관련 조직

Junos OS CLI를 사용하여 루트 CA 인증서를 생성합니다.

  1. 작동 모드에서 로컬 디지털 인증서에 대한 PKI 공개 및 개인 키 쌍을 생성합니다.

    여기에서 다음 조합 중 하나를 선택할 수 있습니다.

    • 1024비트(RSA/DSA만 해당)

    • 2048비트(RSA/DSA만 해당)

    • 256비트(ECDSA만 해당)

    • 384비트(ECDSA만 해당)

    • 4096비트(RSA/DSA만 해당)

    • 521비트(ECDSA만 해당)

    본보기:

    또는
  2. 자체 서명된 인증서를 정의합니다.

    본보기:

    옵션을 구성 add-ca-constraint 하여 인증서를 사용하여 다른 인증서에 서명할 수 있는지 확인합니다.

  3. 구성 모드에서 로드된 인증서를 SSL 프록시 프로파일의 root-ca로 적용합니다.

    본보기:

  4. 루트 CA를 신뢰할 수 있는 CA로 클라이언트 브라우저로 가져옵니다. 루트 CA 인증서는 클라이언트 브라우저가 방화벽에서 서명한 인증서를 신뢰하는 데 필요합니다.

자체 서명된 SSL 인증서 수동 생성

주니퍼 네트웍스 디바이스에서 자체 서명된 SSL 인증서를 수동으로 생성하려면 다음과 같이 하십시오.

  1. 기본 연결을 구축합니다.
  2. 루트 로그인 액세스 권한이 있는 경우 다음 명령을 사용하여 자체 서명된 인증서를 수동으로 생성할 수 있습니다.

    인증서를 생성할 때 제목, 전자 메일 주소 및 도메인 이름 또는 IP 주소를 지정해야 합니다.

  3. 인증서가 올바르게 생성 및 로드되었는지 확인하려면 작동 명령을 입력하고 show security pki local-certificate HTTPS 웹 관리에서 을(를) 지정합니다 local-certificate .

지정된 위치로 인증서 내보내기

PKI 명령을 사용하여 자체 서명된 인증서를 생성하면 새로 생성된 인증서가 미리 정의된 위치(var/db/certs/common/local)에 저장됩니다.

다음 명령을 사용하여 인증서를 특정 위치(디바이스 내)로 내보냅니다. 인증서 ID, 파일 이름 및 파일 형식 유형(DER/PEM)을 지정할 수 있습니다.

루트 CA 인증서 구성

CA는 트리 구조의 형태로 여러 인증서를 발급할 수 있습니다. 루트 인증서는 트리의 최상위 인증서이며 개인 키는 다른 인증서에 sign 사용됩니다. 루트 인증서 바로 아래에 있는 모든 인증서는 루트 인증서의 서명 또는 신뢰성을 상속합니다. 이것은 아이덴티티와 비슷 notarizing 합니다.

루트 CA 인증서를 구성하려면 다음을 수행합니다.

  1. 루트 CA 인증서 가져오기(또는 가져오기를 통해)

    • Junos OS CLI를 사용하여 루트 CA 인증서를 생성할 수 있습니다.

    • 외부 CA에서 인증서를 가져옵니다(이 항목에서는 다루지 않음).

  2. 루트 CA를 SSL 프록시 프로파일에 적용합니다.

인증서 체인 구현

SSL 포워드 프록시는 인증서 체인 구현을 지원합니다. 인증서 체인 개념과 방화벽에서 이를 구성하는 방법에 대해 논의해 보겠습니다.

  • 인증 기관(CA) - CA는 신뢰할 수 있는 제3자로서 엔터티(예: 웹사이트, 이메일 주소, 회사 또는 개인)의 ID를 검증하고 암호화 키를 바인딩하여 디지털 인증서를 발급합니다. 조직에서 CA 서버를 소유하는 경우 자체 CA가 되어 자체 서명된 인증서를 사용합니다.

  • 루트 인증서 - 루트 인증서는 신뢰할 수 있는 CA에서 발급한 인증서입니다. 루트 인증서는 트리의 최상위 인증서이며 개인 키는 다른 인증서에 서명하는 데 사용됩니다. 루트 인증서 바로 아래에 있는 모든 인증서는 루트 인증서의 서명 또는 신뢰성을 상속합니다. 이러한 인증서는 두 끝점 간의 연결을 설정하는 데 사용됩니다.

  • 중간 CA 인증서 - 중간 CA 인증서는 EE 인증서를 검증하기 위해 신뢰할 수 있는 루트가 서명한 하위 인증서입니다.

  • 인증서 체인 - 인증서 체인은 SSL 인증서, 중간 인증서 및 루트 인증서를 포함하는 인증서의 정렬된 목록입니다. 일부 CA는 루트 인증서로 서명하지 않고 대신 중간 인증서를 사용합니다. 중간 CA는 루트 CA 인증서 대신 인증서에 서명할 수 있습니다. 루트 CA는 중간 인증서에 서명하여 신뢰 체인을 형성합니다.

    브라우저, 애플리케이션 및 모바일 장치와 같은 연결 장치가 인증서를 신뢰할 수 있도록 SSL 인증서와 동일한 서버에 중간 인증서를 설치해야 합니다.

연결을 시작하면 연결 디바이스는 인증서가 진짜인지, 브라우저의 신뢰할 수 있는 저장소에 내장된 신뢰할 수 있는 CA에서 발급했는지 확인합니다.

SSL 인증서가 신뢰할 수 있는 CA에서 발급되지 않은 경우 연결 디바이스는 SSL 인증서가 중간 CA에서 발급되고 이 중간 CA가 루트 CA에서 서명되었는지 계속 확인합니다. 검사는 디바이스가 루트 CA를 찾을 때까지 계속됩니다. 디바이스가 루트 CA를 찾으면 보안 연결이 설정됩니다. 디바이스가 루트 CA를 찾지 못하면 연결이 끊어지고 웹 브라우저에 잘못된 인증서 또는 신뢰할 수 없는 인증서에 대한 오류 메시지가 표시됩니다.

SSL 시작을 위한 인증서 체인 지원

SSL 프록시 모드에서 서버는 인증서 체인의 유효성 검증을 위해 중간 인증서를 포함한 전체 인증서 체인을 클라이언트로 보냅니다.

비프록시 모드에서 SSL 시작 단계 중에 클라이언트는 요청된 경우 클라이언트 인증서만 서버에 보냅니다. 그런 다음 서버는 클라이언트 인증서를 인증하기 위해 신뢰할 수 있는 CA 목록을 가져옵니다.

SSL이 시작되는 동안 디바이스는 인증서 체인을 생성하여 클라이언트 인증서와 함께 서버로 보냅니다. SSL 시작 단계 중 인증서 체인을 사용하면 서버가 체인의 중간 CA를 가져오지 않고도 인증서 체인의 유효성을 검증할 수 있습니다.

다음 예제에서는 브라우저가 인증서를 신뢰할 수 있도록 인증서 체인을 설치하는 방법을 보여 줍니다.

요구 사항

이 기능을 구성하기 전에 디바이스 초기화 이외의 특별한 구성은 필요하지 않습니다.

개요

이 예에서는 example.domain-1이라는 도메인이 있으며 도메인에 대한 인증서를 XYZ-Authority에서 구매하려고 합니다. 그러나 XYZ-Authority는 루트 CA가 아니며 방문하는 브라우저는 루트 CA 인증서만 신뢰합니다. 즉, 해당 인증서는 브라우저에 직접 포함되지 않으므로 명시적으로 신뢰할 수 없습니다.

이 경우 인증서 체인(중간 인증서)을 사용하여 다음과 같은 방식으로 신뢰가 설정됩니다.

위상수학

그림 1을 통해 이 체인을 시각화해 보겠습니다. 이 그림은 루트 CA 인증서에서 최종 사용자 인증서까지의 전체 인증서 체인을 보여줍니다. 체인은 최종 사용자 인증서에서 종료됩니다.

그림 1: 인증서 소유자에서 루트 CA Certificate chain in PKI showing hierarchy: End User Certificate, Intermediate CAs 1-3, leading to Root Certificate Authority. 까지의 인증 경로
표 1: 인증서 체인 세부 정보

사용자

인증서 사용

서명자

형

example.도메인-1

최종 사용자 인증서

XYZ 권한

최종 사용자 인증서 - CA에서 구매한 인증서

XYZ 권한

인증서-1

중간 CA-1

중간 인증서

중간 CA-1

인증서-2

중급 CA-2

중간 인증서

중급 CA-2

인증서-3

중급 CA-3

중간 인증서

중급 CA-3

증명서-4

root-example-authority입니다. 루트 CA입니다.

루트 인증서 - 인증서가 브라우저에 직접 포함되어 있으므로 장치가 명시적으로 신뢰할 수 있는 인증서입니다

example.domain-1 서버에 대한 최종 사용자 인증서를 설치할 때 모든 중간 인증서를 번들로 묶어 최종 사용자 인증서와 함께 설치해야 합니다. 인증서 체인에는 Certificate-1에서 Root-CA 인증서까지 모든 인증서가 포함됩니다. 웹 브라우저는 루트 CA를 신뢰하기 때문에 모든 중간 인증서도 암시적으로 신뢰합니다. SSL 인증서 체인이 잘못되었거나 손상된 경우 일부 디바이스에서 인증서를 신뢰하지 않습니다.

모든 인증서는 PEM 형식이어야 합니다.

연결된 인증서 파일을 디바이스로 가져올 때 CA는 서명된 서버 인증서에 추가해야 하는 체인으로 연결된 인증서 번들을 제공합니다. 서버 인증서는 결합된 파일에서 체인으로 연결된 인증서 앞에 나타나야 합니다.

SSL 인증서: 구성 개요

SSL 인증서 체인을 구성하려면 다음을 수행합니다.

  • 서명 인증서와 해당 키가 포함된 SSL 인증서를 CA에서 구입합니다.

  • 신뢰할 수 있는 CA 프로필 그룹을 구성합니다.

  • 장치에 서명 인증서와 키를 로드합니다.

  • PKI 메모리의 중간 및 루트 CA를 로드합니다. 이 인증서 파일에는 필요한 모든 CA 인증서가 PEM 형식으로 차례로 포함되어 있습니다.

  • 중간 또는 루트 CA 인증서에 대해 신뢰할 수 있는 CA 프로필을 생성합니다.

  • SSL 프록시 프로파일을 구성하고 보안 정책에 적용하여 CA에서 받은 서명 인증서를 사용하도록 디바이스를 설정합니다. SSL 포워드 프록시는 이 인증서 체인 정보(CA 인증서 프로필 이름)를 해당 SSL 프로필에 저장합니다. 보안 정책 구현의 일환으로 인증서 체인 정보 및 CA 인증서가 있는 SSL 프로필이 사용됩니다.

인증서 체인 처리에는 다음 프로세스가 포함됩니다.

  • 관리자가 인증서 체인과 로컬 인증서(서명 인증서)를 PKI 인증서 캐시에 로드합니다.

  • NSD(Network Security)는 SSL 프록시 프로파일에 구성된 서명 인증서에 대한 인증서 체인 정보를 제공하도록 PKI에 요청을 보냅니다.

이 예제에서는 CA에서 SSL 인증서를 이미 구입했다고 가정합니다.

디바이스에서 인증서 체인 구성

단계별 절차 Pls는 예제 구성 템플릿을 확인하고 그에 따라 제목을 배치/다시 작성합니다.

인증서 체인 구성:

  • 로컬 인증서를 PKI 메모리에 로드합니다.

    다음 메시지가 표시됩니다.

    인증서 ID는 SSL 프록시 프로필의 root-ca 섹션에서 사용됩니다.

  • PKI 메모리에 중간 또는 루트 CA 인증서를 로드합니다.

    CA 프로필에는 인증에 사용되는 인증서 정보가 포함됩니다. 여기에는 SSL 프록시가 새 인증서를 생성할 때 사용하는 공개 키가 포함됩니다.

    이 인증서를 인증서 체인으로 첨부할 수 있습니다.

  • CA 프로필 그룹을 SSL 프록시 프로필에 연결합니다. 신뢰할 수 있는 CA를 한 번에 하나씩 연결하거나 한 번에 모두 로드할 수 있습니다.

  • SSL 프록시 프로파일에서 서명 인증서를 root-ca로 적용합니다.

  • 보안 정책을 생성하고 정책에 대한 일치 기준을 지정합니다. 일치 기준으로 SSL 프록시를 활성화하려는 트래픽을 지정합니다. 이 예에서는 요구 사항에 따라 보안 영역을 이미 생성했다고 가정합니다.

    SSL 포워드 프록시는 이 인증서 체인 정보(CA 인증서 프로필 이름)를 각 SSL 프로필에 저장합니다. 보안 정책 구현의 일환으로 인증서 체인 정보 및 CA 인증서가 있는 SSL 프로필이 사용됩니다.

    연결하는 브라우저, 즉 클라이언트에서 인증서 체인을 볼 수 있습니다.

디지털 인증서 구성

디지털 인증서 개요

디지털 인증서는 CA라는 신뢰할 수 있는 타사를 통해 사용자를 인증하는 방법을 제공합니다. CA는 인증서 소유자의 ID를 확인하고 인증서에 "서명"하여 인증서가 위조 또는 변경되지 않았음을 증명합니다.

인증서에는 다음 정보가 포함됩니다.

  • 소유자의 DN입니다. DN은 고유 식별자이며 소유자의 일반 이름(CN), 소유자의 조직 및 기타 식별 정보를 포함하는 정규화된 이름으로 구성됩니다.

  • 소유자의 공개 키입니다.

  • 인증서가 발급된 날짜입니다.

  • 인증서가 만료되는 날짜입니다.

  • 발급 CA의 DN입니다.

  • 발급 CA의 디지털 서명입니다.

인증서의 추가 정보를 통해 수신자는 인증서를 수락할지 여부를 결정할 수 있습니다. 받는 사람은 만료 날짜를 기준으로 인증서가 여전히 유효한지 여부를 확인할 수 있습니다. 받는 사람은 발급 CA를 기반으로 사이트에서 CA를 신뢰하는지 여부를 확인할 수 있습니다.

인증서를 사용하여 CA는 소유자의 공개 키를 가져와서 자체 개인 키로 해당 공개 키에 서명하고 이를 소유자에게 인증서로 반환합니다. 수신자는 소유자의 공개 키를 사용하여 인증서(CA의 서명 포함)를 추출할 수 있습니다. 수신자는 추출된 인증서에서 CA의 공개 키와 CA의 서명을 사용하여 CA의 서명과 인증서 소유자의 유효성을 검사할 수 있습니다.

디지털 인증서를 사용하는 경우 먼저 CA에서 인증서를 가져오기 위한 요청을 보냅니다. 그런 다음 디지털 인증서 및 디지털 인증서 IKE(Internet Key Exchange) 정책을 구성합니다. 마지막으로 CA에서 디지털 서명된 인증서를 얻습니다.

메모:

대체 주체 이름이 없는 인증서는 IPsec 서비스에 적합하지 않습니다.

ES PIC를 위해 CA에서 인증서 받기

CA는 인증서 요청을 관리하고 참여하는 IPsec 네트워크 디바이스에 인증서를 발급합니다. 인증서 요청을 만들 때 인증서 소유자에 대한 정보를 제공해야 합니다. 필요한 정보와 형식은 CA마다 다릅니다.

인증서는 읽기 및 업데이트 액세스를 모두 제공하는 DAP인 X.500 형식의 이름을 사용합니다. 전체 이름을 DN이라고 합니다. CN(일반 이름), 조직(O), 조직 단위(OU), 국가(C), 지역(L) 등을 포함하는 구성 요소 집합으로 구성됩니다.

메모:

디지털 인증서의 동적 등록의 경우 Junos OS는 SCEP만 지원합니다.

CA 디지털 인증서 요청

SCEP 서버의 URL과 인증서를 원하는 CA의 이름을 지정합니다. mycompany.com. 결과를 저장하는 파일의 이름은 filename 1입니다. "Received CA certificate:" 출력은 인증서에 대한 서명을 제공하여 인증서가 진짜인지 (오프라인으로) 확인할 수 있습니다.

메모:

처음에 각 라우터는 CA에 수동으로 등록됩니다.

ES PIC용 디지털 인증서에 대한 비공개 및 공개 키 쌍 생성

개인 및 공개 키를 생성하려면 다음 명령을 실행합니다.

name 디바이스가 공개 키와 개인 키를 저장하는 파일 이름을 지정합니다.

key-size 512, 1024, 1596 또는 2048바이트일 수 있습니다. 기본 키 크기는 1024바이트입니다.

type또는 dsa일 수 있습니다rsa. 기본값은 RSA입니다.

메모:

SCEP를 사용할 때 Junos OS는 RSA만 지원합니다.

다음 예제에서는 개인 및 공개 키 쌍을 생성하는 방법을 보여 줍니다.

CA 디지털 인증서 요청

CA 디지털 인증서 요청

CA 디지털 인증서를 온라인 또는 수동으로 요청할 수 있습니다. SCEP를 사용하여 CA 또는 RA에서 온라인으로 디지털 인증서를 요청하려면 명령을 실행합니다 request security pki ca-certificate enroll ca-profile ca-profile-name .

전자 메일 또는 기타 OOB 메커니즘을 통해 CA 디지털 인증서를 수동으로 가져온 경우 수동으로 로드해야 합니다. 라우터에 인증서를 수동으로 설치하려면 명령을 실행합니다 request security pki ca-certificate load ca-profile profile_name filename /path/filename.cert .

퍼블릭-프라이빗 키 쌍 생성

키 쌍은 디지털 인증서 구현의 중요한 요소입니다. 공개 키는 로컬 디지털 인증서에 포함되며 개인 키는 피어에서 받은 데이터를 해독하는 데 사용됩니다. 개인-공개 키 쌍을 request security pki generate-key-pair certificate-id certificate-id-name 생성하려면 명령을 실행합니다.

로컬 디지털 인증서 생성 및 등록

로컬 디지털 인증서를 온라인 또는 수동으로 생성하고 등록할 수 있습니다. SCEP를 사용하여 온라인으로 로컬 인증서를 생성하고 등록하려면 명령을 실행합니다 request security pki local-certificate enroll . PKCS-10 형식으로 로컬 인증서 요청을 수동으로 생성하려면 명령을 실행합니다 request security pki generate-certificate-request .

로컬 인증서 요청을 수동으로 만드는 경우 인증서도 수동으로 로드해야 합니다. 라우터에 인증서를 수동으로 설치하려면 명령을 실행합니다 request security pki local-certificate load .

IPsec 구성에 로컬 디지털 인증서 적용

로컬 디지털 인증서를 활성화하려면 사전 공유 키 대신 디지털 인증서를 사용하도록 IKE 제안을 구성하고, IKE 정책에서 로컬 인증서를 참조하고, 서비스 세트에서 CA 또는 RA를 식별합니다. 디지털 인증서에 대한 IKE 제안을 활성화하려면 계층 수준에서 문을 [edit services ipsec-vpn ike proposal proposal-name authentication-method] 포함합니다rsa-signatures. IKE(Internet Key Exchange) 정책에서 로컬 인증서를 참조하려면 계층 수준에서 문을 [edit services ipsec-vpn ike policy policy-name] 포함합니다local-certificate. 서비스 집합에서 CA 또는 RA를 식별하려면 계층 수준에서 [edit services service-set service-set-name ipsec-vpn-options] 문을 포함합니다trusted-ca.

디지털 인증서의 자동 재등록 구성

디지털 인증서에 대한 자동 재등록을 구성할 수 있습니다. 이 기능은 기본적으로 활성화되어 있지 않습니다. 디지털 인증서에 대한 자동 재등록을 구성하려면 계층 수준에서 명령문을 [edit security pki] 포함합니다auto-re-enrollment.

ES PIC에 대한 디지털 인증서 구성

디지털 인증서는 CA라는 신뢰할 수 있는 제3자를 통해 사용자를 인증하는 방법을 제공합니다. CA는 인증서 소유자의 ID를 확인하고 인증서에 "서명"하여 인증서가 위조 또는 변경되지 않았음을 증명합니다.

암호화 서비스 인터페이스에 대한 디지털 인증서 구성을 정의하려면 및 [edit security ike] 계층 수준에 다음 문을 [edit security certificates] 포함시킵니다.

ES PIC에 대한 디지털 인증서를 구성하는 작업은 다음과 같습니다.

ES PIC에 대한 CA 속성 구성

ES PIC에 대한 CA 및 해당 속성을 구성하기 위해 계층 수준에서 다음 문을 [edit security certificates] 포함합니다.

ca-profile-name 은(는) CA(certificate authority) 프로필 이름입니다.

다음 작업을 수행하여 CA 속성을 구성합니다.

CA 이름을 지정합니다

SCEP를 사용하여 CA에 등록하는 경우 SCEP 서버의 URL 외에 인증서 요청에 사용되는 CA 이름(CA ID)을 지정해야 합니다.

CA ID의 이름을 지정하려면 계층 수준에서 문을 [edit security certificates certification-authority ca-profile-name] 포함합니다ca-name.

ca-identity 은 인증서 요청에 사용할 CA ID를 지정합니다. 일반적으로 CA 도메인 이름입니다.

CRL 구성

CRL에는 만료 날짜 전에 취소된 디지털 인증서 목록이 포함되어 있습니다. 참여하는 피어는 디지털 인증서를 사용할 때 인증서 서명과 유효성을 확인합니다. 또한 가장 최근에 발급된 CRL을 획득하고 인증서 일련 번호가 해당 CRL에 없는지 확인합니다.

CRL을 구성하려면 문을 포함 crl 하고 계층 수준에서 CRL [edit security certificates certification-authority ca-profile-name] 을 읽을 파일을 지정합니다.

CA에서 지원하는 인코딩 유형 구성

기본적으로 encoding은 binary로 설정됩니다. Encoding은 및 local-key-pair 명령문에 local-certificate 사용되는 파일 형식을 지정합니다. 기본적으로 바이너리 DER 형식은 사용하도록 설정되어 있습니다. PEM은 ASCII base 64로 인코딩된 형식입니다. CA에 문의하여 지원되는 파일 형식을 확인합니다.

CA가 지원하는 파일 형식을 구성하려면 문을 포함 encoding 하고 계층 수준에서 이진 또는 PEM 형식을 [edit security certificates certification-authority ca-profile-name] 지정합니다.

등록 URL 지정

라우터 또는 스위치가 SCEP 기반 인증서 등록 요청을 보내는 CA 위치를 지정합니다. CA URL을 명명하여 CA 위치를 지정하려면 계층 수준에서 문을 포함합니다enrollment-url.[edit security certificates certification-authority ca-profile-name]

url-name 은(는) CA 위치입니다. 형식은 http://ca-name입니다. 여기서 ca-name 는 CA 호스트 DNS 이름 또는 IP 주소입니다.

디지털 인증서를 읽을 파일 지정

디바이스가 디지털 인증서를 읽는 파일을 지정하려면 문을 포함 file 하고 계층 수준에서 인증서 파일 이름을 지정합니다.[edit security certificates certification-authority ca-profile-name]

LDAP URL 지정

CA가 현재 CRL을 LDAP 서버에 저장하는 경우 디지털 인증서를 사용하기 전에 선택적으로 CA CRL 목록을 확인할 수 있습니다. 디지털 인증서가 CA CRL에 나타나면 라우터 또는 스위치에서 디지털 인증서를 사용할 수 없습니다. CA CRL에 액세스하려면 계층 수준에서 문을 [edit security certificates certification-authority ca-profile-name] 포함합니다ldap-url.

url-name 은(는) CA LDAP 서버 이름입니다. 형식은 CA 호스트 DNS 이름 또는 IP 주소입니다 ldap://server-name, server-name .

캐시 크기 구성

기본적으로 캐시 크기는 2MB입니다. 디지털 인증서의 총 캐시 크기를 구성하려면 계층 레벨에서 [edit security certificates] 문을 포함합니다cache-size.

bytes 은 디지털 인증서의 캐시 크기입니다. 범위는 64바이트에서 4,294,967,295바이트까지입니다.

메모:

캐시 크기를 4MB로 제한하는 것이 좋습니다.

네거티브 캐시 구성

부정적 캐싱은 부정적 결과를 저장하고 부정적 응답에 대한 응답 시간을 줄입니다. 또한 원격 서버로 전송되는 메시지 수도 줄어듭니다. 음수 캐시 상태를 유지하면 조회 시도가 다시 시도될 때 시스템에서 오류 조건을 신속하게 반환할 수 있습니다. 음수 캐시 상태가 없으면 시스템이 원격 서버가 응답하지 않는다는 것을 이미 알고 있더라도 재시도하려면 원격 서버가 응답하지 않을 때까지 기다려야 합니다.

기본적으로 음수 캐시는 20초입니다. 네거티브 캐시를 구성하려면 계층 수준에서 문을 [edit security certificates] 포함합니다cache-timeout-negative.

seconds 은 실패한 CA 또는 라우터 인증서가 네거티브 캐시에 존재하는 시간입니다. 일치하는 CA ID(인증서의 경우 도메인 이름 또는 CRL의 경우 CA 도메인 이름 및 직렬)가 있는 인증서를 검색하는 동안 네거티브 캐시가 먼저 검색됩니다. 네거티브 캐시에서 항목이 발견되면 검색이 즉시 실패합니다.

메모:

큰 음수 캐시 값을 구성하면 DoS 공격에 취약해질 수 있습니다.

등록 재시도 횟수 구성

기본적으로 등록 재시도 횟수는 무한 재시도 횟수인 0으로 설정됩니다. 라우터 또는 스위치가 인증서 요청을 다시 전송할 횟수를 지정하려면 계층 수준에서 [edit security certificates] 문을 포함합니다enrollment-retry.

attempts 은 등록 재시도 횟수(0에서 100까지)입니다.

피어 인증서의 최대 수를 구성합니다

기본적으로 캐시할 최대 피어 인증서 수는 1024개입니다. 캐시에 저장될 최대 피어 인증서 수를 구성하려면 계층 문 수준에서 문을 [edit security certificates] 포함합니다maximum-certificates.

number 은(는) 캐시할 최대 피어 인증서 수입니다. 범위는 64개에서 4,294,967,295개까지의 피어 인증서입니다.

인증서 계층의 경로 길이를 구성합니다

CA는 다른 CA에 인증서를 발급할 수 있습니다. 이렇게 하면 트리와 같은 인증 계층이 만들어집니다. 계층에서 가장 신뢰할 수 있는 CA를 트러스트 앵커라고 합니다. 경우에 따라 트러스트 앵커는 일반적으로 자체적으로 서명되는 루트 CA입니다. 계층 구조에서 모든 인증서는 바로 위에 있는 CA에 의해 서명됩니다. 예외는 일반적으로 루트 CA 자체에서 서명하는 루트 CA 인증서입니다. 일반적으로 하나의 CA에서 서명한 공개 키 소유자(최종 엔터티)의 인증서와 다른 CA에서 서명한 0개 이상의 추가 CA 인증서로 구성된 여러 인증서 체인이 필요할 수 있습니다. 인증 경로라고 하는 이러한 체인은 공개 키 사용자가 제한된 수의 보장된 CA 공개 키로만 초기화되기 때문에 필요합니다.

경로 길이는 CA와 해당 "자식"의 관계를 기반으로 한 인증서에서 다른 인증서로의 인증서 경로를 나타냅니다. 문을 구성할 path-length 때 신뢰할 수 있는 루트 CA 인증서에서 해당 인증서로 인증서를 검증할 계층의 최대 깊이를 지정합니다. 인증서 계층에 대한 자세한 내용은 RFC 3280, 인터넷 X.509 공개 키 인프라 인증서 및 CRL(인증서 해지 목록) 프로필을 참조하십시오.

기본적으로 최대 인증서 경로 길이는 15로 설정됩니다. 루트 앵커는 1입니다.

경로 길이를 path-length 구성하려면 계층 수준에서 문을 [edit security certificates] 포함합니다.

certificate-path-length 은(는) 인증서 경로 길이에 대한 최대 인증서 수입니다. 범위는 2개에서 15개까지의 인증서입니다.