IdM의 인증서 관리
인증서 발행, 인증서 기반 인증 구성 및 인증서 유효성 제어
초록
certmonger
서비스, certutil
툴 또는 Ansible 플레이북을 사용하여 인증서를 요청 및 갱신할 수 있습니다. IdM 서버의 웹 서버 및 LDAP 서버 인증서를 교체하려면 수동 작업을 수행해야 합니다.
Red Hat 문서에 관한 피드백 제공
문서에 대한 피드백에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
Jira를 통해 피드백 제출 (등록 필요)
- Jira 웹 사이트에 로그인합니다.
- 상단 탐색 모음에서 생성 을 클릭합니다.
- Summary (요약) 필드에 설명 제목을 입력합니다.
- Description (설명) 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
- 대화 상자 하단에서 생성 을 클릭합니다.
1장. Identity Management의 공개 키 인증서
X.509 공개 키 인증서는 IdM(Identity Management)에서 사용자, 호스트 및 서비스를 인증하는 데 사용됩니다. 인증 외에도 X.509 인증서를 사용하면 디지털 서명 및 암호화를 통해 개인 정보 보호, 무결성 및 비회전을 제공할 수 있습니다.
인증서에는 다음 정보가 포함됩니다.
- 인증서가 인증되는 주체입니다.
- 인증서에 서명한 CA인 발급자입니다.
- 인증서 유효성의 시작 및 종료일입니다.
- 인증서의 유효한 사용입니다.
- 주체의 공개 키입니다.
공개 키로 암호화된 메시지는 해당 개인 키로만 암호를 해독할 수 있습니다. 인증서와 공개 키를 공개적으로 사용할 수 있지만 사용자, 호스트 또는 서비스는 개인 키 시크릿을 유지해야 합니다.
1.1. IdM의 인증 기관
인증 기관은 신뢰 계층에서 작동합니다. 내부 인증 기관(CA)이 있는 IdM 환경에서 모든 IdM 호스트, 사용자 및 서비스는 CA에서 서명한 인증서를 신뢰합니다. 이 루트 CA 외에도 IdM은 루트 CA에서 인증서 서명 기능을 부여한 하위 CA를 지원합니다. 이러한 하위 CA가 서명할 수 있는 인증서는 VPN 인증서(예: VPN 인증서)의 인증서입니다. 마지막으로 IdM은 외부 CA 사용을 지원합니다. 아래 표는 IdM에서 개별 유형의 CA를 사용하는 세부 사항을 보여줍니다.
CA 이름 | 설명 | 사용 | 유용한 링크 |
---|---|---|---|
| Dogtag 업스트림 프로젝트를 기반으로 하는 통합 CA | 통합 CA는 사용자, 호스트 및 서비스에 대한 인증서를 생성, 취소 및 발행할 수 있습니다. | |
IdM 하위 CA |
|
IdM 하위 CA는 | |
외부 CA | 외부 CA는 통합 IdM CA 또는 해당 하위 CA 이외의 CA입니다. | IdM 툴을 사용하여 이러한 CA에서 발행한 인증서를 사용자, 서비스 또는 호스트에 추가하고 이를 제거합니다. |
인증서 보기에서는 자체 서명된 IdM CA에서 서명하고 외부에서 서명할 때 차이가 없습니다.
CA의 역할에는 다음과 같은 용도가 포함됩니다.
- 디지털 인증서를 발급합니다.
- 인증서에 서명하면 인증서에 이름이 지정된 주체가 공개 키가 있음을 인증합니다. 주체는 사용자, 호스트 또는 서비스일 수 있습니다.
- 인증서를 해지할 수 있으며 CRL(Certificate Revocation Lists) 및 OCSCSP(Online Certificate Status Protocol)를 통해 해지 상태를 제공합니다.
추가 리소스
1.2. 인증서 및 Kerberos 비교
인증서는 Kerberos 티켓에서 수행하는 것과 유사한 기능을 수행합니다. Kerberos는 안전하지 않은 네트워크를 통해 통신하는 노드가 안전한 방식으로 서로의 ID를 검증할 수 있도록 티켓 기반으로 작동하는 컴퓨터 네트워크 인증 프로토콜입니다. 다음 표에서는 Kerberos 및 X.509 인증서 비교를 보여줍니다.
특성 | Kerberos | X.509 |
| 있음 | 있음 |
| 선택 사항 | 있음 |
| 선택 사항 | 있음 |
| symmetric | encryptedal |
| 짧은 (1일) | 긴(2년) |
기본적으로 Identity Management의 Kerberos는 통신 당사자의 ID만 보장합니다.
1.3. IdM에서 사용자를 인증하기 위해 인증서 사용 및 장단점
IdM에서 사용자를 인증하기 위해 인증서를 사용하는 이점은 다음과 같습니다.
- 스마트 카드의 개인 키를 보호하는 pin은 일반적으로 덜 복잡하고 일반 암호보다 쉽게 기억할 수 있습니다.
- 장치에 따라 스마트 카드에 저장된 개인 키를 내보낼 수 없습니다. 이는 추가 보안을 제공합니다.
- 스마트 카드는 로그아웃을 자동으로 수행할 수 있습니다. IdM은 사용자가 독자에서 스마트 카드를 제거할 때 사용자를 로그아웃하도록 구성할 수 있습니다.
- 개인 키를 도용하려면 스마트 카드에 대한 실제 물리적 액세스가 필요하므로 해킹 공격으로부터 스마트 카드를 보호해야합니다.
- 스마트 카드 인증은 2단계 인증의 예입니다. 이 인증에는 (카드)와 알 수 있는 내용(Pributional)이 모두 필요합니다.
- 스마트 카드는 암호보다 유연합니다. 이메일 암호화와 같은 다른 용도로 사용할 수 있는 키를 제공하기 때문입니다.
- IdM 클라이언트인 공유 시스템에서 스마트 카드를 사용하면 일반적으로 시스템 관리자에게 추가 구성 문제가 발생하지 않습니다. 실제로 스마트 카드 인증은 공유 머신에 이상적인 옵션입니다.
IdM에서 사용자를 인증하기 위해 인증서를 사용하는 단점은 다음과 같습니다.
- 사용자는 스마트 카드 또는 인증서를 가져 와서 효과적으로 잠길 수 있습니다.
- pin을 여러 번 제거하면 카드가 잠길 수 있습니다.
- 일반적으로 일종의 보안 담당자 또는 승인자의 요청과 승인 사이에 중간 단계가 있습니다. IdM에서 보안 담당자 또는 관리자는 ipa cert-request 명령을 실행해야 합니다.
- 스마트 카드와 독자는 공급 업체 및 드라이버별 경향이 있습니다. 독자가 다른 카드에 사용할 수 있지만 특정 공급 업체의 스마트 카드가 다른 공급 업체의 독자 또는 설계되지 않은 독자 유형에서 작동하지 않을 수 있습니다.
- 인증서 및 스마트 카드에는 관리자를위한 스테이프 학습 곡선이 있습니다.
2장. 통합 IdM CA를 사용하여 사용자, 호스트 및 서비스의 인증서 관리
통합 CA, ipa
CA 및 해당 하위 CA를 사용하여 IdM(Identity Management)에서 인증서를 관리하는 방법에 대한 자세한 내용은 다음 섹션을 참조하십시오.
- IdM 웹 UI를 사용하여 사용자, 호스트 또는 서비스에 대한 새 인증서 요청.
IdM CLI를 사용하여 IdM CA에서 사용자, 호스트 또는 서비스에 대한 새 인증서를 요청합니다.
certutil을 사용하여 IdM CA에서 사용자, 호스트 또는 서비스에 대한 새 인증서 요청
-
certutil
유틸리티를 사용하여 IdM CA에서 새 사용자 인증서를 요청하고 IdM 클라이언트로 내보내는 특정 예는 새 사용자 인증서 요청 및 클라이언트에 내보내기를 참조하십시오.
-
- openssl을 사용하여 IdM CA에서 사용자, 호스트 또는 서비스에 대한 새 인증서 요청
certmonger
유틸리티를 사용하여 IdM CA에서 서비스에 대한 새 인증서를 요청할 수도 있습니다. 자세한 내용은 certmonger를 사용하여 IdM CA에서 서비스에 대한 새 인증서 요청 에서 참조하십시오.
사전 요구 사항
IdM 배포에 통합 CA가 포함되어 있습니다.
- IdM에서 CA 서비스를 계획하는 방법에 대한 자세한 내용은 CA 서비스 계획을 참조하십시오.
- 통합 DNS 및 통합 CA를 루트 CA로 사용하여 IdM 서버를 설치하는 방법에 대한 자세한 내용은 통합 DNS 를 루트 CA로 사용하여 통합 DNS를 사용하여 IdM 서버설치를 참조하십시오.
- 통합 DNS 및 외부 CA를 루트 CA로 사용하여 IdM 서버를 설치하는 방법에 대한 자세한 내용은 외부 CA 를 루트 CA로 사용하여 통합 DNS를 사용하여 IdM 서버설치를 참조하십시오.
- 통합 DNS 없이 IdM 서버를 설치하는 방법에 대한 자세한 내용은 루트 CA로 통합 CA 를 사용하여 IdM 서버 설치: 통합 DNS 없이 IdM 서버 설치를 참조하십시오.
선택 사항: IdM 배포에서는 인증서로 인증하는 사용자를 지원합니다.
- IdM 클라이언트 파일 시스템에 저장된 인증서로 사용자 인증을 지원하도록 IdM 배포를 구성하는 방법에 대한 자세한 내용은 IdM 클라이언트 의 데스크탑에 저장된 인증서를 사용하여 인증 구성 을 참조하십시오.
- IdM 클라이언트에 삽입된 스마트 카드에 저장된 인증서로 사용자 인증을 지원하도록 IdM 배포를 구성하는 방법에 대한 자세한 내용은 스마트 카드 인증을 위한 ID 관리 구성을 참조하십시오.
- Active Directory 인증서 시스템에서 발행한 스마트 카드로 사용자 인증을 지원하도록 IdM 배포를 구성하는 방법에 대한 자세한 내용은 IdM의 스마트 카드 인증을 위해 ADCS에서 발급한 인증서 구성 을 참조하십시오.
2.1. IdM 웹 UI를 사용하여 사용자, 호스트 또는 서비스에 대한 새 인증서 요청
IdM(Identity Management) 웹 UI를 사용하여 ipa
CA 또는 해당 하위 CA에서 통합된 IdM 인증 기관(CA)의 새 인증서를 요청합니다.
IdM 엔티티는 다음과 같습니다.
- 사용자
- 호스트
- 서비스
일반적으로 서비스는 개인 키가 저장되는 전용 서비스 노드에서 실행됩니다. 서비스의 개인 키를 IdM 서버에 복사하는 것은 안전하지 않은 것으로 간주됩니다. 따라서 서비스에 대한 인증서를 요청할 때 서비스 노드에 CSR(인증서 서명 요청)을 만듭니다.
사전 요구 사항
- IdM 배포에는 통합 CA가 포함되어 있습니다.
- IdM 관리자로 IdM 웹 UI에 로그인되어 있습니다.
절차
-
Identity
(ID) 탭에서 사용자 ,호스트
서비스
하위 탭을 선택합니다. 사용자, 호스트 또는 서비스의 이름을 클릭하여 구성 페이지를 엽니다.
그림 2.1. 호스트 목록
- → (새 인증서)를 클릭합니다.
- 선택 사항: 발행 CA 및 프로필 ID를 선택합니다.
-
화면에서
certutil
명령줄(CLI) 유틸리티를 사용하는 방법에 대한 지침을 따릅니다. - 를 클릭합니다.
2.2. certutil을 사용하여 IdM CA에서 사용자, 호스트 또는 서비스에 대한 새 인증서 요청
certutil
유틸리티를 사용하여 표준 IdM 상황에서 IdM(Identity Management) 사용자, 호스트 또는 서비스에 대한 인증서를 요청할 수 있습니다. 호스트 또는 서비스 Kerberos 별칭이 인증서를 사용할 수 있도록 하려면 openssl 유틸리티를 사용하여 대신 인증서를 요청합니다.
certutil
을 사용하여 ipa
, IdM 인증 기관(CA)에서 IdM 사용자, 호스트 또는 서비스에 대한 인증서를 요청하려면 다음 절차를 따르십시오.
일반적으로 서비스는 개인 키가 저장되는 전용 서비스 노드에서 실행됩니다. 서비스의 개인 키를 IdM 서버에 복사하는 것은 안전하지 않은 것으로 간주됩니다. 따라서 서비스에 대한 인증서를 요청할 때 서비스 노드에 CSR(인증서 서명 요청)을 만듭니다.
사전 요구 사항
- IdM 배포에는 통합 CA가 포함되어 있습니다.
- IdM 관리자로 IdM 명령줄 인터페이스(CLI)에 로그인되어 있습니다.
절차
인증서 데이터베이스에 대한 임시 디렉터리를 생성합니다.
# mkdir ~/certdb/
새 임시 인증서 데이터베이스를 만듭니다. 예를 들면 다음과 같습니다.
# certutil -N -d ~/certdb/
CSR을 생성하고 출력을 파일로 리디렉션합니다. 예를 들어 4096비트 인증서에 대한 CSR을 생성하고 이를 CN=server.example.com,O=EXAMPLE.COM 으로 설정하려면 다음을 실행합니다.
# certutil -R -d ~/certdb/ -a -g 4096 -s "CN=server.example.com,O=EXAMPLE.COM" -8 server.example.com > certificate_request.csr
인증서 요청 파일을 IdM 서버에서 실행 중인 CA에 제출합니다. 새로 발급된 인증서와 연결할 Kerberos 주체를 지정합니다.
# ipa cert-request certificate_request.csr --principal=host/server.example.com
IdM의
ipa cert-request
명령에서는 다음과 같은 기본값을 사용합니다.caIPAserviceCert
인증서 프로파일사용자 지정 프로필을 선택하려면
--profile-id
옵션을 사용합니다.통합 IdM 루트 CA,
ipa
하위 CA를 선택하려면
--ca
옵션을 사용합니다.
추가 리소스
-
ipa cert-request --help
명령의 출력을 참조하십시오. - Identity Management에서 인증서 프로필 생성 및 관리를 참조하십시오.
2.3. openssl을 사용하여 IdM CA에서 사용자, 호스트 또는 서비스에 대한 새 인증서 요청
호스트 또는 서비스의 Kerberos 별칭이 인증서를 사용할 수 있도록 하려면 openssl
유틸리티를 사용하여 IdM(Identity Management) 호스트 또는 서비스에 대한 인증서를 요청할 수 있습니다. 표준 상황에서는 certutil 유틸리티를 사용하여 새 인증서를 요청하는 것이 좋습니다.
openssl
을 사용하여 ipa
, IdM 인증 기관에서 IdM 호스트 또는 서비스에 대한 인증서를 요청하려면 다음 절차를 따르십시오.
일반적으로 서비스는 개인 키가 저장되는 전용 서비스 노드에서 실행됩니다. 서비스의 개인 키를 IdM 서버에 복사하는 것은 안전하지 않은 것으로 간주됩니다. 따라서 서비스에 대한 인증서를 요청할 때 서비스 노드에 CSR(인증서 서명 요청)을 만듭니다.
사전 요구 사항
- IdM 배포에는 통합 CA가 포함되어 있습니다.
- IdM 관리자로 IdM 명령줄 인터페이스(CLI)에 로그인되어 있습니다.
절차
- Kerberos 보안 주체 test/server.example.com 에 대해 하나 이상의 별칭을 만듭니다. 예: test1/server.example.com 및 test2/server.example.com.
CSR에서 dnsName(server.example.com) 및 otherName(test2/server.example.com)에 subjectAltName을 추가합니다. 이렇게 하려면 UPN otherName 및 subjectAltName을 지정하는 다음 행을 포함하도록
openssl.conf
파일을 구성하십시오.otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM DNS.1 = server.example.com
openssl
을 사용하여 인증서 요청을 생성합니다.openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf
인증서 요청 파일을 IdM 서버에서 실행 중인 CA에 제출합니다. 새로 발급된 인증서와 연결할 Kerberos 주체를 지정합니다.
# ipa cert-request certificate_request.csr --principal=host/server.example.com
IdM의
ipa cert-request
명령에서는 다음과 같은 기본값을 사용합니다.caIPAserviceCert
인증서 프로파일사용자 지정 프로필을 선택하려면
--profile-id
옵션을 사용합니다.통합 IdM 루트 CA,
ipa
하위 CA를 선택하려면
--ca
옵션을 사용합니다.
추가 리소스
-
ipa cert-request --help
명령의 출력을 참조하십시오. - Identity Management에서 인증서 프로필 생성 및 관리를 참조하십시오.
2.4. 추가 리소스
- 통합 IdM CA로 인증서 해지를 참조하십시오.
- 통합 IdM CA가 있는 인증서 복원을 참조하십시오.
- 인증서 서브 세트만 신뢰하도록 애플리케이션 제한을 참조하십시오.
3장. Ansible을 사용하여 IdM 인증서 관리
ansible-freeipa
ipacert
모듈을 사용하여 IdM(Identity Management) 사용자, 호스트 및 서비스에 대한 SSL 인증서를 요청, 취소 및 검색할 수 있습니다. 보류 중인 인증서를 복원할 수도 있습니다.
3.1. Ansible을 사용하여 IdM 호스트, 서비스 및 사용자에 대한 SSL 인증서 요청
ansible-freeipa
ipacert
모듈을 사용하여 IdM(Identity Management) 사용자, 호스트 및 서비스에 대한 SSL 인증서를 요청할 수 있습니다. 그런 다음 이러한 인증서를 사용하여 IdM에 인증할 수 있습니다.
Ansible 플레이북을 사용하여 IdM 인증 기관(CA)에서 HTTP 서버의 인증서를 요청하려면 다음 절차를 완료합니다.
사전 요구 사항
제어 노드에서 다음을 수행합니다.
- Ansible 버전 2.14 이상을 사용하고 있습니다.
-
ansible-freeipa
패키지가 설치되어 있습니다. - ~/MyPlaybooks/ 디렉터리에 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했습니다.
-
ipaadmin_password
를 secret.yml Ansible vault에 저장했습니다.
- IdM 배포에 통합 CA가 있습니다.
절차
사용자, 호스트 또는 서비스에 대한 CSR(인증서 서명 요청)을 생성합니다. 예를 들어
openssl
유틸리티를 사용하여 client.idm.example.com에서 실행되는HTTP
서비스에 대한 CSR을 생성하려면 다음을 입력합니다.# openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout new.key -out new.csr -subj '/CN=client.idm.example.com,O=IDM.EXAMPLE.COM'
결과적으로 CSR은 new.csr 에 저장됩니다.
다음 내용으로 Ansible 플레이북 파일 request-certificate.yml 을 생성합니다.
--- - name: Playbook to request a certificate hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: Request a certificate for a web server ipacert: ipaadmin_password: "{{ ipaadmin_password }}" state: requested csr: | -----BEGIN CERTIFICATE REQUEST----- MIGYMEwCAQAwGTEXMBUGA1UEAwwOZnJlZWlwYSBydWxlcyEwKjAFBgMrZXADIQBs HlqIr4b/XNK+K8QLJKIzfvuNK0buBhLz3LAzY7QDEqAAMAUGAytlcANBAF4oSCbA 5aIPukCidnZJdr491G4LBE+URecYXsPknwYb+V+ONnf5ycZHyaFv+jkUBFGFeDgU SYaXm/gF8cDYjQI= -----END CERTIFICATE REQUEST----- principal: HTTP/client.idm.example.com register: cert
인증서 요청을 new.csr 의 CSR으로 바꿉니다.
인증서를 요청합니다.
$ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/request-certificate.yml
3.2. Ansible을 사용하여 IdM 호스트, 서비스 및 사용자의 SSL 인증서 취소
ansible-freeipa
ipacert
모듈을 사용하여 IdM(Identity Management) 사용자, 호스트 및 서비스에서 IdM을 인증하는 SSL 인증서를 취소할 수 있습니다.
Ansible 플레이북을 사용하여 HTTP 서버의 인증서를 취소하려면 다음 절차를 완료합니다. 인증서를 취소하는 이유는 "keyCompromise"입니다.
사전 요구 사항
제어 노드에서 다음을 수행합니다.
- Ansible 버전 2.14 이상을 사용하고 있습니다.
-
ansible-freeipa
패키지가 설치되어 있습니다. - ~/MyPlaybooks/ 디렉터리에 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했습니다.
-
ipaadmin_password
를 secret.yml Ansible vault에 저장했습니다. -
예를 들어
openssl x509 -noout -text -in <path_to_certificate
> 명령을 입력하여 인증서의 일련 번호를 가져왔습니다. 이 예에서 인증서의 일련 번호는 123456789입니다.
- IdM 배포에 통합 CA가 있습니다.
절차
다음 콘텐츠를 사용하여 Ansible 플레이북 파일 revoke-certificate.yml 을 생성합니다.
--- - name: Playbook to revoke a certificate hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: Revoke a certificate for a web server ipacert: ipaadmin_password: "{{ ipaadmin_password }}" serial_number: 123456789 revocation_reason: "keyCompromise" state: revoked
인증서를 취소하십시오.
$ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/revoke-certificate.yml
추가 리소스
-
ansible-freeipa
업스트림 문서의 cert 모듈 - RFC 5280의 이유 코드
3.3. Ansible을 사용하여 IdM 사용자, 호스트 및 서비스의 SSL 인증서 복원
ansible-freeipa
ipacert
모듈을 사용하여 IdM(Identity Management) 사용자, 호스트 또는 서비스에서 이전에 IdM을 인증하는 취소된 SSL 인증서를 복원할 수 있습니다.
보류 중인 인증서만 복원할 수 있습니다. 예를 들어 개인 키가 손실되었는지 확실하지 않았기 때문에 보류 중일 수 있습니다. 그러나 이제 키를 복구했으며 그동안 아무나 액세스하지 않았으므로 인증서를 다시 사용하려고 합니다.
Ansible 플레이북을 사용하여 IdM에 등록된 서비스의 인증서를 해제하려면 다음 절차를 완료합니다. 이 예에서는 HTTP 서비스의 인증서를 보류에서 해제하는 방법을 설명합니다.
사전 요구 사항
제어 노드에서 다음을 수행합니다.
- Ansible 버전 2.14 이상을 사용하고 있습니다.
-
ansible-freeipa
패키지가 설치되어 있습니다. - ~/MyPlaybooks/ 디렉터리에 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했습니다.
-
ipaadmin_password
를 secret.yml Ansible vault에 저장했습니다.
- IdM 배포에 통합 CA가 있습니다.
-
예를 들어
openssl x509 -noout -text -in path/to/certificate
명령을 입력하여 인증서의 일련 번호를 가져왔습니다. 이 예에서 인증서 일련 번호는 123456789 입니다.
절차
다음 콘텐츠를 사용하여 Ansible 플레이북 파일 restore-certificate.yml 을 생성합니다.
--- - name: Playbook to restore a certificate hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: Restore a certificate for a web service ipacert: ipaadmin_password: "{{ ipaadmin_password }}" serial_number: 123456789 state: released
플레이북을 실행합니다.
$ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/restore-certificate.yml
3.4. Ansible을 사용하여 IdM 사용자, 호스트 및 서비스의 SSL 인증서 검색
ansible-freeipa
ipacert
모듈을 사용하여 IdM(Identity Management) 사용자, 호스트 또는 서비스에 대해 발행된 SSL 인증서를 검색하고 관리 노드의 파일에 저장할 수 있습니다.
사전 요구 사항
제어 노드에서 다음을 수행합니다.
- Ansible 버전 2.14 이상을 사용하고 있습니다.
-
ansible-freeipa
패키지가 설치되어 있습니다. - ~/MyPlaybooks/ 디렉터리에 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했습니다.
-
ipaadmin_password
를 secret.yml Ansible vault에 저장했습니다.
-
예를 들어
openssl x509 -noout -text -in <path_to_certificate
> 명령을 입력하여 인증서의 일련 번호를 가져왔습니다. 이 예에서 인증서의 일련 번호는 123456789이고 검색된 인증서를 저장하는 파일은 cert.pem 입니다.
절차
다음 콘텐츠를 사용하여 Ansible 플레이북 파일 retrieve-certificate.yml 을 생성합니다.
--- - name: Playbook to retrieve a certificate and store it locally on the managed node hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: Retrieve a certificate and save it to file 'cert.pem' ipacert: ipaadmin_password: "{{ ipaadmin_password }}" serial_number: 123456789 certificate_out: cert.pem state: retrieved
인증서를 검색합니다.
$ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/retrieve-certificate.yml
4장. IdM 사용자, 호스트 및 서비스용 외부 서명된 인증서 관리
이 장에서는 IdM(Identity Management) 명령줄 인터페이스(CLI)와 IdM 웹 UI를 사용하여 외부 인증 기관(CA)에서 발급한 사용자, 호스트 또는 서비스 인증서를 추가하거나 제거하는 방법을 설명합니다.
4.1. IdM CLI를 사용하여 외부 CA에서 발급한 인증서 추가, IdM 사용자, 호스트 또는 서비스
IdM(Identity Management) 관리자는 IdM(Identity Management) CLI를 사용하여 IdM 사용자, 호스트 또는 서비스 계정에 외부 서명된 인증서를 추가할 수 있습니다.
사전 요구 사항
- 관리 사용자의 티켓 개발 티켓이 있습니다.
절차
IdM 사용자에게 인증서를 추가하려면 다음을 입력합니다.
$ ipa user-add-cert user --certificate=MIQTPrajQAwg...
명령을 사용하려면 다음 정보를 지정해야 합니다.
- 사용자의 이름
- Base64로 인코딩된 DER 인증서
인증서 내용을 명령줄에 복사하고 붙여넣는 대신 인증서를 DER 형식으로 변환한 다음 Base64로 다시 코딩할 수 있습니다. 예를 들어 user_cert.pem
인증서를 사용자
에 추가하려면 다음을 입력합니다.
$ ipa user-add-cert user --certificate="$(openssl x509 -outform der -in user_cert.pem | base64 -w 0)"
옵션을 추가하지 않고 ipa user-add-cert
명령을 실행할 수 있습니다.
IdM 호스트에 인증서를 추가하려면 다음을 입력합니다.
-
ipa host-add-cert
IdM 서비스에 인증서를 추가하려면 다음을 입력합니다.
-
ipa service-add-cert
4.2. IdM 웹 UI를 사용하여 IdM 사용자, 호스트 또는 서비스에 외부 CA에서 발급한 인증서 추가
IdM(Identity Management) 관리자는 IdM(Identity Management) 웹 UI를 사용하여 IdM 사용자, 호스트 또는 서비스 계정에 외부 서명된 인증서를 추가할 수 있습니다.
사전 요구 사항
- IdM(Identity Management) 웹 UI에 관리자로 로그인되어 있습니다.
절차
-
Identity
탭을 열고사용자
,호스트
또는서비스
하위 탭을 선택합니다. - 사용자, 호스트 또는 서비스의 이름을 클릭하여 구성 페이지를 엽니다.
Certificates
(인증서) 항목 옆에 있는 (추가)를 클릭합니다.그림 4.1. 사용자 계정에 인증서 추가
- Base64 또는 PEM으로 인코딩된 형식으로 인증서를 붙여넣고 텍스트 필드에 인증서를 붙여넣고 클릭합니다.
- 클릭하여 변경 사항을 저장합니다.
4.3. IdM CLI를 사용하여 IdM 사용자, 호스트 또는 서비스 계정에서 외부 CA에서 발급한 인증서 제거
IdM(Identity Management) 관리자는 IdM(Identity Management) CLI를 사용하여 IdM 사용자, 호스트 또는 서비스의 계정에서 외부 서명된 인증서를 제거할 수 있습니다.
사전 요구 사항
- 관리 사용자의 티켓 개발 티켓이 있습니다.
절차
IdM 사용자의 인증서를 제거하려면 다음을 입력합니다.
$ ipa user-remove-cert user --certificate=MIQTPrajQAwg...
명령을 사용하려면 다음 정보를 지정해야 합니다.
- 사용자의 이름
- Base64로 인코딩된 DER 인증서
인증서 내용을 명령줄에 복사하고 붙여넣는 대신 인증서를 DER 형식으로 변환한 다음 Base64로 다시 코딩할 수 있습니다. 예를 들어 사용자 에서 user_cert.pem
인증서를 제거하려면 다음을 입력합니다.
$ ipa user-remove-cert user --certificate="$(openssl x509 -outform der -in user_cert.pem | base64 -w 0)"
옵션을 추가하지 않고 ipa user-remove-cert
명령을 대화형으로 실행할 수 있습니다.
IdM 호스트에서 인증서를 제거하려면 다음을 입력합니다.
-
ipa host-remove-cert
IdM 서비스에서 인증서를 제거하려면 다음을 입력합니다.
-
ipa service-remove-cert
4.4. IdM 웹 UI를 사용하여 IdM 사용자, 호스트 또는 서비스 계정에서 외부 CA에서 발급한 인증서 제거
IdM(Identity Management) 관리자는 IdM(Identity Management) 웹 UI를 사용하여 IdM 사용자, 호스트 또는 서비스의 계정에서 외부 서명된 인증서를 제거할 수 있습니다.
사전 요구 사항
- IdM(Identity Management) 웹 UI에 관리자로 로그인되어 있습니다.
절차
-
Identity
탭을 열고사용자
,호스트
또는서비스
하위 탭을 선택합니다. - 사용자, 호스트 또는 서비스의 이름을 클릭하여 구성 페이지를 엽니다.
- 삭제할 인증서 옆에 있는 클릭하고 삭제를 선택합니다.
- 클릭하여 변경 사항을 저장합니다.
4.5. 추가 리소스
5장. IdM에서 작동하도록 인증서 형식 변환
이 사용자 사례에서는 IdM 시스템 관리자로서 특정 IdM 명령과 함께 올바른 형식의 인증서를 사용하고 있는지 확인하는 방법을 설명합니다. 예를 들어 다음과 같은 경우 유용합니다.
- 사용자 프로필에 외부 인증서를 로드하고 있습니다. 자세한 내용은 외부 인증서를 변환하여 IdM 사용자 계정으로 로드합니다.
- 스마트 카드 인증을 위해 IdM 서버를 구성하거나 스마트 카드 인증을 위해 IdM 클라이언트를 구성할 때 외부 CA 인증서를 사용하고 있으며 사용자는 외부 인증 기관에서 발급한 인증서와 함께 스마트 카드를 사용하여 IdM에 인증할 수 있습니다.
- NSS 데이터베이스의 인증서를 인증서와 개인 키가 모두 포함된 pkcs #12 형식으로 내보내고 있습니다. 자세한 내용은 NSS 데이터베이스에서 PKCS #12 파일로 인증서 및 개인 키 내보내기를 참조하십시오.
5.1. IdM의 인증서 형식 및 인코딩
IdM의 스마트 카드 인증이 포함된 인증서 인증은 사용자가 제공하는 인증서 또는 사용자의 IdM 프로필에 저장된 인증서 데이터를 비교하여 진행합니다.
시스템 구성
IdM 프로필에 저장된 내용은 해당 개인 키가 아닌 인증서일 뿐입니다. 인증하는 동안 사용자는 해당 개인 키를 보유하는 경우에도 표시되어야 합니다. 사용자는 인증서와 개인 키가 모두 포함된 PKCS #12 파일을 제공하거나 두 개의 파일(인증서 포함)과 개인 키를 포함하는 파일을 제공하여 이를 수행합니다.
따라서 사용자 프로필에 인증서를 로드하는 것과 같은 프로세스는 개인 키가 포함되지 않은 인증서 파일만 허용합니다.
마찬가지로 시스템 관리자가 외부 CA 인증서를 제공할 때 공개 데이터만 제공합니다. 개인 키가 없는 인증서만 제공합니다. IdM 서버 또는 스마트 카드 인증을 위한 IdM 클라이언트를 구성하기 위한 ipa-advise
유틸리티에서는 입력 파일에 개인 키가 아닌 외부 CA의 인증서가 포함되어 있어야 합니다.
인증서 인코딩
두 가지 일반적인 인증서 인코딩이 있습니다: 개인 정보 보호 전자 메일 (PEM
) 및 Distinguished Encoding 규칙 (DER
). base64
형식은 PEM
형식과 거의 동일하지만 -----BEGIN CERTIFICATE--------END CERTIFICATE----END CERTIFICATE
------ 헤더 및 footer는 포함되어 있지 않습니다.
DER
를 사용하여 인코딩한 인증서는 바이너리 X509 디지털 인증서 파일입니다. 바이너리 파일로, 인증서는 사람이 읽을 수 없습니다. DER
파일은 때때로 .der
파일 이름 확장자를 사용하지만 .crt
및 .cer
파일 이름이 확장 된 파일에도 DER
인증서가 포함될 수 있습니다. 키를 포함하는 DER
파일의 이름은 .key
일 수 있습니다.
PEM
Base64를 사용하여 인코딩한 인증서는 사람이 읽을 수 있는 파일입니다. 파일에는 ASCII(Base64)가 "------BEGIN" 줄이 접두사가 붙은 데이터가 포함되어 있습니다. PEM
파일은 경우에 따라 .pem
파일 이름 확장자를 사용하지만 .crt
및 .cer
파일 이름 확장자가 있는 파일에 PEM
인증서가 포함된 경우가 있습니다. 키가 포함된 PEM
파일의 이름은 .key
로 지정할 수 있습니다.
다른 ipa
명령은 수락하는 인증서 유형에 대한 다른 제한 사항이 있습니다. 예를 들어 ipa user-add-cert
명령은 base64
형식으로 인코딩된 인증서만 허용하지만 ipa-server-certinstall
은 PEM, DER, PKCS #7, PKCS #8
및 PKCS #12
인증서를 허용합니다.
인코딩 형식 | 사람이 읽을 수 있는 | 일반적인 파일 이름 확장 | 인코딩 형식을 허용하는 샘플 IdM 명령 |
---|---|---|---|
PEM/base64 | 있음 | .pem, .crt, .cer | ipa user-add-cert, ipa-server-certinstall, … |
DER | 없음 | .der, .crt, .cer | ipa-server-certinstall, … |
IdM의 인증서 관련 명령 및 형식은 명령에서 허용하는 인증서 형식과 함께 추가 ipa
명령을 나열합니다.
사용자 인증
웹 UI를 사용하여 IdM에 액세스하는 경우 사용자는 두 브라우저의 데이터베이스에 두 가지를 저장하여 인증서에 해당하는 개인 키를 보유하고 있음을 증명합니다.
CLI를 사용하여 IdM에 액세스하는 경우 사용자는 다음 방법 중 하나로 인증서에 해당하는 개인 키를 보유하고 있음을 증명합니다.
사용자는
kinit -X
명령의X509_user_identity
매개변수 값으로, 인증서와 키를 모두 포함하는 스마트 카드 모듈에 대한 경로를 추가합니다.$ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so'
idm_user
사용자는 두 개의 파일을
kinit -X
명령의X509_user_identity
매개변수 값으로 추가합니다. 하나는 인증서와 다른 개인 키를 포함합니다.$ kinit -X X509_user_identity='FILE:`/path/to/cert.pem,/path/to/cert.key`'
idm_user
유용한 인증서 명령
주체 및 발급자와 같은 인증서 데이터를 보려면 다음을 수행합니다.
$ openssl x509 -noout -text -in ca.pem
두 인증서의 차이가 있는 행을 비교하려면 다음을 수행합니다.
$ diff cert1.crt cert2.crt
두 인증서의 행을 두 개의 인증서가 두 열에 표시된 출력과 비교하려면 다음을 수행합니다.
$ diff cert1.crt cert2.crt -y
5.2. 외부 인증서를 IdM 사용자 계정으로 로드하도록 변환
이 섹션에서는 사용자 항목에 추가하기 전에 외부 인증서가 올바르게 인코딩되고 포맷되는지 확인하는 방법을 설명합니다.
5.2.1. 사전 요구 사항
-
Active Directory 인증 기관에서 인증서를 발급했으며
PEM
인코딩을 사용하는 경우PEM
파일이UNIX
형식으로 변환되었는지 확인합니다. 파일을 변환하려면 eponymous 패키지에서 제공하는dos2unix
유틸리티를 사용합니다.
5.2.2. IdM CLI에서 외부 인증서를 변환하여 IdM 사용자 계정으로 로드합니다.
IdM CLI
는 첫 번째 및 마지막 행(----BEGIN CERTIFICATE--- 및 ---END CERTIFICATE----)이 제거된 PEM
인증서만 허용합니다.
다음 절차에 따라 외부 인증서를 PEM
형식으로 변환하고 IdM CLI를 사용하여 IdM 사용자 계정에 추가합니다.
절차
인증서를
PEM
형식으로 변환합니다.인증서가
DER
형식인 경우:$ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
파일이
PKCS #12
형식인 경우 공통 파일 이름 확장자가.pfx
및.p12
이고 인증서, 개인 키 및 기타 데이터가 포함되어 있는 경우openssl pkcs12
유틸리티를 사용하여 인증서를 추출하십시오. 메시지가 표시되면 파일에 저장된 개인 키를 보호하는 암호를 입력합니다.$ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem Enter Import Password:
관리자의 자격 증명을 가져옵니다.
$ kinit admin
다음 방법 중 하나에서
IdM CLI
를 사용하여 사용자 계정에 인증서를 추가합니다.ipa user-add-cert
명령에 문자열을 추가하기 전에sed
유틸리티를 사용하여PEM
파일의 첫 번째 및 마지막 행(--END CEIFICATE---- 및 ---END CEIFICATE-----)을 제거합니다.$ ipa user-add-cert some_user --certificate="$(sed -e '/BEGIN CERTIFICATE/d;/END CERTIFICATE/d' cert.pem)"
첫 번째 및 마지막 행(-----BEGIN CERTIFICATE--- 및 ---END CERTIFICATE------)을
ipa user-add-cert
명령으로 복사 및 붙여 넣습니다.$ ipa user-add-cert some_user --certificate=MIIDlzCCAn+gAwIBAgIBATANBgkqhki...
참고첫 번째 및 마지막 행(----BEGIN CERTIFICATE--- 및 ----END CERTIFICATE------)을 먼저 제거하지 않고 인증서가 포함된
PEM
파일을ipa user-add-cert
명령에 직접 전달할 수 없습니다.$ ipa user-add-cert some_user --cert=some_user_cert.pem
이 명령을 실행하면 "ipa: ERROR: Base64 디코딩 failed: Incorrect padding" 오류 메시지가 표시됩니다.
인증서가 시스템에서 수락되었는지 확인하려면 다음을 수행합니다.
[idm_user@r8server]$ ipa user-show some_user
5.2.3. IdM 사용자 계정으로 로드하기 위해 IdM 웹 UI에서 외부 인증서를 변환
다음 절차에 따라 외부 인증서를 PEM
형식으로 변환하고 IdM 웹 UI의 IdM 사용자 계정에 추가합니다.
절차
CLI
를 사용하여 인증서를PEM
형식으로 변환합니다.인증서가
DER
형식인 경우:$ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
파일이
PKCS #12
형식인 경우 공통 파일 이름 확장자가.pfx
및.p12
이고 인증서, 개인 키 및 기타 데이터가 포함되어 있는 경우openssl pkcs12
유틸리티를 사용하여 인증서를 추출하십시오. 메시지가 표시되면 파일에 저장된 개인 키를 보호하는 암호를 입력합니다.$ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem Enter Import Password:
-
편집기에서 인증서를 열고 콘텐츠를 복사합니다. IdM 웹 UI에서
PEM
및base64
형식을 모두 수락해야 하므로 "-----BEGIN CERTIFICATE------" 및 "-END CERTIFICATE----" 헤더와 footer 행 모두를 포함할 수 있습니다. - IdM 웹 UI에서 보안 담당자로 로그인합니다.
-
Identity
→Users
→some_user
로 이동합니다. -
인증서
옆에 있는추가를
클릭합니다. - 인증서의 PEM 형식 콘텐츠를 여는 창에 붙여넣습니다.
-
추가를
클릭합니다.
시스템에서 인증서를 수락한 경우 사용자 프로필의 인증서
중 목록을 볼 수 있습니다.
5.3. 브라우저에 인증서 로드 준비
브라우저로 사용자 인증서를 가져오기 전에 인증서 및 해당 개인 키가 PKCS #12
형식이어야 합니다. 추가 준비 작업이 필요한 두 가지 일반적인 상황이 있습니다.
- 인증서는 NSS 데이터베이스에 있습니다. 이 상황에서 진행되는 방법에 대한 자세한 내용은 NSS 데이터베이스에서 인증서 및 개인 키 내보내기를 PKCS #12 파일로 참조하십시오.
-
인증서와 개인 키는 두 개의 별도의
PEM
파일에 있습니다. 이 상황에서 진행되는 방법에 대한 자세한 내용은 인증서 및 개인 키 PEM 파일을 PKCS #12 파일로 결합을 참조하십시오.
그 후, PEM
형식으로 CA 인증서를 둘 다 가져오고 PKCS #12
형식의 사용자 인증서를 브라우저에 가져오 려면 브라우저 설정 절차에 따라 ID 관리 웹 UI를 사용하여 ID 관리 웹 UI에 대한 인증 및 ID 관리 사용자.
5.3.1. NSS 데이터베이스에서 인증서 및 개인 키를 PKCS #12 파일로 내보내기
절차
pk12util
명령을 사용하여 NSS 데이터베이스에서PKCS12
형식으로 인증서를 내보냅니다. 예를 들어~/certdb
디렉터리에 저장된 NSS 데이터베이스에서some_user
nickname을 사용하여 인증서를~/some_user.p12
파일로 내보내려면 다음을 실행합니다.$ pk12util -d
~/certdb
-o~/some_user.p12
-n some_user Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFUL.p12
파일에 적절한 권한을 설정합니다.# chmod 600 ~/some_user.p12
PKCS #12
파일에는 개인 키도 포함되어 있으므로 다른 사용자가 파일을 사용하지 못하도록 보호해야 합니다. 그렇지 않으면 사용자가 가장할 수 있습니다.
5.3.2. 인증서 및 개인 키 PEM 파일을 PKCS #12 파일로 결합
인증서와 별도의 PEM
파일에 저장된 해당 키를 PKCS #12
파일로 결합하려면 다음 절차를 따르십시오.
절차
certfile.cer
에 저장된 인증서와certfile.key
에 저장된 키를 인증서와 키가 모두 포함된certfile.p12
파일로 결합하려면 다음을 수행합니다.$ openssl pkcs12 -export -in certfile.cer -inkey certfile.key -out certfile.p12
5.4. IdM의 인증서 관련 명령 및 형식
다음 표에는 허용 가능한 형식이 있는 IdM의 인증서 관련 명령이 표시되어 있습니다.
명령 | 허용 가능한 형식 | 참고 |
---|---|---|
| base64 PEM 인증서 | |
| PEM 및 DER 인증서, PKCS#7 인증서 체인, PKCS#8 및 원시 개인 키, PKCS#12 인증서 및 개인 키 | |
| DER; PEM; PKCS#7 | |
| PEM 및 DER 인증서; PKCS#7 인증서 체인 | |
| PEM 및 DER 인증서; PKCS#7 인증서 체인 | |
| 해당 없음 |
< |
| 해당 없음 |
< |
| 해당 없음 |
새 인증서로 PEM 형식으로 |
| 해당 없음 |
새 인증서로 PEM 형식으로 |
6장. Identity Management에서 인증서 프로필 생성 및 관리
인증서 프로필은 인증서에 서명할 때 인증서 서명 요청(CSR)이 허용되는지, 인증서 서명 요청(CSR)이 인증서에 존재하는 기능 및 확장이 있는지 확인할 때 CA(인증 기관)에서 사용됩니다. 인증서 프로필은 특정 유형의 인증서를 발급하는 것과 연결되어 있습니다. 인증서 프로필과 CA ACL(액세스 제어 목록)을 결합하면 사용자 정의 인증서 프로필에 대한 액세스를 정의하고 제어할 수 있습니다.
이 절차에서는 인증서 프로필을 생성하는 방법을 설명하여 S/MIME 인증서를 예로 사용합니다. 일부 이메일 프로그램은 S/MIME(Secure Multipurpose Internet mail Extension) 프로토콜을 사용하여 디지털 서명 및 암호화된 이메일을 지원합니다. S/MIME를 사용하여 이메일 메시지를 서명하거나 암호화하려면 메시지의 발신자가 S/MIME 인증서를 가져야 합니다.
6.1. 인증서 프로필이란 무엇입니까?
인증서 프로필을 사용하여 인증서의 콘텐츠와 다음과 같은 인증서를 발급하기 위한 제약 조건을 확인할 수 있습니다.
- 인증서 서명 요청을 연결하는 데 사용할 서명 알고리즘입니다.
- 인증서의 기본 유효성입니다.
- 인증서를 취소하는 데 사용할 수 있는 해지 이유는 다음과 같습니다.
- 보안 주체의 공통 이름이 주체 대체 이름 필드에 복사되는 경우If the common name of the principal is copied to the subject alternative name field.
- 인증서에 존재해야 하는 기능 및 확장 기능입니다.
단일 인증서 프로필은 특정 유형의 인증서를 발급하는 것과 연결되어 있습니다. IdM에서 사용자, 서비스 및 호스트에 대해 다른 인증서 프로필을 정의할 수 있습니다. IdM에는 기본적으로 다음 인증서 프로필이 포함됩니다.
-
caIPAserviceCert
-
IECUserRoles
-
NetNamespaces_PKINIT_Certs
( internally)
또한 특정 용도로 인증서를 발행할 수 있는 사용자 정의 프로필을 생성하고 가져올 수 있습니다. 예를 들어 특정 프로필의 사용을 한 명의 사용자 또는 하나의 그룹으로만 제한하여 다른 사용자 및 그룹이 인증을 위해 인증서를 발급하는 데 해당 프로필을 사용하지 못하도록 할 수 있습니다. 사용자 정의 인증서 프로필을 생성하려면 ipa certprofile
명령을 사용합니다.
추가 리소스
-
ipa help certprofile
명령을 참조하십시오.
6.2. 인증서 프로파일 생성
다음 절차에 따라 S/MIME 인증서를 요청하기 위한 프로파일 구성 파일을 생성하여 명령줄을 통해 인증서 프로필을 생성합니다.
절차
기존 기본 프로필을 복사하여 사용자 정의 프로필을 생성합니다.
$ ipa certprofile-show --out smime.cfg caIPAserviceCert ------------------------------------------------ Profile configuration stored in file 'smime.cfg' ------------------------------------------------ Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE
텍스트 편집기에서 새로 생성된 프로필 구성 파일을 엽니다.
$ vi smime.cfg
프로필 ID
를 프로필 사용을 반영하는 이름으로 변경합니다(예:smime
).참고새로 생성된 프로필을 가져올 때
profileId
필드가 있는 경우 명령줄에 지정된 ID와 일치해야 합니다.확장 키 사용 구성을 업데이트합니다. 기본 확장 키 사용 확장 구성은 TLS 서버 및 클라이언트 인증에 사용됩니다. 예를 들어 S/MIME의 경우 이메일 보호를 위해 확장 키 사용을 구성해야 합니다.
policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.4
새 프로필을 가져옵니다.
$ ipa certprofile-import smime --file smime.cfg \ --desc "S/MIME certificates" --store TRUE ------------------------ Imported profile "smime" ------------------------ Profile ID: smime Profile description: S/MIME certificates Store issued certificates: TRUE
검증
새 인증서 프로필이 가져왔는지 확인합니다.
$ ipa certprofile-find ------------------ 4 profiles matched ------------------ Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE Profile ID: IECUserRoles Profile description: User profile that includes IECUserRoles extension from request Store issued certificates: TRUE Profile ID: KDCs_PKINIT_Certs Profile description: Profile for PKINIT support by KDCs Store issued certificates: TRUE Profile ID: smime Profile description: S/MIME certificates Store issued certificates: TRUE ---------------------------- Number of entries returned 4 ----------------------------
추가 리소스
-
ipa help certprofile
을 참조하십시오. - RFC 5280, 섹션 4.2.1.12 를 참조하십시오.
6.3. CA 액세스 제어 목록이란 무엇입니까?
CA ACL(인증 기관 액세스 제어 목록) 규칙은 보안 주체에 인증서를 발급하는 데 사용할 수 있는 프로필을 정의합니다. CA ACL을 사용하여 이 작업을 수행할 수 있습니다. 예를 들면 다음과 같습니다.
- 특정 프로필을 사용하여 인증서를 발급할 수 있는 사용자, 호스트 또는 서비스 확인
- 인증서를 발급할 수 있는 IdM 인증 기관 또는 하위 CA 확인
예를 들어, CA ACL을 사용하면 런던에 위치한 사무실에서 작업 중인 직원은 런던 사무실 관련 IdM 사용자 그룹의 멤버인 사용자에게만 사용할 수 있습니다.
CA ACL 규칙 관리를 위한 ipa caacl
유틸리티를 사용하면 권한 있는 사용자가 지정된 CA ACL을 추가, 표시, 수정 또는 삭제할 수 있습니다.
추가 리소스
-
ipa help caacl
을 참조하십시오.
6.4. 인증서 프로필에 대한 액세스를 제어하기 위한 CA ACL 정의
caacl
유틸리티를 사용하여 ACL(CA Access Control List) 규칙을 정의하여 그룹의 사용자가 사용자 정의 인증서 프로필에 액세스할 수 있도록 하려면 다음 절차를 따르십시오. 이 경우 절차에서는 S/MIME 사용자 그룹 및 CA ACL을 생성하여 해당 그룹의 사용자가 smime
인증서 프로필에 액세스할 수 있도록 하는 방법을 설명합니다.
사전 요구 사항
- IdM 관리자의 인증 정보를 가져왔는지 확인합니다.
절차
인증서 프로필의 사용자를 위한 새 그룹을 생성합니다.
$ ipa group-add smime_users_group --------------------------------- Added group "smime users group" --------------------------------- Group name: smime_users_group GID: 75400001
smime_user_group
그룹에 추가할 새 사용자를 생성합니다.$ ipa user-add smime_user First name: smime Last name: user ---------------------- Added user "smime_user" ---------------------- User login: smime_user First name: smime Last name: user Full name: smime user Display name: smime user Initials: TU Home directory: /home/smime_user GECOS: smime user Login shell: /bin/sh Principal name: smime_user@IDM.EXAMPLE.COM Principal alias: smime_user@IDM.EXAMPLE.COM Email address: smime_user@idm.example.com UID: 1505000004 GID: 1505000004 Password: False Member of groups: ipausers Kerberos keys available: False
smime_user
를smime_users_group
그룹에 추가합니다.$ ipa group-add-member smime_users_group --users=smime_user Group name: smime_users_group GID: 1505000003 Member users: smime_user ------------------------- Number of members added 1 -------------------------
그룹의 사용자가 인증서 프로필에 액세스할 수 있도록 CA ACL을 만듭니다.
$ ipa caacl-add smime_acl ------------------------ Added CA ACL "smime_acl" ------------------------ ACL name: smime_acl Enabled: TRUE
CA ACL에 사용자 그룹을 추가합니다.
$ ipa caacl-add-user smime_acl --group smime_users_group ACL name: smime_acl Enabled: TRUE User Groups: smime_users_group ------------------------- Number of members added 1 -------------------------
CA ACL에 인증서 프로필을 추가합니다.
$ ipa caacl-add-profile smime_acl --certprofile smime ACL name: smime_acl Enabled: TRUE Profiles: smime User Groups: smime_users_group ------------------------- Number of members added 1 -------------------------
검증
생성한 CA ACL의 세부 정보를 확인합니다.
$ ipa caacl-show smime_acl ACL name: smime_acl Enabled: TRUE Profiles: smime User Groups: smime_users_group ...
추가 리소스
-
시스템의
ipa
도움말 페이지를 참조하십시오. -
ipa help caacl
을 참조하십시오.
6.5. 인증서 프로필 및 CA ACL을 사용하여 인증서 발급
CA ACL(인증 기관 액세스 제어 목록)에서 허용하는 경우 인증서 프로필을 사용하여 인증서를 요청할 수 있습니다. CA ACL을 통해 액세스 권한이 부여된 사용자 정의 인증서 프로필을 사용하여 사용자에 대한 S/MIME 인증서를 요청하려면 다음 절차를 따르십시오.
사전 요구 사항
- 인증서 프로필이 생성되었습니다.
- 사용자가 필요한 인증서 프로필을 사용하여 인증서를 요청할 수 있는 CA ACL이 생성되었습니다.
cert-request
명령을 수행하는 사용자가 CA ACL 검사를 바이패스할 수 있습니다.
-
는
admin
사용자입니다. -
CA ACL
요청에서 CA ACL 권한이 무시되어
있습니다.
절차
사용자에 대한 인증서 요청을 생성합니다. 예를 들어 OpenSSL을 사용합니다.
$ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=smime_user'
IdM CA에서 사용자의 새 인증서를 요청합니다.
$ ipa cert-request cert.csr --principal=smime_user --profile-id=smime
선택적으로 --ca 하위-CA_name 옵션을 명령에 전달하여 루트 CA 대신 하위 CA에서 인증서를 요청합니다.
검증
새로 발급한 인증서가 사용자에게 할당되어 있는지 확인합니다.
$ ipa user-show user User login: user ... Certificate: MIICfzCCAWcCAQA... ...
추가 리소스
-
시스템의 IPA(a)
및openssl(lssl)
도움말 페이지 -
IPA 도움말 user-show
명령 -
IPA 도움말 cert-request
명령
6.6. 인증서 프로필 수정
ipa certprofile-mod
명령을 사용하여 명령줄을 통해 인증서 프로필을 직접 수정하려면 다음 절차를 따르십시오.
절차
수정 중인 인증서 프로필의 인증서 프로필 ID를 확인합니다. IdM에 현재 저장된 모든 인증서 프로필을 표시하려면 다음을 수행합니다.
# ipa certprofile-find ------------------ 4 profiles matched ------------------ Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE Profile ID: IECUserRoles ... Profile ID: smime Profile description: S/MIME certificates Store issued certificates: TRUE -------------------------- Number of entries returned --------------------------
인증서 프로필 설명을 수정합니다. 예를 들어 기존 프로필을 사용하여 S/MIME 인증서에 대한 사용자 정의 인증서 프로필을 생성한 경우 새 사용과 함께 설명을 변경합니다.
# ipa certprofile-mod smime --desc "New certificate profile description" ------------------------------------ Modified Certificate Profile "smime" ------------------------------------ Profile ID: smime Profile description: New certificate profile description Store issued certificates: TRUE
텍스트 편집기에서 고객 인증서 프로필 파일을 열고 요구 사항에 맞게 수정합니다.
# vi smime.cfg
인증서 프로필 구성 파일에서 구성할 수 있는 옵션에 대한 자세한 내용은 인증서 프로필 구성 매개 변수를 참조하십시오.
기존 인증서 프로필 구성 파일을 업데이트합니다.
# ipa certprofile-mod _profile_ID_ --file=smime.cfg
검증
인증서 프로필이 업데이트되었는지 확인합니다.
$ ipa certprofile-show smime Profile ID: smime Profile description: New certificate profile description Store issued certificates: TRUE
추가 리소스
-
시스템의
ipa(a)
도움말 페이지를 참조하십시오. -
ipa help certprofile-mod
를 참조하십시오.
6.7. 인증서 프로필 구성 매개변수
인증서 프로필 구성 매개변수는 CA 프로파일 디렉터리인 /var/lib/pki/pki-tomcat/ca/profiles/ca
.cfg 파일에 저장됩니다. 프로필의 모든 매개 변수(기본값, 입력, 출력 및 제약 조건)는 단일 정책 세트 내에서 구성됩니다. 인증서 프로필에 설정된 정책에는 name policyset.policyName.policyNumber 가 있습니다.
예를 들어 policy set serverCertSet
:의 경우
policyset.list=serverCertSet policyset.serverCertSet.list=1,2,3,4,5,6,7,8 policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.serverCertSet.1.constraint.name=Subject Name Constraint policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+ policyset.serverCertSet.1.constraint.params.accept=true policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl policyset.serverCertSet.1.default.name=Subject Name Default policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=pki-ipa, O=IPA policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl policyset.serverCertSet.2.constraint.name=Validity Constraint policyset.serverCertSet.2.constraint.params.range=740 policyset.serverCertSet.2.constraint.params.notBeforeCheck=false policyset.serverCertSet.2.constraint.params.notAfterCheck=false policyset.serverCertSet.2.default.class_id=validityDefaultImpl policyset.serverCertSet.2.default.name=Validity Default policyset.serverCertSet.2.default.params.range=731 policyset.serverCertSet.2.default.params.startTime=0
각 정책 세트에는 평가해야 하는 순서대로 정책 ID 번호별로 인증서 프로필에 대해 구성된 정책 목록이 포함되어 있습니다. 서버는 수신하는 각 요청에 대해 설정된 각 정책 세트를 평가합니다. 단일 인증서 요청이 수신되면 하나의 세트가 평가되고 프로필의 다른 집합이 무시됩니다. 이중 키 쌍을 발급하면 첫 번째 정책 세트가 첫 번째 인증서 요청에 대해 평가되고 두 번째 세트는 두 번째 인증서 요청에 대해 평가됩니다. 듀얼 키 쌍을 발행할 때 단일 인증서 또는 두 개 이상의 세트를 발행할 때 두 개 이상의 정책 세트가 필요하지 않습니다.
매개변수 | 설명 |
---|---|
desc |
최종 항목 페이지에 표시되는 인증서 프로필에 대한 무료 텍스트 설명입니다. 예를 들어 |
enable |
최종 엔터티 페이지를 통해 액세스할 수 있도록 프로필을 활성화합니다. 예를 들면 |
auth.instance_id |
인증서 요청을 인증하는 데 사용할 인증 관리자 플러그인을 설정합니다. 자동 등록의 경우 인증이 성공하면 CA에서 즉시 인증서를 발행합니다. 인증에 실패하거나 인증 플러그인이 지정되지 않은 경우 에이전트에서 수동으로 승인하도록 요청이 대기됩니다. 예: |
authz.acl |
권한 부여 제약 조건을 지정합니다. 이는 그룹 계산 ACL(액세스 제어 목록)을 설정하는 데 주로 사용됩니다. 예를 들어
디렉터리 기반 사용자 인증서 갱신에서는 이 옵션을 사용하여 원래 요청자 및 현재authenticated 사용자가 동일한지 확인합니다. 권한 부여를 평가하기 전에 엔터티를 인증(바인 또는 기본적으로 시스템에 로그인)해야 합니다. |
name |
인증서 프로필의 이름입니다. 예를 들어 |
input.list |
인증서 프로필에 허용된 입력을 이름으로 나열합니다. 예: |
input.input_id.class_id |
입력 ID( input.list에 나열된 입력 이름)별 입력의 java 클래스 이름을 나타냅니다. 예를 들어 |
output.list |
인증서 프로필의 가능한 출력 형식을 이름으로 나열합니다. 예: |
output.output_id.class_id |
output.list로 이름이 지정된 출력 형식의 Java 클래스 이름을 지정합니다. 예를 들어 |
policyset.list |
구성된 인증서 프로필 규칙을 나열합니다. 이중 인증서의 경우 하나의 규칙 세트는 서명 키와 다른 규칙 세트에 적용됩니다. 단일 인증서는 하나의 인증서 프로필 규칙 세트만 사용합니다. 예를 들면 |
policyset.policyset_id.list |
평가해야 하는 순서대로 정책 ID 번호로 인증서 프로필에 구성된 정책 내의 정책을 나열합니다. 예를 들어 |
policyset.policyset_id.policy_number.constraint.class_id | 프로필 규칙에 구성된 기본값에 대해 설정된 제약 조건 플러그인의 Java 클래스 이름을 나타냅니다. 예를 들어 policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl입니다. |
policyset.policyset_id.policy_number.constraint.name | 제약 조건의 사용자 정의 이름을 제공합니다. 예를 들어 policyset.serverCertSet.1.constraint.name=Subject Name Constraint입니다. |
policyset.policyset_id.policy_number.constraint.params.attribute | 제약 조건에 허용되는 특성의 값을 지정합니다. 가능한 속성은 제약 조건 유형에 따라 다릅니다. 예를 들어 policyset.serverCertSet.1.constraint.params.pattern=CN=.*입니다. |
policyset.policyset_id.policy_number.default.class_id | 프로필 규칙에 설정된 기본 클래스의 Java 클래스 이름을 지정합니다. 예: policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultImpl |
policyset.policyset_id.policy_number.default.name | 기본값의 사용자 정의 이름을 지정합니다. 예: policyset.serverCertSet.1.default.name=Subject Name Default |
policyset.policyset_id.policy_number.default.params.attribute | 기본값에 허용되는 특성의 값을 지정합니다. 사용 가능한 속성은 기본값 유형에 따라 다릅니다. 예를 들어 policyset.serverCertSet.1.default.params.name=CN=(Name)$request.requestor_name$입니다. |
7장. IdM의 인증서 유효성 관리
IdM(Identity Management)에서는 향후 발급하려는 기존 인증서와 인증서의 유효성을 모두 관리할 수 있지만 방법은 다릅니다.
7.1. IdM CA에서 발급한 기존 인증서의 유효성 관리
IdM에서 인증서의 만료 날짜를 확인하는 다음 방법을 사용할 수 있습니다.
다음과 같은 방법으로 IdM CA에서 발급한 기존 인증서의 유효성을 관리할 수 있습니다.
원래 CSR(인증서 서명 요청) 또는 개인 키에서 생성된 새 CSR을 사용하여 새 인증서를 요청하여 인증서를 갱신합니다. 다음 유틸리티를 사용하여 새 인증서를 요청할 수 있습니다.
- certmonger
-
certmonger
를 사용하여 서비스 인증서를 요청할 수 있습니다. 인증서가 만료되기 전에certmonger
는 인증서를 자동으로 갱신하여 서비스 인증서의 지속적인 유효성을 보장합니다. 자세한 내용은 certmonger를 사용하여 서비스에 대한 IdM 인증서 가져오기를 참조하십시오. - certutil
-
certutil
을 사용하여 사용자, 호스트 및 서비스 인증서를 갱신할 수 있습니다. 사용자 인증서 요청에 대한 자세한 내용은 새 사용자 인증서 요청 및 클라이언트로 내보내기를 참조하십시오. - OpenSSL
-
openssl
을 사용하여 사용자, 호스트 및 서비스 인증서를 갱신할 수 있습니다.
인증서를 취소하십시오. 자세한 내용은 다음을 참조하십시오.
인증서가 일시적으로 취소된 경우 인증서를 복원합니다. 자세한 내용은 다음을 참조하십시오.
7.2. IdM CA에서 발행한 향후 인증서의 유효성 관리
IdM CA에서 발행한 향후 인증서의 유효성을 관리하려면 인증서 프로필을 수정, 가져오기 또는 생성합니다. 자세한 내용은 ID 관리에서 인증서 프로필 생성 및 관리를 참조하십시오.
7.3. IdM WebUI에서 인증서 만료 날짜 보기
IdM WebUI를 사용하여 IdM CA에서 발행한 모든 인증서의 만료 날짜를 확인할 수 있습니다.
사전 요구 사항
- 관리자의 자격 증명을 확보했는지 확인합니다.
절차
-
인증
메뉴에서 인증서 >인증서
인증서의 일련 번호를 클릭하여 인증서 정보 페이지를 엽니다.
그림 7.1. 인증서 목록
-
인증서 정보 페이지에서
Expires On
정보를 찾습니다.
7.4. CLI에서 인증서 만료일 보기
CLI(명령줄 인터페이스)를 사용하여 인증서의 만료 날짜를 확인할 수 있습니다.
절차
openssl
유틸리티를 사용하여 사람이 읽을 수 있는 형식으로 파일을 엽니다.$ openssl x509 -noout -text -in ca.pem Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: O = IDM.EXAMPLE.COM, CN = Certificate Authority Validity Not Before: Oct 30 19:39:14 2017 GMT Not After : Oct 30 19:39:14 2037 GMT
7.5. 통합 IdM CA로 인증서 해지
7.5.1. 인증서 해지 이유
취소된 인증서가 유효하지만 인증에 사용할 수 없습니다. 이유 6: Certificate Hold
를 제외한 모든 취소는 영구적입니다.
기본 해지 이유는 0: 지정되지
않음입니다.
ID | 이유 | 설명 |
---|---|---|
0 | 지정되지 않음 | |
1 | key Compromised | 인증서를 발급한 키는 더 이상 신뢰되지 않습니다. 가능한 원인: 토큰 손실, 부적절하게 액세스한 파일. |
2 | CA Compromised | 인증서를 발급한 CA는 더 이상 신뢰되지 않습니다. |
3 | ffiliation changed | 가능한 원인은 다음과 같습니다. * 한 사람이 퇴사하거나 다른 부서로 이동했습니다. * 호스트 또는 서비스가 중단됩니다. |
4 | 대체됨 | 최신 인증서가 현재 인증서를 교체했습니다. |
5 | 운영 중단 | 호스트 또는 서비스가 해제되어 있습니다. |
6 | Certificate Hold | 인증서가 일시적으로 취소됩니다. 나중에 인증서를 복원할 수 있습니다. |
8 | CRL에서 제거 | 인증서가 CRL(인증서 해지 목록)에 포함되어 있지 않습니다. |
9 | 권한 삭제 | 사용자, 호스트 또는 서비스는 더 이상 인증서를 사용할 수 없습니다. |
10 | 특성 기관 (AA) Compromise | AA 인증서는 더 이상 신뢰되지 않습니다. |
7.5.2. IdM WebUI를 사용하여 통합 IdM CA에서 인증서 취소
인증서의 개인 키를 분실한 것을 알고 있는 경우, 악용을 방지하기 위해 인증서를 취소해야 합니다. IdM WebUI를 사용하여 IdM CA에서 발행한 인증서를 취소하려면 이 절차를 완료합니다.
절차
-
인증
>인증서
>인증서
를 클릭합니다. 인증서의 일련 번호를 클릭하여 인증서 정보 페이지를 엽니다.
그림 7.2. 인증서 목록
- 인증서 정보 페이지에서 → .를 클릭합니다.
- 취소 이유를 선택하고 인증서 해지 이유를 참조하십시오. 를 클릭합니다. 자세한 내용은
7.5.3. IdM CLI를 사용하여 통합 IdM CA에서 인증서 취소
인증서의 개인 키를 분실한 것을 알고 있는 경우, 악용을 방지하기 위해 인증서를 취소해야 합니다. IdM CLI를 사용하여 IdM CA에서 발행한 인증서를 취소하려면 이 절차를 완료합니다.
절차
ipa cert-revoke
명령을 사용하고 다음을 지정합니다.- 인증서 일련 번호
- 해지 이유의 ID 번호를 참조하십시오. 자세한 내용은 인증서 해지 이유를 참조하십시오.
예를 들어, 일련 번호 1032
로 인증서를 취소하려면 1: Key Compromised
을 입력하십시오.
$ ipa cert-revoke 1032 --revocation-reason=1
새 인증서를 요청하는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오.
7.6. 통합 IdM CA의 인증서 복원
6: Certificate Hold
로 인해 인증서를 취소한 경우 인증서의 개인 키가 손상되지 않은 경우 다시 복원할 수 있습니다. 인증서를 복원하려면 다음 절차 중 하나를 사용합니다.
7.6.1. IdM WebUI를 사용하여 통합 IdM CA의 인증서 복원
IdM WebUI를 사용하여 이유 6: Certificate Hold
로 인해 취소된 IdM 인증서를 복원하려면 이 절차를 완료합니다.
절차
-
인증
메뉴에서 인증서 >인증서
인증서의 일련 번호를 클릭하여 인증서 정보 페이지를 엽니다.
그림 7.3. 인증서 목록
- 인증서 정보 페이지에서 → 을 클릭합니다.
7.6.2. IdM CLI를 사용하여 통합 IdM CA의 인증서 복원
이유 6: Certificate Hold
로 인해 취소된 IdM 인증서를 복원하려면 IdM CLI를 사용하려면 이 절차를 완료합니다.
절차
ipa cert-remove-hold
명령을 사용하여 인증서 일련 번호를 지정합니다. 예를 들어 다음과 같습니다.$ ipa cert-remove-hold 1032
8장. 스마트 카드 인증을 위한 ID 관리 구성
IdM(Identity Management)은 다음을 사용하여 스마트 카드 인증을 지원합니다.
- IdM 인증 기관에서 발급한 사용자 인증서
- 외부 인증 기관에서 발급한 사용자 인증서
두 가지 유형의 인증서에 대해 IdM에서 스마트 카드 인증을 구성할 수 있습니다. 이 시나리오에서 rootca.pem
CA 인증서는 신뢰할 수 있는 외부 인증 기관의 인증서를 포함하는 파일입니다.
IdM의 스마트 카드 인증에 대한 자세한 내용은 스마트 카드 인증 이해 를 참조하십시오.
스마트 카드 인증 구성에 대한 자세한 내용은 다음을 수행합니다.
8.1. 스마트 카드 인증을 위한 IdM 서버 구성
IdM(Identity Management) CA에서 신뢰하는 <EXAMPLE.ORG> 도메인에서 인증서를 발급한 사용자의 스마트 카드 인증을 활성화하려면 IdM 서버를 구성하는 ipa-advise
스크립트를 실행할 때 다음 인증서를 가져와야 합니다.
- <EXAMPLE.ORG> CA 인증서를 직접 발급했거나 하위 CA 중 하나 이상을 통해 발급한 루트 CA의 인증서입니다. 기관에서 인증서를 발급한 웹 페이지에서 인증서 체인을 다운로드할 수 있습니다. 자세한 내용은 인증서 인증을 사용하도록 브라우저 구성에서 1-4a 단계를 참조하십시오.
-
IdM CA 인증서입니다. IdM CA 인스턴스가 실행 중인 IdM 서버의
/etc/ipa/ca.crt
파일에서 CA 인증서를 가져올 수 있습니다. - 모든 중간 CA의 인증서입니다. 즉 <EXAMPLE.ORG> CA와 IdM CA 사이입니다.
스마트 카드 인증을 위해 IdM 서버를 구성하려면 다음을 수행합니다.
- PEM 형식으로 CA 인증서를 사용하여 파일을 가져옵니다.
-
내장된
ipa-advise
스크립트를 실행합니다. - 시스템 구성을 다시 로드합니다.
사전 요구 사항
- IdM 서버에 대한 루트 액세스 권한이 있습니다.
- 루트 CA 인증서와 모든 중간 CA 인증서가 있습니다.
절차
구성을 수행할 디렉터리를 만듭니다.
[root@server]# mkdir ~/SmartCard/
디렉터리로 이동합니다.
[root@server]# cd ~/SmartCard/
PEM 형식으로 파일에 저장된 관련 CA 인증서를 가져옵니다. CA 인증서가 DER와 같은 다른 형식의 파일에 저장된 경우 PEM 형식으로 변환합니다. IdM 인증 기관 인증서는 PEM 형식이며
/etc/ipa/ca.crt
파일에 있습니다.DER 파일을 PEM 파일로 변환합니다.
# openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM
쉽게 구성을 수행할 디렉터리에 인증서를 복사합니다.
[root@server SmartCard]# cp /tmp/rootca.pem ~/SmartCard/ [root@server SmartCard]# cp /tmp/subca.pem ~/SmartCard/ [root@server SmartCard]# cp /tmp/issuingca.pem ~/SmartCard/
선택 사항: 외부 인증 기관의 인증서를 사용하는 경우
openssl x509
유틸리티를 사용하여PEM
형식의 파일 내용을 보고발급
자 및주체
값이 올바른지 확인합니다.[root@server SmartCard]# openssl x509 -noout -text -in rootca.pem | more
관리자의 권한을 사용하여 기본 제공된
ipa-advise
유틸리티로 구성 스크립트를 생성합니다.[root@server SmartCard]# kinit admin [root@server SmartCard]# ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh
config-server-for-smart-card-auth.sh
스크립트는 다음 작업을 수행합니다.- IdM Apache HTTP 서버를 구성합니다.
- KDC(Key Distribution Center)에서 Kerberos(PKINIT)의 초기 인증용 공개 키 암호화가 가능합니다.
- 스마트 카드 인증 요청을 수락하도록 IdM 웹 UI를 구성합니다.
스크립트를 실행하고 루트 CA 및 하위 CA 인증서가 포함된 PEM 파일을 인수로 추가합니다.
[root@server SmartCard]# chmod +x config-server-for-smart-card-auth.sh [root@server SmartCard]# ./config-server-for-smart-card-auth.sh rootca.pem subca.pem issuingca.pem Ticket cache:KEYRING:persistent:0:0 Default principal: admin@IDM.EXAMPLE.COM [...] Systemwide CA database updated. The ipa-certupdate command was successful
참고하위 CA 인증서 및 CA 또는 하위 CA 인증서가 만료되지 않았는지 루트 CA 인증서를 인수로 추가해야 합니다.
선택 사항: 사용자 인증서를 발급한 인증 기관이 OCSP 응답자를 제공하지 않는 경우 IdM 웹 UI에 대한 인증을 위해 OCSP 검사를 비활성화해야 할 수 있습니다.
/etc/httpd/conf.d/ssl.conf
파일에서SSLOCSPEnable
매개변수를off
로 설정합니다.SSLOCSPEnable off
변경 사항이 즉시 적용되도록 Apache 데몬(httpd)을 다시 시작합니다.
[root@server SmartCard]# systemctl restart httpd
주의IdM CA에서 발급한 사용자 인증서만 사용하는 경우 OCSP 검사를 비활성화하지 마십시오. OCSP 응답자는 IdM의 일부입니다.
OCSP 검사를 계속 활성화하는 방법에 대한 자세한 내용은 사용자 인증서가 OCSP 서비스 요청을 수신하는 CA에 대한 정보가 포함되어 있지 않은 경우, Apache mod_ssl 구성 옵션 의
SSLOCSPDefaultResponder
지시문을 참조하십시오.
이제 서버가 스마트 카드 인증을 위해 구성됩니다.
전체 토폴로지에서 스마트 카드 인증을 활성화하려면 각 IdM 서버에서 절차를 실행합니다.
8.2. Ansible을 사용하여 스마트 카드 인증을 위해 IdM 서버 구성
Ansible을 사용하면 IdM(Identity Management) CA에서 신뢰하는 <EXAMPLE.ORG> 도메인의 인증서가 발급한 사용자의 스마트 카드 인증을 활성화할 수 있습니다. 이렇게 하려면 ipasmartcard_server
ansible-freeipa
역할 스크립트로 Ansible 플레이북을 실행할 때 사용할 수 있도록 다음 인증서를 가져와야 합니다.
- <EXAMPLE.ORG> CA 인증서를 직접 발급했거나 하위 CA 중 하나 이상을 통해 발급한 루트 CA의 인증서입니다. 기관에서 인증서를 발급한 웹 페이지에서 인증서 체인을 다운로드할 수 있습니다. 자세한 내용은 Configuring a browser to enable certificate authentication 을 참조하십시오.
-
IdM CA 인증서입니다. IdM CA 서버의
/etc/ipa/ca.crt
파일에서 CA 인증서를 가져올 수 있습니다. - <EXAMPLE.ORG> CA와 IdM CA 사이에 있는 모든 CA의 인증서입니다.
사전 요구 사항
-
IdM 서버에 대한
루트
액세스 권한이 있습니다. -
IdM
관리자
암호를 알고 있습니다. - 루트 CA 인증서, IdM CA 인증서 및 모든 중간 CA 인증서가 있습니다.
다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.
- Ansible 버전 2.14 이상을 사용하고 있습니다.
-
Ansible 컨트롤러에
ansible-freeipa
패키지가 설치되어 있습니다. - 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 정규화된 도메인 이름(FQDN)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
-
이 예제에서는 secret.yml Ansible 자격 증명 모음이
ipaadmin_password
를 저장하는 것으로 가정합니다.
-
ansible-freeipa
모듈이 실행되는 노드인 대상 노드는 IdM 도메인의 일부인 IdM 클라이언트, 서버 또는 복제본입니다.
절차
CA 인증서가
DER
와 같은 다른 형식의 파일에 저장된 경우PEM
형식으로 변환합니다.# openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM
IdM 인증 기관 인증서는
PEM
형식이며/etc/ipa/ca.crt
파일에 있습니다.선택 사항:
openssl x509
유틸리티를 사용하여PEM
형식의 파일 내용을 보고발급
자 및주체
값이 올바른지 확인합니다.# openssl x509 -noout -text -in root-ca.pem | more
~/MyPlaybook/ 디렉토리로 이동합니다.
$ cd ~/MyPlaybooks/
CA 인증서 전용 하위 디렉터리를 생성합니다.
$ mkdir SmartCard/
편의를 위해 필요한 모든 인증서를 ~/MyPlaybook/SmartCard/ 디렉터리에 복사합니다.
# cp /tmp/root-ca.pem ~/MyPlaybooks/SmartCard/ # cp /tmp/intermediate-ca.pem ~/MyPlaybooks/SmartCard/ # cp /etc/ipa/ca.crt ~/MyPlaybooks/SmartCard/ipa-ca.crt
Ansible 인벤토리 파일에서 다음을 지정합니다.
- 스마트 카드 인증을 위해 구성할 IdM 서버입니다.
- IdM 관리자 암호입니다.
다음 순서로 CA 인증서의 경로입니다.
- 루트 CA 인증서 파일
- 중간 CA 인증서 파일
- IdM CA 인증서 파일
파일은 다음과 같습니다.
[ipaserver] ipaserver.idm.example.com [ipareplicas] ipareplica1.idm.example.com ipareplica2.idm.example.com [ipacluster:children] ipaserver ipareplicas [ipacluster:vars] ipaadmin_password= "{{ ipaadmin_password }}" ipasmartcard_server_ca_certs=/home/<user_name>/MyPlaybooks/SmartCard/root-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/intermediate-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/ipa-ca.crt
다음 콘텐츠를 사용하여
install-smartcard-server.yml
플레이북을 생성합니다.--- - name: Playbook to set up smart card authentication for an IdM server hosts: ipaserver become: true roles: - role: ipasmartcard_server state: present
- 파일을 저장합니다.
Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.
$ ansible-playbook --vault-password-file=password_file -v -i inventory install-smartcard-server.yml
ipasmartcard_server
Ansible 역할은 다음 작업을 수행합니다.- IdM Apache HTTP 서버를 구성합니다.
- KDC(Key Distribution Center)에서 Kerberos(PKINIT)의 초기 인증용 공개 키 암호화가 가능합니다.
- 스마트 카드 인증 요청을 수락하도록 IdM 웹 UI를 구성합니다.
선택 사항: 사용자 인증서를 발급한 인증 기관이 OCSP 응답자를 제공하지 않는 경우 IdM 웹 UI에 대한 인증을 위해 OCSP 검사를 비활성화해야 할 수 있습니다.
root
로 IdM 서버에 연결합니다.ssh root@ipaserver.idm.example.com
/etc/httpd/conf.d/ssl.conf
파일에서SSLOCSPEnable
매개변수를off
로 설정합니다.SSLOCSPEnable off
변경 사항이 즉시 적용되도록 Apache 데몬(httpd)을 다시 시작합니다.
# systemctl restart httpd
주의IdM CA에서 발급한 사용자 인증서만 사용하는 경우 OCSP 검사를 비활성화하지 마십시오. OCSP 응답자는 IdM의 일부입니다.
OCSP 검사를 계속 활성화하는 방법에 대한 자세한 내용은 사용자 인증서가 OCSP 서비스 요청을 수신하는 CA에 대한 정보가 포함되어 있지 않은 경우, Apache mod_ssl 구성 옵션 의
SSLOCSPDefaultResponder
지시문을 참조하십시오.
인벤토리 파일에 나열된 서버가 스마트 카드 인증을 위해 구성되어 있습니다.
전체 토폴로지에서 스마트 카드 인증을 활성화하려면 Ansible 플레이북의 hosts
변수를 ipacluster
로 설정합니다.
---
- name: Playbook to setup smartcard for IPA server and replicas
hosts: ipacluster
[...]
추가 리소스
-
/usr/share/doc/ansible-freeipa/playbooks/
디렉터리에서ipasmartcard_server
역할을 사용하는 샘플 플레이북
8.3. 스마트 카드 인증을 위한 IdM 클라이언트 구성
스마트 카드 인증을 위해 IdM 클라이언트를 구성하려면 다음 절차를 따르십시오. 인증에 스마트 카드를 사용하는 동안 연결하려는 각 IdM 시스템, 클라이언트 또는 서버에서 절차를 실행해야 합니다. 예를 들어 호스트 A에서 호스트 B로 ssh
연결을 활성화하려면 호스트 B에서 스크립트를 실행해야 합니다.
관리자로 다음 절차를 실행하여 스마트 카드 인증을 활성화합니다.
ssh
프로토콜자세한 내용은 스마트 카드 인증을 사용하여 SSH 액세스 구성 을 참조하십시오.
- 콘솔 로그인
- GNOME 디스플레이 관리자(GDM)
-
su
명령
IdM 웹 UI 인증 절차는 필요하지 않습니다. IdM 웹 UI에 인증하려면 두 개의 호스트가 포함되며, 둘 다 IdM 클라이언트일 필요가 없습니다.
- 브라우저가 실행 중인 시스템입니다. 시스템이 IdM 도메인 외부에 있을 수 있습니다.
-
httpd
가 실행 중인 IdM 서버입니다.
다음 절차에서는 IdM 서버가 아닌 IdM 클라이언트에서 스마트 카드 인증을 구성한다고 가정합니다. 따라서 구성 스크립트를 생성하는 IdM 서버와 스크립트를 실행할 IdM 클라이언트의 두 개의 컴퓨터가 필요합니다.
사전 요구 사항
- 스마트 카드 인증을 위한 IdM 서버 구성에 설명된 대로 스마트 카드 인증을 위해 IdM 서버가 구성되어 있습니다.
- IdM 서버 및 IdM 클라이언트에 대한 루트 액세스 권한이 있습니다.
- 루트 CA 인증서와 모든 중간 CA 인증서가 있습니다.
-
원격 사용자가 성공적으로 로그인할 수 있도록
--mkhomedir
옵션과 함께 IdM 클라이언트를 설치했습니다. 홈 디렉터리를 생성하지 않으면 기본 로그인 위치는 디렉터리 구조의 루트입니다./
.
절차
IdM 서버에서 관리자 권한을 사용하여
ipa-advise
로 구성 스크립트를 생성합니다.[root@server SmartCard]# kinit admin [root@server SmartCard]# ipa-advise config-client-for-smart-card-auth > config-client-for-smart-card-auth.sh
config-client-for-smart-card-auth.sh
스크립트는 다음 작업을 수행합니다.- 스마트 카드 데몬을 구성합니다.
- 시스템 전체 신뢰 저장소를 설정합니다.
- 사용자가 사용자 이름 및 암호 또는 스마트 카드로 인증할 수 있도록 SSSD(System Security Services Daemon)를 구성합니다. 스마트 카드 인증에 대한 SSSD 프로필 옵션에 대한 자세한 내용은 RHEL의 스마트 카드 인증 옵션을 참조하십시오.
IdM 서버에서 IdM 클라이언트 시스템에서 선택한 디렉터리에 스크립트를 복사합니다.
[root@server SmartCard]# scp config-client-for-smart-card-auth.sh root@client.idm.example.com:/root/SmartCard/ Password: config-client-for-smart-card-auth.sh 100% 2419 3.5MB/s 00:00
IdM 서버에서 이전 단계에서 사용된 것과 동일한 디렉터리에 편의를 위해 PEM 형식으로 CA 인증서 파일을 복사합니다.
[root@server SmartCard]# scp {rootca.pem,subca.pem,issuingca.pem} root@client.idm.example.com:/root/SmartCard/ Password: rootca.pem 100% 1237 9.6KB/s 00:00 subca.pem 100% 2514 19.6KB/s 00:00 issuingca.pem 100% 2514 19.6KB/s 00:00
클라이언트 시스템에서 스크립트를 실행하고 CA 인증서가 포함된 PEM 파일을 인수로 추가합니다.
[root@client SmartCard]# kinit admin [root@client SmartCard]# chmod +x config-client-for-smart-card-auth.sh [root@client SmartCard]# ./config-client-for-smart-card-auth.sh rootca.pem subca.pem issuingca.pem Ticket cache:KEYRING:persistent:0:0 Default principal: admin@IDM.EXAMPLE.COM [...] Systemwide CA database updated. The ipa-certupdate command was successful
참고하위 CA 인증서 및 CA 또는 하위 CA 인증서가 만료되지 않았는지 루트 CA 인증서를 인수로 추가해야 합니다.
이제 클라이언트가 스마트 카드 인증을 위해 구성됩니다.
8.4. Ansible을 사용하여 스마트 카드 인증을 위해 IdM 클라이언트 구성
IdM 사용자가 스마트 카드로 인증할 수 있도록 ansible-freeipa
ipasmartcard_client
모듈을 사용하여 특정 IdM(Identity Management) 클라이언트를 구성하려면 다음 절차를 따르십시오. 다음 절차를 실행하여 IdM에 액세스하는 데 다음을 사용하는 IdM 사용자의 스마트 카드 인증을 활성화합니다.
ssh
프로토콜자세한 내용은 스마트 카드 인증을 사용하여 SSH 액세스 구성 을 참조하십시오.
- 콘솔 로그인
- GNOME 디스플레이 관리자(GDM)
-
su
명령
IdM 웹 UI 인증 절차는 필요하지 않습니다. IdM 웹 UI에 인증하려면 두 개의 호스트가 포함되며, 둘 다 IdM 클라이언트일 필요가 없습니다.
- 브라우저가 실행 중인 시스템입니다. 시스템이 IdM 도메인 외부에 있을 수 있습니다.
-
httpd
가 실행 중인 IdM 서버입니다.
사전 요구 사항
- Ansible을 사용하여 스마트 카드 인증을 위해 IdM 서버를 구성하는 데 설명된 대로 IdM 서버는 스마트 카드 인증을 위해 구성되어 있습니다.
- IdM 서버 및 IdM 클라이언트에 대한 루트 액세스 권한이 있습니다.
- 루트 CA 인증서, IdM CA 인증서 및 모든 중간 CA 인증서가 있습니다.
다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.
- Ansible 버전 2.14 이상을 사용하고 있습니다.
-
Ansible 컨트롤러에
ansible-freeipa
패키지가 설치되어 있습니다. - 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 정규화된 도메인 이름(FQDN)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
-
이 예제에서는 secret.yml Ansible 자격 증명 모음이
ipaadmin_password
를 저장하는 것으로 가정합니다.
-
ansible-freeipa
모듈이 실행되는 노드인 대상 노드는 IdM 도메인의 일부인 IdM 클라이언트, 서버 또는 복제본입니다.
절차
CA 인증서가
DER
와 같은 다른 형식의 파일에 저장된 경우PEM
형식으로 변환합니다.# openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM
IdM CA 인증서는
PEM
형식이며/etc/ipa/ca.crt
파일에 있습니다.선택 사항:
openssl x509
유틸리티를 사용하여PEM
형식의 파일 내용을 보고발급
자 및주체
값이 올바른지 확인합니다.# openssl x509 -noout -text -in root-ca.pem | more
Ansible 제어 노드에서 ~/MyPlaybook/ 디렉터리로 이동합니다.
$ cd ~/MyPlaybooks/
CA 인증서 전용 하위 디렉터리를 생성합니다.
$ mkdir SmartCard/
편의를 위해 필요한 모든 인증서를 ~/MyPlaybook/SmartCard/ 디렉터리에 복사합니다. 예를 들면 다음과 같습니다.
# cp /tmp/root-ca.pem ~/MyPlaybooks/SmartCard/ # cp /tmp/intermediate-ca.pem ~/MyPlaybooks/SmartCard/ # cp /etc/ipa/ca.crt ~/MyPlaybooks/SmartCard/ipa-ca.crt
Ansible 인벤토리 파일에서 다음을 지정합니다.
- 스마트 카드 인증을 위해 구성할 IdM 클라이언트입니다.
- IdM 관리자 암호입니다.
다음 순서로 CA 인증서의 경로입니다.
- 루트 CA 인증서 파일
- 중간 CA 인증서 파일
- IdM CA 인증서 파일
파일은 다음과 같습니다.
[ipaclients] ipaclient1.example.com ipaclient2.example.com [ipaclients:vars] ipaadmin_password=SomeADMINpassword ipasmartcard_client_ca_certs=/home/<user_name>/MyPlaybooks/SmartCard/root-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/intermediate-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/ipa-ca.crt
다음 콘텐츠를 사용하여
install-smartcard-clients.yml
플레이북을 생성합니다.--- - name: Playbook to set up smart card authentication for an IdM client hosts: ipaclients become: true roles: - role: ipasmartcard_client state: present
- 파일을 저장합니다.
Ansible 플레이북을 실행합니다. Playbook 및 인벤토리 파일을 지정합니다.
$ ansible-playbook --vault-password-file=password_file -v -i inventory install-smartcard-clients.yml
ipasmartcard_client
Ansible 역할은 다음 작업을 수행합니다.- 스마트 카드 데몬을 구성합니다.
- 시스템 전체 신뢰 저장소를 설정합니다.
- 사용자가 사용자 이름 및 암호 또는 스마트 카드로 인증할 수 있도록 SSSD(System Security Services Daemon)를 구성합니다. 스마트 카드 인증에 대한 SSSD 프로필 옵션에 대한 자세한 내용은 RHEL의 스마트 카드 인증 옵션을 참조하십시오.
인벤토리 파일의 ipaclients 섹션에 나열된 클라이언트가 스마트 카드 인증을 위해 구성됩니다.
--mkhomedir
옵션을 사용하여 IdM 클라이언트를 설치한 경우 원격 사용자가 홈 디렉터리에 로그인할 수 있습니다. 그렇지 않으면 기본 로그인 위치는 디렉터리 구조의 루트입니다. /
.
추가 리소스
-
/usr/share/doc/ansible-freeipa/playbooks/
디렉터리에서ipasmartcard_server
역할을 사용하는 샘플 플레이북
8.5. IdM 웹 UI에서 사용자 항목에 인증서 추가
IdM 웹 UI의 사용자 항목에 외부 인증서를 추가하려면 다음 절차를 따르십시오.
전체 인증서를 업로드하는 대신 IdM의 사용자 항목에 인증서 매핑 데이터를 업로드할 수도 있습니다. 전체 인증서 또는 인증서 매핑 데이터를 포함하는 사용자 항목은 해당 인증서 매핑 규칙과 함께 사용하여 시스템 관리자를 위한 스마트 카드 인증 구성을 원활하게 수행할 수 있습니다. 자세한 내용은 참조하십시오.
IdM 인증 기관에서 사용자 인증서를 발급한 경우 인증서가 이미 사용자 항목에 저장되어 있으며 이 절차를 따를 필요가 없습니다.
사전 요구 사항
- 사용자 항목에 추가할 인증서가 있습니다.You have the certificate that you want to add to the user entry.
절차
- 다른 사용자에게 인증서를 추가하려면 IdM 웹 UI에 관리자로 로그인합니다. 고유한 프로필에 인증서를 추가하는 경우 관리자의 인증 정보가 필요하지 않습니다.
-
사용자 → 활성
사용자
→sc_user
로 이동합니다. -
인증서
옵션을 찾고추가를
클릭합니다. 명령줄 인터페이스에서
cat
유틸리티 또는 텍스트 편집기를 사용하여PEM
형식으로 인증서를 표시합니다.[user@client SmartCard]$ cat testuser.crt
- CLI의 인증서를 복사하여 웹 UI에서 열린 창에 붙여넣습니다.
추가를
클릭합니다.그림 8.1. IdM 웹 UI에 새 인증서 추가
이제 sc_user
항목에 외부 인증서가 포함됩니다.
8.6. IdM CLI에서 사용자 항목에 인증서 추가
IdM CLI의 사용자 항목에 외부 인증서를 추가하려면 다음 절차를 따르십시오.
전체 인증서를 업로드하는 대신 IdM의 사용자 항목에 인증서 매핑 데이터를 업로드할 수도 있습니다. 전체 인증서 또는 인증서 매핑 데이터를 포함하는 사용자 항목은 해당 인증서 매핑 규칙과 함께 사용하여 시스템 관리자를 위한 스마트 카드 인증 구성을 원활하게 수행할 수 있습니다. 자세한 내용은 인증 구성을 위한 인증서 매핑 규칙을 참조하십시오.
IdM 인증 기관에서 사용자 인증서를 발급한 경우 인증서가 이미 사용자 항목에 저장되어 있으며 이 절차를 따를 필요가 없습니다.
사전 요구 사항
- 사용자 항목에 추가할 인증서가 있습니다.You have the certificate that you want to add to the user entry.
절차
다른 사용자에게 인증서를 추가하려면 IdM CLI에 관리자로 로그인합니다.
[user@client SmartCard]$ kinit admin
고유한 프로필에 인증서를 추가하는 경우 관리자의 인증 정보가 필요하지 않습니다.
[user@client SmartCard]$ kinit sc_user
ipa user-add-cert
명령에서 예상되는 형식인 헤더 및 푸너가 제거되고 연결된 인증서가 포함된 환경 변수를 생성합니다.[user@client SmartCard]$ export CERT=`openssl x509 -outform der -in testuser.crt | base64 -w0 -`
testuser.crt
파일의 인증서는PEM
형식이어야 합니다.ipa user-add-cert
명령을 사용하여 sc_user의 프로필에 인증서를 추가합니다.[user@client SmartCard]$ ipa user-add-cert sc_user --certificate=$CERT
이제 sc_user
항목에 외부 인증서가 포함됩니다.
8.7. 스마트 카드 관리 및 사용을 위한 도구 설치
사전 요구 사항
-
gnutls-utils
패키지가 설치되어 있습니다. -
opensc
패키지가 설치되어 있습니다. -
pcscd
서비스가 실행 중입니다.
스마트 카드를 구성하려면 인증서를 생성하고 pscd
서비스를 시작할 수 있는 해당 도구를 설치해야 합니다.
절차
opensc
및gnutls-utils
패키지를 설치합니다.# dnf -y install opensc gnutls-utils
pcscd
서비스를 시작합니다.# systemctl start pcscd
검증
pcscd
서비스가 실행 중인지 확인합니다.# systemctl status pcscd
8.8. 스마트 카드 준비 및 스마트 카드에 인증서와 키 업로드
다음 절차에 따라 구성하는 데 도움이 되는 pkcs15-init
도구를 사용하여 스마트 카드를 구성합니다.
- 스마트 카드 삭제
- 새로운 pins 및 선택적 pin Unblocking Keys (PUKs) 설정
- 스마트 카드에서 새 슬롯 생성
- 인증서, 개인 키 및 공개 키를 슬롯에 저장
- 필요한 경우 특정 스마트 카드에 따라 스마트 카드 설정을 잠금하려면 이러한 유형의 최종화가 필요합니다.
pkcs15-init
툴은 모든 스마트 카드에서 작동하지 않을 수 있습니다. 사용 중인 스마트 카드로 작업하는 도구를 사용해야 합니다.
사전 요구 사항
pkcs15-init
툴이 포함된opensc
패키지가 설치됩니다.자세한 내용은 스마트 카드 관리 및 사용을 위한 툴 설치를 참조하십시오.
- 카드가 리더에 삽입되고 컴퓨터에 연결되어 있습니다.
-
개인 키, 공개 키 및 스마트 카드에 저장할 인증서가 있습니다. 이 절차에서는
testuser.key
,testuserpublic.key
및testuser.crt
가 개인 키, 공개 키 및 인증서에 사용되는 이름입니다. - 현재 스마트 카드 사용자 Pin and Security Officer Pin (SO-PIN)이 있습니다.
절차
스마트 카드를 지우고 Pin을 사용하여 사용자를 인증합니다.
$ pkcs15-init --erase-card --use-default-transport-keys Using reader with a card: Reader name PIN [Security Officer PIN] required. Please enter PIN [Security Officer PIN]:
카드가 삭제 되었습니다.
스마트 카드를 초기화하고, 사용자 Pin 및 PUK를 설정하고, 보안 사무실자 Pin 및 PUK를 설정합니다.
$ pkcs15-init --create-pkcs15 --use-default-transport-keys \ --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123 Using reader with a card: Reader name
speeds
ks15-init
툴은 스마트 카드에 새 슬롯을 만듭니다.슬롯의 라벨 및 인증 ID를 설정합니다.
$ pkcs15-init --store-pin --label testuser \ --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478 Using reader with a card: Reader name
레이블은 사람이 읽을 수 있는 값(이 경우
testuser
)으로 설정됩니다.auth-id
는 두 개의 16진수 값이어야 합니다. 이 경우01
로 설정됩니다.스마트 카드의 새 슬롯에 개인 키를 저장하고 레이블을 지정합니다.
$ pkcs15-init --store-private-key testuser.key --label testuser_key \ --auth-id 01 --id 01 --pin 963214 Using reader with a card: Reader name
참고--id
에 지정하는 값은 개인 키를 저장하고 다음 단계에 인증서를 저장할 때 동일해야 합니다. 도구에서 더 복잡한 값을 계산하므로--id
에 대해 자체 값을 지정하는 것이 좋습니다.스마트 카드의 새 슬롯에 인증서를 저장하고 레이블을 지정합니다.
$ pkcs15-init --store-certificate testuser.crt --label testuser_crt \ --auth-id 01 --id 01 --format pem --pin 963214 Using reader with a card: Reader name
선택 사항: 스마트 카드의 새 슬롯에 공개 키를 저장하고 레이블을 지정합니다.
$ pkcs15-init --store-public-key testuserpublic.key --label testuserpublic_key --auth-id 01 --id 01 --pin 963214 Using reader with a card: Reader name
참고공개 키가 개인 키 또는 인증서에 해당하는 경우 개인 키 또는 인증서의 ID와 동일한 ID를 지정합니다.
선택 사항: 특정 스마트 카드를 사용하려면 설정을 잠그어 카드를 종료해야 합니다.
$ pkcs15-init -F
이 단계에서 스마트 카드에는 새로 생성된 슬롯에 인증서, 개인 키 및 공개 키가 포함됩니다. 또한 사용자 Pin 및 PUK 및 Security Officer Pin 및 PUK를 생성했습니다.
8.9. 스마트 카드를 사용하여 IdM 로그인
IdM 웹 UI에 로그인하는 데 스마트 카드를 사용하려면 다음 절차를 따르십시오.
사전 요구 사항
- 웹 브라우저는 스마트 카드 인증을 사용하도록 구성되어 있습니다.
- IdM 서버는 스마트 카드 인증을 위해 구성됩니다.
- 스마트 카드에 설치된 인증서는 IdM 서버에서 발행하거나 IdM의 사용자 항목에 추가되었습니다.
- 스마트 카드 잠금을 해제하는 데 필요한 pin을 알고 있습니다.
- 스마트 카드가 리더에 삽입되었습니다.
절차
- 브라우저에서 IdM 웹 UI를 엽니다.
인증서를 사용하여 로그인을 클릭합니다.
Password Required (암호 필요) 대화 상자가 열리면, 스마트 카드 잠금을 해제하는 pin을 추가하고 OK 버튼을 클릭합니다.
사용자 식별 요청 대화 상자가 열립니다.
스마트 카드에 두 개 이상의 인증서가 포함된 경우 드롭다운 목록에서 인증에 사용할 인증서를 선택합니다. 인증서 선택.
- OK 버튼을 클릭합니다.
이제 IdM 웹 UI에 성공적으로 로그인했습니다.
8.10. IdM 클라이언트에서 스마트 카드 인증을 사용하여 GDM에 로그인
GNOME 데스크탑 관리자(GDM)에는 인증이 필요합니다. 암호를 사용할 수 있지만 인증에 스마트 카드를 사용할 수도 있습니다.
smart 카드 인증을 사용하여 GDM에 액세스하려면 다음 절차를 따르십시오.
사전 요구 사항
- 이 시스템은 스마트 카드 인증을 위해 구성되었습니다. 자세한 내용은 스마트 카드 인증을 위한 IdM 클라이언트 구성을 참조하십시오.
- 스마트 카드에는 인증서와 개인 키가 포함되어 있습니다.
- 사용자 계정은 IdM 도메인의 멤버입니다.
스마트 카드의 인증서는 다음을 통해 사용자 항목에 매핑됩니다.
- 특정 사용자 항목에 인증서 할당. 자세한 내용은 IdM 웹 UI의 사용자 항목에 인증서 추가 또는 IdM CLI의 사용자 항목에 인증서 추가를 참조하십시오.
- 계정에 적용되는 인증서 매핑 데이터입니다. 자세한 내용은 스마트 카드에서 인증을 구성하기 위한 인증서 매핑 규칙을 참조하십시오.
절차
- 리더에 스마트 카드를 삽입합니다.
- 스마트 카드 Pin을 입력합니다.
- Sign In 을 클릭합니다.
RHEL 시스템에 성공적으로 로그인했으며 IdM 서버에서 제공하는 TGT가 있습니다.
검증
터미널 창에서
klist
를 입력하고 결과를 확인합니다.$ klist Ticket cache: KEYRING:persistent:1358900015:krb_cache_TObtNMd Default principal: example.user@REDHAT.COM Valid starting Expires Service principal 04/20/2020 13:58:24 04/20/2020 23:58:24 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 04/27/2020 08:58:15
8.11. su 명령으로 스마트 카드 인증 사용
다른 사용자로 변경하려면 인증이 필요합니다. 암호 또는 인증서를 사용할 수 있습니다. su
명령과 함께 스마트 카드를 사용하려면 다음 절차를 따르십시오. 즉, su
명령을 입력한 후 스마트 카드 Pin을 입력하라는 메시지가 표시됩니다.
사전 요구 사항
스마트 카드 인증을 위해 IdM 서버 및 클라이언트가 구성되어 있습니다.
- 스마트 카드 인증을 위한 IdM 서버 구성을참조하십시오.
- 스마트 카드 인증을 위한 IdM 클라이언트 구성을참조하십시오.
- 스마트 카드에는 인증서와 개인 키가 포함되어 있습니다. 스마트 카드의 인증서 저장을참조하십시오.
- 카드가 리더에 삽입되고 컴퓨터에 연결되어 있습니다.
절차
터미널 창에서
su
명령을 사용하여 다른 사용자로 변경합니다.$ su - example.user PIN for smart_card
구성이 올바르면 스마트 카드 Pin을 입력하라는 메시지가 표시됩니다.
9장. IdM의 스마트 카드 인증을 위해 ADCS에서 발급한 인증서 구성
AD(Active Directory) 인증서 서비스에서 인증서를 발급한 사용자에 대해 IdM에서 스마트 카드 인증을 구성하려면 다음을 수행합니다.
- 배포는 IdM(Identity Management)과 AD(Active Directory) 간의 가장 큰 신뢰를 기반으로 합니다.
- 계정이 AD에 저장되어 있는 사용자에게 스마트 카드 인증을 허용하려고 합니다.
- 인증서는 ADCS(Active Directory 인증서 서비스)에 생성 및 저장됩니다.
스마트 카드 인증 개요는 스마트 카드 인증 이해를 참조하십시오.
구성은 다음 단계로 수행됩니다.
사전 요구 사항
IdM(Identity Management) 및 AD(Active Directory) 신뢰가 설치됨
자세한 내용은 IdM과 AD 간 신뢰 설치를 참조하십시오.
- ADCS(Active Directory 인증서 서비스)가 설치되고 사용자를 위한 인증서가 생성됩니다.
9.1. 신뢰 구성 및 인증서 사용에 필요한 Windows Server 설정
Windows Server에서 다음을 구성해야 합니다.
- ADCS(Active Directory 인증서 서비스)가 설치됨
- 인증 기관 생성
- 선택 사항: 인증 기관 웹 등록을 사용하는 경우 인터넷 정보 서비스(IIS)를 구성해야 합니다.
인증서를 내보냅니다.
-
key에는
2048
비트 이상이 있어야 합니다. - 개인 키 포함
다음과 같은 형식의 인증서가 필요합니다: 개인 정보 교환 Exchange#150-
PKCS #12(.PFX)
- 인증서 개인 정보 보호 활성화
9.2. sftp를 사용하여 Active Directory에서 인증서 복사
스마트 카드 인증 기능을 사용하려면 다음 인증서 파일을 복사해야 합니다.
-
CER
형식의 루트 CA 인증서: IdM 서버의adcs-winserver-ca.cer
. -
etcd 형식의 개인 키가 있는 사용자 인증서: IdM 클라이언트의
aduser1.pfx
.
이 절차에서는 SSH 액세스가 허용됩니다. SSH를 사용할 수 없는 경우 사용자는 AD 서버에서 IdM 서버 및 클라이언트로 파일을 복사해야 합니다.
절차
IdM 서버에서 연결하고
adcs-winserver-ca.cer
루트 인증서를 IdM 서버에 복사합니다.root@idmserver ~]# sftp Administrator@winserver.ad.example.com Administrator@winserver.ad.example.com's password: Connected to Administrator@winserver.ad.example.com. sftp> cd <Path to certificates> sftp> ls adcs-winserver-ca.cer aduser1.pfx sftp> sftp> get adcs-winserver-ca.cer Fetching <Path to certificates>/adcs-winserver-ca.cer to adcs-winserver-ca.cer <Path to certificates>/adcs-winserver-ca.cer 100% 1254 15KB/s 00:00 sftp quit
IdM 클라이언트에서 연결하고
aduser1.pfx
사용자 인증서를 클라이언트에 복사합니다.[root@client1 ~]# sftp Administrator@winserver.ad.example.com Administrator@winserver.ad.example.com's password: Connected to Administrator@winserver.ad.example.com. sftp> cd /<Path to certificates> sftp> get aduser1.pfx Fetching <Path to certificates>/aduser1.pfx to aduser1.pfx <Path to certificates>/aduser1.pfx 100% 1254 15KB/s 00:00 sftp quit
이제 CA 인증서가 IdM 서버에 저장되고 사용자 인증서는 클라이언트 시스템에 저장됩니다.
9.3. ADCS 인증서를 사용하여 스마트 카드 인증을 위한 IdM 서버 및 클라이언트 구성
IdM 환경에서 스마트 카드 인증을 사용하려면 IdM(Identity Management) 서버 및 클라이언트를 구성해야 합니다. IdM에는 필요한 모든 변경을 수행하는 ipa-advise
스크립트가 포함되어 있습니다.
- 필요한 패키지 설치
- IdM 서버 및 클라이언트 구성
- CA 인증서를 예상 위치에 복사
IdM 서버에서 ipa-advise
를 실행할 수 있습니다.
스마트 카드 인증을 위해 서버 및 클라이언트를 구성하려면 다음 절차를 따르십시오.
-
IdM 서버: 스마트 카드 인증을 위해
ipa-advise
스크립트를 준비하여 IdM 서버를 구성합니다. -
IdM 서버: 스마트 카드 인증을 위해
ipa-advise
스크립트를 준비하여 IdM 클라이언트를 구성합니다. -
IdM 서버: AD 인증서를 사용하여 IdM 서버에서
ipa-advise
서버 스크립트 적용. - 클라이언트 스크립트를 IdM 클라이언트 시스템으로 이동합니다.
-
IdM 클라이언트: AD 인증서를 사용하여 IdM 클라이언트에서
ipa-advise
클라이언트 스크립트 적용.
사전 요구 사항
- 인증서가 IdM 서버에 복사되었습니다.
- Kerberos 티켓을 받습니다.
- 관리 권한이 있는 사용자로 로그인합니다.
절차
IdM 서버에서
ipa-advise
스크립트를 사용하여 클라이언트를 구성합니다.[root@idmserver ~]# ipa-advise config-client-for-smart-card-auth > sc_client.sh
IdM 서버에서
ipa-advise
스크립트를 사용하여 서버 구성을 수행합니다.[root@idmserver ~]# ipa-advise config-server-for-smart-card-auth > sc_server.sh
IdM 서버에서 스크립트를 실행합니다.
[root@idmserver ~]# sh -x sc_server.sh adcs-winserver-ca.cer
- IdM Apache HTTP 서버를 구성합니다.
- KDC(Key Distribution Center)에서 Kerberos(PKINIT)의 초기 인증용 공개 키 암호화가 가능합니다.
- 스마트 카드 인증 요청을 수락하도록 IdM 웹 UI를 구성합니다.
sc_client.sh
스크립트를 클라이언트 시스템에 복사합니다.[root@idmserver ~]# scp sc_client.sh root@client1.idm.example.com:/root Password: sc_client.sh 100% 2857 1.6MB/s 00:00
Windows 인증서를 클라이언트 시스템에 복사합니다.
[root@idmserver ~]# scp adcs-winserver-ca.cer root@client1.idm.example.com:/root Password: adcs-winserver-ca.cer 100% 1254 952.0KB/s 00:00
클라이언트 시스템에서 클라이언트 스크립트를 실행합니다.
[root@idmclient1 ~]# sh -x sc_client.sh adcs-winserver-ca.cer
CA 인증서는 IdM 서버 및 클라이언트 시스템의 올바른 형식으로 설치되며 다음 단계는 사용자 인증서를 스마트 카드 자체에 복사하는 것입니다.
9.4. Pcabundle 파일 변환
Pcabundle (PKCS#12) 파일을 스마트 카드에 저장하기 전에 다음을 수행해야합니다.
- 파일을 PEM 형식으로 변환합니다.
- 개인 키와 인증서를 두 개의 다른 파일로 추출합니다.
사전 요구 사항
- Ptekton 파일이 IdM 클라이언트 시스템에 복사됩니다.
절차
IdM 클라이언트에서 PEM 형식으로 되어 있습니다.
[root@idmclient1 ~]# openssl pkcs12 -in aduser1.pfx -out aduser1_cert_only.pem -clcerts -nodes Enter Import Password:
키를 별도의 파일에 추출합니다.
[root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -nocerts -out adduser1.pem > aduser1.key
공용 인증서를 별도의 파일에 추출합니다.
[root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -clcerts -nokeys -out aduser1_cert_only.pem > aduser1.crt
이 시점에서 aduser1.key
및 aduser1.crt
를 스마트 카드에 저장할 수 있습니다.
9.5. 스마트 카드 관리 및 사용을 위한 도구 설치
사전 요구 사항
-
gnutls-utils
패키지가 설치되어 있습니다. -
opensc
패키지가 설치되어 있습니다. -
pcscd
서비스가 실행 중입니다.
스마트 카드를 구성하려면 인증서를 생성하고 pscd
서비스를 시작할 수 있는 해당 도구를 설치해야 합니다.
절차
opensc
및gnutls-utils
패키지를 설치합니다.# dnf -y install opensc gnutls-utils
pcscd
서비스를 시작합니다.# systemctl start pcscd
검증
pcscd
서비스가 실행 중인지 확인합니다.# systemctl status pcscd
9.6. 스마트 카드 준비 및 스마트 카드에 인증서와 키 업로드
다음 절차에 따라 구성하는 데 도움이 되는 pkcs15-init
도구를 사용하여 스마트 카드를 구성합니다.
- 스마트 카드 삭제
- 새로운 pins 및 선택적 pin Unblocking Keys (PUKs) 설정
- 스마트 카드에서 새 슬롯 생성
- 인증서, 개인 키 및 공개 키를 슬롯에 저장
- 필요한 경우 특정 스마트 카드에 따라 스마트 카드 설정을 잠금하려면 이러한 유형의 최종화가 필요합니다.
pkcs15-init
툴은 모든 스마트 카드에서 작동하지 않을 수 있습니다. 사용 중인 스마트 카드로 작업하는 도구를 사용해야 합니다.
사전 요구 사항
pkcs15-init
툴이 포함된opensc
패키지가 설치됩니다.자세한 내용은 스마트 카드 관리 및 사용을 위한 툴 설치를 참조하십시오.
- 카드가 리더에 삽입되고 컴퓨터에 연결되어 있습니다.
-
개인 키, 공개 키 및 스마트 카드에 저장할 인증서가 있습니다. 이 절차에서는
testuser.key
,testuserpublic.key
및testuser.crt
가 개인 키, 공개 키 및 인증서에 사용되는 이름입니다. - 현재 스마트 카드 사용자 Pin and Security Officer Pin (SO-PIN)이 있습니다.
절차
스마트 카드를 지우고 Pin을 사용하여 사용자를 인증합니다.
$ pkcs15-init --erase-card --use-default-transport-keys Using reader with a card: Reader name PIN [Security Officer PIN] required. Please enter PIN [Security Officer PIN]:
카드가 삭제 되었습니다.
스마트 카드를 초기화하고, 사용자 Pin 및 PUK를 설정하고, 보안 사무실자 Pin 및 PUK를 설정합니다.
$ pkcs15-init --create-pkcs15 --use-default-transport-keys \ --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123 Using reader with a card: Reader name
speeds
ks15-init
툴은 스마트 카드에 새 슬롯을 만듭니다.슬롯의 라벨 및 인증 ID를 설정합니다.
$ pkcs15-init --store-pin --label testuser \ --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478 Using reader with a card: Reader name
레이블은 사람이 읽을 수 있는 값(이 경우
testuser
)으로 설정됩니다.auth-id
는 두 개의 16진수 값이어야 합니다. 이 경우01
로 설정됩니다.스마트 카드의 새 슬롯에 개인 키를 저장하고 레이블을 지정합니다.
$ pkcs15-init --store-private-key testuser.key --label testuser_key \ --auth-id 01 --id 01 --pin 963214 Using reader with a card: Reader name
참고--id
에 지정하는 값은 개인 키를 저장하고 다음 단계에 인증서를 저장할 때 동일해야 합니다. 도구에서 더 복잡한 값을 계산하므로--id
에 대해 자체 값을 지정하는 것이 좋습니다.스마트 카드의 새 슬롯에 인증서를 저장하고 레이블을 지정합니다.
$ pkcs15-init --store-certificate testuser.crt --label testuser_crt \ --auth-id 01 --id 01 --format pem --pin 963214 Using reader with a card: Reader name
선택 사항: 스마트 카드의 새 슬롯에 공개 키를 저장하고 레이블을 지정합니다.
$ pkcs15-init --store-public-key testuserpublic.key --label testuserpublic_key --auth-id 01 --id 01 --pin 963214 Using reader with a card: Reader name
참고공개 키가 개인 키 또는 인증서에 해당하는 경우 개인 키 또는 인증서의 ID와 동일한 ID를 지정합니다.
선택 사항: 특정 스마트 카드를 사용하려면 설정을 잠그어 카드를 종료해야 합니다.
$ pkcs15-init -F
이 단계에서 스마트 카드에는 새로 생성된 슬롯에 인증서, 개인 키 및 공개 키가 포함됩니다. 또한 사용자 Pin 및 PUK 및 Security Officer Pin 및 PUK를 생성했습니다.
9.7. sssd.conf에서 시간 제한 설정
스마트 카드 인증서로 인증하는 데 SSSD에서 사용하는 기본 시간 초과보다 오래 걸릴 수 있습니다. 제한 시간 초과는 다음을 통해 발생할 수 있습니다.
- 느린 리더
- 전달은 가상 환경으로 물리적 장치를 형성합니다.
- 스마트 카드에 저장된 인증서가 너무 많습니다.
- OCSP가 인증서를 확인하는 데 사용되는 경우 OCSP(Online Certificate Status Protocol) 응답 속도 저하
이 경우 sssd.conf
파일에서 다음과 같은 시간 초과를 늘릴 수 있습니다(예: 60초).
-
p11_child_timeout
-
krb5_auth_timeout
사전 요구 사항
- root로 로그인해야 합니다.
절차
sssd.conf
파일을 엽니다.[root@idmclient1 ~]# vim /etc/sssd/sssd.conf
p11_child_timeout
의 값을 변경합니다.[pam] p11_child_timeout = 60
NetNamespace
5_auth_timeout
의 값을 변경합니다.[domain/IDM.EXAMPLE.COM] krb5_auth_timeout = 60
- 설정을 저장합니다.
이제 스마트 카드와의 상호 작용은 시간 초과로 인증이 실패하기 전에 1 분 (60 초) 동안 실행할 수 있습니다.
9.8. 스마트 카드 인증을 위한 인증서 매핑 규칙 생성
AD(Active Directory) 및 IdM(Identity Management)에 계정이 있는 사용자에게 하나의 인증서를 사용하려면 IdM 서버에 인증서 매핑 규칙을 생성할 수 있습니다.
이러한 규칙을 생성하면 사용자는 두 도메인에서 스마트 카드로 인증할 수 있습니다.
인증서 매핑 규칙에 대한 자세한 내용은 인증 구성을 위한 인증서 매핑 규칙을 참조하십시오.
10장. Identity Management에서 인증서 매핑 규칙 구성
인증서 매핑 규칙은 IdM(Identity Management) 관리자가 특정 사용자의 인증서에 액세스할 수 없는 경우 사용자가 시나리오에서 인증서를 사용하여 인증할 수 있는 편리한 방법입니다. 일반적으로 인증서가 외부 인증 기관에서 발행되었기 때문입니다.
10.1. 인증을 구성하기 위한 인증서 매핑 규칙
다음 시나리오에서는 인증서 매핑 규칙을 구성해야 할 수 있습니다.
- 인증서는 IdM 도메인이 신뢰 관계에 있는 AD(Active Directory)의 인증서 시스템에서 발급되었습니다.
- 인증서는 외부 인증 기관에서 발급했습니다.
- IdM 환경은 스마트 카드를 사용하는 많은 사용자에게 큽니다. 이 경우 전체 인증서를 추가하는 것은 복잡할 수 있습니다. 제목과 발행자는 대부분의 시나리오에서 예측할 수 있으므로 전체 인증서보다 미리 추가하기가 더 쉽습니다.
시스템 관리자는 인증서 매핑 규칙을 생성하고 특정 사용자에게 인증서를 발급하기 전에 사용자 항목에 인증서 매핑 데이터를 추가할 수 있습니다. 인증서가 발급되면 전체 인증서가 사용자 항목에 아직 업로드되지 않은 경우에도 인증서를 사용하여 로그인할 수 있습니다.
또한 인증서가 정기적으로 갱신되므로 인증서 매핑 규칙이 관리 오버헤드를 줄일 수 있습니다. 사용자의 인증서가 갱신되면 관리자는 사용자 항목을 업데이트할 필요가 없습니다. 예를 들어 매핑이 Subject
및 Issuer
값을 기반으로 하고 새 인증서에는 이전 인증서와 동일한 제목 및 발급자가 있는 경우 매핑은 계속 적용됩니다. 대조적으로 전체 인증서가 사용된 경우 관리자는 이전 인증서를 교체하기 위해 사용자 항목에 새 인증서를 업로드해야 합니다.
인증서 매핑을 설정하려면 다음을 수행합니다.
- 관리자는 인증서 매핑 데이터 또는 전체 인증서를 사용자 계정으로 로드해야 합니다.
- 관리자는 인증서의 정보와 일치하는 인증서 매핑 데이터 항목이 포함된 사용자에 대해 IdM에 성공적으로 로그인할 수 있도록 인증서 매핑 규칙을 생성해야 합니다.
인증서 매핑 규칙이 생성되면 최종 사용자가 인증서를 제공할 때 파일 시스템 또는 스마트 카드에 저장된 인증이 성공적으로 수행됩니다.
KMS(Key Distribution Center)에는 인증서 매핑 규칙에 대한 캐시가 있습니다. 캐시는 첫 번째 certauth
요청에 채워지고 하드 코딩된 시간 제한은 300초입니다. KDC는 재시작되거나 캐시가 만료되지 않는 한 인증서 매핑 규칙에 대한 변경 사항을 볼 수 없습니다.
매핑 규칙을 구성하고 사용하는 개별 구성 요소에 대한 자세한 내용은 IdM의 ID 매핑 규칙의 구성 요소 및 일치하는 규칙에 사용할 인증서에서 발급자 생성을 참조하십시오.
인증서 매핑 규칙은 인증서를 사용하는 사용 사례에 따라 달라질 수 있습니다. 예를 들어 인증서가 포함된 SSH를 사용하는 경우 인증서에서 공개 키를 추출하려면 전체 인증서가 있어야 합니다.
10.2. IdM의 ID 매핑 규칙 구성 요소
IdM에서 ID 매핑 규칙을 생성할 때 다양한 구성 요소를 구성합니다. 각 구성 요소에는 재정의할 수 있는 기본값이 있습니다. 웹 UI 또는 CLI에서 구성 요소를 정의할 수 있습니다. CLI에서 ID 매핑 규칙은 ipa certmaprule-add
명령을 사용하여 생성됩니다.
- 매핑 규칙
매핑 규칙 구성 요소는 인증서를 하나 이상의 사용자 계정과 연결(또는 매핑)합니다. 규칙은 인증서를 의도한 사용자 계정과 연결하는 LDAP 검색 필터를 정의합니다.
다른 CA(인증 기관)에서 발급한 인증서에는 다른 속성이 있을 수 있으며 다른 도메인에서 사용할 수 있습니다. 따라서 IdM은 매핑 규칙을 무조건 적용하지 않고 적절한 인증서에만 적용합니다. 적절한 인증서는 일치하는 규칙을 사용하여 정의됩니다.
매핑 규칙 옵션을 비워 두면 인증서가 DER 인코딩 바이너리 파일로
userCertificate
속성에서 검색됩니다.--maprule
옵션을 사용하여 CLI에서 매핑 규칙을 정의합니다.- 일치 규칙
일치하는 규칙 구성 요소는 매핑 규칙을 적용할 인증서를 선택합니다. 기본 일치 규칙은
digitalSignature 키
사용과 함께 인증서와 일치하며clientAuth는 확장된 키
사용량과 일치합니다.--matchrule
옵션을 사용하여 CLI에서 일치하는 규칙을 정의합니다.- 도메인 목록
domain list는 ID 매핑 규칙을 처리할 때 IdM에서 사용자를 검색할 ID 도메인을 지정합니다. 옵션을 지정하지 않으면 IdM에서 IdM 클라이언트가 속하는 로컬 도메인에서만 사용자를 검색합니다.
domain 옵션을 사용하여 CLI에서
도메인
을 정의합니다.- 우선 순위
인증서에 여러 규칙이 적용되는 경우 우선 순위가 가장 높은 규칙이 우선합니다. 다른 모든 규칙은 무시됩니다.
- 숫자 값이 낮으면 ID 매핑 규칙의 우선 순위가 높습니다. 예를 들어 우선 순위 1이 있는 규칙은 우선 순위가 2인 규칙보다 우선 순위가 높습니다.
- 규칙에 우선순위 값이 정의되어 있지 않으면 우선순위가 가장 낮습니다.
--priority
옵션을 사용하여 CLI에서 매핑 규칙 우선 순위를 정의합니다.
인증서 매핑 규칙 예
CLI를 사용하여 해당 인증서의 주체
가 IdM의 사용자 계정에 있는 certmapdata
항목과 일치하는 경우 EXAMPLE.ORG
조직의 스마트 카드 CA
에서 발급한 인증서에 대해 인증을 허용하는 인증서 매핑 규칙을
사용하여 다음을 수행합니다.
# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'
10.3. 일치하는 규칙에 사용할 인증서에서 데이터 가져오기
다음 절차에서는 인증서 매핑 규칙의 일치하는 규칙에 복사하여 붙여넣을 수 있도록 인증서에서 데이터를 가져오는 방법을 설명합니다. 일치하는 규칙에 필요한 데이터를 가져오려면 sssctl cert-show
또는 sssctl cert-eval-rule
명령을 사용합니다.
사전 요구 사항
- PEM 형식의 사용자 인증서가 있습니다.
절차
필요한 데이터를 검색할 수 있도록 인증서가 올바르게 인코딩되었는지 확인하는 변수를 만듭니다.
# CERT=$(openssl x509 -in /path/to/certificate -outform der|base64 -w0)
sssctl cert-eval-rule
을 사용하여 일치하는 데이터를 확인합니다. 다음 예제에서는 인증서 일련 번호가 사용됩니다.# sssctl cert-eval-rule $CERT --match='<ISSUER>CN=adcs19-WIN1-CA,DC=AD,DC=EXAMPLE,DC=COM' --map='LDAPU1:(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<SR>{serial_number!hex_ur})' Certificate matches rule. Mapping filter: (altSecurityIdentities=X509:<I>DC=com,DC=example,DC=ad,CN=adcs19-WIN1-CA<SR>0F0000000000DB8852DD7B246C9C0F0000003B)
이 경우
altSecurityIdentities=
후 모든 항목을 AD의altSecurityIdentities
속성에 추가합니다. SKI 매핑을 사용하는 경우--map='LDAPU1:(altSecurityIdentities=X509:<SKI>{subject_key_id!hex_u})'
를 사용합니다.선택 사항: 인증서 발행자가
ad.example.com
도메인의dcs19- Cryostat1-CA
와 일치해야 함을 지정하는 일치 규칙에 따라 CLI에 새 매핑 규칙을 생성하려면 사용자 계정의altSecurityIdentities
항목과 일치해야 합니다.# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=adcs19-WIN1-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule 'LDAPU1:(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<SR>{serial_number!hex_ur})'
10.4. IdM에 저장된 사용자의 인증서 매핑 구성
인증서 인증이 구성된 사용자가 IdM에 저장된 경우 IdM에서 인증서 매핑을 활성화하려면 시스템 관리자가 다음 작업을 완료해야 합니다.
- 매핑 규칙에 지정된 조건과 일치하는 인증서가 있는 IdM 사용자가 인증서 매핑 규칙을 설정하고 인증서 매핑 데이터 항목에서 IdM을 인증할 수 있도록 인증서 매핑 규칙을 설정합니다.
- 인증서 매핑 데이터 항목에 지정된 값이 모두 포함된 경우 사용자가 여러 인증서를 사용하여 인증할 수 있도록 IdM 사용자 항목에 인증서 매핑 데이터를 입력합니다.
사전 요구 사항
- 사용자에게 IdM에 계정이 있습니다.
- 관리자에게는 사용자 항목에 추가할 전체 인증서 또는 인증서 매핑 데이터가 있습니다.
10.4.1. IdM 웹 UI에 인증서 매핑 규칙 추가
- IdM 웹 UI에 관리자로 로그인합니다.
-
인증
→인증서 ID 매핑 규칙
→인증서 ID 매핑 규칙으로
이동합니다. 추가를
클릭합니다.그림 10.1. IdM 웹 UI에 새 인증서 매핑 규칙 추가
- 규칙 이름을 입력합니다.
매핑 규칙을 입력합니다. 예를 들어, IdM에서 제공되는 인증서의
Issuer
및Subject
항목을 검색하고 제공된 인증서의 두 항목에 있는 정보를 인증하기로 결정하십시오.(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
일치하는 규칙을 입력합니다. 예를 들어
EXAMPLE.ORG
조직의Smart Card CA
에서 발급한 인증서만 허용하려면 사용자를 IdM에 인증하십시오.<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG
그림 10.2. IdM 웹 UI에서 인증서 매핑 규칙 세부 정보 입력
-
대화 상자 하단에 있는
Add
(추가)를 클릭하여 규칙을 추가하고 상자를 닫습니다. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 SSSD를 다시 시작합니다.
# systemctl restart sssd
이제 스마트 카드 인증서에서 찾은 매핑 규칙에 지정된 데이터 유형을 IdM 사용자 항목의 인증서 매핑 데이터와 비교하는 인증서 매핑 규칙을 설정했습니다. 일치 항목을 찾으면 일치하는 사용자를 인증합니다.
10.4.2. IdM CLI에 인증서 매핑 규칙 추가
관리자의 자격 증명을 가져옵니다.
# kinit admin
매핑 규칙을 입력하고 매핑 규칙이 기반으로 하는 일치 규칙을 입력합니다. 예를 들어, 표시된 인증서의
Issuer
및Subject
항목을 IdM 검색을 수행하고 제공되는 인증서의 두 항목에 있는 정보에 대해 인증하기로 결정하려면EXAMPLE.ORG
조직의Smart Card CA
에서 발급한 인증서만 인식합니다.# ipa certmaprule-add
rule_name
--matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})' ------------------------------------------------------- Added Certificate Identity Mapping Rule "rule_name" ------------------------------------------------------- Rule name: rule_name Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}) Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG Enabled: TRUESSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 SSSD를 다시 시작합니다.
# systemctl restart sssd
이제 스마트 카드 인증서에서 찾은 매핑 규칙에 지정된 데이터 유형을 IdM 사용자 항목의 인증서 매핑 데이터와 비교하는 인증서 매핑 규칙을 설정했습니다. 일치 항목을 찾으면 일치하는 사용자를 인증합니다.
10.4.3. IdM 웹 UI에서 사용자 항목에 인증서 매핑 데이터 추가
- IdM 웹 UI에 관리자로 로그인합니다.
-
사용자 → 활성
사용자
→idm_user
로 이동합니다. -
인증서 매핑 데이터
옵션을 찾아추가를
클릭합니다. 다음 옵션 중 하나를 선택합니다.
idm_user
인증서가 있는 경우 :명령줄 인터페이스에서
cat
유틸리티 또는 텍스트 편집기를 사용하여 인증서를 표시합니다.[root@server ~]# cat idm_user_certificate.pem -----BEGIN CERTIFICATE----- MIIFFTCCA/2gAwIBAgIBEjANBgkqhkiG9w0BAQsFADA6MRgwFgYDVQQKDA9JRE0u RVhBTVBMRS5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x ODA5MDIxODE1MzlaFw0yMDA5MDIxODE1MzlaMCwxGDAWBgNVBAoMD0lETS5FWEFN [...output truncated...]
- 인증서를 복사합니다.
IdM 웹 UI에서 인증서 옆에 있는
Add
(추가)를 클릭하고 인증서가 열리는 창에 붙여넣습니다.그림 10.3. 사용자의 인증서 매핑 데이터 추가: certificate
-
IDm
_user
의 인증서가 있지만발행자
및 인증서주체
를 알고 있는 경우 발급자및
제목의 라디오 버튼을 확인하고 해당 두 박스에 있는 값을 입력합니다.
그림 10.4. 사용자의 인증서 매핑 데이터 추가: issuer 및 subject
-
IDm
-
추가를
클릭합니다.
검증
.pem
형식의 전체 인증서에 액세스할 수 있는 경우 사용자 및 인증서가 연결되어 있는지 확인합니다.
sss_cache
유틸리티를 사용하여 SSSD 캐시에서idm_user
레코드를 무효화하고idm_user
정보를 다시 로드합니다.# sss_cache -u idm_user
IdM 사용자의 인증서가 포함된 파일 이름으로
ipa certmap-match
명령을 실행합니다.# ipa certmap-match idm_user_cert.pem -------------- 1 user matched -------------- Domain: IDM.EXAMPLE.COM User logins: idm_user ---------------------------- Number of entries returned 1 ----------------------------
출력은 이제
idm_user
에 인증서 매핑 데이터를 추가하고 해당 매핑 규칙이 존재하는지 확인합니다. 즉 정의된 인증서 매핑 데이터와 일치하는 인증서를 사용하여idm_user
로 인증할 수 있습니다.
10.4.4. IdM CLI에서 사용자 항목에 인증서 매핑 데이터 추가
관리자의 자격 증명을 가져옵니다.
# kinit admin
다음 옵션 중 하나를 선택합니다.
-
idm_user
인증서가 있는 경우ipa user-add-cert
명령을 사용하여 사용자 계정에 인증서를 추가합니다.
# CERT=$(openssl x509 -in idm_user_cert.pem -outform der|base64 -w0) # ipa user-add-certmapdata idm_user --certificate $CERT
idm_user
인증서가 없지만발급
자 및 사용자 인증서주체
를 알고 있는 경우:# ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG" -------------------------------------------- Added certificate mappings to user "idm_user" -------------------------------------------- User login: idm_user Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
-
검증
.pem
형식의 전체 인증서에 액세스할 수 있는 경우 사용자 및 인증서가 연결되어 있는지 확인합니다.
sss_cache
유틸리티를 사용하여 SSSD 캐시에서idm_user
레코드를 무효화하고idm_user
정보를 다시 로드합니다.# sss_cache -u idm_user
IdM 사용자의 인증서가 포함된 파일 이름으로
ipa certmap-match
명령을 실행합니다.# ipa certmap-match idm_user_cert.pem -------------- 1 user matched -------------- Domain: IDM.EXAMPLE.COM User logins: idm_user ---------------------------- Number of entries returned 1 ----------------------------
출력은 이제
idm_user
에 인증서 매핑 데이터를 추가하고 해당 매핑 규칙이 존재하는지 확인합니다. 즉 정의된 인증서 매핑 데이터와 일치하는 인증서를 사용하여idm_user
로 인증할 수 있습니다.
10.5. Active Directory 도메인을 사용하는 신뢰에 대한 인증서 매핑 규칙
IdM 배포가 AD(Active Directory) 도메인과의 신뢰 관계에 있는 경우 다른 인증서 매핑 사용 사례가 가능합니다.
AD 구성에 따라 다음 시나리오가 가능합니다.
- 인증서가 AD 인증서 시스템에서 발행되지만 사용자와 인증서가 IdM에 저장된 경우 인증 요청의 매핑과 전체 처리가 IdM 측에서 수행됩니다. 이 시나리오 구성의 자세한 내용은 IdM에 저장된 사용자의 인증서 매핑 구성을참조하십시오.
사용자가 AD에 저장된 경우 인증 요청 처리가 AD에서 수행됩니다. 세 가지 하위 사례가 있습니다.
- AD 사용자 항목에는 전체 인증서가 포함되어 있습니다. 이 시나리오에서 IdM을 구성하는 방법에 대한 자세한 내용은 AD 사용자 항목이 전체 인증서가 포함된 사용자를 위한 인증서 매핑 구성을 참조하십시오.
-
AD는 사용자 인증서를 사용자 계정에 매핑하도록 구성됩니다. 이 경우 AD 사용자 항목에 전체 인증서가 포함되어 있지 않지만 대신
altSecurityIdentities
라는 속성이 포함됩니다. 이 시나리오에서 IdM을 구성하는 방법에 대한 자세한 내용은 사용자 인증서를 사용자 계정에 매핑하도록 AD가 구성된 경우 인증서 매핑 구성을 참조하십시오. AD 사용자 항목에는 전체 인증서와 매핑 데이터가 포함되어 있지 않습니다. 이 경우 다음 두 가지 옵션이 있습니다.
- AD 인증서 시스템에서 사용자 인증서를 발급한 경우 인증서에는 SAN(Subject Alternative Name)으로 사용자 주체 이름이 포함되어 있거나 최신 업데이트가 AD에 적용되는 경우 인증서 SID에 있는 사용자의 SID가 포함됩니다. 두 가지 모두 인증서를 사용자에게 매핑하는 데 사용할 수 있습니다.
-
사용자 인증서가 스마트 카드에 있는 경우 스마트 카드로 SSH를 활성화하려면 인증서에서 공개 SSH 키를 파생해야 하므로 전체 인증서가 필요합니다. 유일한 해결책은
ipa idoverrideuser-add
명령을 사용하여 IdM의 AD 사용자 ID 재정의에 전체 인증서를 추가하는 것입니다. 자세한 내용은 AD 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 인증서 매핑 구성 을 참조하십시오.
AD 도메인 관리자는 altSecurityIdentities
특성을 사용하여 AD의 사용자에게 인증서를 수동으로 매핑할 수 있습니다. 이 속성에는 지원되는 6개의 값이 있지만 세 매핑은 안전하지 않은 것으로 간주됩니다. 2022 보안 업데이트 의 일부로 설치되면 모든 장치가 호환성 모드에 있고 인증서가 사용자에게 약한 경우 인증이 예상대로 수행됩니다. 그러나 경고 메시지는 전체 적용 모드와 호환되지 않는 모든 인증서를 식별할 수 있습니다. 2023년 11월 14일 이후부터 모든 장치가 완전히 적용 모드로 업데이트되고 인증서가 강력한 매핑 기준에 실패하면 인증이 거부됩니다.
예를 들어 AD 사용자가 인증서(PKINIT)를 사용하여 IdM Kerberos 티켓을 요청하는 경우 AD는 인증서를 내부적으로 사용자에게 매핑해야 하며 새 매핑 규칙을 사용합니다. 그러나 IdM 클라이언트의 사용자에게 인증서를 매핑하는 데 IdM을 사용하는 경우 이전 규칙이 계속 작동합니다.
IdM은 새 매핑 템플릿을 지원하므로 AD 관리자가 새 규칙을 더 쉽게 사용할 수 있으며 두 가지 모두를 유지 관리하지 않습니다. IdM은 다음을 포함하도록 Active Directory에 추가된 새 매핑 템플릿을 지원합니다.
- 일련 번호: LDAPU1:(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<SR>{serial_number!hex_ur})
- 제목 키 ID: LDAPU1:(altSecurityIdentities=X509:<SKI>{subject_key_id!hex_u})
- 사용자 SID: LDAPU1:(objectsid={sid})
새 SID 확장으로 인증서를 다시 게시하지 않으려면 AD의 사용자 altSecurityIdentities
속성에 적절한 매핑 문자열을 추가하여 수동 매핑을 만들 수 있습니다.
10.6. AD 사용자 항목이 전체 인증서가 포함되어 있는 사용자에 대한 인증서 매핑 구성
이 사용자 사례에서는 IdM 배포가 AD(Active Directory)와 함께 신뢰되는 경우 IdM에서 인증서 매핑을 활성화하는 데 필요한 단계를 설명하고, AD의 사용자 항목에 전체 인증서가 포함되어 있습니다.
사전 요구 사항
- 사용자에게 IdM에 계정이 없습니다.
- 사용자에는 인증서를 포함하는 AD 계정이 있습니다.
- IdM 관리자는 IdM 인증서 매핑 규칙을 기반으로 할 수 있는 데이터에 액세스할 수 있습니다.
PKINIT가 사용자에게 작동하도록 하려면 다음 조건 중 하나를 적용해야 합니다.
- 사용자 항목의 인증서에는 사용자 주체 이름 또는 사용자의 SID 확장이 포함됩니다.
-
AD의 사용자 항목에는
altSecurityIdentities
속성에 적절한 항목이 있습니다.
10.6.1. IdM 웹 UI에 인증서 매핑 규칙 추가
- IdM 웹 UI에 관리자로 로그인합니다.
-
인증
→인증서 ID 매핑 규칙
→인증서 ID 매핑 규칙으로
이동합니다. 추가를
클릭합니다.그림 10.5. IdM 웹 UI에 새 인증서 매핑 규칙 추가
- 규칙 이름을 입력합니다.
매핑 규칙을 입력합니다. 인증을 위해 IdM에 제공되는 전체 인증서를 AD에서 사용할 수 있는 것과 비교하려면 다음을 수행하십시오.
(userCertificate;binary={cert!bin})
참고전체 인증서를 사용하여 매핑하는 경우 인증서를 갱신하는 경우 새 인증서를 AD 사용자 오브젝트에 추가해야 합니다.
일치하는 규칙을 입력합니다. 예를 들어
AD.EXAMPLE.COM
도메인의AD-ROOT-CA
에서 발급한 인증서만 인증하려면 다음을 수행합니다.<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
그림 10.6. AD에 저장된 인증서가 있는 사용자의 인증서 매핑 규칙
-
추가를
클릭합니다. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 CLI에서 SSSD를 다시 시작합니다.
# systemctl restart sssd
10.6.2. IdM CLI에 인증서 매핑 규칙 추가
관리자의 자격 증명을 가져옵니다.
# kinit admin
매핑 규칙을 입력하고 매핑 규칙이 기반으로 하는 일치 규칙을 입력합니다. AD에서 사용할 수 있는 것과 비교하여 인증을 위해 제공되는 전체 인증서를 설정하려면
AD.EXAMPLE.COM
도메인의AD-ROOT-CA
에서 발행한 인증서만 인증할 수 있습니다.# ipa certmaprule-add
simpleADrule
--matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com ------------------------------------------------------- Added Certificate Identity Mapping Rule "simpleADrule" ------------------------------------------------------- Rule name: simpleADrule Mapping rule: (userCertificate;binary={cert!bin}) Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com Domain name: ad.example.com Enabled: TRUE참고전체 인증서를 사용하여 매핑하는 경우 인증서를 갱신하는 경우 새 인증서를 AD 사용자 오브젝트에 추가해야 합니다.
SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 SSSD를 다시 시작합니다.
# systemctl restart sssd
10.7. AD가 사용자 인증서를 사용자 계정에 매핑하도록 구성된 경우 인증서 매핑 구성
이 사용자 스토리는 IdM 배포가 AD(Active Directory)와 신뢰하고, 사용자가 AD에 저장되고, AD의 사용자 항목에는 인증서 매핑 데이터가 포함된 경우 IdM에서 인증서 매핑을 활성화하는 데 필요한 단계를 설명합니다.
사전 요구 사항
- 사용자에게 IdM에 계정이 없습니다.
-
사용자에게는
altSecurityIdentities
속성이 포함된 AD 계정이 있으며, AD는 IdMcertmapdata
속성과 동일합니다. - IdM 관리자는 IdM 인증서 매핑 규칙을 기반으로 할 수 있는 데이터에 액세스할 수 있습니다.
10.7.1. IdM 웹 UI에 인증서 매핑 규칙 추가
- IdM 웹 UI에 관리자로 로그인합니다.
-
인증
→인증서 ID 매핑 규칙
→인증서 ID 매핑 규칙으로
이동합니다. 추가를
클릭합니다.그림 10.7. IdM 웹 UI에 새 인증서 매핑 규칙 추가
- 규칙 이름을 입력합니다.
매핑 규칙을 입력합니다. 예를 들어 AD DC에서 제공되는 인증서의
Issuer
및Subject
항목을 검색하고 제공된 인증서의 두 항목에 있는 정보를 인증하기로 결정하십시오.(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
일치하는 규칙을 입력합니다. 예를 들어
AD.EXAMPLE.COM
도메인의AD-ROOT-CA
에서 발급한 인증서만 허용하여 사용자를 IdM에 인증하려면 다음을 수행합니다.<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
도메인에 로그인합니다.
ad.example.com
그림 10.8. AD가 매핑용으로 구성된 경우 인증서 매핑 규칙
-
추가를
클릭합니다. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 CLI에서 SSSD를 다시 시작합니다.
# systemctl restart sssd
10.7.2. IdM CLI에 인증서 매핑 규칙 추가
관리자의 자격 증명을 가져옵니다.
# kinit admin
매핑 규칙을 입력하고 매핑 규칙이 기반으로 하는 일치 규칙을 입력합니다. 예를 들어 제공되는 인증서의
Issuer
및Subject
항목을 AD 검색을 수행하고AD.EXAMPLE.COM
도메인의AD-ROOT-CA
에서 발급한 인증서만 허용하려면 다음을 수행합니다.# ipa certmaprule-add ad_configured_for_mapping_rule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' --domain=ad.example.com ------------------------------------------------------- Added Certificate Identity Mapping Rule "ad_configured_for_mapping_rule" ------------------------------------------------------- Rule name: ad_configured_for_mapping_rule Mapping rule: (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}) Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com Domain name: ad.example.com Enabled: TRUE
SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 SSSD를 다시 시작합니다.
# systemctl restart sssd
10.7.3. AD 측에서 인증서 매핑 데이터 확인
altSecurityIdentities
속성은 IdM의 certmapdata
사용자 속성에 해당하는 AD(Active Directory)입니다. 신뢰할 수 있는 AD 도메인을 사용자 계정에 매핑하도록 구성된 시나리오에서 IdM에서 인증서 매핑을 구성할 때 IdM 시스템 관리자는 AD의 사용자 항목에 altSecurityIdentities
속성이 올바르게 설정되었는지 확인해야 합니다.
사전 요구 사항
- 사용자 계정에는 사용자 관리 액세스 권한이 있어야 합니다.
절차
AD에 저장된 사용자에 대한 올바른 정보가 포함되어 있는지 확인하려면
ldapsearch
명령을 사용하십시오. 예를 들어 아래 명령을 입력하여 다음 조건이 적용되는adserver.ad.example.com
서버를 사용하여 확인합니다.-
altSecurityIdentities
속성은ad_user
의 사용자 항목에 설정됩니다. matchrule에서 다음과 같은 조건이 적용됩니다.
-
ad_user
가 AD에 인증하는 데 사용하는 인증서는ad.example.com
도메인의AD-ROOT-CA
에서 발행되었습니다. -
제목은 <
S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user
:
-
$ ldapsearch -o ldif-wrap=no -LLL -h adserver.ad.example.com \ -p 389 -D cn=Administrator,cn=users,dc=ad,dc=example,dc=com \ -W -b cn=users,dc=ad,dc=example,dc=com "(cn=ad_user)" \ altSecurityIdentities Enter LDAP Password: dn: CN=ad_user,CN=Users,DC=ad,DC=example,DC=com altSecurityIdentities: X509:<I>DC=com,DC=example,DC=ad,CN=AD-ROOT-CA<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user
-
10.8. AD 사용자 항목에 인증서가 없거나 매핑 데이터가 없는 경우 인증서 매핑 구성
이 사용자 사례에서는 IdM 배포가 AD(Active Directory)와 함께 IdM 배포가 신뢰할 수 있는 경우 IdM에서 인증서 매핑을 활성화하는 데 필요한 단계를 설명하고, AD의 사용자 항목에 전체 인증서와 인증서 매핑 데이터가 포함되어 있지 않습니다.
사전 요구 사항
- 사용자에게 IdM에 계정이 없습니다.
-
사용자는 AD에 전체 인증서와
altSecurityIdentities
속성을 모두 포함하는 계정을 가지고 있으며, AD는 IdMcertmapdata
속성과 동일합니다. IdM 관리자가 다음 중 하나를 수행했습니다.
-
IdM의 AD 사용자
ID 재정의에 전체 AD 사용자
인증서를 추가했습니다. - 주체 대체 이름 또는 사용자의 SID와 같이 인증서의 대체 필드에 매핑되는 인증서 매핑 규칙을 생성했습니다.
-
IdM의 AD 사용자
10.8.1. IdM 웹 UI에 인증서 매핑 규칙 추가
- IdM 웹 UI에 관리자로 로그인합니다.
-
인증
→인증서 ID 매핑 규칙
→인증서 ID 매핑 규칙으로
이동합니다. 추가를
클릭합니다.그림 10.9. IdM 웹 UI에 새 인증서 매핑 규칙 추가
- 규칙 이름을 입력합니다.
매핑 규칙을 입력합니다. IdM에서 AD 사용자 항목의 사용자 ID 오버라이드 항목에 저장된 인증서와 비교하여 IdM에 제공되는 전체 인증서를 보유하려면 다음을 수행합니다.
(userCertificate;binary={cert!bin})
참고인증서에는 사용자 주체 이름이 SAN으로 포함되어 있거나 최신 업데이트, 인증서의 SID 확장에 있는 사용자의 SID도 포함되어 있으므로 이러한 필드를 사용하여 인증서를 사용자에게 매핑할 수도 있습니다. 예를 들어 사용자의 SID를 사용하는 경우 이 매핑 규칙을
LDAPU1:(objectsid={sid})
로 바꿉니다. 인증서 매핑에 대한 자세한 내용은 시스템의sss-certmap
도움말 페이지를 참조하십시오.일치하는 규칙을 입력합니다. 예를 들어
AD.EXAMPLE.COM
도메인의AD-ROOT-CA
에서 발급한 인증서만 인증하려면 다음을 수행합니다.<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
도메인 이름을 입력합니다. 예를 들어
ad.example.com
도메인에서 사용자를 검색하려면 다음을 수행합니다.그림 10.10. 인증서 또는 AD에 저장된 데이터를 매핑하지 않은 사용자의 인증서 매핑 규칙
-
추가를
클릭합니다. SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 CLI에서 SSSD를 다시 시작합니다.
# systemctl restart sssd
10.8.2. IdM CLI에 인증서 매핑 규칙 추가
관리자의 자격 증명을 가져옵니다.
# kinit admin
매핑 규칙을 입력하고 매핑 규칙이 기반으로 하는 일치 규칙을 입력합니다. IdM의 사용자 ID 덮어쓰기 항목에 저장된 인증서에 비해 인증을 위해 제공되는 전체 인증서를 보유하려면
AD.EXAMPLE.COM
도메인의AD-ROOT-CA
에서 발행한 인증서만 인증할 수 있습니다.# ipa certmaprule-add
simpleADrule
--matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com ------------------------------------------------------- Added Certificate Identity Mapping Rule "simpleADrule" ------------------------------------------------------- Rule name: simpleADrule Mapping rule: (userCertificate;binary={cert!bin}) Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com Domain name: ad.example.com Enabled: TRUE참고인증서에는 사용자 주체 이름이 SAN으로 포함되어 있거나 최신 업데이트, 인증서의 SID 확장에 있는 사용자의 SID도 포함되어 있으므로 이러한 필드를 사용하여 인증서를 사용자에게 매핑할 수도 있습니다. 예를 들어 사용자의 SID를 사용하는 경우 이 매핑 규칙을
LDAPU1:(objectsid={sid})
로 바꿉니다. 인증서 매핑에 대한 자세한 내용은 시스템의sss-certmap
도움말 페이지를 참조하십시오.SSSD(System Security Services Daemon)는 인증서 매핑 규칙을 주기적으로 다시 읽습니다. 새로 생성된 규칙을 즉시 로드하도록 하려면 SSSD를 다시 시작합니다.
# systemctl restart sssd
10.8.3. IdM 웹 UI에서 AD 사용자 ID 재정의에 인증서 추가
-
Identity
→ID Views
→Default Trust View
로 이동합니다. 추가를
클릭합니다.그림 10.11. IdM 웹 UI에서 새 사용자 ID 덮어쓰기 추가
-
User to override
필드에ad_user@ad.example.com
을 입력합니다. ad_user
의 인증서를 복사하여인증서
필드에 붙여넣습니다.그림 10.12. AD 사용자에 대한 사용자 ID 재정의 구성
-
추가를
클릭합니다.
검증
사용자 및 인증서가 연결되었는지 확인합니다.
sss_cache
유틸리티를 사용하여 SSSD 캐시에서ad_user@ad.example.com
레코드를 무효화하고ad_user@ad.example.com
정보를 다시 로드합니다.# sss_cache -u ad_user@ad.example.com
AD 사용자의 인증서가 포함된 파일 이름으로
ipa certmap-match
명령을 실행합니다.# ipa certmap-match ad_user_cert.pem -------------- 1 user matched -------------- Domain: AD.EXAMPLE.COM User logins: ad_user@ad.example.com ---------------------------- Number of entries returned 1 ----------------------------
출력은 인증서 매핑 데이터가 ad_user@ad.example.com
에 추가되고 AD 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 인증서 매핑 규칙 추가에 정의된 해당 매핑 규칙이 있는지 확인합니다. 즉, 정의된 인증서 매핑 데이터와 일치하는 인증서를 사용하여 ad_user@ad.example.com
로 인증할 수 있습니다.
10.8.4. IdM CLI에서 AD 사용자 ID 재정의에 인증서 추가
관리자의 자격 증명을 가져옵니다.
# kinit admin
인증서 Blob을
CERT
라는 새 변수에 저장합니다.# CERT=$(openssl x509 -in /path/to/certificate -outform der|base64 -w0)
ipa idoverrideuser-add-cert
명령을 사용하여 사용자 계정에ad_user@ad.example.com
의 인증서를 추가합니다.# ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT
검증
사용자 및 인증서가 연결되었는지 확인합니다.
sss_cache
유틸리티를 사용하여 SSSD 캐시에서ad_user@ad.example.com
레코드를 무효화하고ad_user@ad.example.com
정보를 다시 로드합니다.# sss_cache -u ad_user@ad.example.com
AD 사용자의 인증서가 포함된 파일 이름으로
ipa certmap-match
명령을 실행합니다.# ipa certmap-match ad_user_cert.pem -------------- 1 user matched -------------- Domain: AD.EXAMPLE.COM User logins: ad_user@ad.example.com ---------------------------- Number of entries returned 1 ----------------------------
출력은 인증서 매핑 데이터가 ad_user@ad.example.com
에 추가되고 AD 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 인증서 매핑 규칙 추가에 정의된 해당 매핑 규칙이 있는지 확인합니다. 즉, 정의된 인증서 매핑 데이터와 일치하는 인증서를 사용하여 ad_user@ad.example.com
로 인증할 수 있습니다.
10.9. 여러 ID 매핑 규칙을 하나로 결합
여러 ID 매핑 규칙을 하나의 결합된 규칙으로 결합하려면 |
(또는) 문자를 사용하여 개별 매핑 규칙 앞에 를 사용하고 ()
대괄호를 사용하여 분리합니다.
인증서 매핑 필터 예 1
$ ipa certmaprule-add ad_cert_for_ipa_and_ad_users \ --maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \ --domain=ad.example.com
위 예에서 --maprule
옵션의 필터 정의에는 다음과 같은 기준이 포함됩니다.
-
ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}
는 스마트 카드 인증서 인증서에서 주체와 발급자를 IdM 사용자 계정의ipacertmapdata
속성 값으로 연결하는 필터입니다. IdM에서 인증서 매핑 규칙 추가에설명된 대로 -
altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}
는 신뢰할 수 있는 AD 도메인 추가에 설명된 대로 스마트 카드 인증서의 제목과 발급자를 AD 사용자 계정의altSecurityIdentities
속성 값으로 연결하는 필터입니다. -
--domain=ad.example.com
옵션을 추가하면 지정된 인증서에 매핑된 사용자가 로컬idm.example.com
도메인에서뿐만 아니라ad.example.com
도메인에서도 검색됩니다.
--maprule
옵션의 필터 정의는 논리 연산자 |
(또는)를 허용하므로 여러 기준을 지정할 수 있습니다. 이 경우 규칙은 조건 중 하나 이상을 충족하는 모든 사용자 계정을 매핑합니다.
인증서 매핑 필터 예 2
$ ipa certmaprule-add ipa_cert_for_ad_users \ --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \ --domain=idm.example.com --domain=ad.example.com
위 예에서 --maprule
옵션의 필터 정의에는 다음과 같은 기준이 포함됩니다.
-
userCertificate;binary={cert!bin}
은 전체 인증서가 포함된 사용자 항목을 반환하는 필터입니다. AD 사용자의 경우 AD 사용자 항목에 인증서 또는 매핑 데이터가 없는 경우 이러한 유형의 필터를 생성하는 데 인증서 매핑 규칙 추가 에 자세히 설명되어 있습니다. -
ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}
은 IdM 사용자 계정의 인증서 매핑 규칙에 설명된 대로 스마트 카드 인증서의 주체와 발급자를 IdM 사용자 계정의ipacertmapdata
속성 값으로 연결하는 필터입니다. -
altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}
는 신뢰할 수 있는 AD 도메인이 사용자 인증서를 추가하도록 구성된 경우 인증서 매핑 규칙 추가에 설명된 대로 스마트 카드 인증서의 제목과 발급자를 AD 사용자 계정의altSecurityIdentities
속성 값으로 연결하는 필터입니다.
--maprule
옵션의 필터 정의는 논리 연산자 |
(또는)를 허용하므로 여러 기준을 지정할 수 있습니다. 이 경우 규칙은 조건 중 하나 이상을 충족하는 모든 사용자 계정을 매핑합니다.
10.10. 추가 리소스
-
시스템의
SSS-certmap(5)
도움말 페이지
11장. IdM 클라이언트의 데스크탑에 저장된 인증서로 인증 구성
IdM(Identity Management)을 구성하면 IdM 시스템 관리자가 인증 기관(CA)이 사용자에게 발행한 인증서를 사용하여 IdM 웹 UI 및 CLI(명령줄 인터페이스)에 인증할 수 있습니다. 인증서는 IdM 클라이언트의 데스크탑에 저장됩니다.
웹 브라우저는 IdM 도메인에 포함되지 않은 시스템에서 실행할 수 있습니다.
인증서를 사용하여 인증을 구성하는 동안 다음 사항에 유의하십시오.
- 인증서에 이미 인증서가 있는 경우 새 사용자 인증서 요청 및 클라이언트 내보내기 를 건너뛸 수 있습니다.
- IdM CA 에서 사용자의 인증서를 발급한 경우 인증서와 사용자가 함께 연결되어 있는지 여부를 건너뛸 수 있습니다.
ID 관리 사용자만 인증서를 사용하여 웹 UI에 로그인할 수 있습니다. Active Directory 사용자는 사용자 이름과 암호를 사용하여 로그인할 수 있습니다.
11.1. 웹 UI에서 인증 인증을 위한 Identity Management Server 구성
IdM(Identity Management) 관리자는 사용자가 인증서를 사용하여 IdM 환경에 인증할 수 있습니다.
절차
Identity Management 관리자:
Identity Management 서버에서 관리자 권한을 얻고 서버를 구성하는 쉘 스크립트를 생성합니다.
ipa-advise config-server-for-smart-card-auth
명령을 실행하고 출력을 파일에 저장합니다(예:server_certificate_script.sh
):# kinit admin # ipa-advise config-server-for-smart-card-auth >
server_certificate_script.sh
pkexec 유틸리티를 사용하여 파일에 실행 권한을 추가합니다.
# chmod +x
server_certificate_script.sh
Identity Management 도메인의 모든 서버에서
server_certificate_script.sh
스크립트를 실행합니다.IdM CA가 인증서 인증을 활성화하려는 사용자의 인증서를 발급한 유일한 인증 기관인 경우 입력으로서 IdM 인증 기관의 경로
/etc/ipa/ca.crt
입니다.#
./server_certificate_script.sh
/etc/ipa/ca.crt
다른 외부 CA가 인증서 인증을 활성화하려는 사용자의 인증서에 서명하면 관련 CA 인증서가 입력으로 발생합니다.
#
./server_certificate_script.sh
/tmp/ca1.pem
/tmp/ca2.pem
전체 토폴로지에서 활성화된 사용자에 대한 인증서 인증을 사용하려면 나중에 시스템에 추가하는 각 새 복제본에서 스크립트를 실행해야 합니다.
11.2. 새 사용자 인증서 요청 및 클라이언트로 내보내기
IdM(Identity Management) 관리자는 IdM 환경에서 사용자의 인증서를 생성하고 사용자에게 인증서 인증을 활성화하려는 IdM 클라이언트에 내보낼 수 있습니다.
인증서를 사용하여 인증하려는 사용자에게 이미 인증서가 있는 경우 이 절차를 따를 필요가 없습니다.
절차
선택 사항: 새 디렉터리(예:
~/certdb/
)를 생성하고 임시 인증서 데이터베이스로 설정합니다. 메시지가 표시되면 NSS 인증서 DB 암호를 생성하여 후속 단계에서 생성할 인증서에 대한 키를 암호화합니다.# mkdir
~/certdb/
# certutil -N -d~/certdb/
Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password:CSR(인증서 서명 요청)을 생성하고 출력을 파일로 리디렉션합니다. 예를 들어
IDM.EXAMPLE.COM
영역에 있는idm_user
사용자의4096
비트 인증서에 대해certificate_request.csr
이라는 이름으로 CSR을 생성하려면 인증서 개인 키의 nickname을 쉽게 찾을 수 있도록idm_user
로 설정하고CN=idm_user,O=IDMM.EXALE :COM으로 설정합니다.
# certutil -R -d
~/certdb/
-a -g4096
-nidm_user
-s "CN=idm_user
,O=IDM.EXAMPLE.COM" >certificate_request.csr
메시지가 표시되면
certutil
을 사용하여 임시 데이터베이스를 생성할 때 입력한 암호와 동일한 암호를 입력합니다. 다음으로 중지될 때까지 randlomly를 계속 입력합니다.Enter Password or Pin for "NSS Certificate DB": A random seed must be generated that will be used in the creation of your key. One of the easiest ways to create a random seed is to use the timing of keystrokes on a keyboard. To begin, type keys on the keyboard until this progress meter is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD! Continue typing until the progress meter is full:
인증서 요청 파일을 서버에 제출합니다. 새로 발급된 인증서, 인증서를 저장할 출력 파일, 선택적으로 인증서 프로필과 연결할 Kerberos 주체를 지정합니다. 예를 들어
IECUserRoles
프로필의 인증서를 얻으려면 사용자 역할 확장이 추가된 프로필인idm_user
@IDM.EXAMPLE.COM
주체의 경우~/idm_user.pem
파일에 저장합니다.# ipa cert-request
certificate_request.csr
--principal=idm_user
@IDM.EXAMPLE.COM
--profile-id=IECUserRoles
--certificate-out=~/idm_user.pem
NSS 데이터베이스에 인증서를 추가합니다.
-n
옵션을 사용하여 이전에 CSR을 생성할 때 사용한 것과 동일한 nickname을 설정하여 인증서가 NSS 데이터베이스의 개인 키와 일치하도록 합니다.t
옵션은 신뢰 수준을 설정합니다. 자세한 내용은 certutil(1) 매뉴얼 페이지를 참조하십시오.i
옵션은 입력 인증서 파일을 지정합니다. 예를 들어 NSS 데이터베이스에~/certdb/
데이터베이스의~/
파일에 저장된 idm_user nickname을 사용하여 인증서를 추가하려면 다음을 수행합니다.idm_user
.pem# certutil -A -d
~/certdb/
-nidm_user
-t "P,," -i~/idm_user.pem
NSS 데이터베이스의 키가 닉네임
(orphan)
으로 표시되지 않는지 확인합니다. 예를 들어~/certdb/
데이터베이스에 저장된 인증서가 분리되지 않았는지 확인하려면 다음을 수행합니다.# certutil -K -d
~/certdb/
< 0> rsa 5ad14d41463b87a095b1896cf0068ccc467df395 NSS Certificate DB:idm_userpk12util
명령을 사용하여 NSS 데이터베이스에서 PKCS12 형식으로 인증서를 내보냅니다. 예를 들어idm_user
nickname을 사용하여 인증서를/root/certdb
NSS 데이터베이스에서~/idm_user.p12
파일로 내보내려면 다음을 실행합니다.# pk12util -d
~/certdb
-o~/idm_user.p12
-nidm_user
Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFULidm_user
의 인증서 인증을 활성화할 호스트에 인증서를 전송합니다.# scp
~/idm_user.p12
idm_user@client.idm.example.com:/home/idm_user/
인증서가 전송된 호스트에서 .pkcs12 파일이 저장된 디렉토리를 보안상의 이유로 'other' 그룹에 저장할 수 없도록 합니다.
# chmod o-rwx
/home/idm_user/
보안상의 이유로 서버에서 임시 NSS 데이터베이스 및 .pkcs12 파일을 제거하십시오.
# rm
~/certdb/
# rm~/idm_user.p12
11.3. 인증서와 사용자가 연결되어 있는지 확인
IdM CA에서 사용자 인증서를 발급한 경우 이 절차를 따를 필요가 없습니다.
인증서 인증이 작동하려면 인증서가 IdM(Identity Management)에 인증할 사용자에게 인증서가 연결되어 있는지 확인해야 합니다.
- ID 관리 환경에 포함되지 않은 인증 기관에서 인증서를 제공하는 경우 사용자 계정 링크를 통해 인증서와 관련된 절차에 따라 사용자와 인증서를 연결합니다.
- ID 관리 CA에서 인증서를 제공하는 경우 인증서가 이미 사용자 항목에 자동으로 추가되고 인증서를 사용자 계정에 연결할 필요가 없습니다. IdM에서 새 인증서를 생성하는 방법에 대한 자세한 내용은 새 사용자 인증서 요청 및 클라이언트로 내보내기를 참조하십시오.
11.4. 인증서 인증을 사용하도록 브라우저 구성
WebUI를 사용하여 IdM(Identity Management)에 로그인할 때 인증서로 인증할 수 있으려면 사용자와 관련 인증 기관(CA) 인증서를 Mozilla Firefox 또는 Google Chrome 브라우저로 가져와야 합니다. 브라우저가 실행 중인 호스트 자체는 IdM 도메인의 일부가 될 필요가 없습니다.
IdM은 다음 브라우저를 지원하여 WebUI 연결을 지원합니다.
- Mozilla Firefox 38 이상
- Google Chrome 46 이상
다음 절차에서는 Mozilla Firefox 57.0.1 브라우저를 구성하는 방법을 보여줍니다.
사전 요구 사항
- PKCS#12 형식으로든 브라우저로 가져올 사용자 인증서 가 있습니다.
절차
Firefox를 연 다음
기본 설정
→개인 정보 보호 및 보안
으로 이동합니다.그림 11.1. 기본 설정의 개인 정보 및 보안 섹션
그림 11.2. 개인 정보 보호 및 보안의 인증서 보기
-
인증서
탭에서 를 클릭합니다. PKCS12 형식으로 사용자 인증서를 찾아서 연 다음 클릭합니다. Firefox에서 Identity Management 인증 기관을 신뢰할 수 있는 기관으로 인식했는지 확인합니다.
IdM CA 인증서를 로컬에 저장합니다.
Firefox 주소 표시줄에 IdM 서버 이름을 작성하여 IdM 웹 UI로 이동합니다. Insecure Connection 경고 페이지에서
Advanced
를 클릭합니다.그림 11.3. 비보안 연결
예외를 추가합니다
.View
를 클릭합니다.그림 11.4. 인증서 세부 정보 보기
Details
(세부 정보) 탭에서Certificate Authority
필드를 강조 표시합니다.그림 11.5. CA 인증서 내보내기
-
CertificateAuthority.crt
파일과 같은 CA 인증서를 저장한 다음 를 클릭하고 클릭합니다. . 예를 들어
IdM CA 인증서를 신뢰할 수 있는 인증 기관 인증서로 Firefox로 가져옵니다.
Firefox를 열고 기본 설정으로 이동하고
.그림 11.6. 기본 설정의 개인 정보 및 보안 섹션
그림 11.7. 개인 정보 보호 및 보안의 인증서 보기
-
Authorities
(권한) 탭에서 (가져오기)를 클릭합니다.CertificateAuthority.crt
파일에서 이전 단계에서 저장한 CA 인증서를 찾아서 엽니다. 인증서를 신뢰하여 웹 사이트를 식별한 다음 클릭합니다.
- Identity Management User로 인증서를 사용하여 ID 관리 웹 UI를 계속 인증합니다.
11.5. Identity Management User로 인증서를 사용하여 Identity Management 웹 UI에 인증
Identity Management 클라이언트의 데스크탑에 저장된 인증서를 사용하여 IdM(Identity Management) 웹 UI에 대한 사용자로 인증하려면 다음 절차를 따르십시오.
절차
-
브라우저에서 에서 ID 관리 웹 UI로 이동합니다(예:
https:
//server.idm.example.com/ipa/ui
). 그림 11.8. Identity Management 웹 UI에서
- 사용자 인증서가 이미 선택되어 있어야 합니다. .를 선택 해제한 다음 클릭합니다.
이제 인증서에 해당하는 사용자로 인증되었습니다.
11.6. 인증서를 사용하여 CLI에 인증할 수 있도록 IdM 클라이언트 구성
IdM 클라이언트의 CLI(명령줄 인터페이스)에서 IdM 사용자에 대한 인증서 인증을 수행하려면 IdM 사용자의 인증서 인증서 및 개인 키를 IdM 클라이언트에 가져옵니다. 사용자 인증서 생성 및 전송에 대한 자세한 내용은 새 사용자 인증서 요청 및 클라이언트로 내보내기를 참조하십시오.
절차
IdM 클라이언트에 로그인하고 사용자 인증서와 개인 키가 포함된 .p12 파일이 있어야 합니다. Kerberos 티켓 부여 티켓(TGT)을 가져오고 캐시하려면
X509_username:/path/to/file.p12
속성과 함께-X
옵션을 사용하여 사용자의 X509 ID 정보를 찾을 위치를 지정합니다.예를 들어
~/
파일에 저장된 사용자의 ID 정보를 사용하여 idm_user에 대한 TGT를 얻으려면 다음을 실행합니다.idm_user
.p12$ kinit -X X509_idm_user='PKCS12:~/idm_user.p12' idm_user
참고또한 이 명령은 .pem 파일 형식인 kinit -X X509_username='FILE:/path/to/cert.pem,/path/to/key' user_principal을 지원합니다.
12장. IdM CA 갱신 서버 사용
12.1. IdM CA 갱신 서버에 대한 설명
CA(인증 기관)를 사용하는 IdM(Identity Management) 배포에서 CA 갱신 서버는 IdM 시스템 인증서를 유지 관리하고 갱신합니다. 이를 통해 강력한 IdM 배포를 수행할 수 있습니다.
IdM 시스템 인증서는 다음과 같습니다.
-
IdM CA
인증서 -
OCSP
서명 인증서 -
IdM CA 하위 시스템
인증서 -
IdM CA 감사 서명
인증서 -
IdM 갱신 에이전트
(RA) 인증서 -
KRA
전송 및 스토리지 인증서
시스템 인증서를 특징으로 설정하는 것은 해당 키가 모든 CA 복제본에서 공유된다는 것입니다. 대조적으로 IdM 서비스 인증서(예: LDAP
,HTTP
및 PKINIT
인증서)에는 서로 다른 IdM CA 서버에서 키 쌍 및 제목 이름이 다릅니다.
IdM 토폴로지에서는 기본적으로 첫 번째 IdM CA 서버는 CA 갱신 서버입니다.
업스트림 설명서에서 IdM CA는 Dogtag
라고 합니다.
CA 갱신 서버의 역할
IdM 배포에 IdM CA
,IdM CA 하위 시스템
및 IdM RA
인증서가 중요합니다. 각 인증서는 /etc/pki/pki-tomcat/
디렉터리에 있는 NSS 데이터베이스에 저장되고 LDAP 데이터베이스 항목으로 저장됩니다. LDAP에 저장된 인증서는 NSS 데이터베이스에 저장된 인증서와 일치해야 합니다. 일치하지 않는 경우 IdM 프레임워크와 IdM CA 간에 인증 오류가 발생하고 IdM CA와 LDAP 간에 인증 오류가 발생합니다.
모든 IdM CA 복제본에는 모든 시스템 인증서에 대한 추적 요청이 있습니다. 통합 CA가 있는 IdM 배포에 CA 갱신 서버가 없는 경우 각 IdM CA 서버는 시스템 인증서 갱신을 독립적으로 요청합니다. 이로 인해 다양한 시스템 인증서 및 인증 오류가 발생하는 다른 CA 복제본이 발생합니다.
하나의 CA 복제본을 갱신 서버로 지정하면 필요에 따라 시스템 인증서를 정확히 한 번 갱신할 수 있으므로 인증 오류가 발생하지 않습니다.
CA 복제본에서 certmonger
서비스의 역할
모든 IdM CA 복제본에서 실행되는 certmonger
서비스는 dogtag-ipa-ca-renew-agent
갱신 도우미를 사용하여 IdM 시스템 인증서를 추적합니다. 갱신 도우미 프로그램은 CA 갱신 서버 구성을 읽습니다. CA 갱신 서버가 아닌 각 CA 복제본에서 갱신 도우미는 ca_renewal
LDAP 항목에서 최신 시스템 인증서를 검색합니다. 정확히 certmonger
갱신 시도가 발생할 때 발생하는 결정적이지 않기 때문에 dogtag-ipa-ca-renew-agent
도우미는 CA 갱신 서버가 인증서를 실제로 갱신하기 전에 시스템 인증서를 업데이트하려고 하는 경우가 있습니다. 이 경우 이전의 곧 만료되는 인증서가 CA 복제본의 certmonger
서비스로 반환됩니다. certmonger
서비스를 통해 이미 데이터베이스에 저장된 인증서와 동일한 인증서이며 CA 갱신 서버에서 업데이트된 인증서를 검색할 수 있을 때까지 개별 시도 사이에 일정 지연으로 인증서를 갱신하려고 합니다.
IdM CA 갱신 서버의 올바른 기능
포함된 CA가 있는 IdM 배포는 IdM CA와 함께 설치된 IdM 배포 또는 IdM CA 서버가 나중에 설치된 IdM 배포입니다. 포함된 CA가 포함된 IdM 배포에는 항상 하나의 CA 복제본이 갱신 서버로 구성되어 있어야 합니다. 갱신 서버는 온라인 상태여야 하며, 다른 서버와 함께 올바르게 복제해야 합니다.
ipa server-del
,ipa-replica-manage del
,ipa-csreplica-manage del
또는 ipa-server-install --uninstall
명령을 사용하여 현재 CA 갱신 서버가 삭제되면 다른 CA 복제본이 CA 갱신 서버로 자동으로 할당됩니다. 이 정책은 갱신 서버 구성이 유효한 상태로 유지됩니다.
이 정책은 다음 상황을 다루지 않습니다.
오프라인 갱신 서버
갱신 서버가 연장된 기간 동안 오프라인 상태인 경우 갱신 기간이 누락될 수 있습니다. 이 경우 인증서가 만료될 때까지 모든 갱신 CA 서버가 현재 시스템 인증서를 다시 설치합니다. 이 경우 만료된 인증서도 다른 인증서에 대해 갱신 오류가 발생할 수 있으므로 IdM 배포가 중단됩니다.
복제 문제
갱신 서버 및 기타 CA 복제본 간에 복제 문제가 있을 수 있지만 다른 CA 복제본은 만료되기 전에 업데이트된 인증서를 검색하지 못할 수 있습니다.
이러한 상황을 방지하려면 복제 계약이 올바르게 작동하는지 확인하십시오. 자세한 내용은 RHEL 7 Linux 도메인 ID, 인증 및 정책 가이드의 일반 또는 특정 복제 문제 해결 지침을 참조하십시오.
12.2. IdM CA 갱신 서버 변경 및 재설정
CA(인증 기관) 갱신 서버가 해제되는 경우 IdM(Identity Management)은 IdM CA 서버 목록에서 새 CA 갱신 서버를 자동으로 선택합니다. 시스템 관리자가 선택에 영향을 미칠 수 없습니다.
새 IdM CA 갱신 서버를 선택하려면 시스템 관리자가 수동으로 교체를 수행해야 합니다. 현재 갱신 서버를 해제하는 프로세스를 시작하기 전에 새 CA 갱신 서버를 선택합니다.
현재 CA 갱신 서버 구성이 유효하지 않으면 IdM CA 갱신 서버를 재설정합니다.
CA 갱신 서버를 변경하거나 재설정하려면 이 절차를 완료합니다.
사전 요구 사항
- IdM 관리자 인증 정보가 있습니다.
절차
IdM 관리자 자격 증명을 가져옵니다.
~]$ kinit admin Password for admin@IDM.EXAMPLE.COM:
선택 사항: 배포에 있는 IdM 서버에 새 CA 갱신 서버가 되는 데 필요한 CA 역할이 있는지 확인하려면 다음을 수행합니다.
~]$ ipa server-role-find --role 'CA server' ---------------------- 2 server roles matched ---------------------- Server name: server.idm.example.com Role name: CA server Role status: enabled Server name: replica.idm.example.com Role name: CA server Role status: enabled ---------------------------- Number of entries returned 2 ----------------------------
배포에는 두 개의 CA 서버가 있습니다.
optionALL: 현재 CA 갱신 서버인 CA 서버를 확인하려면 다음을 입력합니다.
~]$ ipa config-show | grep 'CA renewal' IPA CA renewal master: server.idm.example.com
현재 갱신 서버는
server.idm.example.com
입니다.갱신 서버 구성을 변경하려면
--ca-renewal-master-server
옵션과 함께ipa config-mod
유틸리티를 사용합니다.~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal' IPA CA renewal master: replica.idm.example.com
중요다음을 사용하여 새 CA 갱신 서버로 전환할 수도 있습니다.
-
ipa-cacert-manage --renew
명령. 이 명령은 둘 다 CA 인증서를 갱신 하고 새 CA 갱신 서버를 실행하는 CA 서버를 만듭니다. ipa-cert-fix
명령 이 명령은 만료된 인증서로 인해 오류가 발생하면 배포를 복구합니다. 또한 명령을 새 CA 갱신 서버로 실행하는 CA 서버를 만듭니다.자세한 내용은 IdM이 오프라인인 경우 만료된 시스템 인증서 갱신을 참조하십시오.
-
13장. 외부 서명된 CA 인증서 관리
IdM(Identity Management)은 다양한 유형의 CA(인증 기관) 구성을 제공합니다. 통합 CA 또는 외부 CA를 사용하여 IdM을 설치하도록 선택할 수 있습니다. 설치 중에 사용 중인 CA 유형을 지정해야 합니다. 그러나 설치한 후에는 외부 서명된 CA에서 자체 서명된 CA로 이동할 수 있으며 그 반대의 경우도 마찬가지입니다. 또한 자체 서명된 CA가 자동으로 갱신되는 동안 외부 서명된 CA 인증서를 갱신해야 합니다. 외부 서명된 CA 인증서를 관리하는 데 필요한 관련 섹션을 참조하십시오.
외부 서명된 CA를 사용하여 IdM 설치:
- 외부 서명된 CA에서 자체 서명된 CA로 전환합니다.
- 자체 서명된 CA에서 외부 서명된 CA로 전환합니다.
- 외부 서명된 CA 인증서 업데이트.
13.1. 외부에서 서명된 IdM의 CA로 전환
외부에 서명된 IdM(Identity Management) 인증 기관(CA)의 자체 서명된 인증서로 전환하려면 이 절차를 완료합니다. 자체 서명된 CA에서는 CA 인증서 갱신이 자동으로 관리됩니다. 시스템 관리자는 CSR(인증서 서명 요청)을 외부 기관에 제출할 필요가 없습니다.
외부에 서명된 자체 서명된 CA로 전환하면 CA 인증서만 대체됩니다. 이전 CA에서 서명한 인증서는 계속 유효하며 여전히 사용 중입니다. 예를 들어 자체 서명된 CA로 이동한 후에도 LDAP
인증서의 인증서 체인은 변경되지 않고 유지됩니다.
external_CA
certificate >IdM CA
certificate >LDAP
certificate
사전 요구 사항
-
IdM CA 갱신 서버 및 모든 IdM 클라이언트 및 서버에 대한
루트
액세스 권한이 있습니다.
절차
IdM CA 갱신 서버에서 CA 인증서를 자체 서명으로 갱신합니다.
# ipa-cacert-manage renew --self-signed Renewing CA certificate, please wait CA certificate successfully renewed The ipa-cacert-manage command was successful
나머지 IdM 서버 및 클라이언트에
root
로SSH
를 수행합니다. 예를 들어 다음과 같습니다.# ssh root@idmclient01.idm.example.com
IdM 클라이언트에서 서버의 인증서로 로컬 IdM 인증서 데이터베이스를 업데이트합니다.
[idmclient01 ~]# ipa-certupdate Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
검증
업데이트가 성공했는지 확인하고 새 CA 인증서가
/etc/ipa/ca.crt
파일에 추가되었습니다.[idmclient01 ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout [...] Certificate: Data: Version: 3 (0x2) Serial Number: 39 (0x27) Signature Algorithm: sha256WithRSAEncryption Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority Validity Not Before: Jul 1 16:32:45 2019 GMT Not After : Jul 1 16:32:45 2039 GMT Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority [...]
새 CA 인증서가 이전 CA 인증서를 사용하여 나열되므로 출력에 업데이트가 성공한 것으로 표시됩니다.
13.2. 자체 서명된 CA에서 IdM의 외부 서명된 CA로 전환
자체 서명된 CA에서 IdM의 외부 서명된 CA로 전환할 수 있습니다. IdM에서 외부 서명된 CA로 전환하면 IdM CA 서버가 외부 CA의 하위 CA가 됩니다. 또한 CA 인증서 갱신이 자동으로 관리되지 않으며 시스템 관리자가 CSR(인증서 서명 요청)을 외부 기관에 제출해야 합니다.
외부 서명된 CA로 전환하려면 외부 CA에서 CSR에 서명해야 합니다. 외부 CA를 사용하여 IdM CA 업데이트 서버 인증서 업데이트 단계에 따라 IdM에서 자체 서명된 CA 로 전환합니다.
13.3. 외부 CA를 사용하여 IdM CA 갱신 서버 인증서 업데이트
다음 절차에 따라 외부 CA를 사용하여 CSR(인증서 서명 요청)에 서명하는 IdM(Identity Management) 인증 기관(CA) 인증서를 갱신합니다. 이 구성에서 IdM CA 서버는 외부 CA의 하위 CA입니다. 외부 CA는 AD CS(Active Directory 인증서 서버)일 수 있지만 반드시 필요한 것은 아닙니다.
외부 인증 기관이 AD CS인 경우 CSR에서 IdM CA 인증서에 원하는 템플릿을 지정할 수 있습니다. 인증서 템플릿은 인증서 요청이 수신될 때 CA에서 사용하는 정책 및 규칙을 정의합니다. AD의 인증서 템플릿은 IdM의 인증서 프로필에 해당합니다.
OID(Object Identifier)를 통해 특정 AD CS 템플릿을 정의할 수 있습니다. OIDS는 분산 애플리케이션의 데이터 요소, 구문 및 기타 부분을 고유하게 식별하기 위해 다양한 발행 기관에서 발행한 고유한 숫자 값입니다.
또는 특정 AD CS 템플릿을 이름으로 정의할 수 있습니다. 예를 들어 IdM CA가 AD CS에 제출한 CSR에 사용된 기본 프로필 이름은 subCA
입니다.
CSR에서 OID 또는 이름을 지정하여 프로필을 정의하려면 external-ca-profile
옵션을 사용합니다. 자세한 내용은 시스템의 ipa-cacert-manage
도움말 페이지를 참조하십시오.
미리 작성된 인증서 템플릿을 사용하는 것 외에도 AD CS에 사용자 지정 인증서 템플릿을 생성하고 CSR에서 사용할 수도 있습니다.
사전 요구 사항
- IdM CA 갱신 서버에 대한 루트 액세스 권한이 있습니다.
절차
현재 CA 인증서가 자체 서명되었는지 여부에 관계없이 IdM CA의 인증서를 외부 서명으로 갱신하려면 이 절차를 완료합니다.
외부 CA에 제출할 CSR을 생성합니다.
외부 CA가 AD CS인 경우
--external-ca-type=ms-cs
옵션을 사용합니다. 기본subCA
템플릿과 다른 템플릿을 원하는 경우--external-ca-profile
옵션을 사용하여 지정합니다.~]#
ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
Exporting CA certificate signing request, please wait The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as: ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate The ipa-cacert-manage command was successful외부 CA가 AD CS가 아닌 경우:
~]#
ipa-cacert-manage renew --external-ca
Exporting CA certificate signing request, please wait The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as: ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate The ipa-cacert-manage command was successful출력은 CSR이 생성되었으며
/var/lib/ipa/ca.csr
파일에 저장되어 있음을 보여줍니다.
-
/var/lib/ipa/ca.csr
에 있는 CSR을 외부 CA에 제출합니다. 이 프로세스는 외부 CA로 사용할 서비스에 따라 다릅니다. 발행된 인증서와 권한 있는 Blob에 대해 발행된 CA의 CA 인증서 체인(CA 인증서 체인)을 검색합니다.
- 외부 CA가 AD CS가 아닌 경우 PEM 파일입니다.
외부 CA가 AD CS인 경우 Base_64 인증서입니다.
이 프로세스는 모든 인증서 서비스에 따라 다릅니다. 일반적으로 웹 페이지 또는 알림 이메일의 다운로드 링크를 사용하면 관리자가 필요한 모든 인증서를 다운로드할 수 있습니다.
외부 CA가 AD CS이고 Microsoft Windows 인증 기관 관리 창을 통해 알려진 템플릿이 있는 CSR을 제출한 경우 AD CS가 인증서를 즉시 발행하고 Save Certificate 대화 상자가 AD CS 웹 인터페이스에 표시되어 발급된 인증서를 저장할 위치를 묻는 메시지가 표시됩니다.
ipa-cacert-manage renew
명령을 다시 실행하여 전체 인증서 체인을 제공하는 데 필요한 모든 CA 인증서 파일을 추가합니다.--external-cert-file
옵션을 여러 번 사용하여 필요한 만큼 파일을 지정합니다.~]#
ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2
모든 IdM 서버 및 클라이언트에서 서버의 인증서로 로컬 IdM 인증서 데이터베이스를 업데이트합니다.
[client ~]$ ipa-certupdate Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
검증
업데이트가 성공했는지 확인하고 새 CA 인증서가
/etc/ipa/ca.crt
파일에 추가되었습니다.[client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout [...] Certificate: Data: Version: 3 (0x2) Serial Number: 39 (0x27) Signature Algorithm: sha256WithRSAEncryption Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority Validity Not Before: Jul 1 16:32:45 2019 GMT Not After : Jul 1 16:32:45 2039 GMT Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority [...]
새 CA 인증서가 이전 CA 인증서를 사용하여 나열되므로 출력에 업데이트가 성공한 것으로 표시됩니다.
14장. IdM이 오프라인 상태일 때 만료된 시스템 인증서 갱신
시스템 인증서가 만료된 경우 IdM(Identity Management)이 시작되지 않습니다. IdM은 ipa-cert-fix
툴을 사용하여 이 경우에도 시스템 인증서 갱신을 지원합니다.
-
호스트에
ipactl start --ignore-service-failures
명령을 입력하여 LDAP 서비스가 실행 중인지 확인합니다.
14.1. CA 갱신 서버에서 만료된 시스템 인증서 갱신
만료된 IdM 인증서에 ipa-cert-fix
툴을 적용하려면 다음 절차를 따르십시오.
CA 갱신 서버가 아닌 CA(Certificate Authority) 호스트에서 ipa-cert-fix
툴을 실행하고 유틸리티가 공유 인증서를 갱신하는 경우 해당 호스트는 도메인의 새 CA 갱신 서버가 자동으로 됩니다. 불일치를 방지하려면 도메인에 항상 하나의 CA 갱신 서버만 있어야 합니다.
사전 요구 사항
- 관리 권한이 있는 서버에 로그인합니다.
절차
-
선택 사항: 시스템을 백업합니다.
ipa-cert-fix
가nssdbs
에 대한 되돌릴 수 없는 변경을 수행하기 때문에 이는 매우 권장됩니다.ipa-cert-fix
도 LDAP를 변경하므로 전체 클러스터를 백업하는 것이 좋습니다. ipa-cert-fix
툴을 시작하여 시스템을 분석하고 갱신이 필요한 만료된 인증서를 나열합니다.# ipa-cert-fix ... The following certificates will be renewed: Dogtag sslserver certificate: Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205 Serial: 13 Expires: 2019-05-12 05:55:47 ... Enter "yes" to proceed:
yes
를 입력하여 갱신 프로세스를 시작합니다.Enter "yes" to proceed: true Proceeding. Renewed Dogtag sslserver certificate: Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205 Serial: 268369925 Expires: 2021-08-14 02:19:33 ... Becoming renewal master. The ipa-cert-fix command was successful
ipa-cert-fix
가 만료된 모든 인증서를 갱신하기까지 최대 1분 정도 걸릴 수 있습니다.
검증
모든 서비스가 실행 중인지 확인합니다.
# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful
이 시점에서 인증서가 갱신되어 서비스가 실행됩니다. 다음 단계는 IdM 도메인의 다른 서버를 확인하는 것입니다.
여러 CA 서버에서 인증서를 복구해야 하는 경우:
-
토폴로지에서 LDAP 복제가 작동하는지 확인한 후 먼저 위 절차에 따라 하나의 CA 서버에서
ipa-cert-fix
를 실행합니다. -
다른 CA 서버에서
ipa-cert-fix
를 실행하기 전에, 공유 인증서의 불필요한 갱신을 방지하기 위해getcert-resubmit
(다른 CA 서버의 경우)을 통해 공유 인증서에 대한 Certmonger 갱신을 트리거합니다.
14.2. 갱신 후 IdM 도메인의 다른 IdM 서버 확인
ipa-cert-fix
툴을 사용하여 CA 갱신 서버의 인증서를 갱신한 후 다음을 수행해야 합니다.
- 도메인에서 다른 모든 IdM(Identity Management) 서버를 재시작합니다.
- certmonger에서 인증서를 갱신했는지 확인합니다.
-
만료된 시스템 인증서가 있는 다른 CA(인증 기관) 복제본이 있는 경우
ipa-cert-fix
툴을 사용하여 해당 인증서를 갱신합니다.
사전 요구 사항
- 관리 권한을 사용하여 서버에 로그인합니다.
절차
--force
매개변수를 사용하여 IdM을 다시 시작합니다.# ipactl restart --force
--force
매개변수를 사용하면ipactl
유틸리티에서 개별 서비스 시작 실패를 무시합니다. 예를 들어 서버가 만료된 인증서가 있는 CA인 경우pki-tomcat
서비스가 시작되지 않습니다. 이는--force
매개변수를 사용하므로 예상되고 무시됩니다.다시 시작한 후
certmonger
서비스가 인증서를 갱신했는지 확인합니다(인증서 상태가 MONITORING으로 표시됨).# getcert list | egrep '^Request|status:|subject:' Request ID '20190522120745': status: MONITORING subject: CN=IPA RA,O=EXAMPLE.COM 201905222205 Request ID '20190522120834': status: MONITORING subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205 ...
certmonger
가 복제본의 공유 인증서를 갱신하는 데 다소 시간이 걸릴 수 있습니다.서버가 CA이기도 한 경우 이전 명령은
pki-tomcat
서비스에서 사용하는 인증서에CA_UNREACHABLE
을 보고합니다.Request ID '20190522120835': status: CA_UNREACHABLE subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205 ...
이 인증서를 갱신하려면
ipa-cert-fix
유틸리티를 사용하십시오.# ipa-cert-fix Dogtag sslserver certificate: Subject: CN=ca2.example.com,O=EXAMPLE.COM Serial: 3 Expires: 2019-05-11 12:07:11 Enter "yes" to proceed: true Proceeding. Renewed Dogtag sslserver certificate: Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205 Serial: 15 Expires: 2019-08-14 04:25:05 The ipa-cert-fix command was successful
이제 모든 IdM 인증서가 갱신되어 올바르게 작동합니다.
15장. IdM 복제본에서 웹 서버 및 LDAP 서버 인증서가 아직 만료되지 않은 경우 교체
IdM(Identity Management) 시스템 관리자는 IdM 서버에서 실행되는 웹(또는 httpd
) 및 LDAP(또는 디렉터리) 서비스의 인증서를 수동으로 교체할 수 있습니다. 예를 들어 인증서가 만료되고
certmonger
유틸리티가 인증서를 자동으로 갱신하지 않거나 인증서가 외부 CA(인증 기관)에 의해 서명되는 경우 이 작업이 필요할 수 있습니다.
이 예제에서는 server.idm.example.com IdM 서버에서 실행되는 서비스의 인증서를 설치합니다. 외부 CA에서 인증서를 가져옵니다.
HTTP 및 LDAP 서비스 인증서에는 서로 다른 IdM 서버의 키 쌍과 주체 이름이 다르므로 각 IdM 서버에서 인증서를 개별적으로 업데이트해야 합니다.
사전 요구 사항
-
IdM 서버에 복제 계약이 있는 토폴로지의 다른 하나 이상의 IdM 복제본에서는 웹 및 LDAP 인증서가 계속 유효합니다.
ipa-server-certinstall
명령에 대한 사전 요구 사항입니다. 명령에는 다른 IdM 복제본과 통신하려면TLS
연결이 필요합니다. 그러나 유효하지 않은 인증서에서는 이러한 연결을 설정할 수 없으며ipa-server-certinstall
명령이 실패했습니다. 이 경우 전체 IdM 배포에 만료된 경우 웹 서버 및 LDAP 서버 인증서 교체를 참조하십시오. -
IdM 서버에 대한
루트
액세스 권한이 있습니다. -
Directory Manager
암호를 알고 있습니다. - 외부 CA의 CA 인증서 체인을 저장하는 파일에 액세스할 수 있습니다. ca_certificate_chain_file.crt.
절차
IdM에 대한 추가 CA 인증서로 ca_certificate_chain_file.crt 에 포함된 인증서를 설치합니다.
# ipa-cacert-manage install
ca_certicate_chain_file.crt 의 인증서로 로컬 IdM 인증서 데이터베이스를 업데이트합니다.
# ipa-certupdate
OpenSSL
유틸리티를 사용하여 개인 키와 CSR(인증서 서명 요청)을 생성합니다.$ openssl req -new -newkey rsa:4096 -days 365 -nodes -keyout new.key -out new.csr -addext "subjectAltName = DNS:server.idm.example.com" -subj '/CN=server.idm.example.com,O=IDM.EXAMPLE.COM'
CSR을 외부 CA에 제출합니다. 이 프로세스는 외부 CA로 사용할 서비스에 따라 다릅니다. CA가 인증서에 서명한 후 인증서를 IdM 서버로 가져옵니다.
IdM 서버에서 Apache 웹 서버의 이전 개인 키와 인증서를 새 키 및 새로 서명된 인증서로 교체합니다.
# ipa-server-certinstall -w --pin=password new.key new.crt
위의 명령에서:
-
-w
옵션은 웹 서버에 인증서를 설치하도록 지정합니다. -
pin
옵션은 개인 키를 보호하는 암호를 지정합니다.
-
-
메시지가 표시되면
Directory Manager
암호를 입력합니다. LDAP 서버의 이전 개인 키와 인증서를 새 키 및 새로 서명된 인증서로 바꿉니다.
# ipa-server-certinstall -d --pin=password new.key new.cert
위의 명령에서:
-
d
옵션은 LDAP 서버에 인증서를 설치하도록 지정합니다. -
pin
옵션은 개인 키를 보호하는 암호를 지정합니다.
-
-
메시지가 표시되면
Directory Manager
암호를 입력합니다. httpd
서비스를 다시 시작합니다.# systemctl restart httpd.service
Directory
서비스를 다시 시작하십시오.# systemctl restart dirsrv@IDM.EXAMPLE.COM.service
서버에서 하위 CA가 제거되거나 교체된 경우 클라이언트를 업데이트합니다.
# ipa-certupdate
추가 리소스
- IdM과 작동하도록 인증서 형식 변환
-
시스템의
ipa-server-certinstall(1)
매뉴얼 페이지
16장. 웹 서버 및 LDAP 서버 인증서가 전체 IdM 배포에 만료된 경우 교체
IdM(Identity Management)은 다음 서비스 인증서를 사용합니다.
-
LDAP(또는
디렉터리
) 서버 인증서 -
웹(또는
httpd
) 서버 인증서 - PKINIT 인증서
CA가 없는 IdM 배포에서 certmonger
는 기본적으로 IdM 서비스 인증서를 추적하거나 만료에 대한 알림을 받지 않습니다. IdM 시스템 관리자가 이러한 인증서에 대한 알림을 수동으로 설정하지 않거나 인증서를 추적하도록 certmonger
를 구성하지 않으면 인증서가 통지 없이 만료됩니다.
server.idm.example.com IdM 서버에서 실행 중인 httpd
및 LDAP 서비스에 대해 만료된 인증서를 수동으로 교체하려면 다음 절차를 따르십시오.
HTTP 및 LDAP 서비스 인증서에는 서로 다른 IdM 서버에 다른 키 쌍과 주체 이름이 있습니다. 따라서 각 IdM 서버의 인증서를 개별적으로 갱신해야 합니다.
사전 요구 사항
- HTTP 및 LDAP 인증서는 토폴로지의 모든 IdM 복제본에서 만료되었습니다. 그러지 않은 경우 IdM 복제본에 아직 만료되지 않은 경우 웹 서버 및 LDAP 서버 인증서 교체를 참조하십시오.
-
IdM 서버 및 복제본에 대한
루트
액세스 권한이 있어야 합니다. -
Directory Manager
암호를 알고 있습니다. 다음 디렉터리 및 파일의 백업을 생성했습니다.
-
/etc/dirsrv/slapd-IDM-EXAMPLE-COM/
-
/etc/httpd/alias
-
/var/lib/certmonger
-
/var/lib/ipa/certs/
-
절차
-
선택 사항:
/var/lib/ipa/private
및 /var/lib/ipa/passwds의
백업을 수행합니다. 동일한 CA를 사용하여 새 인증서에 서명하지 않거나 이미 설치된 CA 인증서가 더 이상 유효하지 않은 경우 외부 CA의 유효한 CA 인증서 체인이 포함된 파일로 로컬 데이터베이스의 외부 CA에 대한 정보를 업데이트합니다. 이 파일은 PEM 및 DER 인증서, PKCS#7 인증서 체인, PKCS##8 및 원시 개인 키, PKCS#12 형식으로 허용됩니다.
추가 CA 인증서로 ca_certificate_chain_file.crt 에서 사용 가능한 인증서를 IdM에 설치합니다.
# ipa-cacert-manage install ca_certificate_chain_file.crt
ca_certicate_chain_file.crt 의 인증서로 로컬 IdM 인증서 데이터베이스를 업데이트합니다.
# ipa-certupdate
httpd
및 LDAP에 대한 인증서를 요청합니다.OpenSSL
유틸리티를 사용하여 IdM 인스턴스에서 타사 CA로 실행되는 Apache 웹 서버에 대한 CSR(인증서 서명 요청)을 생성합니다.새 개인 키 생성은 선택 사항입니다. 원래 개인 키가 여전히 있는 경우
openssl req
명령과 함께-in
옵션을 사용하여 요청을 읽을 입력 파일 이름을 지정할 수 있습니다.$ openssl req -new -nodes -in /var/lib/ipa/private/httpd.key -out /tmp/http.csr -addext 'subjectAltName = DNS:_server.idm.example.com_, otherName:1.3.6.1.4.1.311.20.2.3;UTF8:HTTP/server.idm.example.com@IDM.EXAMPLE.COM' -subj '/O=IDM.EXAMPLE.COM/CN=server.idm.example.com'
새 키를 생성하려면 다음을 수행합니다.
$ openssl req -new -newkey rsa:2048 -nodes -keyout /var/lib/ipa/private/httpd.key -out /tmp/http.csr -addext 'subjectAltName = DNS:server.idm.example.com, otherName:1.3.6.1.4.1.311.20.2.3;UTF8:HTTP/server.idm.example.com@IDM.EXAMPLE.COM' -subj '/O=IDM.EXAMPLE.COM/CN=server.idm.example.com'
OpenSSL
유틸리티를 사용하여 타사 CA에 대한 IdM 인스턴스에서 실행되는 LDAP 서버에 대한 CSR(인증서 서명 요청)을 생성합니다.$ openssl req -new -newkey rsa:2048 -nodes -keyout ~/ldap.key -out /tmp/ldap.csr -addext 'subjectAltName = DNS:server.idm.example.com, otherName:1.3.6.1.4.1.311.20.2.3;UTF8:ldap/server.idm.example.com@IDM.EXAMPLE.COM' -subj '/O=IDM.EXAMPLE.COM/CN=server.idm.example.com'
-
CSRs, /tmp/http.csr 및 tmp/ldap.csr 를 외부 CA에 제출하고
httpd
의 인증서와 LDAP의 인증서를 가져옵니다. 이 프로세스는 외부 CA로 사용할 서비스에 따라 다릅니다.
httpd
인증서 설치 :# cp /path/to/httpd.crt /var/lib/ipa/certs/
LDAP 인증서를 NSS 데이터베이스에 설치합니다.
선택 사항: 사용 가능한 인증서를 나열합니다.
# certutil -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u
기본 인증서 닉네임은 Server-Cert 이지만 다른 이름을 적용할 수 있습니다.
이전 단계에서 인증서 nickname을 사용하여 NSSDB(
NSSDB
)에서 유효하지 않은 이전 인증서를 제거합니다.# certutil -D -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -n 'Server-Cert' -f /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
NSSDB
로 가져오기 프로세스를 쉽게 하기 위해 PKCS12 파일을 만듭니다.# openssl pkcs12 -export -in ldap.crt -inkey ldap.key -out ldap.p12 -name Server-Cert
생성된 PKCS#12 파일을
NSSDB
에 설치합니다.# pk12util -i ldap.p12 -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -k /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
새 인증서를 성공적으로 가져왔는지 확인합니다.
# certutil -L -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/
httpd
서비스를 다시 시작합니다.# systemctl restart httpd.service
Directory
서비스를 다시 시작하십시오.# systemctl restart dirsrv@IDM-EXAMPLE-COM.service
-
모든 IdM 복제본에서 이전 단계를 모두 수행합니다. 이는 복제본 간
TLS
연결을 설정하기 위한 사전 요구 사항입니다. LDAP 스토리지에 새 인증서를 등록합니다.
Apache 웹 서버의 이전 개인 키와 인증서를 새 키 및 새로 서명된 인증서로 교체합니다.
# ipa-server-certinstall -w --pin=password /var/lib/ipa/private/httpd.key /var/lib/ipa/certs/httpd.crt
위의 명령에서:
-
-w
옵션은 웹 서버에 인증서를 설치하도록 지정합니다. -
pin
옵션은 개인 키를 보호하는 암호를 지정합니다.
-
-
메시지가 표시되면
Directory Manager
암호를 입력합니다. LDAP 서버의 이전 개인 키와 인증서를 새 키 및 새로 서명된 인증서로 바꿉니다.
# ipa-server-certinstall -d --pin=password /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ldap.key /path/to/ldap.crt
위의 명령에서:
-
d
옵션은 LDAP 서버에 인증서를 설치하도록 지정합니다. -
pin
옵션은 개인 키를 보호하는 암호를 지정합니다.
-
-
메시지가 표시되면
Directory Manager
암호를 입력합니다. httpd
서비스를 다시 시작합니다.# systemctl restart httpd.service
Directory
서비스를 다시 시작하십시오.# systemctl restart dirsrv@IDM-EXAMPLE-COM.service
- 영향을 받는 다른 모든 복제본에서 이전 단계의 명령을 실행합니다.
추가 리소스
- IdM과 작동하도록 인증서 형식 변환
-
man
ipa-server-certinstall(1)
- 만료된 후 RHEL 8에서 IPA(Identity Management) 인증서를 수동으로 갱신하려면 어떻게 해야 합니까? (CA가 없는 IPA)
17장. IdM CA 서버에서 CRL 생성
IdM 배포 시 포함된 CA(인증 기관)를 사용하는 경우 하나의 IdM(Identity Management) 서버에서 다른 IdM(Identity Management)으로 CRL(Certificate Revocation List)을 생성해야 할 수도 있습니다. 예를 들어 서버를 다른 시스템으로 마이그레이션하려는 경우 필요할 수 있습니다.
CRL을 생성하도록 하나의 서버만 구성합니다. CRL 게시자 역할을 수행하는 IdM 서버는 일반적으로 CA 갱신 서버 역할을 수행하는 동일한 서버이지만 필수는 아닙니다. CRL 게시자 서버를 해제하기 전에 CRL 게시자 서버 역할을 수행하도록 다른 서버를 선택하고 구성하십시오.
17.1. IdM 서버에서 CRL 생성 중지
IdM CRL 게시자 서버에서 CRL(Certificate Revocation List) 생성을 중지하려면 ipa-crlgen-manage
명령을 사용합니다. 생성을 비활성화하기 전에 서버가 실제로 CRL을 생성하는지 확인합니다. 그러면 비활성화할 수 있습니다.
사전 요구 사항
- root로 로그인해야 합니다.
절차
서버가 CRL을 생성 중인지 확인합니다.
[root@server ~]# ipa-crlgen-manage status CRL generation: enabled Last CRL update: 2019-10-31 12:00:00 Last CRL Number: 6 The ipa-crlgen-manage command was successful
서버에서 CRL 생성을 중지합니다.
[root@server ~]# ipa-crlgen-manage disable Stopping pki-tomcatd Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg Starting pki-tomcatd Editing /etc/httpd/conf.d/ipa-pki-proxy.conf Restarting httpd CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable. The ipa-crlgen-manage command was successful
서버가 CRL 생성을 중지했는지 확인합니다.
[root@server ~]# ipa-crlgen-manage status
서버가 CRL 생성을 중지했습니다. 다음 단계는 IdM 복제본에서 CRL 생성을 활성화하는 것입니다.
17.2. IdM 복제본 서버에서 CRL 생성 시작
ipa-crlgen-manage
명령을 사용하여 IdM CA 서버에서 CRL(Certificate Revocation List)을 생성할 수 있습니다.
사전 요구 사항
- RHEL 시스템은 IdM 인증 기관 서버여야 합니다.
- root로 로그인해야 합니다.
절차
CRL 생성을 시작합니다.
[root@replica1 ~]# ipa-crlgen-manage enable Stopping pki-tomcatd Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg Starting pki-tomcatd Editing /etc/httpd/conf.d/ipa-pki-proxy.conf Restarting httpd Forcing CRL update CRL generation enabled on the local host. Please make sure to have only a single CRL generation master. The ipa-crlgen-manage command was successful
CRL이 생성되었는지 확인합니다.
[root@replica1 ~]# ipa-crlgen-manage status CRL generation: enabled Last CRL update: 2019-10-31 12:10:00 Last CRL Number: 7 The ipa-crlgen-manage command was successful
17.3. CRL 업데이트 간격 변경
CRL(Certificate Revocation List) 파일은 기본적으로 4시간마다 IdM(Identity Management Certificate Authority)에 의해 자동으로 생성됩니다. 다음 절차에 따라 이 간격을 변경할 수 있습니다.
절차
CRL 생성 서버를 중지합니다.
# systemctl stop pki-tomcatd@pki-tomcat.service
/var/lib/pki/pki-tomcat/conf/ca/CS.cfg
파일을 열고ca.crl.MasterCRL.autoUpdateInterval
값을 새 간격 설정으로 변경합니다. 예를 들어 60분마다 CRL을 생성하려면 다음을 수행합니다.ca.crl.MasterCRL.autoUpdateInterval=60
참고ca.crl.MasterCRL.autoUpdateInterval
매개변수를 업데이트하면 이미 예약된 CRL 업데이트 후에 변경 사항이 적용됩니다.CRL 생성 서버를 시작합니다.
# systemctl start pki-tomcatd@pki-tomcat.service
추가 리소스
- IdM 복제본 서버의 CRL 생성에 대한 자세한 내용은 IdM 복제본 서버에서 CRL 생성 시작을 참조하십시오.
18장. CA 갱신 서버 및 CRL 게시자 역할을 수행하는 서버 해제
CA(인증 기관) 갱신 서버 역할과 CRL(Certificate Revocation List) 게시자 역할을 모두 수행하는 하나의 서버가 있을 수 있습니다. 이 서버를 오프라인으로 전환하거나 해제해야 하는 경우 다른 CA 서버를 선택하고 구성하여 이러한 역할을 수행합니다.
이 예에서는 CA 갱신 서버 및 CRL 게시자 역할을 수행하는 호스트 server.idm.example.com
을 해제해야 합니다. 이 절차에서는 CA 갱신 서버 및 CRL 게시자 역할을 호스트 replica.idm.example.com
에 전송하고 IdM 환경에서 server.idm.example.com
을 제거합니다.
CA 갱신 서버 및 CRL 게시자 역할을 모두 수행하도록 동일한 서버를 구성할 필요가 없습니다.
사전 요구 사항
- IdM 관리자 인증 정보가 있습니다.
- 해제 중인 서버의 루트 암호가 있습니다.
- IdM 환경에 두 개 이상의 CA 복제본이 있습니다.
절차
IdM 관리자 자격 증명을 가져옵니다.
[user@server ~]$ kinit admin Password for admin@IDM.EXAMPLE.COM:
선택 사항: CA 갱신 서버 및 CRL 게시자 역할을 수행하는 서버가 확실하지 않은 경우:
현재 CA 갱신 서버를 표시합니다. IdM 서버에서 다음 명령을 실행할 수 있습니다.
[user@server ~]$ ipa config-show | grep 'CA renewal' IPA CA renewal master: server.idm.example.com
호스트가 현재 CRL 게시자인지 테스트합니다.
[user@server ~]$ ipa-crlgen-manage status CRL generation: enabled Last CRL update: 2019-10-31 12:00:00 Last CRL Number: 6 The ipa-crlgen-manage command was successful
CRL을 생성하지 않는 CA 서버는
CRL 생성: disabled
를 표시합니다.[user@replica ~]$ ipa-crlgen-manage status CRL generation: disabled The ipa-crlgen-manage command was successful
CRL 게시자 서버를 찾을 때까지 CA 서버에 이 명령을 계속 입력합니다.
이러한 역할을 충족하도록 승격할 수 있는 다른 모든 CA 서버를 표시합니다. 이 환경에는 두 개의 CA 서버가 있습니다.
[user@server ~]$ ipa server-role-find --role 'CA server' ---------------------- 2 server roles matched ---------------------- Server name: server.idm.example.com Role name: CA server Role status: enabled Server name: replica.idm.example.com Role name: CA server Role status: enabled ---------------------------- Number of entries returned 2 ----------------------------
replica.idm.example.com
을 CA 갱신 서버로 설정합니다.[user@server ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com
server.idm.example.com
에서 :인증서 업데이트 프로그램 작업을 비활성화합니다.
[root@server ~]# pki-server ca-config-set ca.certStatusUpdateInterval 0
IdM 서비스를 다시 시작하십시오.
[root@server ~]# ipactl restart
replica.idm.example.com
에서 :인증서 업데이트 프로그램 작업을 활성화합니다.
[root@replica ~]# pki-server ca-config-unset ca.certStatusUpdateInterval
IdM 서비스를 다시 시작하십시오.
[root@replica ~]# ipactl restart
server.idm.example.com
에서 CRL 생성을 중지합니다.[user@server ~]$ ipa-crlgen-manage disable Stopping pki-tomcatd Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg Starting pki-tomcatd Editing /etc/httpd/conf.d/ipa-pki-proxy.conf Restarting httpd CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable. The ipa-crlgen-manage command was successful
replica.idm.example.com
에서 CRL 생성을 시작합니다.[user@replica ~]$ ipa-crlgen-manage enable Stopping pki-tomcatd Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg Starting pki-tomcatd Editing /etc/httpd/conf.d/ipa-pki-proxy.conf Restarting httpd Forcing CRL update CRL generation enabled on the local host. Please make sure to have only a single CRL generation master. The ipa-crlgen-manage command was successful
server.idm.example.com
에서 IdM 서비스를 중지합니다.[root@server ~]# ipactl stop
replica.idm.example.com
에서 IdM 환경에서server.idm.example.com
을 삭제합니다.[user@replica ~]$ ipa server-del server.idm.example.com
server.idm.example.com
에서ipa-server-install --uninstall
명령을 루트 계정으로 사용합니다.[root@server ~]# ipa-server-install --uninstall ... Are you sure you want to continue with the uninstall procedure? [no]: yes
검증
현재 CA 갱신 서버를 표시합니다.
[user@replica ~]$ ipa config-show | grep 'CA renewal' IPA CA renewal master: replica.idm.example.com
replica.idm.example.com
호스트에서 CRL을 생성하는지 확인합니다.[user@replica ~]$ ipa-crlgen-manage status CRL generation: enabled Last CRL update: 2019-10-31 12:10:00 Last CRL Number: 7 The ipa-crlgen-manage command was successful
19장. certmonger를 사용하여 서비스에 대한 IdM 인증서 가져오기
19.1. certmonger 개요
IdM(Identity Management)이 통합된 IdM 인증 기관(CA)과 함께 설치되면 certmonger
서비스를 사용하여 시스템 및 서비스 인증서를 추적하고 갱신합니다. 인증서가 만료일에 도달하면 certmonger
는 다음을 통해 갱신 프로세스를 관리합니다.
- 원래 요청에 제공된 옵션을 사용하여 CSR(인증서 서명 요청)을 다시 생성합니다.
-
IdM API
cert-request
명령을 사용하여 IdM CA에 CSR을 제출합니다. - IdM CA에서 인증서를 수신합니다.
- 원래 요청으로 지정된 경우 pre-save 명령을 실행합니다.
-
업데이트 요청에 지정된 위치에 새 인증서 설치:
NSS
데이터베이스 또는 파일. -
원래 요청에 의해 지정된 경우 post-save 명령을 실행합니다. 예를 들어 post-save 명령은 서비스가 새 인증서를 선택하도록
certmonger
에 관련 서비스를 재시작하도록 지시할 수 있습니다.
인증서 certmonger
트랙
인증서는 시스템 및 서비스 인증서로 나눌 수 있습니다.
서비스 인증서(예: HTTP
,LDAP
및 PKINIT
)와 달리, 서로 다른 서버에 키 쌍과 제목 이름이 다른 경우 IdM 시스템 인증서와 해당 키는 모든 CA 복제본에서 공유합니다. IdM 시스템 인증서는 다음과 같습니다.
-
IdM CA
인증서 -
OCSP
서명 인증서 -
IdM CA 하위 시스템
인증서 -
IdM CA 감사 서명
인증서 -
IdM 갱신 에이전트
(RA) 인증서 -
KRA
전송 및 스토리지 인증서
certmonger
서비스는 통합된 CA를 사용하여 IdM 환경 설치 중에 요청된 IdM 시스템 및 서비스 인증서를 추적합니다. certmonger는
IdM 호스트에서 실행되는 다른 서비스를 위해 시스템 관리자가 수동으로 요청한 인증서도 추적합니다. certmonger
는 외부 CA 인증서 또는 사용자 인증서를 추적하지 않습니다.
certmonger 구성 요소
certmonger
서비스는 두 가지 주요 구성 요소로 구성됩니다.
-
certmonger 데몬
- 인증서 목록을 추적하고 갱신 명령 시작 -
시스템 관리자가
certmonger
데몬에 적극적으로명령을 보낼 수 있는 CLI(명령줄 인터페이스
)용getcert
유틸리티입니다.
특히 시스템 관리자는 getcert
유틸리티를 사용하여 다음을 수행할 수 있습니다.
19.2. certmonger를 사용하여 서비스에 대한 IdM 인증서 가져오기
IdM(Identity Management) 클라이언트에서 실행되는 브라우저와 웹 서비스 간 통신이 안전하고 암호화되도록 하려면 TLS 인증서를 사용합니다. IdM CA(인증 기관)에서 웹 서비스의 TLS 인증서를 가져옵니다.
IdM 클라이언트에서 실행 중인 서비스의 IdM 인증서(HTTP/my_company.idm.example.com
@IDM.EXAMPLE.COM
)를 받으려면 certmonger
를 사용하십시오.
certmonger
를 사용하여 인증서를 자동으로 요청한다는 것은 certmonger
가 갱신이 발생할 때 인증서를 관리하고 갱신한다는 것을 의미합니다.
certmonger
가 서비스 인증서를 요청할 때 발생하는 상황을 시각적으로 표현하려면 19.3절. “서비스 인증서를 요청하는 certmonger의 통신 흐름” 을 참조하십시오.
사전 요구 사항
- 웹 서버는 IdM 클라이언트로 등록되어 있습니다.
- 프로시저를 실행 중인 IdM 클라이언트에 대한 루트 액세스 권한이 있습니다.
- 인증서를 요청하는 서비스는 IdM에 사전 존재할 필요가 없습니다.
절차
HTTP 서비스가 실행 중인
my_company.idm.example.com
IdM 클라이언트에서HTTP
/my_company.idm.example.com@IDM.EXAMPLE.COM-
인증서는 로컬
/etc/pki/tls/certs/httpd.pem
파일에 저장됩니다. -
개인 키는 로컬
/etc/pki/tls/private/httpd.key
파일에 저장해야 합니다. SubjectAltName
에 대한 extensionRequest가my_company.idm.example.com
의 DNS 이름을 사용하여 서명 요청에 추가됩니다.# ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -C "systemctl restart httpd" New signing request "20190604065735" added.
위의 명령에서:
-
ipa-getcert request
명령은 인증서를 IdM CA에서 가져올 수 있도록 지정합니다.ipa-getcert request
명령은getcert request -c IPA
의 바로 가기입니다. -
g
옵션은 아직 없는 경우 생성할 키 크기를 지정합니다. -
d 옵션은 요청에 추가할
SubjectAltName
DNS 값을 지정합니다. -
-C
옵션은 인증서를 가져온 후httpd
서비스를 다시 시작하도록certmonger
에 지시합니다.
-
특정 프로필로 인증서를 발행하도록 지정하려면
-T
옵션을 사용합니다. -
지정된 CA에서 이름이 지정된 발행자를 사용하여 인증서를 요청하려면
-X ISSUER
옵션을 사용합니다.
-
-
인증서는 로컬
선택 사항: 요청 상태를 확인하려면 다음을 수행합니다.
# ipa-getcert list -f /etc/pki/tls/certs/httpd.pem Number of certificates and requests being tracked: 3. Request ID '20190604065735': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key' certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt' CA: IPA [...]
출력은 요청이
MONITORING
상태에 있음을 보여줍니다. 즉, 인증서를 가져온 것입니다. 키 쌍과 인증서의 위치는 요청된 위치입니다.
19.3. 서비스 인증서를 요청하는 certmonger의 통신 흐름
이러한 다이어그램은 certmonger
에서 IdM(Identity Management) 인증 기관(CA) 서버에서 서비스 인증서를 요청할 때 발생하는 단계를 보여줍니다. 시퀀스는 다음 다이어그램으로 구성됩니다.
암호화되지 않은 통신 에서는 초기 상황을 보여줍니다. HTTPS 인증서가 없으면 웹 서버와 브라우저 간 통신이 암호화되지 않습니다.
그림 19.1. 암호화되지 않은 통신
서비스 인증서를 요청하는 certmonger 는 certmonger
를 사용하여 Apache 웹 서버에 대한 HTTPS 인증서를 수동으로 요청하는 시스템 관리자에게 보여줍니다. 웹 서버 인증서를 요청할 때 certmonger는 CA와 직접 통신하지 않습니다. IdM을 통해 프록시합니다.
그림 19.2. 서비스 인증서 요청
서비스 인증서를 발행하는 IdM CA는 웹 서버의 HTTPS 인증서를 발행하는 IdM CA를 보여줍니다.
그림 19.3. 서비스 인증서를 발급하는 IdM CA
서비스 인증서를 적용하는 certmonger
는 IdM 클라이언트의 적절한 위치에 HTTPS 인증서를 배치하고 이를 수행하라는 지침이 있는 certmonger를 사용하여 httpd
서비스를 다시 시작합니다. Apache 서버에서는 HTTPS 인증서를 사용하여 자체와 브라우저 간 트래픽을 암호화합니다.
그림 19.4. 서비스 인증서 적용
만료일이 다가오는 경우 certmonger에서 새 인증서를 요청하는 certmonger
가 인증서 만료 전에 IdM CA에서 서비스 인증서 갱신을 자동으로 요청합니다. IdM CA는 새 인증서를 발행합니다.
그림 19.5. certmonger에서 이전 인증서가 만료되는 경우 새 인증서를 요청합니다.
19.4. certmonger에서 추적한 인증서 요청의 세부 정보 보기
certmonger
서비스는 인증서 요청을 모니터링합니다. 인증서에 대한 요청이 성공적으로 서명되면 인증서가 생성됩니다. certmonger
는 결과 인증서를 포함하여 인증서 요청을 관리합니다. certmonger
에서 관리하는 특정 인증서 요청의 세부 정보를 보려면 다음 절차를 따르십시오.
절차
인증서 요청을 지정하는 방법을 알고 있는 경우 해당 특정 인증서 요청의 세부 사항만 나열합니다. 예를 들어 다음을 지정할 수 있습니다.
- 요청 ID
- 인증서의 위치
인증서 닉네임
예를 들어 요청 ID가 20190408146인 인증서의 세부 정보를 보려면
-v
옵션을 사용하여 인증서에 대한 요청이 실패한 경우 오류의 모든 세부 정보를 볼 수 있습니다.# getcert list -i 20190408143846 -v Number of certificates and requests being tracked: 16. Request ID '20190408143846': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IDM.EXAMPLE.COM subject: CN=r8server.idm.example.com,O=IDM.EXAMPLE.COM expires: 2021-04-08 16:38:47 CEST dns: r8server.idm.example.com principal name: ldap/server.idm.example.com@IDM.EXAMPLE.COM key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IDM-EXAMPLE-COM track: true auto-renew: true
출력에는 인증서에 대한 여러 정보가 표시됩니다. 예를 들면 다음과 같습니다.
-
위의 예에서 인증서 위치.
/etc/dirsrv/slapd-IDM-EXAMPLE-COM
디렉터리의 NSS 데이터베이스입니다. -
인증서 닉네임; 위의 예에서
Server-Cert
입니다. -
위 예제에서 핀을 저장하는 파일은
/etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
입니다. -
인증서를 갱신하는 데 사용할 CA(인증 기관)는
IPA
CA입니다. -
위의 예에서 만료 날짜는
2021-04-08 16:38:47 CEST
입니다. -
인증서 상태; 위의 예에서
MONITORING
상태는 인증서가 유효하고 추적됨을 나타냅니다. -
위의 예에서 post-save 명령은
LDAP
서비스를 다시 시작합니다.
인증서 요청을 지정하는 방법을 모르는 경우
certmonger
가 모니터링 중이거나 획득하려는 모든 인증서의 세부 정보를 나열합니다.# getcert list
추가 리소스
-
시스템의
getcert 목록
도움말 페이지를 참조하십시오.
19.5. 인증서 추적 시작 및 중지
getcert stop-tracking
및 getcert start-tracking
명령을 사용하여 인증서를 모니터링합니다. 두 명령은 certmonger
서비스에서 제공합니다. 인증서 추적을 활성화하면 IdM(Identity Management) 인증 기관(CA)에서 다른 IdM 클라이언트의 시스템으로 발급한 인증서를 가져온 경우 특히 유용합니다. 인증서 추적을 활성화하는 것도 다음 프로비저닝 시나리오의 최종 단계가 될 수 있습니다.
- IdM 서버에서 아직 존재하지 않는 시스템의 인증서를 생성합니다.
- 새 시스템을 생성합니다.
- 새 시스템을 IdM 클라이언트로 등록합니다.
- 의 IdM 서버에서 IdM 클라이언트로 인증서와 키를 가져옵니다.
-
certmonger
를 사용하여 인증서 추적을 시작하여 만료될 때 갱신되도록 합니다.
절차
20190408143846의 요청 ID가 있는 인증서 모니터링을 비활성화하려면 다음을 실행합니다.
# getcert stop-tracking -i 20190408143846
자세한 옵션은 시스템의
getcert stop-tracking
도움말 페이지를 참조하십시오.개인 키가
/tmp/some_key.key
파일에 저장되어 있는/tmp/some_cert.crt
파일에 저장된 인증서의 모니터링을 활성화하려면 다음을 수행합니다.# getcert start-tracking -c IPA -f /tmp/some_cert.crt -k /tmp/some_key.key
certmonger는
인증서를 발급한 CA 유형을 자동으로 식별할 수 없습니다. 따라서 IdM CA에서 인증서를 발급한 경우getcert start-tracking
명령에IPA
값이 있는-c
옵션을 추가합니다.-c
옵션을 추가하도록 생략하면certmonger
가 NEED_CA 상태가 됩니다.자세한 옵션은 시스템의
getcert 시작
도움말 페이지를 참조하십시오.
두 명령에서는 인증서를 조작하지 않습니다. 예를 들어, getcert stop-tracking
은 인증서를 삭제하거나 NSS 데이터베이스 또는 파일 시스템에서 제거하지만 모니터링된 인증서 목록에서 인증서를 제거하기만 하면 됩니다. 마찬가지로 getcert start-tracking
은 모니터링된 인증서 목록에 인증서만 추가합니다.
19.6. 인증서를 수동으로 업데이트
인증서가 만료일이 되면 certmonger
데몬은 CA(인증 기관) 도우미를 사용하여 갱신 명령을 자동으로 발행하고, 갱신된 인증서를 가져와 이전 인증서를 새 인증서로 대체합니다.
getcert resubmit
명령을 사용하여 사전에 인증서를 수동으로 갱신할 수도 있습니다. 이렇게 하면 SAN(주체 대체 이름)을 추가하여 인증서에 포함된 정보를 업데이트할 수 있습니다.
인증서를 수동으로 갱신하려면 다음 절차를 따르십시오.
절차
20190408143846의 요청 ID로 인증서를 갱신하려면 다음을 수행합니다.
# getcert resubmit -i 20190408143846
특정 인증서에 대한 요청 ID를 얻으려면
getcert list
명령을 사용합니다. 자세한 내용은 시스템의getcert list
man 페이지를 참조하십시오.
19.7. certmonger는 CA 복제본에서 IdM 인증서 추적을 재개합니다.
다음 절차에서는 인증서 추적이 중단된 후 통합 인증 기관을 사용한 IdM 배포에 중요한 IdM(Identity Management) 시스템 인증서 추적을 재개하는 방법을 설명합니다. 시스템 인증서를 갱신하는 동안 IdM 호스트에서 또는 복제 토폴로지가 제대로 작동하지 않아 IdM 호스트가 중단될 수 있습니다. 또한
certmonger
를 통해 IdM 서비스 인증서 추적, 즉 HTTP
,LDAP
및 PKINIT
인증서의 추적을 재개하는 방법도 설명합니다.
사전 요구 사항
- 시스템 인증서 추적을 재개할 호스트는 IdM CA 갱신 서버가 아닌 IdM 인증 기관(CA)이기도 합니다.
절차
하위 시스템 CA 인증서에 대한 pin을 가져옵니다.
# grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
하위 시스템 CA 인증서에 추적을 추가하고 아래 명령에서
[내부 Pin]
을 이전 단계에서 얻은 PIN으로 교체합니다.# getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"' -T caCACert # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"' -T caSignedLogCert # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"' -T caOCSPCert # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"' -T caSubsystemCert # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T caServerCert
나머지 IdM 인증서,
HTTP
,LDAP
,IPA 갱신 에이전트
및PKINIT
인증서에 대한 추적을 추가합니다.# getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd -T caIPAserviceCert # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv "IDM-EXAMPLE-COM"' -T caIPAserviceCert # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert -T caSubsystemCert # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert -T KDCs_PKINIT_Certs
certmonger
를 다시 시작하십시오.# systemctl restart certmonger
certmonger
가 시작된 후 1 분 정도 기다린 다음 새 인증서의 상태를 확인합니다.# getcert list
추가 리소스
- IdM 시스템 인증서가 모두 만료된 경우 CA 갱신 서버 및 CRL 게시자 서버이기도 하는 IdM CA 서버에서 IdM 시스템 인증서를 수동으로 갱신하려면 기술 센터 지원(KCS) 솔루션을 참조하십시오. 그런 다음 이 KCS 솔루션에 설명된 절차에 따라 토폴로지의 다른 모든 CA 서버에서 IdM 시스템 인증서를 수동으로 갱신합니다.
19.8. certmonger와 함께 SCEP 사용
SCEP(Simple Certificate Enrollment Protocol)는 다양한 장치 및 운영 체제에서 사용할 수 있는 인증서 관리 프로토콜입니다. SCEP 서버를 환경에서 CA(외부 인증 기관)로 사용하는 경우 certmonger
를 사용하여 IdM(Identity Management) 클라이언트의 인증서를 받을 수 있습니다.
19.8.1. SCEP 개요
SCEP(Simple Certificate Enrollment Protocol)는 다양한 장치 및 운영 체제에서 사용할 수 있는 인증서 관리 프로토콜입니다. SCEP 서버를 외부 CA(인증 기관)로 사용할 수 있습니다.
IdM(Identity Management) 클라이언트를 구성하여 CA SCEP 서비스에서 HTTP를 통해 직접 인증서를 요청 및 검색할 수 있습니다. 이 프로세스는 일반적으로 제한된 시간 동안만 유효한 공유 보안으로 보호됩니다.
클라이언트 측에서 SCEP는 다음 구성 요소를 제공해야 합니다.
- SCEP URL: CA SCEP 인터페이스의 URL입니다.
-
SCEP 공유 시크릿: 인증서를 가져오는 데 사용되는 CA와 SCEP 클라이언트 간에 공유되는
챌린지Password
Pin입니다.
그런 다음 클라이언트는 SCEP를 통해 CA 인증서 체인을 검색하고 CA에 인증서 서명 요청을 보냅니다.
certmonger
를 사용하여 SCEP를 구성할 때 발급한 인증서 매개변수를 지정하는 새 CA 구성 프로필을 생성합니다.
19.8.2. SCEP를 통해 IdM CA 서명 인증서 요청
다음 예제는 certmonger
에 SCEP_example
SCEP CA 구성을 추가하고 client.idm.example.com
IdM 클라이언트에서 새 인증서를 요청합니다. certmonger
는 OpenSSL과 같은 NSS 인증서 데이터베이스 형식과 PEM(파일 기반) 형식을 모두 지원합니다.
사전 요구 사항
- SCEP URL을 알고 있습니다.
-
챌린지Password
pin shared secret이 있습니다.
절차
certmonger
에 CA 구성을 추가합니다.[root@client.idm.example.com ~]# getcert add-scep-ca -c SCEP_example -u SCEP_URL
-
-c
: CA 구성에 대한 필수 구성 이름입니다. 나중에 동일한 값을 다른getcert
명령과 함께 사용할 수 있습니다. -u
: 서버의 SCEP 인터페이스의 URL입니다.중요HTTPS URL을 사용하는 경우
-R
옵션을 사용하여 SCEP 서버 CA 인증서의 PEM 형식 사본 위치도 지정해야 합니다.
-
CA 구성이 성공적으로 추가되었는지 확인합니다.
[root@client.idm.example.com ~]# getcert list-cas -c SCEP_example CA 'SCEP_example': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/scep-submit -u http://SCEP_server_enrollment_interface_URL SCEP CA certificate thumbprint (MD5): A67C2D4B 771AC186 FCCA654A 5E55AAF7 SCEP CA certificate thumbprint (SHA1): FBFF096C 6455E8E9 BD55F4A5 5787C43F 1F512279
구성이 성공적으로 추가되면 certmonger는 원격 CA에서 CA 체인을 검색합니다. 그런 다음 CA 체인이 명령 출력에서 지문으로 표시됩니다. 암호화되지 않은 HTTP를 통해 서버에 액세스하는 경우 지문을 SCEP 서버에 표시된 것과 수동으로 비교하여 중간자 공격을 방지합니다.
CA에서 인증서를 요청합니다.
NSS를 사용하는 경우:
[root@client.idm.example.com ~]# getcert request -I Example_Task -c SCEP_example -d /etc/pki/nssdb -n ExampleCert -N cn="client.idm.example.com" -L one-time_PIN -D client.idm.example.com
옵션을 사용하여 인증서 요청의 다음 매개변수를 지정할 수 있습니다.
-
-
i :(선택 사항) 작업의 이름: 요청 추적 ID입니다. 나중에getcert list
명령과 동일한 값을 사용할 수 있습니다. -
-c
: 요청을 제출하기 위한 CA 구성입니다. -
-
D : 인증서와 키를 저장할 NSS 데이터베이스가 있는 디렉터리입니다. -
-n
: NSS 데이터베이스에 사용된 인증서의 Nickname입니다. -
-
n : CSR의 주체 이름입니다. -
-L
: CA에서 발행한1회성
규칙 pin입니다. -
-
d : 인증서의 주체 대체 이름, 일반적으로 호스트 이름과 동일합니다.
-
OpenSSL을 사용하는 경우:
[root@client.idm.example.com ~]# getcert request -I Example_Task -c SCEP_example -f /etc/pki/tls/certs/server.crt -k /etc/pki/tls/private/private.key -N cn="client.idm.example.com" -L one-time_PIN -D client.idm.example.com
옵션을 사용하여 인증서 요청의 다음 매개변수를 지정할 수 있습니다.
-
-
i :(선택 사항) 작업의 이름: 요청 추적 ID입니다. 나중에getcert list
명령과 동일한 값을 사용할 수 있습니다. -
-c
: 요청을 제출하기 위한 CA 구성입니다. -
-f
: 인증서의 스토리지 경로입니다. -
-k
: 키의 스토리지 경로입니다. -
-
n : CSR의 주체 이름입니다. -
-L
: CA에서 발행한1회성
규칙 pin입니다. -
-
d : 인증서의 주체 대체 이름, 일반적으로 호스트 이름과 동일합니다.
-
검증
인증서가 발급되었는지 확인하고 로컬 데이터베이스에 올바르게 저장되었는지 확인합니다.
NSS를 사용한 경우 다음을 입력합니다.
[root@client.idm.example.com ~]# getcert list -I Example_Task Request ID 'Example_Task': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='ExampleCert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='ExampleCert',token='NSS Certificate DB' signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4 CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=client.idm.example.com,O=EXAMPLE.COM expires: 2018-05-06 10:28:06 UTC key usage: digitalSignature,keyEncipherment eku: iso.org.dod.internet.security.mechanisms.8.2.2 certificate template/profile: IPSECIntermediateOffline pre-save command: post-save command: track: true auto-renew: true
OpenSSL을 사용한 경우 다음을 입력합니다.
[root@client.idm.example.com ~]# getcert list -I Example_Task Request ID 'Example_Task': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/private.key' certificate: type=FILE,location='/etc/pki/tls/certs/server.crt' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=client.idm.example.com,O=EXAMPLE.COM expires: 2018-05-06 10:28:06 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: true auto-renew: true
MONITORING 상태는 발급된 인증서를 성공적으로 검색할 수 있음을 나타냅니다.
getcert-list(1)
도움말 페이지에는 가능한 다른 상태 및 의미가 나열됩니다.
추가 리소스
-
인증서를 요청할 때 자세한 옵션은 시스템의
getcert-request(1)
매뉴얼 페이지를 참조하십시오.
19.8.3. certmonger를 사용하여 AD SCEP 인증서 자동 갱신
certmonger
에서 SCEP 인증서 갱신 요청을 보내면 이 요청은 기존 인증서 개인 키를 사용하여 서명됩니다. 그러나 기본적으로 certmonger
에서 전송한 갱신 요청에는 원래 인증서를 받는 데 사용된 challengePassword
Pin도 포함되어 있습니다.
SCEP 서버로 작동하는 NDES(Network Device Enrollment Service) 서버는 원래의 challengePassword
pin이 포함된 갱신 요청에 대한 요청을 자동으로 거부합니다. 따라서 갱신이 실패합니다.
AD가 작동하도록 갱신하려면 challengePassword
Pin 없이 서명된 갱신 요청을 보내도록 certmonger
를 구성해야 합니다. 갱신 시 주체 이름을 비교하지 않도록 AD 서버를 구성해야 합니다.
AD 이외의 SCEP 서버는 challengePassword
가 포함된 요청도 거부할 수 있습니다. 이러한 경우 이러한 방식으로 certmonger
구성을 변경해야 할 수도 있습니다.
사전 요구 사항
- RHEL 서버는 RHEL 8.6 이상을 실행해야 합니다.
절차
-
AD 서버에서
등록
할 수 있습니다. -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP 하위 키에서 새로운 32비트 REG_Doctets 항목
DisableRenewalSubjectNameMatch
를 추가하고 해당 값을1
로 설정합니다. certmonger
가 실행 중인 서버에서/etc/certmonger/certmonger.conf
파일을 열고 다음 섹션을 추가합니다.[scep] challenge_password_otp = yes
certmonger를 다시 시작하십시오.
# systemctl restart certmonger
20장. IdM에서 ACME 서비스 배포 및 관리
이 기능은 기술 프리뷰 기능입니다.
ACME(Automated Certificate Management Environment)는 자동 식별자 검증 및 인증서 발급을 위한 프로토콜입니다. 목표는 인증서 수명을 줄이고 인증서 라이프사이클 관리에서 수동 프로세스를 방지하여 보안을 개선하는 것입니다.
RHEL IdM(Identity Management)을 사용하여 관리자는 단일 시스템에서 ACME 서비스 토폴로지를 쉽게 배포하고 관리할 수 있습니다.
20.1. IdM의 ACME 서비스
이 기능은 기술 프리뷰 기능입니다.
IdM은 현재 Random Certificate Serial Numbers (RSNv3)가 활성화된 RHEL 9.2 이상에서만 ACME를 지원합니다.
ACME는 과제 및 응답 인증 메커니즘을 사용하여 클라이언트가 ID를 제어할 수 있음을 증명합니다. ACME에서 식별자는 문제를 해결함으로써 인증서를 얻는 데 사용되는 소유권 증명입니다. IdM(Identity Management)에서 ACME는 현재 다음과 같은 과제를 지원합니다.
-
클라이언트에서 DNS 레코드를 생성하여 ID를 제어하는 DNS
-01
-
클라이언트가 HTTP 리소스를 프로비저닝하여 이를 증명하기 위해 ID를 제어하는 HTTP
-01
IdM에서 ACME 서비스는 PKI ACME 응답자를 사용합니다. ACME 하위 시스템은 IdM 배포의 모든 CA 서버에 자동으로 배포되지만 관리자가 활성화할 때까지 요청 서비스를 제공하지 않습니다. 서버는 ipa-ca.DOMAIN
이라는 이름을 사용하여 검색됩니다. 모든 IdM CA 서버는 이 DNS 이름에 등록되므로 요청이 라운드 로빈을 통해 부하 분산됩니다.
관리자가 ipa-server-upgrade
명령을 사용하여 서버를 업그레이드할 때 ACME도 배포되었지만 비활성화되어 있습니다.
ACME는 Apache Tomcat 내에서 별도의 서비스로 실행됩니다. ACME 구성 파일은 /etc/pki/pki-tomcat/acme
에 저장되고 PKI 정보는 /var/log/pki/pki-tomcat/acme/
에 기록됩니다.
IdM은 ACME 인증서를 발행할 때 acmeIPAServerCert
프로필을 사용합니다. 발급된 인증서의 유효 기간은 90일입니다. 따라서 CA에 누적되지 않도록 ACME를 자동으로 제거하여 성능에 부정적인 영향을 미칠 수 있으므로 ACME를 설정하는 것이 좋습니다.
다양한 ACME 클라이언트가 있습니다. RHEL과 함께 사용하려면 선택한 클라이언트에서 dns-01
및 http-01
챌린지 중 하나를 지원해야 합니다. 현재 다음 클라이언트가 테스트되었으며 RHEL에서 ACME와 함께 작동하는 것으로 알려져 있습니다.
-
http-01
및dns-01
과제를 모두 사용하는 Certbot
-
mod_md
,http-01
챌린지만 지원
20.2. IdM에서 ACME 서비스 활성화
이 기능은 기술 프리뷰 기능입니다.
기본적으로 ACME 서비스는 배포되지만 비활성화되어 있습니다. ACME 서비스를 활성화하면 전체 IdM 배포의 모든 IdM CA 서버에서 이를 활성화할 수 있습니다. 이는 복제를 통해 처리됩니다.
이 예제에서는 ACME를 활성화하여 매일 자정에 만료된 인증서를 자동으로 제거하도록 설정합니다.
사전 요구 사항
- IdM 배포의 서버에서는 Random Certificate Serial Numbers(RSNv3)가 활성화된 RHEL 9.2 이상을 실행하고 있습니다.
- 절차를 실행 중인 IdM 서버에 대한 root 권한이 있습니다.
절차
전체 IdM 배포에서 ACME를 활성화합니다.
# ipa-acme-manage enable The ipa-acme-manage command was successful
CA에서 만료된 인증서를 자동으로 제거하도록 ACME를 설정합니다.
# ipa-acme-manage pruning --enable --cron "0 0 1 * *"
참고만료된 인증서는 보존 기간 후에 제거됩니다. 기본적으로 만료 후 30일입니다.
검증
-
ACME 서비스가 설치되어 활성화되어 있는지 확인하려면
ipa-acme-manage status
명령을 사용합니다.
# ipa-acme-manage status ACME is enabled The ipa-acme-manage command was successful
20.3. IdM에서 ACME 서비스 비활성화
이 기능은 기술 프리뷰 기능입니다.
ACME 서비스를 비활성화하면 전체 IdM 배포에서 비활성화됩니다. 이는 복제를 통해 처리됩니다.
사전 요구 사항
- IdM 배포의 서버에서는 Random Certificate Serial Numbers(RSNv3)가 활성화된 RHEL 9.2 이상을 실행하고 있습니다.
- 절차를 실행 중인 IdM 서버에 대한 root 권한이 있습니다.
절차
전체 IdM 배포에서 ACME를 비활성화합니다.
# ipa-acme-manage disable The ipa-acme-manage command was successful
선택 사항: 만료된 인증서의 자동 제거를 비활성화합니다.
ipa-acme-manage pruning --disable
검증
-
ACME 서비스가 설치되어 있지만 비활성화되었는지 확인하려면
ipa-acme-manage status
명령을 사용합니다.
# ipa-acme-manage status ACME is disabled The ipa-acme-manage command was successful
21장. RHEL 시스템 역할을 사용하여 인증서 요청
인증서 시스템 역할을 사용하여 인증서
를 발행하고 관리할 수 있습니다.
21.1. 인증서
RHEL 시스템 역할
인증서
시스템 역할을 사용하여 Ansible Core를 사용하여 TLS 및 SSL 인증서를 발행하고 갱신할 수 있습니다.
이 역할은 certmonger
를 인증서 공급자로 사용하며 현재 자체 서명된 인증서를 발행 및 갱신하고 IdM 통합 인증 기관(CA)을 사용합니다.
인증서
시스템 역할과 함께 Ansible 플레이북에서 다음 변수를 사용할 수 있습니다.
certificate_wait
- 작업이 인증서가 발급될 때까지 기다려야 하는지 여부를 지정하려면 다음을 수행합니다.
certificate_requests
- 실행할 각 인증서 및 해당 매개 변수를 나타냅니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일 -
/usr/share/doc/rhel-system-roles/certificate/
directory
21.2. 인증서 RHEL 시스템 역할을 사용하여 자체 서명된 새 인증서
요청
인증서
시스템 역할을 사용하면 Ansible Core를 사용하여 자체 서명된 인증서를 발행할 수 있습니다.
이 프로세스는 certmonger
공급자를 사용하고 getcert
명령을 통해 인증서를 요청합니다.
사전 요구 사항
- 컨트롤 노드 및 관리형 노드를 준비했습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다.
절차
다음 콘텐츠를 사용하여 플레이북 파일(예:
~/playbook.yml
)을 생성합니다.--- - hosts: managed-node-01.example.com roles: - rhel-system-roles.certificate vars: certificate_requests: - name: mycert dns: "*.example.com" ca: self-sign
-
name
매개 변수를 원하는 인증서 이름(예:mycert
)으로 설정합니다. -
dns
매개 변수를 인증서에 포함할 도메인으로 설정합니다(예:*.example.com
). -
ca
매개 변수를자체 서명
으로 설정합니다.
기본적으로
certmonger
는 만료되기 전에 인증서를 자동으로 갱신합니다. Ansible 플레이북의auto_renew
매개변수를no
로 설정하여 비활성화할 수 있습니다.-
플레이북 구문을 확인합니다.
$ ansible-playbook --syntax-check ~/playbook.yml
이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.
플레이북을 실행합니다.
$ ansible-playbook ~/playbook.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일 -
/usr/share/doc/rhel-system-roles/certificate/
directory
21.3. 인증서 RHEL 시스템 역할을 사용하여 IdM CA에서 새 인증서
요청
인증서
시스템 역할을 사용하면 통합 CA(인증 기관)가 있는 IdM 서버를 사용하는 동안 anible-core
를 사용하여 인증서를 발행할 수 있습니다. 따라서 IdM을 CA로 사용할 때 여러 시스템의 인증서 신뢰 체인을 효율적이고 일관되게 관리할 수 있습니다.
이 프로세스는 certmonger
공급자를 사용하고 getcert
명령을 통해 인증서를 요청합니다.
사전 요구 사항
- 컨트롤 노드 및 관리형 노드를 준비했습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다.
절차
다음 콘텐츠를 사용하여 플레이북 파일(예:
~/playbook.yml
)을 생성합니다.--- - hosts: managed-node-01.example.com roles: - rhel-system-roles.certificate vars: certificate_requests: - name: mycert dns: www.example.com principal: HTTP/www.example.com@EXAMPLE.COM ca: ipa
-
name
매개 변수를 원하는 인증서 이름(예:mycert
)으로 설정합니다. -
dns
매개변수를 인증서에 포함할 도메인으로 설정합니다(예:www.example.com
). -
principal
매개변수를 설정하여HTTP/www.example.com@EXAMPLE.COM
와 같은 Kerberos 보안 주체를 지정합니다. -
ca
매개 변수를ipa
로 설정합니다.
기본적으로
certmonger
는 만료되기 전에 인증서를 자동으로 갱신합니다. Ansible 플레이북의auto_renew
매개변수를no
로 설정하여 비활성화할 수 있습니다.-
플레이북 구문을 확인합니다.
$ ansible-playbook --syntax-check ~/playbook.yml
이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.
플레이북을 실행합니다.
$ ansible-playbook ~/playbook.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일 -
/usr/share/doc/rhel-system-roles/certificate/
directory
21.4. 인증서 RHEL 시스템 역할을 사용하여 인증서
발행 전후에 실행할 명령 지정
인증서
역할을 사용하면 Ansible Core를 사용하여 인증서를 발급하거나 갱신하기 전과 후에 명령을 실행할 수 있습니다.
다음 예에서 관리자는 www.example.com
의 자체 서명된 인증서를 발행하거나 갱신하기 전에 httpd
서비스를 중지한 후 나중에 다시 시작합니다.
사전 요구 사항
- 컨트롤 노드 및 관리형 노드를 준비했습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다.
절차
다음 콘텐츠를 사용하여 플레이북 파일(예:
~/playbook.yml
)을 생성합니다.--- - hosts: managed-node-01.example.com roles: - rhel-system-roles.certificate vars: certificate_requests: - name: mycert dns: www.example.com ca: self-sign run_before: systemctl stop httpd.service run_after: systemctl start httpd.service
-
name
매개 변수를 원하는 인증서 이름(예:mycert
)으로 설정합니다. -
dns
매개변수를 인증서에 포함할 도메인으로 설정합니다(예:www.example.com
). -
ca
매개 변수를 사용하여 인증서를 발급할 CA(예:self-sign
)로 설정합니다. -
이 인증서를 발행하거나
systemctl stop httpd.service
와 같이 갱신하기 전에 실행할 명령에run_before
매개변수를 설정합니다. -
이 인증서가 실행된 후 실행할
run_after
매개 변수를systemctl start httpd.service
와 같이 갱신합니다.
기본적으로
certmonger
는 만료되기 전에 인증서를 자동으로 갱신합니다. Ansible 플레이북의auto_renew
매개변수를no
로 설정하여 비활성화할 수 있습니다.-
플레이북 구문을 확인합니다.
$ ansible-playbook --syntax-check ~/playbook.yml
이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.
플레이북을 실행합니다.
$ ansible-playbook ~/playbook.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일 -
/usr/share/doc/rhel-system-roles/certificate/
directory
22장. 인증서 서브 세트만 신뢰하도록 애플리케이션 제한
IdM(Identity Management) 설치가 통합된 CA(Certificate System) 인증 기관(CA)으로 구성된 경우 경량의 하위 CA를 생성할 수 있습니다. 생성하는 모든 하위 CA는 인증서 시스템의 기본 CA인 ipa CA로 분류됩니다.
이 컨텍스트의 경량 하위 CA 는 하위 CA가 특정 목적으로 인증서를 발급 한다는 것을 의미합니다. 예를 들어, 경량 하위 CA를 사용하면 가상 사설 네트워크(VPN) 게이트웨이 및 웹 브라우저와 같은 서비스를 구성하여 하위 CA A 에서 발급한 인증서만 허용할 수 있습니다. 하위 CA B 에서만 발급한 인증서만 수락하도록 다른 서비스를 구성하면 하위 CA, 즉 ipa
CA 및 둘 사이의 중간 하위 CA에서 발급한 인증서를 수락하지 못합니다.
하위 CA의 중간 인증서를 취소하면 이 하위 CA에서 발행한 모든 인증서는 올바르게 구성된 클라이언트에서 자동으로 유효하지 않은 것으로 간주됩니다. 루트 CA, ipa 또는 다른 하위 CA에서 직접 발급한 기타 모든 인증서는 유효한 상태로 유지됩니다.
이 섹션에서는 Apache 웹 서버의 예제를 사용하여 인증서 서브 세트만 신뢰하도록 애플리케이션을 제한하는 방법을 설명합니다. IdM 클라이언트에서 실행 중인 웹 서버가 webserver-ca IdM 하위 CA에서 발급한 인증서를 사용하도록 제한하고, 사용자가 webclient-ca IdM 하위 명령에서 발급한 사용자 인증서를 사용하여 웹 서버에 인증해야 하는 경우 이 섹션을 완료합니다.
수행하는데 필요한 단계는 다음과 같습니다.
- IdM 하위 CA 생성
- IdM WebUI에서 하위 CA 인증서 다운로드
- 사용자, 서비스 및 CA 및 사용된 인증서 프로필의 올바른 조합을 지정하는 CA ACL을 생성합니다.
- IdM 하위 CA에서 IdM 클라이언트에서 실행 중인 웹 서비스에 대한 인증서 요청
- 단일 인스턴스 Apache HTTP Server 설정
- Apache HTTP 서버에 TLS 암호화 추가
- Apache HTTP Server에서 지원되는 TLS 프로토콜 버전 설정
- Apache HTTP Server에서 지원되는 암호 설정
- 웹 서버에서 TLS 클라이언트 인증서 인증 구성
- IdM 하위 CA에서 사용자의 인증서를 요청하고 클라이언트로 내보냅니다.
- 브라우저로 사용자 인증서를 가져와서 하위 CA 인증서를 신뢰하도록 브라우저를 구성합니다.
22.1. 경량 하위 CA 관리
이 섹션에서는 경량의 하위 인증 기관(sub-CA)을 관리하는 방법을 설명합니다. 생성하는 모든 하위 CA는 인증서 시스템의 기본 CA인 ipa
CA로 분류됩니다. 하위 CA를 비활성화하고 삭제할 수도 있습니다.
-
하위 CA를 삭제하면 해당 하위 CA에 대한 해지 검사는 더 이상 작동하지 않습니다. 향후 만료 시간이
아닌
해당 하위 CA에서 발행한 인증서가 더 이상 없는 경우에만 하위 CA를 삭제합니다. - 해당 하위 CA에서 발급한 만료되지 않은 인증서가 있는 동안 하위 CA만 비활성화해야 합니다. 하위 CA에서 발급한 모든 인증서가 만료된 경우 해당 하위 CA를 삭제할 수 있습니다.
- IdM CA를 비활성화하거나 삭제할 수 없습니다.
하위 CA 관리에 대한 자세한 내용은 다음을 참조하십시오.
22.1.1. IdM 웹 UI에서 하위 CA 생성
IdM WebUI를 사용하여 webserver-ca 및 webclient-ca 라는 새 하위 CA를 생성하려면 다음 절차를 따르십시오.
사전 요구 사항
- 관리자의 자격 증명을 확보했는지 확인합니다.
절차
- Authentication (인증) 메뉴에서 Certificates (인증서)를 클릭합니다.
- 인증 기관을 선택하고 추가를 클릭합니다.
- webserver-ca 하위 CA의 이름을 입력합니다. 주체 DN(예: CN=WEBSERVER,O=IDM.EXAMPLE.COM )을 주체 DN 필드에 입력합니다. 주체 DN은 IdM CA 인프라에서 고유해야 합니다.
- webclient-ca 하위 CA의 이름을 입력합니다. Subject DN CN=WEBCLIENT,O=IDM.EXAMPLE.COM 을 Subject DN 필드에 입력합니다.
명령줄 인터페이스에서
ipa-certupdate
명령을 실행하여 webserver-ca 및 webclient-ca 하위 CA 인증서에 대한 certmonger 추적 요청을 생성합니다.[root@ipaserver ~]#
ipa-certupdate
중요하위 CA를 생성한 후
ipa-certupdate
명령을 실행하는 것을 잊어버린 경우 end-entity 인증서가 만료되지 않은 경우에도 하위 CA에서 발급한 종료 인증서가 유효하지 않은 것으로 간주됩니다.
검증
새 하위 CA의 서명 인증서가 IdM 데이터베이스에 추가되었는지 확인합니다.
[root@ipaserver ~]#
certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u참고새 하위 CA 인증서는 인증서 시스템 인스턴스가 설치된 모든 복제본으로 자동으로 전송됩니다.
22.1.2. IdM 웹 UI에서 하위 CA 삭제
IdM WebUI에서 경량 하위 CA를 삭제하려면 다음 절차를 따르십시오.
-
하위 CA를 삭제하면 해당 하위 CA에 대한 해지 검사는 더 이상 작동하지 않습니다. 향후 만료 시간이
아닌
해당 하위 CA에서 발행한 인증서가 더 이상 없는 경우에만 하위 CA를 삭제합니다. - 해당 하위 CA에서 발급한 만료되지 않은 인증서가 있는 동안 하위 CA만 비활성화해야 합니다. 하위 CA에서 발급한 모든 인증서가 만료된 경우 해당 하위 CA를 삭제할 수 있습니다.
- IdM CA를 비활성화하거나 삭제할 수 없습니다.
사전 요구 사항
- 관리자의 자격 증명을 확보했는지 확인합니다.
- IdM CLI에서 하위 CA를 비활성화했습니다. IdM CLI에서 하위 CA 비활성화를참조하십시오.
절차
-
IdM 웹 UI에서
Authentication
(인증) 탭을 열고Certificates
(인증서) 하위 탭을 선택합니다. -
인증 기관을 선택합니다
. 제거할 하위 CA를 선택하고
삭제
를 클릭합니다.그림 22.1. IdM 웹 UI에서 하위 명령 삭제
-
Delete
를 클릭하여 확인합니다.
하위 CA는 인증 기관
목록에서 제거됩니다.
22.1.3. IdM CLI에서 하위 명령 생성
IdM CLI를 사용하여 webserver-ca 및 webclient-ca 라는 새 하위 CA를 생성하려면 다음 절차를 따르십시오.
사전 요구 사항
- 관리자의 자격 증명을 확보했는지 확인합니다.
- CA 서버인 IdM 서버에 로그인되어 있는지 확인합니다.
절차
ipa ca-add
명령을 입력하고 webserver-ca 하위 CA의 이름과 제목 Distinguished Name (DN)을 지정합니다.[root@ipaserver ~]#
ipa ca-add webserver-ca --subject="CN=WEBSERVER,O=IDM.EXAMPLE.COM"
------------------- Created CA "webserver-ca" ------------------- Name: webserver-ca Authority ID: ba83f324-5e50-4114-b109-acca05d6f1dc Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM- 이름
- CA의 이름입니다.
- 기관 ID
- CA의 개별 ID를 자동으로 생성합니다.
- 제목 DN
- Distinguished Name (DN)입니다. 주체 DN은 IdM CA 인프라에서 고유해야 합니다.
- 발급자 DN
- 하위 CA 인증서를 발급한 상위 CA입니다. 모든 하위 CA는 IdM 루트 CA의 하위 항목으로 생성됩니다.
웹 클라이언트에 인증서를 발급하기 위해 webclient-ca 하위 CA를 생성합니다.
[root@ipaserver ~]#
ipa ca-add webclient-ca --subject="CN=WEBCLIENT,O=IDM.EXAMPLE.COM"
------------------- Created CA "webclient-ca" ------------------- Name: webclient-ca Authority ID: 8a479f3a-0454-4a4d-8ade-fd3b5a54ab2e Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COMipa-certupdate 명령을 실행하여 webserver-ca 및 webclient-ca 하위 CA 인증서에 대한 certmonger 추적 요청을 생성합니다.
[root@ipaserver ~]#
ipa-certupdate
중요하위 CA를 생성하고 하위 CA 인증서가 만료된 후 ipa-certupdate 명령을 실행하는 것을 잊어버린 경우 엔드 고유 인증서가 만료되지 않은 경우에도 해당 하위 CA에서 발급한 엔드 엔티티 인증서가 유효하지 않은 것으로 간주됩니다.
검증
새 하위 CA의 서명 인증서가 IdM 데이터베이스에 추가되었는지 확인합니다.
[root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u
참고새 하위 CA 인증서는 인증서 시스템 인스턴스가 설치된 모든 복제본으로 자동으로 전송됩니다.
22.1.4. IdM CLI에서 하위 명령 비활성화
IdM CLI에서 하위 CA를 비활성화하려면 다음 절차를 따르십시오. 하위 CA에서 발급한 만료되지 않은 인증서가 여전히 있는 경우 삭제할 수 없지만 비활성화할 수 있습니다. 하위 CA를 삭제하면 해당 하위 CA에 대한 해지 검사는 더 이상 작동하지 않습니다.
사전 요구 사항
- 관리자의 자격 증명을 확보했는지 확인합니다.
절차
ipa ca-find
명령을 실행하여 삭제 중인 하위 CA의 이름을 확인합니다.[root@ipaserver ~]# ipa ca-find ------------- 3 CAs matched ------------- Name: ipa Description: IPA CA Authority ID: 5195deaf-3b61-4aab-b608-317aff38497c Subject DN: CN=Certificate Authority,O=IPA.TEST Issuer DN: CN=Certificate Authority,O=IPA.TEST Name: webclient-ca Authority ID: 605a472c-9c6e-425e-b959-f1955209b092 Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IPA.TEST Name: webserver-ca Authority ID: 02d537f9-c178-4433-98ea-53aa92126fc3 Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IPA.TEST ---------------------------- Number of entries returned 3 ----------------------------
ipa ca-disable
명령을 실행하여 하위 CA(이 예에서는webserver-ca
)를 비활성화합니다.ipa ca-disable webserver-ca -------------------------- Disabled CA "webserver-ca" --------------------------
22.1.5. IdM CLI에서 하위 명령 삭제
IdM CLI에서 경량 하위 CA를 삭제하려면 다음 절차를 따르십시오.
-
하위 CA를 삭제하면 해당 하위 CA에 대한 해지 검사는 더 이상 작동하지 않습니다. 향후 만료 시간이
아닌
해당 하위 CA에서 발행한 인증서가 더 이상 없는 경우에만 하위 CA를 삭제합니다. - 해당 하위 CA에서 발급한 만료되지 않은 인증서가 있는 동안 하위 CA만 비활성화해야 합니다. 하위 CA에서 발급한 모든 인증서가 만료된 경우 해당 하위 CA를 삭제할 수 있습니다.
- IdM CA를 비활성화하거나 삭제할 수 없습니다.
사전 요구 사항
- 관리자의 자격 증명을 확보했는지 확인합니다.
절차
하위 CA 및 CA 목록을 표시하려면
ipa ca-find
명령을 실행합니다.# ipa ca-find ------------- 3 CAs matched ------------- Name: ipa Description: IPA CA Authority ID: 5195deaf-3b61-4aab-b608-317aff38497c Subject DN: CN=Certificate Authority,O=IPA.TEST Issuer DN: CN=Certificate Authority,O=IPA.TEST Name: webclient-ca Authority ID: 605a472c-9c6e-425e-b959-f1955209b092 Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IPA.TEST Name: webserver-ca Authority ID: 02d537f9-c178-4433-98ea-53aa92126fc3 Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IPA.TEST ---------------------------- Number of entries returned 3 ----------------------------
ipa ca-disable
명령을 실행하여 하위 CA(이 예에서는webserver-ca
)를 비활성화합니다.# ipa ca-disable webserver-ca -------------------------- Disabled CA "webserver-ca" --------------------------
이 예에서 sub-CA를 삭제합니다.
webserver-ca
:# ipa ca-del webserver-ca ------------------------- Deleted CA "webserver-ca" -------------------------
검증
ipa ca-find
를 실행하여 CA 및 하위 CA 목록을 표시합니다.webserver-ca
가 더 이상 목록에 없습니다.# ipa ca-find ------------- 2 CAs matched ------------- Name: ipa Description: IPA CA Authority ID: 5195deaf-3b61-4aab-b608-317aff38497c Subject DN: CN=Certificate Authority,O=IPA.TEST Issuer DN: CN=Certificate Authority,O=IPA.TEST Name: webclient-ca Authority ID: 605a472c-9c6e-425e-b959-f1955209b092 Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IPA.TEST ---------------------------- Number of entries returned 2 ----------------------------
22.2. IdM WebUI에서 하위 CA 인증서 다운로드
사전 요구 사항
- IdM 관리자의 인증 정보를 가져왔는지 확인합니다.
절차
인증 메뉴에서 인증서 > 인증서 를 클릭합니다.
그림 22.2. 인증서 목록의 하위 CA 인증서
- 하위 CA 인증서의 일련 번호를 클릭하여 인증서 정보 페이지를 엽니다.
- 인증서 정보 페이지에서 작업 > 다운로드를 클릭합니다.
CLI에서 하위 CA 인증서를
/etc/pki/tls/private/
디렉터리로 이동합니다.# mv path/to/the/downloaded/certificate /etc/pki/tls/private/sub-ca.crt
22.3. 웹 서버 및 클라이언트 인증에 대한 CA ACL 생성
CA ACL(인증 기관 액세스 제어 목록) 규칙은 사용자, 서비스 또는 호스트에 인증서를 발급하는 데 사용할 수 있는 프로필을 정의합니다. 프로필, 주체 및 그룹을 연결함으로써 CA ACL은 보안 주체 또는 그룹을 통해 특정 프로필을 사용하여 인증서를 요청할 수 있습니다.
예를 들어, CA ACL을 사용하면, 관리자는 런던에 위치한 사무실에서 작업 중인 직원들에게 런던 관련 그룹의 멤버인 사용자에게만 사용할 수 있는 프로필의 사용을 제한할 수 있습니다.
22.3.1. IdM CLI에서 CA ACL 보기
IdM 배포에서 사용 가능한 인증 기관 액세스 제어 목록(CA ACL) 목록과 특정 CA ACL의 세부 정보를 보려면 다음 절차를 따르십시오.
절차
IdM 환경의 모든 CA ACL을 보려면
ipa caacl-find
명령을 입력합니다.$ ipa caacl-find ----------------- 1 CA ACL matched ----------------- ACL name: hosts_services_caIPAserviceCert Enabled: TRUE
CA ACL의 세부 정보를 보려면
ipa caacl-show
명령을 입력하고 CA ACL 이름을 지정합니다. 예를 들어 hosts_services_caIPAserviceCert CA ACL의 세부 정보를 보려면 다음을 입력합니다.$ ipa caacl-show hosts_services_caIPAserviceCert ACL name: hosts_services_caIPAserviceCert Enabled: TRUE Host category: all Service category: all CAs: ipa Profiles: caIPAserviceCert Users: admin
22.3.2. webserver-ca에서 발행한 인증서를 사용하여 웹 클라이언트에 인증하는 웹 서버에 대한 CA ACL 생성
다음 절차에 따라 시스템 관리자가 HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM 서비스에 대한 인증서를 요청할 때 webserver-ca 하위 CA 및 caIPAserviceCert 프로필을 사용해야 하는 CA ACL을 생성합니다. 사용자가 다른 하위 CA 또는 다른 프로필의 인증서를 요청하면 요청이 실패합니다. 유일한 예외는 활성화된 또 다른 일치하는 CA ACL이 있는 경우입니다. 사용 가능한 CA ACL을 보려면 IdM CLI에서 CA ACL 보기를 참조하십시오.
사전 요구 사항
- HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM 서비스가 IdM의 일부인지 확인합니다.
- IdM 관리자의 인증 정보가 있는지 확인합니다.
절차
ipa caacl
명령을 사용하여 CA ACL을 생성하고 이름을 지정합니다.$ ipa caacl-add TLS_web_server_authentication -------------------------------------------- Added CA ACL "TLS_web_server_authentication" -------------------------------------------- ACL name: TLS_web_server_authentication Enabled: TRUE
ipa caacl-mod
명령을 사용하여 CA ACL을 수정하여 CA ACL 설명을 지정합니다.$ ipa caacl-mod TLS_web_server_authentication --desc="CAACL for web servers authenticating to web clients using certificates issued by webserver-ca" ----------------------------------------------- Modified CA ACL "TLS_web_server_authentication" ----------------------------------------------- ACL name: TLS_web_server_authentication Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca Enabled: TRUE
CA ACL에 webserver-ca 하위 CA를 추가합니다.
$ ipa caacl-add-ca TLS_web_server_authentication --ca=webserver-ca ACL name: TLS_web_server_authentication Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca Enabled: TRUE CAs: webserver-ca ------------------------- Number of members added 1 -------------------------
ipa caacl-add-service
를 사용하여 보안 주체가 인증서를 요청할 수 있는 서비스를 지정합니다.$ ipa caacl-add-service TLS_web_server_authentication --service=HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM ACL name: TLS_web_server_authentication Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca Enabled: TRUE CAs: webserver-ca Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM ------------------------- Number of members added 1 -------------------------
ipa caacl-add-profile
명령을 사용하여 요청된 인증서의 인증서 프로필을 지정합니다.$ ipa caacl-add-profile TLS_web_server_authentication --certprofiles=caIPAserviceCert ACL name: TLS_web_server_authentication Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca Enabled: TRUE CAs: webserver-ca Profiles: caIPAserviceCert Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM ------------------------- Number of members added 1 -------------------------
새로 생성된 CA ACL을 즉시 사용할 수 있습니다. 기본적으로 생성된 후 활성화됩니다.
CA ACL의 핵심은 특정 보안 주체 또는 그룹에서 들어오는 요청에 대해 허용되는 CA 및 프로필 조합을 지정하는 것입니다. CA ACL은 인증서 검증 또는 신뢰에 영향을 미치지 않습니다. 인증서 사용 방식에는 영향을 미치지 않습니다.
22.3.3. webclient-ca에서 발행한 인증서를 사용하여 웹 서버에 인증하는 사용자 웹 브라우저의 CA ACL 생성
다음 절차에 따라 시스템 관리자가 인증서를 요청할 때 webclient-ca 하위 CA 및 Cryostat UserRoles 프로필을 사용해야 하는 CA ACL을 생성합니다. 사용자가 다른 하위 CA 또는 다른 프로필의 인증서를 요청하면 요청이 실패합니다. 유일한 예외는 활성화된 또 다른 일치하는 CA ACL이 있는 경우입니다. 사용 가능한 CA ACL을 보려면 IdM CLI에서 CA ACL 보기를 참조하십시오.
사전 요구 사항
- IdM 관리자의 인증 정보를 가져왔는지 확인합니다.
절차
ipa caacl
명령을 사용하여 CA ACL을 생성하고 이름을 지정합니다.$ ipa caacl-add TLS_web_client_authentication -------------------------------------------- Added CA ACL "TLS_web_client_authentication" -------------------------------------------- ACL name: TLS_web_client_authentication Enabled: TRUE
ipa caacl-mod
명령을 사용하여 CA ACL을 수정하여 CA ACL 설명을 지정합니다.$ ipa caacl-mod TLS_web_client_authentication --desc="CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca" ----------------------------------------------- Modified CA ACL "TLS_web_client_authentication" ----------------------------------------------- ACL name: TLS_web_client_authentication Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca Enabled: TRUE
CA ACL에 webclient-ca 하위 CA를 추가합니다.
$ ipa caacl-add-ca TLS_web_client_authentication --ca=webclient-ca ACL name: TLS_web_client_authentication Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca Enabled: TRUE CAs: webclient-ca ------------------------- Number of members added 1 -------------------------
ipa caacl-add-profile
명령을 사용하여 요청된 인증서의 인증서 프로필을 지정합니다.$ ipa caacl-add-profile TLS_web_client_authentication --certprofiles=IECUserRoles ACL name: TLS_web_client_authentication Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca Enabled: TRUE CAs: webclient-ca Profiles: IECUserRoles ------------------------- Number of members added 1 -------------------------
ipa caacl-mod
명령을 사용하여 CA ACL을 수정하여 CA ACL이 모든 IdM 사용자에게 적용되도록 지정합니다.$ ipa caacl-mod TLS_web_client_authentication --usercat=all ----------------------------------------------- Modified CA ACL "TLS_web_client_authentication" ----------------------------------------------- ACL name: TLS_web_client_authentication Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca Enabled: TRUE User category: all CAs: webclient-ca Profiles: IECUserRoles
새로 생성된 CA ACL을 즉시 사용할 수 있습니다. 기본적으로 생성된 후 활성화됩니다.
CA ACL의 핵심은 특정 보안 주체 또는 그룹에서 들어오는 요청에 대해 허용되는 CA 및 프로필 조합을 지정하는 것입니다. CA ACL은 인증서 검증 또는 신뢰에 영향을 미치지 않습니다. 인증서 사용 방식에는 영향을 미치지 않습니다.
22.4. certmonger를 사용하여 서비스에 대한 IdM 인증서 가져오기
IdM 클라이언트에서 실행되는 브라우저와 웹 서비스 간 통신이 안전하고 암호화되도록 하려면 TLS 인증서를 사용합니다. 웹 브라우저가 webserver-ca
하위 CA에서 발급한 인증서를 신뢰하도록 제한하고 기타 IdM 하위 CA는 없는 경우 webserver-ca
하위 CA에서 웹 서비스의 TLS 인증서를 가져옵니다.
IdM 클라이언트에서 실행 중인 서비스의 IdM 인증서(HTTP/my_company.idm.example.com
@IDM.EXAMPLE.COM
)를 받으려면 certmonger
를 사용하십시오.
certmonger
를 사용하여 인증서를 자동으로 요청한다는 것은 certmonger
가 갱신이 발생할 때 인증서를 관리하고 갱신한다는 것을 의미합니다.
certmonger
가 서비스 인증서를 요청할 때 발생하는 상황을 시각적으로 표현하려면 22.5절. “서비스 인증서를 요청하는 certmonger의 통신 흐름” 을 참조하십시오.
사전 요구 사항
- 웹 서버는 IdM 클라이언트로 등록되어 있습니다.
- 프로시저를 실행 중인 IdM 클라이언트에 대한 루트 액세스 권한이 있습니다.
- 인증서를 요청하는 서비스는 IdM에 사전 존재할 필요가 없습니다.
절차
HTTP 서비스가 실행 중인
my_company.idm.example.com
IdM 클라이언트에서HTTP
/my_company.idm.example.com@IDM.EXAMPLE.COM-
인증서는 로컬
/etc/pki/tls/certs/httpd.pem
파일에 저장됩니다. -
개인 키는 로컬
/etc/pki/tls/private/httpd.key
파일에 저장해야 합니다. -
webserver-ca
하위 CA는 발급 기관입니다. SubjectAltName
에 대한 extensionRequest가my_company.idm.example.com
의 DNS 이름을 사용하여 서명 요청에 추가됩니다.# ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -X webserver-ca -C "systemctl restart httpd" New signing request "20190604065735" added.
위의 명령에서:
-
ipa-getcert request
명령은 인증서를 IdM CA에서 가져올 수 있도록 지정합니다.ipa-getcert request
명령은getcert request -c IPA
의 바로 가기입니다. -
g
옵션은 아직 없는 경우 생성할 키 크기를 지정합니다. -
d 옵션은 요청에 추가할
SubjectAltName
DNS 값을 지정합니다. -
X
옵션은 인증서 발행자가ipa
가 아닌webserver-ca
여야 함을 지정합니다. -
-C
옵션은 인증서를 가져온 후httpd
서비스를 다시 시작하도록certmonger
에 지시합니다.
-
특정 프로필로 인증서를 발행하도록 지정하려면
-T
옵션을 사용합니다.
-
-
인증서는 로컬
선택 사항: 요청 상태를 확인하려면 다음을 수행합니다.
# ipa-getcert list -f /etc/pki/tls/certs/httpd.pem Number of certificates and requests being tracked: 3. Request ID '20190604065735': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key' certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt' CA: IPA issuer: CN=WEBSERVER,O=IDM.EXAMPLE.COM [...]
출력은 요청이
MONITORING
상태에 있음을 보여줍니다. 즉, 인증서를 가져온 것입니다. 키 쌍과 인증서의 위치는 요청된 위치입니다.
22.5. 서비스 인증서를 요청하는 certmonger의 통신 흐름
이러한 다이어그램은 certmonger
에서 IdM(Identity Management) 인증 기관(CA) 서버에서 서비스 인증서를 요청할 때 발생하는 단계를 보여줍니다. 시퀀스는 다음 다이어그램으로 구성됩니다.
다이어그램에서 webserver-ca
하위 CA는 일반 IdM CA 서버로
표시됩니다.
암호화되지 않은 통신 에서는 초기 상황을 보여줍니다. HTTPS 인증서가 없으면 웹 서버와 브라우저 간 통신이 암호화되지 않습니다.
그림 22.3. 암호화되지 않은 통신
서비스 인증서를 요청하는 certmonger 는 certmonger
를 사용하여 Apache 웹 서버에 대한 HTTPS 인증서를 수동으로 요청하는 시스템 관리자에게 보여줍니다. 웹 서버 인증서를 요청할 때 certmonger는 CA와 직접 통신하지 않습니다. IdM을 통해 프록시합니다.
그림 22.4. 서비스 인증서 요청
서비스 인증서를 발행하는 IdM CA는 웹 서버의 HTTPS 인증서를 발행하는 IdM CA를 보여줍니다.
그림 22.5. 서비스 인증서를 발급하는 IdM CA
서비스 인증서를 적용하는 certmonger
는 IdM 클라이언트의 적절한 위치에 HTTPS 인증서를 배치하고 이를 수행하라는 지침이 있는 certmonger를 사용하여 httpd
서비스를 다시 시작합니다. Apache 서버에서는 HTTPS 인증서를 사용하여 자체와 브라우저 간 트래픽을 암호화합니다.
그림 22.6. 서비스 인증서 적용
만료일이 다가오는 경우 certmonger에서 새 인증서를 요청하는 certmonger
가 인증서 만료 전에 IdM CA에서 서비스 인증서 갱신을 자동으로 요청합니다. IdM CA는 새 인증서를 발행합니다.
그림 22.7. certmonger에서 이전 인증서가 만료되는 경우 새 인증서를 요청합니다.
22.6. 단일 인스턴스 Apache HTTP Server 설정
정적 HTML 콘텐츠를 제공하도록 단일 인스턴스 Apache HTTP Server를 설정할 수 있습니다.
웹 서버가 서버와 연결된 모든 도메인에 동일한 콘텐츠를 제공해야 하는 경우 절차를 따르십시오. 도메인마다 다른 콘텐츠를 제공하려면 이름 기반 가상 호스트를 설정합니다. 자세한 내용은 Apache 이름 기반 가상 호스트 구성을 참조하십시오.
절차
httpd
패키지를 설치합니다.# dnf install httpd
firewalld
를 사용하는 경우 로컬 방화벽에서 TCP 포트80
을 엽니다.# firewall-cmd --permanent --add-port=80/tcp # firewall-cmd --reload
httpd
서비스를 활성화하고 시작합니다.# systemctl enable --now httpd
선택 사항:
/var/www/html/
디렉터리에 HTML 파일을 추가합니다.참고콘텐츠를
/var/www/html/
에 추가할 때 기본적으로httpd
가 실행되는 사용자가 파일 및 디렉터리를 읽을 수 있어야 합니다. 콘텐츠 소유자는root
사용자 및root
사용자 그룹 또는 다른 사용자 또는 관리자가 선택한 그룹일 수 있습니다. 콘텐츠 소유자가root
사용자 및root
사용자 그룹인 경우 다른 사용자가 파일을 읽을 수 있어야 합니다. 모든 파일 및 디렉터리에 대한 SELinux 컨텍스트는 기본적으로/var/www
디렉터리 내의 모든 콘텐츠에 적용되는httpd_sys_content_t
이어야 합니다.
검증
웹 브라우저에서
http://my_company.idm.example.com/
또는http://server_IP/
에 연결합니다./var/www/html/
디렉터리가 비어 있거나index.html
또는index.htm
파일이 포함되어 있지 않은 경우 Apache에서Red Hat Enterprise Linux Test Page
를 표시합니다./var/www/html/
에 다른 이름이 있는 HTML 파일이 포함된 경우 해당 파일에 URL을 입력하여 로드할 수 있습니다(예:http://server_IP/example.html
또는http://my_company.idm.example.com/example.html
).
추가 리소스
- Apache manual: Apache HTTP Server 수동 설치.
-
시스템의
httpd.service(8)
도움말 페이지를 참조하십시오.
22.7. Apache HTTP Server에 TLS 암호화 추가
my_company.idm.example.com
Apache HTTP Server에서 idm.example.com
도메인에 TLS 암호화를 활성화할 수 있습니다.
사전 요구 사항
-
my_company.idm.example.com
Apache HTTP 서버가 설치되어 실행 중입니다. -
webserver-ca 하위 CA에서 TLS 인증서를 가져 와서 certmonger를 사용하여 서비스에 대한 IdM 인증서 가져오기 에 설명된 대로
/etc/pki/tls/certs/httpd.pem
파일에 저장했습니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다. -
해당 개인 키는
/etc/pki/tls/private/httpd.key
파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다. -
webserver-ca CA 인증서는
/etc/pki/tls/private/sub-ca.crt
파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다. - 클라이언트 및 my_company.idm.example.com 웹 서버는 서버의 호스트 이름을 웹 서버의 IP 주소로 확인합니다.
- 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 클라이언트는 확장 마스터 시크릿(Extended Master Secret) 확장을 지원하거나 TLS 1.3을 사용해야 합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.
절차
mod_ssl
패키지를 설치합니다.# dnf install mod_ssl
/etc/httpd/conf.d/ssl.conf
파일을 편집하고 다음 설정을<VirtualHost _default_:443>
지시문에 추가합니다.서버 이름을 설정합니다.
ServerName my_company.idm.example.com
중요서버 이름은 인증서의
Common Name
필드에 설정된 항목과 일치해야 합니다.선택 사항: 인증서에 SAN(
주체 Alt Names
) 필드에 추가 호스트 이름이 포함된 경우 이러한 호스트 이름에 TLS 암호화도 제공하도록mod_ssl
을 구성할 수 있습니다. 이를 구성하려면 해당 이름으로ServerAliases
매개변수를 추가합니다.ServerAlias www.my_company.idm.example.com server.my_company.idm.example.com
개인 키, 서버 인증서 및 CA 인증서에 대한 경로를 설정합니다.
SSLCertificateKeyFile "/etc/pki/tls/private/httpd.key" SSLCertificateFile "/etc/pki/tls/certs/httpd.pem" SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"
보안상의 이유로
root
사용자만 개인 키 파일에 액세스할 수 있도록 구성합니다.# chown root:root /etc/pki/tls/private/httpd.key # chmod 600 //etc/pki/tls/private/httpd.key
주의권한이 없는 사용자가 개인 키에 액세스한 경우 인증서를 취소하고 새 개인 키를 만들고 새 인증서를 요청합니다. 그렇지 않으면 TLS 연결이 더 이상 안전하지 않습니다.
firewalld
를 사용하는 경우 로컬 방화벽에서 포트443
을 엽니다.# firewall-cmd --permanent --add-port=443/tcp # firewall-cmd --reload
httpd
서비스를 다시 시작합니다.# systemctl restart httpd
참고개인 키 파일을 암호로 보호한 경우
httpd
서비스가 시작될 때마다 이 암호를 입력해야 합니다.-
브라우저를 사용하여
https://my_company.idm.example.com
에 연결합니다.
-
브라우저를 사용하여
추가 리소스
22.8. Apache HTTP Server에서 지원되는 TLS 프로토콜 버전 설정
기본적으로 RHEL의 Apache HTTP Server는 최신 브라우저와 호환되는 안전한 기본값을 정의하는 시스템 전체 암호화 정책을 사용합니다. 예를 들어 DEFAULT
정책은 apache에서 TLSv1.2
및 TLSv1.3
프로토콜 버전만 사용하도록 정의합니다.
my_company.idm.example.com Apache HTTP Server에서 지원하는 TLS 프로토콜 버전을 수동으로 구성할 수 있습니다. 환경에서 특정 TLS 프로토콜 버전만 활성화해야 하는 경우 절차를 따르십시오. 예를 들면 다음과 같습니다.
-
환경에 해당 클라이언트가 클라이언트가 취약한
TLS1
(TLSv1.0) 또는TLS1.1
프로토콜을 사용할 수도 있어야 하는 경우 -
Apache가
TLSv1.2
또는TLSv1.3
프로토콜만 지원하도록 구성하려는 경우
사전 요구 사항
- Apache HTTP 서버에 TLS 암호화 추가에 설명된 대로 my_company.idm.example.com 서버에서 TLS 암호화가 활성화되어 있습니다.
- 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 클라이언트는 확장 마스터 시크릿(Extended Master Secret) 확장을 지원하거나 TLS 1.3을 사용해야 합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.
절차
/etc/httpd/conf/httpd.conf
파일을 편집하고 다음 설정을 TLS 프로토콜 버전을 설정하려는<VirtualHost>
지시문에 추가합니다. 예를 들어TLSv1.3
프로토콜만 활성화하려면 다음을 수행합니다.SSLProtocol -All TLSv1.3
httpd
서비스를 다시 시작합니다.# systemctl restart httpd
검증
다음 명령을 사용하여 서버가
TLSv1.3
을 지원하는지 확인합니다:# openssl s_client -connect example.com:443 -tls1_3
다음 명령을 사용하여 서버가
TLSv1.2
를 지원하지 않는지 확인합니다.# openssl s_client -connect example.com:443 -tls1_2
서버가 프로토콜을 지원하지 않으면 명령에서 오류를 반환합니다.
140111600609088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70
- 선택 사항: 다른 TLS 프로토콜 버전에 대해 명령을 반복합니다.
추가 리소스
-
시스템의
update-crypto-policies(8)
도움말 페이지 - 시스템 전체 암호화 정책 사용.
-
SSLProtocol
매개변수에 대한 자세한 내용은 Apache 설명서의mod_ssl
문서를 참조하십시오. Apache HTTP 서버 설명서 설치.
22.9. Apache HTTP Server에서 지원되는 암호 설정
기본적으로 Apache HTTP 서버는 최근 브라우저와 호환되는 안전한 기본값을 정의하는 시스템 전체 암호화 정책을 사용합니다. 시스템 전체에서 허용하는 암호 목록은 /etc/crypto-policies/back-ends/openssl.config
파일을 참조하십시오.
my_company.idm.example.com Apache HTTP 서버가 지원하는 암호를 수동으로 구성할 수 있습니다. 환경에 특정 암호가 필요한 경우 절차를 따르십시오.
사전 요구 사항
절차
/etc/httpd/conf/httpd.conf
파일을 편집하고SSLCipherSuite
매개변수를 TLS 암호를 설정하려는<VirtualHost>
지시문에 추가합니다.SSLCipherSuite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SHA1:!SHA256"
이 예제에서는
EECDH+AESGCM
,EDH+AESGCM
,AES256+EECDH
및AES256+EDH
암호만 활성화하며SHA1
및SHA256
메시지 인증 코드(MAC)를 사용하는 모든 암호를 비활성화합니다.httpd
서비스를 다시 시작합니다.# systemctl restart httpd
검증
Apache HTTP Server에서 지원하는 암호 목록을 표시하려면 다음을 수행합니다.
nmap
패키지를 설치합니다.# dnf install nmap
nmap
유틸리티를 사용하여 지원되는 암호를 표시합니다.# nmap --script ssl-enum-ciphers -p 443 example.com ... PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A ...
추가 리소스
-
시스템의
update-crypto-policies(8)
도움말 페이지 - 시스템 전체 암호화 정책 사용.
- Apache HTTP Server 설명서 설치 - SSLCipherSuite
22.10. TLS 클라이언트 인증서 인증 구성
클라이언트 인증서 인증을 사용하면 관리자는 인증서를 사용하여 인증한 사용자만 my_company.idm.example.com 웹 서버의 리소스에 액세스할 수 있습니다. /var/www/html/Example/
디렉터리에 대한 클라이언트 인증서 인증을 구성할 수 있습니다.
my_company.idm.example.com Apache 서버에서 TLS 1.3 프로토콜을 사용하는 경우 특정 클라이언트에 추가 구성이 필요합니다. 예를 들어 Firefox에서 about:config
메뉴의 security.tls.enable_post_handshake_auth
매개 변수를 true
로 설정합니다. 자세한 내용은 Red Hat Enterprise Linux 8의 전송 계층 보안 버전 1.3을 참조하십시오.
사전 요구 사항
절차
/etc/httpd/conf/httpd.conf
파일을 편집하고 다음 설정을 클라이언트 인증을 구성하려는<VirtualHost>
지시문에 추가합니다.<Directory "/var/www/html/Example/"> SSLVerifyClient require </Directory>
SSLverifyClient require
를 설정해야 클라이언트가/var/www/html/Example/
디렉터리의 콘텐츠에 액세스하기 전에 서버가 클라이언트 인증서의 유효성을 검사해야 합니다.httpd
서비스를 다시 시작합니다.# systemctl restart httpd
검증
curl
유틸리티를 사용하여 클라이언트 인증 없이https://my_company.idm.example.com/Example/
URL에 액세스합니다.$ curl https://my_company.idm.example.com/Example/ curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0
이 오류는 my_company.idm.example.com 웹 서버에 클라이언트 인증서 인증이 필요함을 나타냅니다.
클라이언트 개인 키 및 인증서와 CA 인증서를
curl
에 전달하여 클라이언트 인증으로 동일한 URL에 액세스합니다.$ curl --cacert ca.crt --key client.key --cert client.crt https://my_company.idm.example.com/Example/
요청이 성공하면
curl
은/var/www/html/Example/
디렉터리에 저장된index.html
파일을 표시합니다.
22.11. 새 사용자 인증서 요청 및 클라이언트로 내보내기
IdM(Identity Management) 관리자는 IdM 클라이언트에서 실행되는 웹 서버를 구성하여 웹 브라우저를 사용하여 서버에 액세스하여 특정 IdM 하위 명령에서 발급한 인증서로 인증하는 사용자를 요청할 수 있습니다. 다음 절차에 따라 특정 IdM 하위 CA에서 사용자 인증서를 요청하고 인증서와 해당 개인 키를 사용자가 웹 브라우저를 사용하여 웹 서버에 액세스하려는 호스트로 내보냅니다. 그런 다음 인증서와 개인 키를 브라우저로 가져옵니다.
절차
선택 사항: 새 디렉터리(예:
~/certdb/
)를 생성하고 임시 인증서 데이터베이스로 설정합니다. 메시지가 표시되면 NSS 인증서 DB 암호를 생성하여 후속 단계에서 생성할 인증서에 대한 키를 암호화합니다.# mkdir
~/certdb/
# certutil -N -d~/certdb/
Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password:CSR(인증서 서명 요청)을 생성하고 출력을 파일로 리디렉션합니다. 예를 들어
IDM.EXAMPLE.COM
영역에 있는idm_user
사용자의4096
비트 인증서에 대해certificate_request.csr
이라는 이름으로 CSR을 생성하려면 인증서 개인 키의 nickname을 쉽게 찾을 수 있도록idm_user
로 설정하고CN=idm_user,O=IDMM.EXALE :COM으로 설정합니다.
# certutil -R -d
~/certdb/
-a -g4096
-nidm_user
-s "CN=idm_user
,O=IDM.EXAMPLE.COM" >certificate_request.csr
메시지가 표시되면
certutil
을 사용하여 임시 데이터베이스를 생성할 때 입력한 암호와 동일한 암호를 입력합니다. 다음으로 중지될 때까지 randlomly를 계속 입력합니다.Enter Password or Pin for "NSS Certificate DB": A random seed must be generated that will be used in the creation of your key. One of the easiest ways to create a random seed is to use the timing of keystrokes on a keyboard. To begin, type keys on the keyboard until this progress meter is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD! Continue typing until the progress meter is full:
인증서 요청 파일을 서버에 제출합니다. 새로 발급된 인증서, 인증서를 저장할 출력 파일, 선택적으로 인증서 프로필과 연결할 Kerberos 주체를 지정합니다. 인증서를 발행할 IdM 하위 CA를 지정합니다. 예를 들어,
webclient-ca
의idm_user
@IDM.EXAMPLE.COM
주체에 대한 사용자 역할 확장이 추가된 프로필인IECUserRoles
프로필의 인증서를 얻으려면~/idm_user.pem
파일에 인증서를 저장합니다.# ipa cert-request
certificate_request.csr
--principal=idm_user
@IDM.EXAMPLE.COM
--profile-id=IECUserRoles
--ca=webclient-ca
--certificate-out=~/idm_user.pem
NSS 데이터베이스에 인증서를 추가합니다.
-n
옵션을 사용하여 이전에 CSR을 생성할 때 사용한 것과 동일한 nickname을 설정하여 인증서가 NSS 데이터베이스의 개인 키와 일치하도록 합니다.t
옵션은 신뢰 수준을 설정합니다. 자세한 내용은 certutil(1) 매뉴얼 페이지를 참조하십시오.i
옵션은 입력 인증서 파일을 지정합니다. 예를 들어 NSS 데이터베이스에~/certdb/
데이터베이스의~/
파일에 저장된 idm_user nickname을 사용하여 인증서를 추가하려면 다음을 수행합니다.idm_user
.pem# certutil -A -d
~/certdb/
-nidm_user
-t "P,," -i~/idm_user.pem
NSS 데이터베이스의 키가 닉네임
(orphan)
으로 표시되지 않는지 확인합니다. 예를 들어~/certdb/
데이터베이스에 저장된 인증서가 분리되지 않았는지 확인하려면 다음을 수행합니다.# certutil -K -d
~/certdb/
< 0> rsa 5ad14d41463b87a095b1896cf0068ccc467df395 NSS Certificate DB:idm_userpk12util
명령을 사용하여 NSS 데이터베이스에서 PKCS12 형식으로 인증서를 내보냅니다. 예를 들어idm_user
nickname을 사용하여 인증서를/root/certdb
NSS 데이터베이스에서~/idm_user.p12
파일로 내보내려면 다음을 실행합니다.# pk12util -d
~/certdb
-o~/idm_user.p12
-nidm_user
Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFULidm_user
의 인증서 인증을 활성화할 호스트에 인증서를 전송합니다.# scp
~/idm_user.p12
idm_user@client.idm.example.com:/home/idm_user/
인증서가 전송된 호스트에서 .pkcs12 파일이 저장된 디렉토리를 보안상의 이유로 'other' 그룹에 저장할 수 없도록 합니다.
# chmod o-rwx
/home/idm_user/
보안상의 이유로 서버에서 임시 NSS 데이터베이스 및 .pkcs12 파일을 제거하십시오.
# rm
~/certdb/
# rm~/idm_user.p12
22.12. 인증서 인증을 사용하도록 브라우저 구성
WebUI를 사용하여 IdM(Identity Management)에 로그인할 때 인증서로 인증할 수 있으려면 사용자와 관련 인증 기관(CA) 인증서를 Mozilla Firefox 또는 Google Chrome 브라우저로 가져와야 합니다. 브라우저가 실행 중인 호스트 자체는 IdM 도메인의 일부가 될 필요가 없습니다.
IdM은 다음 브라우저를 지원하여 WebUI 연결을 지원합니다.
- Mozilla Firefox 38 이상
- Google Chrome 46 이상
다음 절차에서는 Mozilla Firefox 57.0.1 브라우저를 구성하는 방법을 보여줍니다.
사전 요구 사항
- PKCS#12 형식으로든 브라우저로 가져올 사용자 인증서 가 있습니다.
- 하위 CA 인증서를 다운로드하여 PEM 형식으로 폐기합니다.
절차
Firefox를 연 다음
기본 설정
→개인 정보 보호 및 보안
으로 이동합니다.그림 22.8. 기본 설정의 개인 정보 및 보안 섹션
그림 22.9. 개인 정보 보호 및 보안의 인증서 보기
-
인증서
탭에서 를 클릭합니다. PKCS12 형식으로 사용자 인증서를 찾아서 연 다음 클릭합니다. IdM 하위 CA가 Firefox에서 신뢰할 수 있는 기관으로 인식되도록 하려면 IdM WebUI에서 하위 CA 인증서를 신뢰할 수 있는 인증 기관 인증서로 다운로드할 때 저장한 IdM 하위 CA 인증서를 가져옵니다.
Firefox를 열고 기본 설정으로 이동하고
.그림 22.10. 기본 설정의 개인 정보 및 보안 섹션
그림 22.11. 개인 정보 보호 및 보안의 인증서 보기
-
Authorities
(권한) 탭에서 (가져오기)를 클릭합니다. 하위 CA 인증서를 찾아서 엽니다. 인증서를 신뢰하여 웹 사이트를 식별한 다음 클릭합니다.
24장. IdM 상태 점검을 사용하여 인증서 확인
IdM(Identity Management)의 Healthcheck 툴을 이해하고 사용하여 certmonger
에서 유지 관리하는 IPA 인증서의 문제를 식별하는 방법에 대해 자세히 알아보십시오.
자세한 내용은 IdM의 상태 점검을 참조하십시오.
24.1. IdM 인증서 상태 점검 테스트
Healthcheck 툴에는 IdM(Identity Management)의 certmonger에서 유지 관리하는 인증서 상태를 확인하는 여러 테스트가 포함됩니다. certmonger에 대한 자세한 내용은 certmonger를 사용하여 서비스에 대한 IdM 인증서 Obtaining an IdM certificate 을 참조하십시오.
이 테스트 검사 모음의 만료, 검증, 신뢰 및 기타 문제. 동일한 기본 문제에 대해 여러 오류가 발생할 수 있습니다.
모든 인증서 테스트를 보려면 --list-sources
옵션을 사용하여 ipa-healthcheck
을 실행합니다.
# ipa-healthcheck --list-sources
ipahealthcheck.ipa.certs
소스에서 모든 테스트를 찾을 수 있습니다.
- IPACertmongerExpirationCheck
이 테스트에서는
certmonger
의 만료를 확인합니다.오류가 보고되면 인증서가 만료되었습니다.
경고가 표시되면 인증서가 곧 만료됩니다. 기본적으로 이 테스트는 인증서가 만료되기 전 28일 이내에 적용됩니다.
/etc/ipahealthcheck/ipahealthcheck.conf
파일에서 일 수를 구성할 수 있습니다. 파일을 연 후 default 섹션에 있는cert_expiration_days
옵션을 변경합니다.참고certmonger는 인증서 만료에 대한 자체 보기를 로드하고 유지합니다. 이 검사에서는 디스크상의 인증서의 유효성을 검사하지 않습니다.
- IPACertfileExpirationCheck
이 테스트에서는 인증서 파일 또는 NSS 데이터베이스를 열 수 없는지 확인합니다. 이 테스트는 또한 만료를 확인합니다. 따라서 오류 또는 경고 출력에서
msg
속성을 주의 깊게 읽습니다. 메시지는 문제를 지정합니다.참고이 테스트에서는 디스크상의 인증서를 확인합니다. 인증서가 누락된 경우 읽을 수 없으므로 별도의 오류도 발생할 수 있습니다.
- IPACertNSSTrust
- 이 테스트에서는 NSS 데이터베이스에 저장된 인증서에 대한 신뢰를 비교합니다. NSS 데이터베이스에서 예상되는 추적된 인증서의 경우 신뢰는 예상 값과 비교되며 일치하지 않는 항목에서 발생하는 오류입니다.
- IPANSSChainValidation
-
이 테스트에서는 NSS 인증서의 인증서 체인의 유효성을 검사합니다. 테스트 실행:
certutil -V -u V -e -d [dbdir] -n [nickname]
- IPAOpenSSLChainValidation
이 테스트에서는 OpenSSL 인증서의 인증서 체인을 검증합니다.
NSSChain
검증과 비교하려면 다음을 실행하는 OpenSSL 명령을 실행합니다.openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt [cert file]
- IPARAAgent
-
이 테스트에서는 디스크의 인증서를
uid=ipara,ou=People,o=ipaca
의 LDAP의 동등한 레코드와 비교합니다. - IPACertRevocation
- 이 테스트에서는 certmonger를 사용하여 인증서가 취소되지 않았는지 확인합니다. 따라서 이 테스트는 certmonger에서만 유지 관리하는 인증서와 관련된 문제를 찾을 수 있습니다.
- IPACertmongerCA
이 테스트는 certmonger CA(인증 기관) 구성을 확인합니다. IdM은 CA 없이 인증서를 발행할 수 없습니다.
certmonger는 CA 도우미 세트를 유지합니다. IdM에는 IdM을 통해 인증서를 발행하고 호스트 또는 서비스 인증서에 대한 호스트 또는 사용자 주체로 인증하는 IPA라는 CA가 있습니다.
CA 하위 시스템 인증서를 갱신하는
dogtag-ipa-ca-renew-agent
및dogtag-ipa-ca-renew-agent-reuse
도 있습니다.
문제를 확인하려고 할 때 모든 IdM 서버에서 이 테스트를 실행합니다.
24.2. Healthcheck 도구를 사용하여 인증서 확인
Healthcheck 툴을 사용하여 IdM(Identity Management) 인증서 상태 점검의 독립 실행형 수동 테스트를 실행하려면 다음 절차를 따르십시오.
Healthcheck 툴에는 많은 테스트가 포함되어 있으므로 다음과 같이 결과를 단축할 수 있습니다.
-
모든 성공적인 테스트 제외:
--failures-only
-
인증서 테스트만 포함:
--source=ipahealthcheck.ipa.certs
사전 요구 사항
-
root
사용자로 상태 점검 테스트를 수행해야 합니다.
절차
인증서와 관련된 경고, 오류 및 심각한 문제로 Healthcheck를 실행하려면 다음을 입력합니다.
# ipa-healthcheck --source=ipahealthcheck.ipa.certs --failures-only
테스트에 빈 대괄호가 표시됩니다.
[]
실패한 테스트에서는 다음 출력을 보여줍니다.
{ "source": "ipahealthcheck.ipa.certs", "check": "IPACertfileExpirationCheck", "result": "ERROR", "kw": { "key": 1234, "dbdir": "/path/to/nssdb", "error": [error], "msg": "Unable to open NSS database '/path/to/nssdb': [error]" } }
이 IPACertfileExpirationCheck
test가 NSS 데이터베이스를 여는 데 실패했습니다.
추가 리소스
-
man ipa-healthcheck
를 참조하십시오.
25장. IdM 상태 점검을 사용하여 시스템 인증서 확인
Healthcheck 툴을 사용하여 IdM(Identity Management)에서 시스템 인증서 문제 식별에 대해 자세히 알아보십시오.
자세한 내용은 참조하십시오.
25.1. 시스템 인증서 상태 점검 테스트
Healthcheck 툴에는 시스템(DogTag) 인증서를 확인하기 위한 여러 테스트가 포함되어 있습니다.
모든 테스트를 보려면 --list-sources
옵션을 사용하여 ipa-healthcheck
을 실행합니다.
# ipa-healthcheck --list-sources
ipahealthcheck.dogtag.ca
소스에서 모든 테스트를 찾을 수 있습니다.
- DogtagCertsConfigCheck
이 테스트에서는 NSS 데이터베이스의 CA(Certificate Authority) 인증서를
CS.cfg
에 저장된 동일한 값과 비교합니다. 일치하지 않으면 CA가 시작되지 않습니다.특히 확인을 수행합니다.
-
auditSigningCert cert-pki-ca
againstca.audit_signing.cert
-
ocspSigningCert cert-pki-ca
againstca.ocsp_signing.cert
-
caSigningCert cert-pki-ca
againstca.signing.cert
-
subsystemCert cert-pki-ca
againstca.subsystem.cert
-
server-Cert cert-pki-ca
againstca.sslserver.cert
키 복구 기관(KRA)이 설치된 경우:
-
transportCert cert-pki-kra
againstca.connector.KRA.transportCert
-
- DogtagCertsConnectivityCheck
이 테스트에서는 연결을 확인합니다. 이 테스트는 검사를 수행하는
ipa cert-show 1
명령과 동일합니다.- Apache의 PKI 프록시 구성
- IdM에서 CA를 찾을 수 있음
- RA 에이전트 클라이언트 인증서
- 요청에 대한 CA 응답의 수정
cert-show
를 실행할 수 있는지 확인하고 CA(인증서 또는 찾을 수 없음)에서 예상 결과를 반환할 수 있으므로 테스트에서 직렬 #1로 인증서를 확인합니다.
문제를 해결하려고 할 때 모든 IdM 서버에서 이 테스트를 실행합니다.
25.2. Healthcheck를 사용하여 시스템 인증서 확인
Healthcheck 툴을 사용하여 IdM(Identity Management) 인증서의 독립 실행형 수동 테스트를 실행하려면 다음 절차를 따르십시오.
상태 점검 툴에는 많은 테스트가 포함되어 있으므로 DogTag tests: --source=ipahealthcheck.dogtag.ca
만 포함하면 결과를 좁힐 수 있습니다.
절차
Healthcheck restricted를 DogTag 인증서로 제한하려면 다음을 입력합니다.
# ipa-healthcheck --source=ipahealthcheck.dogtag.ca
성공적인 테스트의 예:
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: SUCCESS", "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c", "when: 20191008135826Z", "duration: 0.252280", "kw:" { "key": "Server-Cert cert-pki-ca", "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg" } }
실패한 테스트의 예는 다음과 같습니다.
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: CRITICAL", "uuid: 59d66200-1447-4b3b-be01-89810c803a98", "when: 20191008135912Z", "duration: 0.002022", "kw:" { "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized", } }
추가 리소스
-
man ipa-healthcheck
를 참조하십시오.
26장. IdM에서 내부적으로 사용하는 인증서 이해
CA(통합 인증 기관)를 사용하거나 CA 없이 Red Hat IdM(Identity Management) 서버를 설치할 수 있습니다. IdM에 액세스하고 관리하는 데 필요한 인증서는 CA 통합 여부에 따라 다르게 관리됩니다.
-
통합 CA:
certmonger
에 의해 인증서가 자동으로 생성되고 추적됩니다.certmonger
는 인증서를 자동으로 갱신하여 IdM 서비스의 지속적인 유효성을 보장합니다. - CA가 없으면 타사 기관에서 인증서를 요청합니다. 이 경우 만료 시간을 모니터링하고 IdM 서비스의 지속적인 유효성을 보장하기 위해 갱신되어야 합니다.
26.1. IdM의 내부 인증서 정보
Red Hat IdM(Identity Management)은 LDAP 서버 및 HTTP 서버를 포함하여 네트워크를 사용하여 액세스하는 많은 서비스를 사용합니다. 서버 인증서가 필요한 SSL/TLS 포트를 사용하여 이러한 서비스에 액세스합니다. IdM 서버를 설치하는 동안 HTTP 및 LDAP 서버 인증서가 필요합니다.
IdM을 설치하고 구성하는 방법에 따라 여러 가지 방법으로 인증서를 가져올 수 있습니다.
외부 CA에서 자체 서명하거나 서명할 수 있는 통합 CA를 사용하여 IdM에서 관리하는 사용자, 호스트 및 서비스에 대한 모든 인증서를 발행하고 인증서 파일을 제공할 필요가 없습니다.
certmonger
는 인증서의 만료 날짜를 자동으로 모니터링하고 필요한 경우 자동으로 갱신됩니다.외부 서명된 CA 사용: 설치는 여러 단계 프로세스입니다.
-
CSR을 생성하려면
--external-ca
옵션으로 설치를 실행해야 합니다. - CSR을 외부 CA에 제출하고 발급된 인증서 및 CA 인증서 체인을 PEM 파일 또는 Base64 인코딩 인증서로 검색합니다.
IdM 서버 설치를 다시 실행하여 새로 발급한 CA 인증서 및 CA 체인 파일의 위치와 이름을 지정합니다. IdM 인증 기관은 외부 CA의 하위 CA로 구성되며 이 하위 CA는 필요한 HTTP 및 LDAP 서버 인증서를 발행합니다.
certmonger
는 인증서의 만료 날짜를 자동으로 모니터링하고 필요한 경우 자동으로 갱신됩니다.
-
CSR을 생성하려면
CA가 없으면 타사 기관에서 다음 인증서를 요청해야 합니다.
- LDAP 서버 인증서
- Apache 서버 인증서
- PKINIT 인증서
LDAP 및 Apache 서버 인증서를 발급한 CA의 전체 CA 인증서 체인
이러한 인증서는
certmonger
에 의해 추적되지 않으며 관리자는 만료 날짜에 도달하기 전에 갱신할 책임이 있습니다.
추가 리소스
26.2. IdM 내부 인증서
내부 인증서는 IdM을 설치하는 방법과 해당 설치에 포함된 구성 요소에 따라 달라질 수 있습니다. 해당 설치에 따라 다음 인증서가 시스템에 저장되어 있을 수 있습니다.
IdM CA 인증서
IdM CA 인증서는 다른 모든 인증서에 서명하는 데 IdM에서 사용됩니다. CA가 없는 설치에는 존재하지 않습니다.
caSigningCert | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 |
|
issuer | 외부 CA에서 자체 서명 또는 서명 |
제목 |
이는 기본값이지만 IdM 서버 설치 중에 사용자 지정할 수 있습니다. |
추가 정보 |
|
외부 CA 인증서
외부 CA를 사용하는 경우 IdM 인증서를 확인하려면 IdM에서 외부 CA 체인을 사용할 수 있어야 합니다. CA가 없는 설치의 경우 LDAP 및 /etc/ipa/ca.crt
디렉터리에 HTTPD 및 LDAP 인증서를 검증하는 외부 CA 인증서가 다양한 위치에 있어야 합니다.
설치 중에 자동으로 수행되므로 필요한 모든 위치에 외부 CA 인증서를 수동으로 추가할 필요는 없습니다. 그러나 외부 CA 인증서가 나중에 업데이트되면 외부 CA를 사용하여 IdM CA 갱신 서버 인증서 업데이트 단계를 수행하여 새 인증서가 필요한 모든 위치에 추가되었는지 확인해야 합니다.
외부 인증서 | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 |
|
issuer | 외부 CA 서명 |
제목 | 외부 CA 제목 |
추가 정보 |
체인에 DER 형식의 모든 인증서가 있어야 하며 LDAP로 가져와야 합니다. NSS 데이터베이스에 |
하위 시스템 CA 인증서
이 인증서는 LDAP 데이터베이스에 작성할 때 LDAP 서버를 인증하는 데 사용됩니다. 이 인증서는 CA가 없는 설치에는 없습니다.
subsystemCert | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 |
|
issuer | IPA CA |
제목 |
|
추가 정보 |
LDAP에서 직렬 및 Blob 불일치를 주의하십시오. 예를 들어 |
감사 서명 인증서
이 인증서는 감사 로그에 서명하는 데 사용됩니다. CA가 없는 설치에는 존재하지 않습니다.
auditSigningCert | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 |
|
issuer | IPA CA |
제목 |
|
추가 정보 |
NSS 데이터베이스에 |
OCSP 서명 인증서
이 인증서는 OCSP(Online Certificate Status Protocol) 서비스를 제공하는 데 사용됩니다. CA가 없는 설치에는 존재하지 않습니다.
ocspSigningCert | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 |
|
issuer | IPA CA |
제목 |
|
추가 정보 |
Tomcat 서블릿 인증서
이 인증서는 클라이언트가 PKI에 연결할 때 사용됩니다. 이 서버 인증서는 호스트에 고유하며 CA가 없는 설치에 존재하지 않습니다.
서버-인증 | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 | |
issuer | IPA CA |
제목 | CN=$HOSTNAME,O=REALM.NAME |
추가 정보 |
등록 기관 인증서
certmonger
및 IdM 프레임워크에서 PKI에 인증하는 데 사용하는 인증서입니다. 예를 들어 ipa cert-show 1
을 실행하는 경우 HTTPD는 PKI와 통신하고 이 인증서로 인증합니다. CA가 없는 설치에는 존재하지 않습니다.
RA 에이전트 | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 |
|
issuer | IPA CA |
제목 |
|
추가 정보 |
LDAP에서 직렬 및 Blob 불일치를 주의하십시오. 예를 들어 |
HTTPD 프런트 엔드 인증서
HTTPD 프런트 엔드에 웹 UI 및 API에 대한 연결을 보호하는 데 사용되는 인증서입니다. 존재할 수 있어야 합니다.
HTTPD | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 | |
issuer | CA가 없는 설치의 IPA CA 또는 외부 CA |
제목 |
|
추가 정보 |
사용자 이름이 |
LDAP TLS 및 STARTTLS 인증서
LDAP TLS 및 STARTTLS 연결에 사용되는 인증서입니다. 존재할 수 있어야 합니다.
LDAP | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 | |
issuer | CA가 없는 설치의 IPA CA 또는 외부 CA |
제목 |
|
추가 정보 |
사용자 이름이 |
KDC 인증서
IdM KDC에 PKINIT에 사용되는 인증서입니다.
KDC | 설명 |
---|---|
파일 시스템 위치 |
|
LDAP 위치 | |
issuer | CA가 없는 설치의 IPA CA 또는 외부 CA |
제목 |
|
추가 정보 |
확장된 키 사용량 |
26.3. IdM 내부 인증서 갱신 프로세스
기본적으로 certmonger
는 내부 인증서를 추적하고 갱신을 트리거하고 IdM CA를 요청하여 새 인증서를 발행합니다.
외부 CA를 사용하고 있고 내부 인증서가 이 CA에서 발급된 경우 자동으로 갱신되지 않습니다. 이 경우 인증서 만료 날짜를 모니터링하여 만료되기 전에 갱신해야 합니다. 갱신 프로세스는 시간이 오래 걸리며 만료 날짜를 신중하게 추적하지 않으면 인증서가 만료되고 일부 서비스를 더 이상 사용할 수 없습니다.
내부 IdM(Red Hat Identity Management) 인증서가 만료되면 IdM이 시작되지 않습니다.
IdM CA 갱신 서버는 만료일보다 28일 전에 공유 내부 인증서를 갱신합니다. certmonger
는 이 갱신을 트리거하고 새 인증서를 cn=<nickname>,cn=ca_renewal,cn=ipa,cn=etc,$BASEDN
에 업로드합니다. certmonger
는 다른 IdM 서버에서 갱신 프로세스를 트리거하지만 CA가 아닌 갱신 서버에서 실행되므로 새 인증서를 요청하지 않지만 LDAP에서 인증서를 다운로드합니다. Server-Cert cert-pki-ca
, HTTP, LDAP 및 PKINIT 인증서는 제목의 호스트 이름을 포함하는 각 복제본에 고유합니다.
인증서가 만료되기 전에 getcert
를 사용하여 공유 인증서를 수동으로 갱신하면 갱신 프로세스가 다른 복제본에서 트리거되지 않으며 LDAP에서 갱신된 인증서 다운로드를 수행하려면 다른 복제본에서 getcert
를 실행해야 합니다.