이 페이지의 내용
 

디지털 인증서

디지털 인증서에 대해 알아보고 디지털 인증서를 구성하는 방법을 알아보십시오.

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

수동 인증서 처리에는 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를 사용하며, 이를 위해서는 공개 키와 개인 키로 구성된 키 쌍을 생성해야 합니다. 키는 난수 생성기로 생성되며 데이터를 암호화하고 해독하는 데 사용됩니다. 디지털 인증서를 사용하지 않는 네트워크에서 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(Simple Certificate Enrollment Protocol) 형식을 사용합니다. CA 인증서를 수동으로 요청하는 경우 인증서도 수동으로 로드해야 합니다.

  • 비공개/공개 키 쌍 생성 - 공개 키는 로컬 디지털 인증서에 포함되며 비공개 키는 피어로부터 수신한 데이터를 복호화하는 데 사용됩니다.

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

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

선택적으로 다음을 수행할 수 있습니다.

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

  • 디지털 인증서 이벤트 모니터링 및 인증서 및 요청 삭제 - 운영 모드 명령을 실행하여 디지털 인증서를 사용하여 설정된 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. SSL 프록시 프로필에 루트 CA를 적용합니다.

인증서 체인 구현

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

  • CA(Certificate Authority) - 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: 인증서 체인 세부 정보

사용자

인증서 사용

서명자

유형

예제.도메인-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 인증서 체인을 구성하려면 다음을 수행합니다.

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

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

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

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

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

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

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

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

  • 네트워크 보안(nsd)은 SSL 프록시 프로파일에 구성된 서명 인증서에 대한 인증서 체인 정보를 제공하도록 PKI에 요청을 보냅니다.

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

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

단계별 절차

인증서 체인 구성:

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

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

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

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

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

    이 인증서를 인증서 체인으로 연결할 수 있습니다.

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

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

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

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

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

디지털 인증서 구성

디지털 인증서 개요

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

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

  • 소유자의 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)을 지정합니다. 결과를 저장하는 파일의 이름은 파일 이름 1입니다. 출력 "Received CA certificate:"는 인증서에 대한 서명을 제공하여 인증서가 정품인지 (오프라인에서) 확인할 수 있습니다.

참고:

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

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

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

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

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

type 또는 일 rsa dsa수 있습니다. 기본값은 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(Internet Key Exchange) 제안을 구성하고, IKE(Internet Key Exchange) 정책에서 로컬 인증서를 참조하며, 서비스 세트에서 CA 또는 RA를 식별합니다. 디지털 인증서에 대한 IKE(Internet Key Exchange) 제안을 활성화하려면 계층 수준에서 [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라는 신뢰할 수 있는 타사를 통해 사용자를 인증하는 방법을 제공합니다. CA는 인증서 소유자의 신원을 검증하고 인증서에 "서명"하여 위조 또는 변경되지 않았음을 증명합니다.

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

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

ES PIC에 대한 CA 속성 구성

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

ca-profile-name 는 CA 프로필 이름입니다.

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

CA 이름 지정

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

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

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

CRL을 구성합니다

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

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

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

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

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

등록 URL 지정

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

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

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

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

LDAP URL 지정

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

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

캐시 크기 구성

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

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

참고:

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

네거티브 캐시 구성

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

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

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

참고:

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

등록 재시도 횟수 구성

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

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

피어 인증서의 최대 수 구성

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

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

인증서 계층의 경로 길이 구성

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

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

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

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

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