인증 기관 지침

 

적용 대상: Windows Server 2012 R2, Windows Server 2012

CA(인증 기관)는 사용자, 컴퓨터 및 조직의 ID를 증명할 책임이 있습니다. CA는 디지털 서명 인증서를 발급하여 엔터티를 인증하고 해당 ID를 보증합니다. 또한 CA는 인증서를 관리, 해지 및 갱신할 수 있습니다.

인증 기관은 다음을 의미할 수 있습니다.

• 최종 사용자의 ID를 보증하는 조직

• 조직에서 인증서를 발급하고 관리하는 데 사용하는 서버

AD CS(Active Directory 인증서 서비스)의 인증 기관 역할 서비스를 설치하면 CA 역할을 하도록 Windows Server를 구성할 수 있습니다.

CA 역할 서비스를 설치하기 전에 다음 작업을 수행해야 합니다.

1. 조직에 적합한 PKI(공개 키 인프라)를 계획합니다.

2. HSM(하드웨어 보안 모듈)을 사용할 계획인 경우 HSM 공급업체 지침에 따라 HSM을 설치하고 구성합니다.

3. 기본 설치 설정을 수정하려면 적절한 CAPolicy.inf를 만듭니다.

PKI 계획

조직에서 AD CS(Active Directory 인증서 서비스) 설치를 최대한 활용할 수 있도록 하려면 PKI 배포 계획을 적절히 수립해야 합니다. CA를 설치하기 전에 몇 개의 CA를 어떤 구성으로 설치할지 결정해야 합니다. 적절한 PKI 디자인을 만드는 데 시간이 오래 걸릴 수 있지만 이는 PKI의 성공에 매우 중요합니다.

자세한 내용 및 관련 리소스는 Microsoft TechNet에서 PKI 디자인 지침을 참조하세요.

HSM 사용

HSM(하드웨어 보안 모듈)을 사용하여 CA 및 PKI의 보안을 개선할 수 있습니다.

HSM은 운영 체제와 별도로 관리되는 전용 하드웨어 장치입니다. 이러한 모듈은 서명 및 암호화 작업을 가속화하는 전용 암호화 프로세서 외에 CA 키용 보안 하드웨어 저장소를 제공합니다. 운영 체제에서는 CryptoAPI 인터페이스를 통해 HSM을 사용하며 HSM은 CSP(암호화 서비스 공급자) 장치 역할을 합니다.

HSM은 일반적으로 PCI 어댑터이지만 네트워크 기반 어플라이언스, 직렬 장치 및 USB 장치로 사용될 수도 있습니다. 조직에서 둘 이상의 CA를 구현하려는 경우 단일 네트워크 기반 HSM을 설치하고 이를 여러 CA에서 공유할 수 있습니다.

HSM을 사용하여 CA를 설정하려면 HSM에 저장할 키로 CA를 설정하기 전에 HSM을 설치하고 구성해야 합니다.

CAPolicy.inf 파일 고려

CAPolicy.inf 파일은 AD CS를 설치하는 데 필요하지 않지만 CA 설정을 사용자 지정하는 데 사용될 수 있습니다. CAPolicy.inf 파일에는 CA를 설치하거나 CA 인증서를 갱신할 때 사용되는 다양한 설정이 포함되어 있습니다. CAPolicy.inf 파일을 만든 후 %systemroot% 디렉터리(일반적으로 C:\Windows)에 저장해야 사용할 수 있습니다.

CAPolicy.inf 파일에 포함하는 설정은 주로 만들려는 배포 유형에 따라 달라집니다. 예를 들어 루트 CA에는 다음과 같은 CAPolicy.inf 파일이 있을 수 있습니다.

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0

반면 CA를 발급하는 엔터프라이즈의 CAPolicy.inf 파일은 다음과 같을 수 있습니다.

[Version]
Signature= "$Windows NT$"
[PolicyStatementExtension]
Policies = LegalPolicy, LimitedUsePolicy
[LegalPolicy]
OID = 1.1.1.1.1.1.1.1.1
URL = "https://www.contoso.com/pki/Policy/USLegalPolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLegalPolicy.txt"
[LimitedUsePolicy]
OID = 2.2.2.2.2.2.2.2.2
URL = "https://www.contoso.com/pki/Policy/USLimitedUsePolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLimitedUsePolicy.txt"
LoadDefaultTemplates=0

CA 구성 설정 선택

다음 섹션에서는 CA 이진 설치 파일을 설치한 후 선택할 구성 옵션에 대해 설명합니다.

설치 유형 선택

엔터프라이즈 CA는 AD DS(Active Directory 도메인 서비스)와 통합되며, 인증서 및 CRL(인증서 해지 목록)을 AD DS에 게시합니다. 엔터프라이즈 CA는 사용자 계정 및 보안 그룹 등 AD DS에 저장된 정보를 사용하여 인증서 요청을 승인하거나 거부합니다. 엔터프라이즈 CA는 인증서 템플릿을 사용합니다. 인증서가 발급되면 엔터프라이즈 CA에서 인증서 템플릿에 있는 정보를 사용하여 해당 인증서 종류에 적절한 특성으로 인증서를 생성합니다.

자동화된 인증서 승인 및 사용자 인증서 자동 등록을 사용하도록 설정하려면 엔터프라이즈 CA를 사용하여 인증서를 발급하세요. 이러한 기능은 CA 인프라가 Active Directory와 통합된 경우에 사용할 수 있습니다. 또한 이 프로세스를 사용하려면 스마트 카드 인증서가 Active Directory의 사용자 계정에 자동으로 매핑되어야 하므로 스마트 카드 로그인을 사용할 수 있는 엔터프라이즈 CA만 인증서를 발급할 수 있습니다.

독립 CA는 AD DS가 필요하지 않으며 인증서 템플릿을 사용하지 않습니다. 독립 CA를 사용하는 경우 요청된 인증서 종류에 대한 모든 정보를 인증서 요청에 포함해야 합니다. 기본적으로 독립 CA에 제출된 모든 인증서 요청은 CA 관리자가 승인할 때까지 보류 중인 큐에 유지됩니다. 요청 시 자동으로 인증서를 발급하도록 독립 CA를 구성할 수 있지만 이는 안전하지 않으며, 요청이 인증되지 않기 때문에 일반적으로 권장되지 않습니다.

성능 면에서는 자동 발급되는 독립 CA를 사용하는 것이 엔터프라이즈 CA를 사용하는 것보다 빠른 속도로 인증서를 발급할 수 있습니다. 그러나 자동 발급을 사용하지 않는 경우에는 관리자가 각 인증서 요청을 수동으로 검토한 다음 승인하거나 거부해야 하므로 독립 CA를 사용하여 대량의 인증서를 발급하는 데 일반적으로 관리 비용이 많이 듭니다. 이러한 이유로 독립 CA는 사용자에게 사용자 계정이 없는 경우 및 발급하고 관리해야 하는 인증서 양이 비교적 적은 경우 엑스트라넷 및 인터넷에서 공개 키 보안 응용 프로그램과 함께 사용하는 것이 가장 좋습니다.

타사 디렉터리 서비스를 사용하거나 AD DS를 사용할 수 없을 때는 독립 CA를 사용하여 인증서를 발급해야 합니다. 다음 표에 설명된 대로 조직에서 엔터프라이즈 CA와 독립 CA를 둘 다 사용할 수 있습니다.

옵션	엔터프라이즈 CA	독립 CA
Active Directory에 인증서를 게시하고 Active Directory를 사용하여 인증서 요청의 유효성 검사	예	아니요
CA를 오프라인으로 전환	권장되지 않음	예
인증서를 자동으로 발급하도록 CA 구성	예	권장되지 않음
관리자가 인증서 요청을 수동으로 승인하도록 허용	예	예
인증서 템플릿 사용 허용	예	아니요
Active Directory에 대한 요청 인증	예	아니요

CA 유형 선택

엔터프라이즈 및 독립 CA를 루트 CA 또는 하위 CA로 구성할 수 있습니다. 또한 하위 CA를 중간 CA(정책 CA라고도 함)로 추가 구성할 수 있습니다.

루트 CA 지정

루트 CA는 인증 계층 구조의 최상위에 있는 CA이며, 조직의 클라이언트에서 무조건적으로 신뢰할 수 있어야 합니다. 모든 인증서 체인은 루트 CA에서 종료됩니다. 엔터프라이즈 CA를 사용하든 독립 CA를 사용하든 루트 CA를 지정해야 합니다.

루트 CA는 인증 계층 구조의 최상위 CA이므로 루트 CA에서 발급한 인증서의 주체 필드 값은 인증서의 발급자 필드 값과 같습니다. 마찬가지로, 인증서 체인은 자체 서명된 CA에 도달하면 종료되므로 자체 서명된 CA는 모두 루트 CA입니다. CA를 신뢰할 수 있는 루트 CA로 지정할지는 개별 IT 관리자가 로컬로 결정하거나 엔터프라이즈 수준에서 결정할 수 있습니다.

루트 CA는 인증 기관 트러스트 모델의 기준이 되는 기초 역할을 하며, 주체의 공개 키가 발급한 인증서의 주체 필드에 표시된 ID 정보에 해당함을 보장합니다. 여러 CA에서 서로 다른 표준을 사용하여 이 관계를 확인할 수도 있습니다. 따라서 공개 키를 확인하려면 루트 인증 기관을 신뢰하도록 선택하기 전에 해당 기관의 정책과 절차를 이해해야 합니다.

루트 CA는 계층 구조에서 가장 중요한 CA입니다. 루트 CA가 손상된 경우 계층 구조의 모든 CA와 루트 CA에서 발급된 모든 인증서가 손상된 것으로 간주됩니다. 네트워크 연결이 끊어진 상태에서 하위 CA를 사용하여 다른 하위 CA 또는 최종 사용자에게 인증서를 발급하면 루트 CA의 보안을 극대화할 수 있습니다.

하위 CA

루트 CA가 아닌 CA는 하위 CA로 간주됩니다. 계층 구조의 첫 번째 하위 CA는 루트 CA에서 해당 CA 인증서를 가져옵니다. 이 첫 번째 하위 CA에서는 이 키를 사용하여 다른 하위 CA의 무결성을 확인하는 인증서를 발급할 수 있습니다. 이러한 상위 수준의 하위 CA를 중간 CA라고 합니다. 중간 CA는 루트 CA의 하위 CA이지만 하나 이상의 하위 CA에 대한 상위 인증 기관의 역할을 합니다.

중간 CA는 일반적으로 정책으로 구별할 수 있는 인증서 등급을 구분하는 데 사용되기 때문에 정책 CA라고도 합니다. 예를 들어 정책 구분에는 CA에서 제공하는 보증 수준 또는 다양한 최종 엔터티 모집단을 구별하는 CA의 지리적 위치가 포함됩니다. 정책 CA는 온라인 또는 오프라인일 수 있습니다.

개인 키 저장

개인 키는 CA ID의 일부이므로 손상되지 않도록 보호해야 합니다. 많은 조직에서 HSM(하드웨어 보안 모듈)을 사용하여 CA 개인 키를 보호합니다. HSM을 사용하지 않는 경우에는 CA 컴퓨터에 개인 키가 저장됩니다. 자세한 내용은 Microsoft TechNet에서 HSM(하드웨어 보안 모듈)(영문)을 참조하세요.

오프라인 CA는 안전한 위치에 저장해야 하며 네트워크에 연결되어 있지 않아야 합니다. 발급 CA에서는 인증서를 발급할 때 자체 개인 키를 사용하므로 CA가 작동 중인 동안 개인 키에 온라인으로 액세스할 수 있어야 합니다. 어떤 경우든 CA와 CA의 개인 키를 물리적으로 보호해야 합니다.

기존 키 찾기

설치하는 동안 사용할 기존 개인 키가 이미 있는 경우 기존 키 화면을 사용하여 해당 키를 찾을 수 있습니다.변경 단추를 사용하여 암호화 공급자를 수정하고, 필요에 따라 기존 키를 검색할 CA를 수정할 수 있습니다.

기존 인증서 찾기

CA의 개인 키가 포함된 인증서가 이미 있는 경우 기존 인증서 화면을 사용하여 인증서를 찾을 수 있습니다.가져오기 단추를 사용하여 기존 인증서 가져오기 대화 상자를 열고 기존 PKCS #12 파일을 찾을 수 있습니다.

암호화 옵션 선택

CA(인증 기관)에 대한 암호화 옵션을 선택하는 것은 해당 CA의 보안, 성능 및 호환성 면에서 중요한 의미를 가질 수 있습니다. 기본 암호화 옵션이 대부분의 CA에 적합할 수 있지만 사용자 지정 옵션을 구현하는 기능은 암호화에 대한 이해도가 높고 이러한 유연성을 필요로 하는 관리자 및 응용 프로그램 개발자에게 유용할 수 있습니다. CSP(암호화 서비스 공급자) 또는 KSP(키 저장소 공급자)를 사용하여 암호화 옵션을 구현할 수 있습니다.

CSP는 Windows 운영 체제에서 일반 암호화 기능을 제공하는 하드웨어 및 소프트웨어 구성 요소입니다. 다양 한 암호화 및 서명 알고리즘을 제공하도록 CSP를 작성할 수 있습니다.

KSP는 최소 서버 버전 Windows Server 2008 R2 및 최소 클라이언트 버전 Windows Vista를 실행하는 컴퓨터에 강력한 키 보호를 제공할 수 있습니다.

CA가 개인 키를 액세스할 때 관리자 조작 허용은 HSM(하드웨어 보안 모듈)에서 일반적으로 사용되는 옵션입니다. 이 옵션을 사용하면 CA의 개인 키에 액세스할 때 암호화 공급자가 사용자에게 추가 인증을 묻는 메시지를 표시할 수 있습니다. 이 옵션은 관리자가 모든 암호화 작업 전에 암호를 입력하도록 요구함으로써 CA 및 개인 키의 무단 사용을 방지하도록 도와줍니다.

기본 제공 암호화 공급자는 다음 표에 설명된 대로 특정 키 길이 및 해시 알고리즘을 지원합니다.

암호화 공급자	키 길이	해시 알고리즘
Microsoft Base Cryptographic Provider v1.0	512 1024 2048 4096	SHA1 MD2 MD4 MD5
Microsoft Base DSS Cryptographic Provider	512 1024	SHA1
Microsoft Base Smart Card Crypto Provider	1024 2048 4096	SHA1 MD2 MD4 MD5
Microsoft Enhanced Cryptographic Provider v1.0	512 1024 2048 4096	SHA1 MD2 MD4 MD5
Microsoft Strong Cryptographic Provider	512 1024 2048 4096	SHA1 MD2 MD4 MD5
RSA#Microsoft Software Key Storage Provider	512 1024 2048 4096	SHA1 SHA256 SHA384 SHA512 MD2 MD4 MD5
DSA#Microsoft Software Key Storage Provider	512 1024 2048	SHA1
ECDSA_P256#Microsoft Software Key Storage Provider	256	SHA1 SHA256 SHA384 SHA512
ECDSA_P384#Microsoft Software Key Storage Provider	384	SHA1 SHA256 SHA384 SHA512
ECDSA_P521#Microsoft Software Key Storage Provider	521	SHA1 SHA256 SHA384 SHA512
RSA#Microsoft Smart Card Key Storage Provider	1024 2048 4096	SHA1 SHA256 SHA384 SHA512 MD2 MD4 MD5
ECDSA_P256#Microsoft Smart Card Key Storage Provider	256	SHA1 SHA256 SHA384 SHA512
ECDSA_P384#Microsoft Smart Card Key Storage Provider	384	SHA1 SHA256 SHA384 SHA512
ECDSA_P521#Microsoft Smart Card Key Storage Provider	521	SHA1 SHA256 SHA384 SHA512

CA 이름 설정

조직의 CA(인증 기관)를 구성하기 전에 CA 명명 규칙을 설정해야 합니다.

모든 유니코드 문자를 사용하여 이름을 만들 수 있지만 상호 운용성이 중요한 경우 ANSI 문자 집합을 사용할 수도 있습니다. 예를 들어 특정 유형의 라우터는 CA 이름에 밑줄과 같은 특수 문자가 포함된 경우 네트워크 장치 등록 서비스를 사용하여 인증서를 등록할 수 없습니다.

AD DS(Active Directory 도메인 서비스)에서는 서버를 CA로 구성할 때 지정한 이름이 CA의 일반 이름이 되며 CA에서 발급하는 모든 인증서에 이 이름이 반영됩니다. 따라서 CA의 일반 이름에 정규화된 도메인 이름을 사용하지 않아야 합니다. 그러면 인증서 복사본을 얻은 악의적인 사용자가 CA의 정규화된 도메인 이름을 식별하고 사용하여 잠재적 보안 취약점을 만들 수 없습니다.

AD CS를 설치한 후 서버 이름을 변경하려면 CA를 제거하고 서버 이름을 변경한 다음, 동일한 키를 사용하여 CA를 다시 설치하고 기존 CA 키 및 데이터베이스를 사용하도록 레지스트리를 수정해야 합니다. 도메인 이름을 바꿀 경우에는 CA를 다시 설치할 필요가 없지만 변경된 이름을 지원하도록 CA를 다시 구성해야 합니다.

인증서 요청 가져오기

루트 CA(인증 기관)를 설치한 후 많은 조직에서 PKI(공개 키 인프라)에 대한 정책 제한을 구현하고 최종 클라이언트에 인증서를 발급하기 위해 하나 이상의 하위 CA를 설치합니다. 하나 이상의 하위 CA를 사용하면 루트 CA가 불필요하게 노출되는 것을 방지할 수 있습니다. 하위 CA를 설치할 때 부모 CA에서 인증서를 가져와야 합니다.

부모 CA가 온라인 상태인 경우 부모 CA에 인증서 요청을 보냄 옵션을 사용하여 CA 이름 또는 컴퓨터 이름으로 부모 CA를 선택할 수 있습니다.

부모 CA가 오프라인 상태인 경우 대상 컴퓨터의 파일에 인증서 요청 저장 옵션을 사용해야 합니다. 이 절차는 부모 CA에 고유합니다. 최소한 부모 CA가 하위 CA의 새로 발급된 인증서를 포함하는 파일을 제공해야 하며, 가급적이면 전체 인증 경로를 포함하는 파일을 제공하는 것이 좋습니다.

전체 인증 경로를 포함하지 않는 하위 CA 인증서를 가져온 경우에는 설치한 새 하위 CA를 시작할 때 해당 CA에서 유효한 CA 체인을 만들 수 있어야 합니다. 유효한 인증 경로 만들려면 다음을 수행합니다.

• 부모 CA가 루트 CA가 아닌 경우 컴퓨터의 중간 인증 기관 인증서 저장소에 부모 CA의 인증서를 설치합니다.

• 체인의 다른 모든 중간 CA에 대한 인증서를 설치합니다.

• 신뢰할 수 있는 루트 인증 기관 저장소에 루트 CA의 인증서를 설치합니다.

유효 기간 확인

인증서 기반 암호화에서는 공개 키 암호화를 사용하여 데이터를 보호하고 서명합니다. 시간이 지남에 따라 공격자는 공개 키로 보호된 데이터를 가져와 개인 키를 추출하려고 시도할 수 있습니다. 시간과 리소스가 충분하다면 이 개인 키를 손상시켜 보호된 모든 데이터를 보호되지 않은 상태로 만들 수 있습니다. 또한 인증서에 의해 보장된 이름을 시간이 지남에 따라 변경해야 할 수도 있습니다. 인증서는 이름과 공개 키 간의 바인딩이므로 둘 중 하나를 변경할 경우 인증서를 갱신해야 합니다.

모든 인증서에는 유효 기간이 있습니다. 유효 기간이 끝난 인증서는 더 이상 허용되거나 사용 가능한 자격 증명으로 간주되지 않습니다.

CA는 자체 유효 기간이 지난 후에도 유효한 인증서를 발급할 수 없습니다. 유효 기간의 절반이 지났을 때 CA 인증서를 갱신하는 것이 가장 좋습니다. CA를 설치할 때 이 날짜를 계획하고 이후 작업으로 기록해 두어야 합니다.

CA 데이터베이스 선택

많은 데이터베이스와 마찬가지로 인증 기관의 데이터베이스는 하드 드라이브의 파일입니다. 이 파일 외에 다른 파일은 트랜잭션 로그 역할을 하며, 변경 내용이 적용되기 전에 데이터베이스의 모든 수정 사항을 받습니다. 이러한 파일에 동시에 자주 액세스할 수 있으므로 데이터베이스와 트랜잭션 로그를 별도의 하드 드라이브에 유지하거나 스트라이프 볼륨과 같은 고성능 디스크 구성에 유지하는 것이 가장 좋습니다.

인증서 데이터베이스와 로그 파일의 위치는 다음 레지스트리 위치에 유지됩니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

레지스트리에는 다음 값이 포함되어 있습니다.

• DBDirectory

• DBLogDirectory

• DBSystemDirectory

• DBTempDirectory

CA 구성

루트 또는 하위 CA를 설치한 후 CA에서 인증서를 발급하기 전에 AIA(기관 정보 액세스) 및 CDP(CRL 배포 지점) 확장을 구성해야 합니다. AIA 확장은 CA에 대한 최신 인증서를 찾을 수 있는 위치를 지정하고, CDP 확장은 CA에서 서명한 최신 CRL을 찾을 수 있는 위치를 지정합니다. 이러한 확장은 해당 CA에서 발급한 모든 인증서에 적용됩니다.

이러한 확장을 구성하면 CA에서 발급하는 각 인증서에 이 정보가 포함되므로 모든 클라이언트에서 정보를 사용할 수 있습니다. 따라서 PKI 클라이언트에서 확인되지 않은 인증서 체인 또는 인증서 해지로 인해 VPN 연결 실패, 스마트 카드 로그인 실패, 확인되지 않은 메일 서명 등의 오류가 발행할 수 있는 가능성이 최소화됩니다.

CA 관리자는 CRL 배포 지점과 CDP 및 AIA 인증서 발급 위치를 추가, 제거 또는 수정할 수 있습니다. CRL 배포 지점의 URL 수정은 새로 발급된 인증서에만 영향을 줍니다. 이전에 발급된 인증서는 원래 위치를 계속 참조하므로 CA에서 인증서를 배포하기 전에 이러한 위치를 설정해야 합니다.

CDP 확장 URL을 구성할 때 다음 지침을 고려하세요.

• 오프라인 루트 CA에 델타 CRL을 게시하지 마세요. 오프라인 루트 CA에서는 많은 인증서를 해지하지 않으므로 델타 CRL이 필요하지 않을 수 있습니다.

• 요구 사항에 따라 인증 기관의 속성 확장 탭에 있는 확장 탭에서 LDAP:/// 및 HTTP:// URL 위치를 조정합니다.

• 조직 외부의 사용자 및 응용 프로그램에서 인증서 유효성 검사를 수행할 수 있도록 HTTP 인터넷 또는 엑스트라넷 위치에 CRL을 게시합니다. 클라이언트가 HTTP 및 LDAP를 사용하여 CRL 데이터를 검색할 수 있도록 CDP 위치에 대한 LDAP 및 HTTP URL을 게시할 수 있습니다.

• Windows 클라이언트는 유효한 CRL이 검색될 때까지 항상 URL 목록을 순서대로 검색합니다.

• Windows가 아닌 운영 체제를 실행하는 클라이언트에 액세스 가능한 CRL 위치를 제공하려면 HTTP CDP 위치를 사용합니다.

Windows PowerShell과 certutil은 CDP 및 AIA 위치를 쉽게 게시할 수 있도록 변수 번호(% 기호가 앞에 옴)를 지원합니다. CA의 속성 확장 탭은 괄호로 묶인 변수를 지원합니다. 다음 표에서는 인터페이스 간의 변수를 동일시하여 해당 의미를 설명합니다.

변수	확장 탭 이름	설명
%1	<ServerDNSName>	CA 컴퓨터의 DNS 이름입니다. DNS 도메인에 연결된 경우에는 정규화된 도메인 이름이고, 그렇지 않으면 컴퓨터의 호스트 이름입니다.
%2	<ServerShortName>	CA 컴퓨터의 NetBIOS 이름입니다.
%3	<CaName>	CA의 이름입니다.
%4	<CertificateName>	인증서의 추가 수정 버전마다 고유한 접미사를 지정합니다.
%4	없음	사용되지 않습니다.
%6	<ConfigurationContainer>	AD DS(Active Directory 도메인 서비스) 내 구성 컨테이너의 위치입니다.
%7	<CATruncatedName>	32자로 잘리고 끝에 해시가 있는 CA의 이름입니다.
%8	<CRLNameSuffix>	파일 또는 URL 위치에 CRL을 게시할 때 파일 이름에 접미사를 삽입합니다.
%9	<DeltaCRLAllowed>	델타 CRL을 게시할 때 CRL과 구별하기 위해 CRLNameSuffix 변수를 별도의 접미사로 바꿉니다.
%10	<CDPObjectClass>	LDAP URL에 게시할 때 사용되는 CRL 배포 지점의 개체 클래스 식별자입니다.
%11	<CAObjectClass>	LDAP URL에 게시할 때 사용되는 CA의 개체 클래스 식별자입니다.

AIA 확장 게시

AIA 확장은 확인할 인증서를 찾을 수 있는 위치를 클라이언트 컴퓨터에 알려 줍니다. 이를 통해 클라이언트는 인증서를 신뢰할 수 있는지 여부를 확인할 수 있습니다.

인증 기관 인터페이스, Windows PowerShell 또는 certutil 명령을 사용하여 AIA 확장을 구성할 수 있습니다. 다음 표에서는 이러한 방법으로 AIA 확장에서 사용할 수 있는 옵션을 설명합니다.

인터페이스 확인란 이름	Windows PowerShell 매개 변수	Certutil 값
발급된 인증서의 AIA 확장에 포함	-AddToCertificateAia	2
OCSP(온라인 인증서 상태 프로토콜) 확장을 포함	-AddToCertificateOcsp	32

AIA 확장 게시에 대한 이 섹션의 예는 다음 시나리오를 나타냅니다.

• 도메인 이름이 corp.contoso.com입니다.

• 도메인에 App1이라는 웹 서버가 있습니다.

• App1에는 CA 읽기 및 쓰기 권한을 허용하는 PKI라는 공유 폴더가 있습니다.

• App1에는 www의 DNS CNAME 및 PKI 라는 공유 가상 디렉터리가 있습니다.

• 클라이언트 컴퓨터에서 AIA 정보에 사용해야 하는 첫 번째 프로토콜은 HTTP입니다.

• 클라이언트 컴퓨터에서 AIA 정보에 사용해야 하는 두 번째 프로토콜은 LDAP입니다.

• 구성할 CA는 온라인 발급 CA입니다.

• OCSP는 사용되지 않습니다.

인터페이스를 사용하여 AIA 확장 게시

인터페이스에서는 위 표에 설명된 변수 및 확인란 이름을 사용합니다. 인증 기관 인터페이스를 통해 인터페이스에 액세스할 수 있습니다. 내용 창에서 CA를 마우스 오른쪽 단추로 클릭하고 속성을 클릭한 후 확장을 클릭합니다.확장 선택에서 **AIA(기관 정보 액세스)**를 클릭합니다.

그림 1   AIA 확장 메뉴

사용자 인터페이스에 구성된 위치 및 설정은 다음과 같습니다.

• C:\Windows\system32\CertSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt

• https://www.contoso.com/pki/\<ServerDNSName>_<CaName><CertificateName>.crt

  • 발급된 인증서의 AIA 확장에 포함

• file://\\App1.corp.contoso.com\pki\<ServerDNSName>_<CaName><CertificateName>.crt

• ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CAObjectClass>

  • 발급된 인증서의 AIA 확장에 포함

Windows PowerShell을 사용하여 AIA 확장 게시

다음 Windows PowerShell 명령을 사용하여 주어진 시나리오에 대한 AIA 확장을 구성할 수 있습니다.

$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia https://www.contoso.com/pki/%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia file://\\App1.corp.contoso.com\pki\%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia "ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

certutil을 사용하여 AIA 확장 게시

다음 certutil 명령을 사용하여 주어진 시나리오에 대한 AIA 확장을 구성할 수 있습니다.

certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:https://www.contoso.com/pki/%1_%3%4.crt\n1:file://\\App1.corp.contoso.com\pki\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

CDP 확장 게시

CDP 확장은 클라이언트에서 특정 인증서가 해지되지 않았는지 확인할 수 있도록 최신 CRL을 확인할 수 있는 위치를 클라이언트 컴퓨터에 알려 줍니다.

인증 기관 인터페이스, Windows PowerShell 또는 certutil 명령을 사용하여 CDP 확장을 구성할 수 있습니다. 다음 표에서는 이러한 방법으로 CDP 확장에서 사용할 수 있는 옵션을 설명합니다.

인터페이스 확인란 이름	Windows PowerShell 매개 변수	Certutil 값
이 위치로 CRL을 게시	-PublishToServer	1
모든 CRL을 포함. 수동으로 게시할 때 Active Directory에 게시할 위치를 지정합니다.	-AddToCrlCdp	8
CRL에 포함. 클라이언트에서 델타 CRL 위치를 찾도록 해줍니다.	-AddToFreshestCrl	4
발급된 인증서의 CDP 확장에 포함	-AddToCertificateCdp	2
이 위치로 델타 CRL을 게시	-PublishDeltaToServer	64
발급된 CRL의 IDP 확장에 포함	-AddToCrlIdp	128

IIS(인터넷 정보 서비스) 웹 서버에 델타 CRL을 게시하도록 허용하려면 IIS 구성의 system.web 섹션에서 requestFiltering 요소에 대해 allowDoubleEscaping=true를 설정하여 기본 IIS 구성을 수정해야 합니다. 예를 들어 IIS에서 기본 웹 사이트의 PKI 가상 디렉터리에 대한 이중 이스케이프를 허용하려면 IIS 웹 서버에서 appcmd set config "Default Web Site/pki" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true 명령을 실행합니다. 자세한 내용은 AD CS: 델타 CRL의 게시를 사용하도록 설정하려면 웹 서버에서 “+” 문자가 포함된 URI를 허용해야 함(영문)을 참조하세요.

CDP 확장 게시에 대한 이 섹션의 예는 다음 시나리오를 나타냅니다.

• 도메인 이름이 corp.contoso.com입니다.

• 도메인에 App1이라는 웹 서버가 있습니다.

• App1에는 CA 읽기 및 쓰기 권한을 허용하는 PKI라는 공유 폴더가 있습니다.

• App1에는 www의 DNS CNAME 및 PKI 라는 공유 가상 디렉터리가 있습니다.

• 클라이언트 컴퓨터에서 CDP 정보에 사용해야 하는 첫 번째 프로토콜은 HTTP입니다.

• 클라이언트 컴퓨터에서 CDP 정보에 사용해야 하는 두 번째 프로토콜은 LDAP입니다.

• 구성할 CA는 온라인 발급 CA입니다.

• IDP는 사용되지 않습니다.

인터페이스를 사용하여 CDP 확장 게시

인터페이스에서는 위 표에 설명된 변수 및 확인란 이름을 사용합니다. 인증 기관 인터페이스를 통해 인터페이스에 액세스할 수 있습니다. 내용 창에서 CA를 마우스 오른쪽 단추로 클릭하고 속성을 클릭한 후 확장을 클릭합니다.확장 선택에서 **CDP(CRL 배포 지점)**를 클릭합니다.

그림 2   CDP 확장 메뉴

인터페이스에 구성된 위치 및 설정은 다음과 같습니다.

• C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  • 이 위치로 CRL을 게시

  • 이 위치로 델타 CRL을 게시

• https://www.contoso.com/pki/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  • CRL에 포함. 클라이언트에서 델타 CRL 위치를 찾도록 해줍니다.

  • 발급된 인증서의 CDP 확장에 포함

• file://\\App1.corp.contoso.com\pki\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  • 이 위치로 CRL을 게시

  • 이 위치로 델타 CRL을 게시

• ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

  • 모든 CRL을 포함. 수동으로 게시할 때 Active Directory에 게시할 위치를 지정합니다.

  • 인증서의 CDP 확장에 포함

Windows PowerShell을 사용하여 CDP 확장 게시

다음 Windows PowerShell 명령을 사용하여 주어진 시나리오에 대한 CDP 확장을 구성할 수 있습니다.

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri https://www.contoso.com/pki/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl
Add-CACRLDistributionPoint -Uri file://\\App1.corp.contoso.com\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri "ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10" -AddToCrlCdp -AddToCertificateCdp

certutil을 사용하여 CDP 확장 게시

다음 certutil 명령은 주어진 시나리오에 대한 CDP 확장을 구성합니다.

certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n6:https://www.contoso.com/pki/%3%8%9.crl\n65:file://\\App1.corp.contoso.com\pki\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

CRL을 게시하려면 관리자 권한으로 실행되는 명령 프롬프트 또는 Windows PowerShell에서 CA에 대해 certutil -crl 명령을 실행하면 됩니다. CRL 구성 및 게시에 대한 자세한 내용은 인증서 해지 구성을 참조하세요.

구성 확인

CA 구성을 확인하려면 Windows PowerShell 또는 명령 프롬프트 창에서 다음 명령을 실행하면 됩니다.

명령	설명
Certutil -CAInfo	CA의 이름, 로캘, OID(개체 식별자) 및 CRL 상태를 표시합니다.
Certutil -getreg	CA 레지스트리 구성을 표시합니다.
Certutil -ADCA	엔터프라이즈 CA의 구성을 확인합니다.

엔터프라이즈 PKI 보기(PKIView.msc) 도구를 사용하여 AIA 및 CDP 게시 구성을 확인할 수 있습니다. 자세한 내용은 엔터프라이즈 PKI를 참조하세요.

또한 온라인 응답자 역할 서비스를 사용하여 인증서 해지를 확인할 수 있습니다. 온라인 응답자에 대한 자세한 내용은 온라인 응답자 설치, 구성 및 문제 해결 가이드를 참조하세요.

관련 콘텐츠

• Windows Server 보안 포럼

• AD CS(Active Directory 인증서 서비스) PKI(공개 키 인프라)에 대한 FAQ(질문과 대답)

• Windows PKI 설명서 참조 및 라이브러리

• Windows PKI 블로그