자습서: 테스트를 위한 인증서 만들기 및 업로드
X.509 인증서를 사용하여 디바이스를 IoT 허브에 인증할 수 있습니다. 프로덕션 환경의 경우 전문 인증서 서비스 공급업체로부터 X.509 CA 인증서를 구매하는 것이 좋습니다. 그런 다음 포괄적인 공개 키 인프라(PKI) 전략의 일환으로 구매한 CA 인증서에 연결된 내부 자체 관리 인증 기관(CA)을 통해, 조직 내에서 인증서를 발급할 수 있습니다. 전문 인증서 서비스 공급업체가 제공하는 CA에서 X.509 CA 인증서를 가져오는 방법에 대한 자세한 내용은 X.509 CA 인증서를 사용하여 디바이스 인증의 X.509 CA 인증서 가져오기 섹션을 참조하세요.
그러나 내부 루트 CA를 신뢰 앵커로 사용하는 자체 관리 프라이빗 CA를 만드는 것은 환경 테스트에 적합합니다. 내부 루트 CA에 하나 이상의 하위 CA가 연결된 자체 관리 프라이빗 CA를 하위 CA에서 서명한 디바이스용 클라이언트 인증서와 함께 사용하면, 권장 프로덕션 환경을 시뮬레이션할 수 있습니다.
Important
프로덕션 환경에는 자체 서명된 인증서를 사용하지 않는 것이 좋습니다. 이 자습서는 예시용으로만 제공됩니다.
다음 자습서에서는 OpenSSL과 OpenSSL Cookbook을 사용하여 다음 작업을 수행하는 방법을 설명합니다.
- 내부 루트 인증 기관(CA) 및 루트 CA 인증서 만들기
- 내부 루트 CA 인증서로 서명한 내부 하위 CA 및 하위 CA 인증서 만들기
- 테스트를 위해 IoT 허브에 하위 CA 인증서 업로드
- IoT 허브를 이용해 테스트할 IoT 디바이스에 대한 클라이언트 인증서를 하위 CA를 사용하여 만들기
참고 항목
Microsoft는 사용자 고유의 X.509 인증서를 만들어 IoT 허브에서 인증을 받는 방법을 이해하는 데 도움이 되는 PowerShell 및 Bash 스크립트를 제공합니다. 스크립트는 C용 Azure IoT 허브 디바이스 SDK에 포함되어 있습니다. 스크립트는 데모용으로만 제공됩니다. 만든 인증서는 프로덕션에 사용할 수 없습니다. 인증서는 하드 코딩된 암호("1234")를 포함하며 30일 후에 만료됩니다. 프로덕션 환경에서는 인증서 만들기 및 수명 관리를 위해 고유한 모범 사례를 사용해야 합니다. 자세한 내용은 C용 Azure IoT Hub 디바이스 SDK에 대한 GitHub 리포지토리에서 샘플 및 자습서를 위한 테스트 CA 인증서 관리를 참조하세요.
필수 구성 요소
Azure 구독 Azure 구독이 아직 없는 경우 시작하기 전에 체험 계정을 만듭니다.
Azure 구독의 IoT Hub 아직 허브가 없는 경우 IoT Hub 만들기의 단계를 따를 수 있습니다.
Git의 최신 버전입니다. Git이 명령 창에 액세스할 수 있는 환경 변수에 추가되었는지 확인합니다. 설치할
git도구의 최신 버전은 Software Freedom Conservancy의 Git 클라이언트 도구를 참조하세요. 여기에는 로컬 Git 리포지토리와 상호 작용하는 데 사용할 수 있는 명령줄 앱인 Git Bash가 포함됩니다.OpenSSL 설치입니다. Windows에서 Git 설치에는 OpenSSL 설치가 포함됩니다. Git Bash 프롬프트에서 OpenSSL에 액세스할 수 있습니다. OpenSSL이 설치되었는지 확인하려면 Git Bash 프롬프트를 열고
openssl version을 입력합니다.참고 항목
OpenSSL에 익숙하지 않고 Windows 컴퓨터에 이미 설치되어 있지 않은 경우 Git Bash 프롬프트에서 OpenSSL을 사용하는 것이 좋습니다. 또는 소스 코드를 다운로드하고 OpenSSL을 빌드하도록 선택할 수 있습니다. 자세한 내용은 OpenSSL 다운로드 페이지를 참조하세요. 또는 타사에서 사전 빌드된 OpenSSL을 다운로드할 수 있습니다. 자세한 내용은 OpenSSL 위키를 참조하세요. Microsoft는 타사에서 다운로드한 패키지의 유효성에 대해 보증하지 않습니다. OpenSSL을 빌드하거나 다운로드하기로 선택한 경우 경로에서 OpenSSL 이진 파일에 액세스할 수 있고
OPENSSL_CNF환경 변수가 openssl.cnf 파일의 경로로 설정되어 있는지 확인합니다.
루트 CA 만들기
테스트를 위해 다른 인증서를 만들 수 있는 신뢰 앵커 역할을 하려면 먼저 내부 루트 인증 기관(CA) 및 자체 서명된 루트 CA 인증서를 만들어야 합니다. 내부 루트 CA를 만들고 유지 관리하는 데 사용하는 파일은 폴더 구조에 저장되고 이 프로세스의 일부로서 초기화됩니다. 다음 단계를 수행합니다.
- 루트 CA에서 사용하는 폴더와 파일 만들기 및 초기화
- 루트 CA 및 루트 CA를 사용하여 만든 인증서를 구성하기 위해, OpenSSL에서 사용하는 구성 파일 만들기
- 루트 CA 인증서 역할을 하는 자체 서명된 CA 인증서 요청 및 만들기
Git Bash 창을 시작하고 다음 명령을 실행하여
{base_dir}을(를) 이 자습서의 인증서를 생성할 디렉터리로 바꿉니다.cd {base_dir}Git Bash 창에서 다음 명령을 한 번에 하나씩 실행합니다. 이 단계에서는 루트 CA에 대한 다음 디렉터리 구조 및 지원 파일을 만듭니다.
디렉터리 또는 파일 설명 rootca 루트 CA의 루트 디렉터리입니다. rootca/certs 루트 CA에 대한 CA 인증서가 생성되고 저장되는 디렉터리입니다. rootca/db 루트 CA에 대한 인증서 데이터베이스와 지원 파일이 저장되는 디렉터리입니다. rootca/db/index 루트 CA에 대한 인증서 데이터베이스입니다. touch명령은 나중에 사용할 수 있도록 콘텐츠 없는 파일을 만듭니다. 인증서 데이터베이스는 발급된 인증서에 대한 정보를 포함하는 OpenSSL에서 관리하는 일반 텍스트 파일입니다. 인증서 데이터베이스에 대한 자세한 내용은 openssl-ca 수동 페이지를 참조하세요.rootca/db/serial 루트 CA를 위해 생성할 다음 인증서의 일련 번호를 저장하는 데 사용되는 파일입니다. openssl명령은 16바이트 난수를 16진수 형식으로 만든 다음, 이 파일에 저장하여 루트 CA 인증서를 만드는 데 필요한 파일을 초기화합니다.rootca/db/crlnumber 루트 CA에서 발급한 해지된 인증서의 일련 번호를 저장하는 데 사용되는 파일입니다. echo명령은 샘플 일련 번호인 1001을 파일로 파이프합니다.rootca/private 루트 CA에 대한 프라이빗 파일(프라이빗 키 포함)이 저장되는 디렉터리입니다.
이 디렉터리의 파일은 반드시 보호되어야 합니다.mkdir rootca cd rootca mkdir certs db private chmod 700 private touch db/index openssl rand -hex 16 > db/serial echo 1001 > db/crlnumber이전 단계에서 만든
rootca디렉터리에rootca.conf(이)라는 텍스트 파일을 만듭니다. 텍스트 편집기에서 해당 파일을 열고 다음 OpenSSL 구성 설정을 복사하여 파일에 저장합니다.이 파일은 테스트 루트 CA를 구성하는 데 필요한 값을 OpenSSL에 제공합니다. 이 예제에서 파일은 이전 단계에서 만든 디렉터리와 파일을 사용하여 rootca라 불리는 루트 CA를 구성합니다. 이 파일은 다음에 대한 구성 설정도 제공합니다.
- 인증서 고유 이름(DN) 필드를 위해 루트 CA에서 사용하는 CA 정책
- 루트 CA에서 만든 인증서 요청
- 루트 CA 인증서, 하위 CA 인증서 및 루트 CA에서 발급한 클라이언트 인증서에 적용된 X.509 확장
참고 항목
ca_default섹션에서home특성은../rootca로 설정됩니다. 이 구성 파일은 하위 CA용 인증서를 만들 때도 사용하기 때문입니다. 지정한 상대 경로를 사용하면 이 프로세스가 진행되는 중에 OpenSSL이 하위 CA 폴더에서 루트 CA 폴더로 이동할 수 있습니다.OpenSSL 구성 파일의 구문에 대한 자세한 내용은 OpenSSL 설명서의 구성 매뉴얼 페이지를 참조하세요.
[default] name = rootca domain_suffix = exampledomain.com aia_url = http://$name.$domain_suffix/$name.crt crl_url = http://$name.$domain_suffix/$name.crl default_ca = ca_default name_opt = utf8,esc_ctrl,multiline,lname,align [ca_dn] commonName = "rootca_common_name" [ca_default] home = ../rootca database = $home/db/index serial = $home/db/serial crlnumber = $home/db/crlnumber certificate = $home/$name.crt private_key = $home/private/$name.key RANDFILE = $home/private/random new_certs_dir = $home/certs unique_subject = no copy_extensions = none default_days = 3650 default_crl_days = 365 default_md = sha256 policy = policy_c_o_match [policy_c_o_match] countryName = optional stateOrProvinceName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [req] default_bits = 2048 encrypt_key = yes default_md = sha256 utf8 = yes string_mask = utf8only prompt = no distinguished_name = ca_dn req_extensions = ca_ext [ca_ext] basicConstraints = critical,CA:true keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [sub_ca_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:true,pathlen:0 extendedKeyUsage = clientAuth,serverAuth keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [client_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:false extendedKeyUsage = clientAuth keyUsage = critical,digitalSignature subjectKeyIdentifier = hashGit Bash 창에서 다음 명령을 실행하여
rootca디렉터리에 인증서 서명 요청(CSR)을 생성하고rootca/private디렉터리에 프라이빗 키를 생성합니다. OpenSSLreq명령에 대한 자세한 내용은 OpenSSL 설명서의 openssl-req 매뉴얼 페이지를 참조하세요.참고 항목
이 루트 CA는 테스트용이며 공개 키 인프라(PKI)의 일부로 노출되지 않지만, 프라이빗 키를 복사하거나 공유하지 않는 것이 좋습니다.
winpty openssl req -new -config rootca.conf -out rootca.csr -keyout private/rootca.key다음 예제와 같이 프라이빗 키 파일에 대해 PEM 전달 구를 입력하라는 메시지가 표시됩니다. 프라이빗 키와 CSR을 생성하기 위한 전달 구를 입력하고 확인합니다.
Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----계속하기 전에 CSR 파일
rootca.csr이(가)rootca디렉터리에 있고 프라이빗 키 파일rootca.key이(가)private하위 디렉터리에 있는지 확인합니다.Git Bash 창에서 다음 명령을 실행하여 자체 서명된 루트 CA 인증서를 만듭니다. 이 명령은
ca_ext구성 파일 확장을 인증서에 적용합니다. 이러한 확장은 인증서가 루트 CA용이며, 인증서 및 CRL(인증서 해지 목록)에 서명하는 데 사용할 수 있음을 나타냅니다. OpenSSLca명령에 대한 자세한 내용은 OpenSSL 설명서의 openssl-ca 매뉴얼 페이지를 참조하세요.winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt -extensions ca_ext다음 예제와 같이 프라이빗 키 파일에 대해 PEM 전달 구를 제공하라는 메시지가 표시됩니다. 전달 구를 제공하면 OpenSSL은 인증서를 생성하고, 루트 CA에 대한 인증서에 서명하고 커밋하라는 메시지를 표시합니다. 루트 CA를 위한 자체 서명된 인증서를 생성하려면 두 프롬프트에 y를 지정합니다.
Using configuration from rootca.conf Enter pass phrase for ../rootca/private/rootca.key: Check that the request matches the signature Signature ok Certificate Details: {Details omitted from output for clarity} Certificate is to be certified until Mar 24 18:51:41 2033 GMT (3650 days) Sign the certificate? [y/n]: 1 out of 1 certificate requests certified, commit? [y/n] Write out database with 1 new entries Data Base UpdatedOpenSSL이 인증서 데이터베이스를 업데이트하면, 인증서 파일인
rootca.crt이(가)rootca디렉터리에 있고 인증서용 PEM 인증서(.pem) 파일이rootca/certs디렉터리에 있는지 확인합니다. .pem 파일의 파일 이름은 루트 CA 인증서의 일련 번호와 일치합니다.
하위 CA 만들기
내부 루트 CA를 만든 후에는 디바이스용 클라이언트 인증서에 서명할 ‘중간’ CA 로 사용할 하위 CA를 만들어야 합니다. 이론적으로는 하위 CA를 만들지 않아도 됩니다. 루트 CA 인증서를 IoT 허브에 업로드하고 루트 CA에서 바로 클라이언트 인증서에 서명할 수 있습니다. 하지만 하위 CA를 중간 CA로 사용하여 클라이언트 인증서에 서명하면, 루트 CA가 오프라인으로 유지되는 권장 프로덕션 환경을 더 정확하게 시뮬레이션할 수 있습니다. 또한 하위 CA를 사용하여 다른 하위 CA를 서명하고, 다시 다른 하위 CA를 서명할 수도 있습니다. 하위 CA를 사용하여 다른 하위 CA를 서명하면 신뢰 인증서 체인의 일부로 중간 CA의 계층 구조가 생성됩니다. 프로덕션 환경에서는 신뢰 인증서 체인을 통해 서명 디바이스에 대한 신뢰 위임을 할 수 있습니다. 신뢰 인증서 체인에 디바이스를 서명하는 방법에 대한 자세한 내용은 X.509 CA 인증서를 사용하여 디바이스 인증을 참조하세요.
루트 CA와 마찬가지로, 하위 CA를 만들고 유지 관리하는 데 사용하는 파일은 폴더 구조에 저장되고 이 프로세스의 일부로서 초기화됩니다. 다음 단계를 수행합니다.
- 하위 CA에서 사용하는 폴더와 파일 만들기 및 초기화
- 하위 CA 및 하위 CA를 사용하여 만든 인증서를 구성하기 위해, OpenSSL에서 사용하는 구성 파일 만들기
- 하위 CA 인증서 역할을 하는 루트 CA에서 서명한 CA 인증서 요청 및 만들기
rootca디렉터리가 포함된 기본 디렉터리로 돌아갑니다. 이 예제에서는 루트 CA와 하위 CA가 모두 동일한 기본 디렉터리에 있습니다.cd ..Git Bash 창에서 다음 명령을 한 번에 하나씩 실행합니다.
이 단계에서는 이전 섹션의 루트 CA에 대해 만든 폴더 구조 및 파일과 유사한 하위 CA에 대한 디렉터리 구조 및 지원 파일을 만듭니다.
mkdir subca cd subca mkdir certs db private chmod 700 private touch db/index openssl rand -hex 16 > db/serial echo 1001 > db/crlnumber이전 단계에서 만든
subca디렉터리에subca.conf(이)라는 텍스트 파일을 만듭니다. 텍스트 편집기에서 해당 파일을 열고 다음 OpenSSL 구성 설정을 복사하여 파일에 저장합니다.테스트 루트 CA용 구성 파일과 마찬가지로, 이 파일은 테스트 하위 CA를 구성하는 데 필요한 값을 OpenSSL에 제공합니다. 테스트 시나리오 또는 환경을 관리하기 위해 여러 하위 CA를 만들 수 있습니다.
OpenSSL 구성 파일의 구문에 대한 자세한 내용은 OpenSSL 설명서의 구성 마스터 매뉴얼 페이지를 참조하세요.
[default] name = subca domain_suffix = exampledomain.com aia_url = http://$name.$domain_suffix/$name.crt crl_url = http://$name.$domain_suffix/$name.crl default_ca = ca_default name_opt = utf8,esc_ctrl,multiline,lname,align [ca_dn] commonName = "subca_common_name" [ca_default] home = ../subca database = $home/db/index serial = $home/db/serial crlnumber = $home/db/crlnumber certificate = $home/$name.crt private_key = $home/private/$name.key RANDFILE = $home/private/random new_certs_dir = $home/certs unique_subject = no copy_extensions = copy default_days = 365 default_crl_days = 90 default_md = sha256 policy = policy_c_o_match [policy_c_o_match] countryName = optional stateOrProvinceName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [req] default_bits = 2048 encrypt_key = yes default_md = sha256 utf8 = yes string_mask = utf8only prompt = no distinguished_name = ca_dn req_extensions = ca_ext [ca_ext] basicConstraints = critical,CA:true keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [sub_ca_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:true,pathlen:0 extendedKeyUsage = clientAuth,serverAuth keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [client_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:false extendedKeyUsage = clientAuth keyUsage = critical,digitalSignature subjectKeyIdentifier = hashGit Bash 창에서 다음 명령을 실행하여 하위 CA 디렉터리에서 프라이빗 키 및 인증서 서명 요청(CSR)을 생성합니다.
다음 예제와 같이 프라이빗 키 파일에 대해 PEM 전달 구를 입력하라는 메시지가 표시됩니다. 프라이빗 키와 CSR을 생성하기 위한 전달 구를 입력하고 확인합니다.
Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----계속하기 전에 CSR 파일
subca.csr이(가) 하위 CA 디렉터리에 있고 프라이빗 키 파일subca.key이(가)private하위 디렉터리에 있는지 확인합니다.Git Bash 창에서 다음 명령을 실행하여 하위 CA 디렉터리에 하위 CA 인증서를 만듭니다. 이 명령은
sub_ca_ext구성 파일 확장을 인증서에 적용합니다. 이러한 확장은 인증서가 하위 CA용이며, 인증서 및 CRL(인증서 해지 목록)에 서명하는 용도로도 사용할 수 있음을 나타냅니다. 루트 CA 인증서와 달리 이 인증서는 자체 서명형이 아닙니다. 대신 하위 CA 인증서는 루트 CA 인증서로 서명되어, 공개 키 인프라(PKI)에 사용하는 것과 유사한 인증서 체인을 만듭니다. 그런 다음 하위 CA 인증서를 사용하여 디바이스를 테스트하기 위한 클라이언트 인증서에 서명합니다.winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt -extensions sub_ca_ext다음 예제와 같이 루트 CA의 프라이빗 키 파일에 대해 전달 구를 입력하라는 메시지가 표시됩니다. 전달 구를 입력하면 OpenSSL은 인증서의 세부 정보를 생성하고 표시한 다음, 하위 CA에 대한 인증서에 서명하고 커밋하라는 메시지를 표시합니다. 두 프롬프트 모두에
y을(를) 지정하여 하위 CA에 대한 인증서를 생성합니다.Using configuration from rootca.conf Enter pass phrase for ../rootca/private/rootca.key: Check that the request matches the signature Signature ok Certificate Details: {Details omitted from output for clarity} Certificate is to be certified until Mar 24 18:55:00 2024 GMT (365 days) Sign the certificate? [y/n]: 1 out of 1 certificate requests certified, commit? [y/n] Write out database with 1 new entries Data Base UpdatedOpenSSL이 인증서 데이터베이스를 업데이트하면, 인증서 파일인
subca.crt이(가) 하위 CA 디렉터리에 있고 인증서용 PEM 인증서(.pem) 파일이rootca/certs디렉터리에 있는지 확인합니다. .pem 파일의 파일 이름은 하위 CA 인증서의 일련 번호와 일치합니다.
하위 CA 인증서를 IoT 허브에 등록
하위 CA 인증서를 IoT Hub에 등록하면 등록 및 연결 중에 디바이스를 인증하는 데 이 인증서를 사용합니다. 다음 단계에서는 IoT 허브에 하위 CA 인증서를 업로드하고 자동으로 확인하는 방법을 설명합니다.
Azure Portal에서 IoT Hub로 이동하고 리소스 메뉴의 보안 설정에서 인증서를 선택합니다.
명령 모음에서 추가 를 선택하여 새 CA 인증서를 추가합니다.
인증서 이름 필드에 하위 CA 인증서의 표시 이름을 입력합니다.
rootca/certs디렉터리에서 하위 CA 인증서의 PEM 인증서(.pem) 파일을 선택하여 인증서 .pem 또는 .cer 파일 필드에 추가합니다.업로드 시 인증서 상태를 확인됨으로 설정 옆의 확인란을 선택합니다.
저장을 선택합니다.
업로드된 하위 CA 인증서는 작업 창의 인증서 탭에서 상태가 확인으로 설정되어 표시됩니다.
디바이스에 대한 클라이언트 인증서 만들기
하위 CA를 만든 후에는 디바이스에 대한 클라이언트 인증서를 만들 수 있습니다. 하위 CA에 대해 만든 파일 및 폴더는 CSR, 프라이빗 키 및 클라이언트 인증서용 인증서 파일을 저장하는 데 사용합니다.
클라이언트 인증서의 주체 일반 이름(CN) 필드 값은 Azure IoT Hub에 해당 디바이스를 등록할 때 사용된 디바이스 ID 값으로 설정되어야 합니다.
다음 단계를 수행합니다.
- 클라이언트 인증서에 대한 프라이빗 키와 인증서 서명 요청(CSR) 만들기
- 하위 CA 인증서로 서명된 클라이언트 인증서 만들기
Git Bash 창에서 아직
subca디렉터리에 있는지 확인합니다.Git Bash 창에서 다음 명령을 한 번에 하나씩 실행합니다. 자리 표시자를 IoT 디바이스의 이름으로 바꿉습니다(예:
testdevice). 이 단계에서는 클라이언트 인증서에 대한 프라이빗 키와 CSR을 만듭니다.이 단계에서는 클라이언트 인증서에 대한 2048비트 RSA 프라이빗 키를 만든 다음, 이 프라이빗 키를 사용하여 인증서 서명 요청(CSR)을 생성합니다.
다음 예제와 같이 인증서 세부 정보를 입력하라는 메시지가 표시됩니다.
특정 값을 입력해야 하는 유일한 프롬프트는 일반 이름이며, 이전 단계에서 제공한 디바이스 이름과 반드시 동일해야 합니다. 나머지 프롬프트에 대해 건너뛰거나 임의의 값을 제공할 수 있습니다.
인증서 세부 정보를 입력하면 OpenSSL은 인증서의 세부 정보를 생성하고 표시한 다음, 하위 CA에 대한 인증서에 서명하고 커밋하라는 메시지를 표시합니다. 두 프롬프트 모두에 y를 지정하여 하위 CA에 대한 인증서를 생성합니다.
----- Country Name (2 letter code) [XX]:. State or Province Name (full name) []:. Locality Name (eg, city) [Default City]:. Organization Name (eg, company) [Default Company Ltd]:. Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server hostname) []:'<DEVICE_NAME>' Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:계속하기 전에 CSR 파일이 하위 CA 디렉터리에 있고 프라이빗 키 파일이
private하위 디렉터리에 있는지 확인합니다. CSR 및 프라이빗 키 파일의 형식에 대한 자세한 내용은 X.509 인증서를 참조하세요.Git Bash 창에서 다음 명령을 실행하여 장치 이름 자리 표시자를 이전 단계에서 사용한 것과 동일한 이름으로 바꿉니다.
이 단계에서는 하위 CA 디렉터리에 클라이언트 인증서를 만듭니다. 이 명령은
client_ext구성 파일 확장을 인증서에 적용합니다. 이러한 확장은 인증서가 클라이언트 인증서용이라 CA 인증서로 사용할 수 없음을 나타냅니다. 클라이언트 인증서는 하위 CA 인증서로 서명됩니다.winpty openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.crt -extensions client_ext다음 예제와 같이 하위 CA의 프라이빗 키 파일에 대해 전달 구를 입력하라는 메시지가 표시됩니다. 전달 구를 입력하면 OpenSSL은 인증서의 세부 정보를 생성하고 표시한 다음, 디바이스에 대한 클라이언트 인증서에 서명하고 커밋하라는 메시지를 표시합니다. 두 프롬프트 모두에 y를 지정하여 클라이언트 인증서를 생성합니다.
Using configuration from subca.conf Enter pass phrase for ../subca/private/subca.key: Check that the request matches the signature Signature ok Certificate Details: {Details omitted from output for clarity} Certificate is to be certified until Mar 24 18:51:41 2024 GMT (365 days) Sign the certificate? [y/n]: 1 out of 1 certificate requests certified, commit? [y/n] Write out database with 1 new entries Data Base UpdatedOpenSSL이 인증서 데이터베이스를 업데이트하면, 클라이언트 인증서용 인증서 파일이 하위 CA 디렉터리에 있고 클라이언트 인증서용 PEM 인증서(.pem) 파일이 하위 CA 디렉터리의 certs 하위 디렉터리에 있는지 확인합니다. .pem 파일의 파일 이름은 클라이언트 인증서의 일련 번호와 일치합니다.
다음 단계
디바이스용으로 만든 클라이언트 인증서를 테스트하기 위해 디바이스를 IoT 허브에 등록할 수 있습니다. 디바이스 등록에 대한 자세한 내용은 디바이스 ID 만들기 및 관리를 참조하세요.
테스트할 관련 디바이스가 여러 개 있는 경우, Azure IoT Hub Device Provisioning Service를 사용하여 등록 그룹에 여러 디바이스를 프로비전할 수 있습니다. Device Provisioning Service에서 등록 그룹을 사용하는 방법에 대한 자세한 내용은 자습서: 등록 그룹을 사용하여 여러 X.509 디바이스 프로비전닝을 참조하세요.