X.509 인증서

아티클
04/26/2023

X.509 인증서는 사용자, 컴퓨터, 서비스 또는 디바이스를 나타내는 디지털 문서입니다. CA(인증 기관), 하위 CA 또는 등록 기관에서 X.509 인증서를 발급합니다. 인증서에는 인증서 주체의 공개 키가 포함됩니다. 안전하게 저장해야 하는 주체의 프라이빗 키는 여기에 포함되지 않습니다. RFC 5280 은 해당 필드 및 확장을 포함하여 공개 키 인증서를 문서화합니다. 공개 키 인증서는 디지털 서명되며 일반적으로 다음 정보를 포함합니다.

인증서 주체에 대한 정보
주체의 프라이빗 키에 해당하는 공개 키
발급 CA에 대한 정보
지원되는 암호화 및/또는 디지털 서명 알고리즘
인증서의 해지 및 유효성 검사 상태를 확인하기 위한 정보

인증서 필드

X.509 인증서 표준에는 세 가지 증분 버전이 있으며 각 후속 버전은 표준에 인증서 필드를 추가했습니다.

1988년에 게시된 버전 1(v1)은 인증서에 대한 초기 X.509 표준을 따릅니다.
1993년에 게시된 버전 2(v2)는 버전 1에 포함된 필드에 두 개의 필드를 추가합니다.
2008년에 게시된 버전 3(v3)은 X.509 표준의 현재 버전을 나타냅니다. 이 버전은 인증서 확장에 대한 지원을 추가합니다.

이 섹션은 X.509 인증서에서 사용할 수 있는 인증서 필드 및 인증서 확장에 대한 일반적인 참조로 사용됩니다. 데이터 형식, 제약 조건 및 기타 세부 정보를 포함하여 인증서 필드 및 인증서 확장에 대한 자세한 내용은 RFC 5280 사양을 참조하세요.

버전 1 필드

다음 표에서는 X.509 인증서의 버전 1 인증서 필드에 대해 설명합니다. 이 테이블에 포함된 모든 필드는 후속 X.509 인증서 버전에서 사용할 수 있습니다.

속성	Description
버전	인증서의 버전 번호를 식별하는 정수입니다.
일련 번호	CA(인증 기관)에서 발급한 각 인증서의 고유 번호를 나타내는 정수입니다.
서명	CA가 인증서에 서명하는 데 사용하는 암호화 알고리즘의 식별자입니다. 값에는 알고리즘의 식별자와 해당 알고리즘에서 사용하는 선택적 매개 변수(해당하는 경우)가 모두 포함됩니다.
발급자	인증서 발급 CA의 고유 이름(DN)입니다.
유효성 검사	인증서가 유효한 포괄 기간입니다.
Subject	인증서 주체의 고유 이름(DN)입니다.
주체 공개 키 정보	인증서 주체가 소유한 공개 키입니다.

버전 2 필드

다음 표에서는 인증서 발급자 정보를 포함하는 버전 2에 대해 추가된 필드에 대해 설명합니다. 그러나 이러한 필드는 거의 사용되지 않습니다. 이 테이블에 포함된 모든 필드는 후속 X.509 인증서 버전에서 사용할 수 있습니다.

속성	Description
발급자 고유 ID	발급 CA에서 정의한 대로 발급 CA를 나타내는 고유 식별자입니다.
주체 고유 ID	발급 CA에서 정의한 인증서 주체를 나타내는 고유 식별자입니다.

버전 3 필드

다음 표에서는 X.509 인증서 확장의 컬렉션을 나타내는 버전 3에 대해 추가된 필드에 대해 설명합니다.

속성	Description
확장	표준 및 인터넷 관련 인증서 확장의 컬렉션입니다. X.509 v3 인증서에 사용할 수 있는 인증서 확장에 대한 자세한 내용은 인증서 확장을 참조하세요.

인증서 확장

버전 3에 도입된 인증서 확장은 더 많은 특성을 사용자 또는 공개 키와 연결하고 인증 기관 간의 관계를 관리하는 방법을 제공합니다. 인증서 확장에 대한 자세한 내용은 RFC 5280 사양의 인증서 확장 섹션을 참조하세요.

표준 확장

X.509 표준은 인터넷 PKI(공개 키 인프라)에서 사용하기 위해 이 섹션에 포함된 확장을 정의합니다.

속성	Description
기관 키 식별자	인증서 주체와 이 인증서를 발급한 CA 인증서의 일련 번호 또는 발급 CA의 공개 키 해시를 나타내는 식별자입니다.
주체 키 식별자	현재 인증서의 공개 키 해시입니다.
주요 사용량	인증서를 사용할 수 있는 서비스를 정의하는 비트맵 값입니다.
프라이빗 키 사용 기간	키 쌍의 프라이빗 키 부분에 대한 유효 기간입니다.
인증서 정책	인증서 주체의 유효성을 검사하는 데 사용되는 정책 정보의 컬렉션입니다.
정책 매핑	각 organization 정책을 다른 organization 정책에 매핑하는 정책 매핑 컬렉션입니다.
주체 대체 이름	제목에 대한 대체 이름의 컬렉션입니다.
발급자 대체 이름	발급 CA에 대한 대체 이름의 컬렉션입니다.
주체 디렉터리 특성	X.500 또는 LDAP 디렉터리의 특성 컬렉션입니다.
기본 제약 조건	인증서가 CA 또는 사용자, 컴퓨터, 디바이스 또는 서비스에 발급되었는지 여부를 지정할 수 있도록 하는 제약 조건 컬렉션입니다. 이 확장에는 있을 수 있는 하위 CA의 수를 제한하는 경로 길이 제약 조건도 포함됩니다.
이름 제약 조건	CA에서 발급한 인증서에서 허용되는 네임스페이스를 지정하는 제약 조건 컬렉션입니다.
정책 제약 조건	CA 간의 정책 매핑을 금지하는 데 사용할 수 있는 제약 조건의 컬렉션입니다.
확장 키 사용	키 사용 확장에서 식별된 목적 외에 인증서의 공개 키를 사용하는 방법을 나타내는 키 용도 값의 컬렉션입니다.
CRL 배포 지점	기본 CRL(인증서 해지 목록)이 게시되는 URL 컬렉션입니다.
anyPolicy 억제	하위 CA 인증서에서 모든 발급 정책 OID(2.5.29.32.0)의 사용을 금지합니다.
최신 CRL	델타 CRL 배포 지점이라고도 하는 이 확장에는 발급 CA의 델타 CRL이 게시된 하나 이상의 URL이 포함되어 있습니다.

프라이빗 인터넷 확장

이 섹션에 포함된 확장은 표준 확장과 유사하며 발급 CA 또는 인증서 주체에 대한 온라인 정보로 애플리케이션을 안내하는 데 사용할 수 있습니다.

속성	Description
기관 정보 액세스	발급 CA에서 제공하는 추가 정보의 형식 및 위치를 설명하는 항목의 컬렉션입니다.
주체 정보 액세스	인증서 주체에서 제공하는 추가 정보의 형식 및 위치를 설명하는 항목의 컬렉션입니다.

인증서 형식

인증서는 다양한 형식으로 저장할 수 있습니다. Azure IoT Hub 인증은 일반적으로 PEM(Privacy-Enhanced Mail) 및 PFX(Personal Information Exchange) 형식을 사용합니다. 다음 표에서는 인증서를 나타내는 데 사용되는 일반적으로 사용되는 파일 및 형식에 대해 설명합니다.

서식	Description
이진 인증서	DER(Distinguished Encoding Rules) ASN.1 인코딩을 사용하는 원시 양식의 이진 인증서.
ASCII PEM 형식	PEM 인증서(.pem) 파일에는 `-----BEGIN CERTIFICATE-----`로 시작하고 `-----END CERTIFICATE-----`로 끝나는 Base64로 인코딩된 인증서가 포함되어 있습니다. X.509 인증서의 가장 일반적인 형식 중 하나인 PEM 형식은 디바이스 인증서와 같은 특정 인증서를 업로드할 때 IoT Hub 필요합니다.
ASCII PEM 키	Base64 인코딩 DER 키를 포함하며 선택적으로 암호를 보호하는 데 사용되는 알고리즘에 대한 추가 메타데이터가 포함됩니다.
PKCS #7 인증서	서명되거나 암호화된 데이터를 전송하도록 설계된 형식입니다. 전체 인증서 체인을 포함할 수 있습니다. RFC 2315 는 이 형식을 정의합니다.
PKCS #8 키	프라이빗 키 저장소의 형식입니다. RFC 5208 은 이 형식을 정의합니다.
PKCS #12 키 및 인증서	키 및 전체 인증서 체인을 저장하고 보호할 수 있는 복합 형식입니다. 일반적으로 .p12 또는 .pfx 확장과 함께 사용됩니다. PKCS #12는 PFX 형식과 동의어입니다. RFC 7292 는 이 형식을 정의합니다.

자체 서명된 인증서

두 개의 자체 서명된 인증서를 사용하여 테스트 목적으로 IoT Hub에 디바이스를 인증할 수 있습니다. 인증서는 지문 또는 지문이라는 계산된 해시 값으로 식별되기 때문에 이러한 유형의 인증을 지문 인증이라고도 합니다. 이러한 계산된 해시 값은 IoT Hub 디바이스를 인증하는 데 사용됩니다.

중요

테스트 목적이더라도 발급 CA(인증 기관)에서 서명한 인증서를 사용하는 것이 좋습니다. 프로덕션 환경에서 자체 서명된 인증서를 사용하지 마세요.

자체 서명된 인증서 만들기

OpenSSL을 사용하여 자체 서명된 인증서를 만들 수 있습니다. 다음 단계에서는 bash 셸에서 OpenSSL 명령을 실행하여 자체 서명된 인증서를 만들고 IoT Hub 디바이스를 인증하는 데 사용할 수 있는 인증서 지문을 검색하는 방법을 보여 줍니다.

참고

테스트에 자체 서명된 인증서를 사용하려면 각 디바이스에 대해 두 개의 인증서를 만들어야 합니다.

다음 명령을 실행하여 프라이빗 키를 생성하고 PEM으로 인코딩된 프라이빗 키(.key) 파일을 만들어 다음 자리 표시자를 해당 값으로 바꿉니다. 다음 명령으로 생성된 프라이빗 키는 2048비트 암호화와 함께 RSA 알고리즘을 사용합니다.

{KeyFile}. 프라이빗 키 파일의 이름입니다.
```
openssl genpkey -out {KeyFile} -algorithm RSA -pkeyopt rsa_keygen_bits:2048
```

다음 명령을 실행하여 PKCS #10 CSR(인증서 서명 요청)을 생성하고 CSR(.csr) 파일을 만들어 다음 자리 표시자를 해당 값으로 바꿉니다. 메시지가 표시되면 자체 서명된 인증서에 대한 IoT 디바이스의 디바이스 ID를 지정해야 합니다.

{KeyFile}. 프라이빗 키 파일의 이름입니다.

{CsrFile}. CSR 파일의 이름입니다.

{DeviceID}. IoT 디바이스의 이름입니다.

openssl req -new -key {KeyFile} -out {CsrFile}

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) []:{DeviceID}
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

다음 명령을 실행하여 CSR을 검사하고 확인하여 다음 자리 표시자를 해당 값으로 바꿉니다.

{CsrFile}. 인증서 파일의 이름입니다.
```
openssl req -text -in {CsrFile} -verify -noout
```
다음 명령을 실행하여 자체 서명된 인증서를 생성하고 PEM으로 인코딩된 인증서(.crt) 파일을 만들어 다음 자리 표시자를 해당 값으로 바꿉니다. 명령은 프라이빗 키로 CSR을 변환하고 서명하여 365일 후에 만료되는 자체 서명된 인증서를 생성합니다.

{KeyFile}. 프라이빗 키 파일의 이름입니다.

{CsrFile}. CSR 파일의 이름입니다.

{CrtFile}. 인증서 파일의 이름입니다.
```
openssl x509 -req -days 365 -in {CsrFile} -signkey {KeyFile} -out {CrtFile}
```
다음 명령을 실행하여 인증서의 지문을 검색하고 다음 자리 표시자를 해당 값으로 바꿉 있습니다. 인증서의 지문은 해당 인증서에 고유한 계산된 해시 값입니다. 테스트를 위해 IoT Hub IoT 디바이스를 구성하려면 지문이 필요합니다.

{CrtFile}. 인증서 파일의 이름입니다.
```
openssl x509 -in {CrtFile} -noout -fingerprint
```

업로드 후 수동으로 인증서 확인

루트 CA(인증 기관) 인증서 또는 종속 CA 인증서를 IoT Hub에 업로드할 때 인증서를 자동으로 확인하도록 선택할 수 있습니다. 업로드하는 동안 인증서를 자동으로 확인하도록 선택하지 않은 경우 인증서가 확인되지 않음 상태로 표시됩니다. 인증서를 수동으로 확인하려면 다음 단계를 수행해야 합니다.

인증서를 선택하여 인증서 세부 정보 대화 상자를 표시합니다.
대화 상자에서 확인 코드 생성을 선택합니다.
확인 코드를 클립보드에 복사합니다. 이후 단계에서 이 확인 코드를 인증서 주체로 사용해야 합니다. 예를 들어 확인 코드가 인 75B86466DA34D2B04C0C4C9557A119687ADAE7D4732BDDB3경우 다음 단계에서와 같이 인증서의 주체로 추가합니다.
확인 인증서를 생성하는 방법에는 다음 세 가지가 있습니다.
- Microsoft에서 제공하는 PowerShell 스크립트를 사용하는 경우 New-CACertsVerificationCert "<verification code>"를 실행하여 <verification code>를 이전에 생성된 확인 코드로 바꾸는 VerifyCert4.cer이라는 인증서를 만듭니다. 자세한 내용은 C용 Azure IoT Hub 디바이스 SDK에 대한 GitHub 리포지토리에서 샘플 및 자습서를 위한 테스트 CA 인증서 관리를 참조하세요.
- Microsoft에서 제공하는 Bash 스크립트를 사용하는 경우 를 실행 ./certGen.sh create_verification_certificate "<verification code>" 하여 verification-code.cert.pem이라는 인증서를 만들고 를 이전에 생성된 확인 코드로 바꿉 <verification code> 있습니다. 자세한 내용은 C용 Azure IoT Hub 디바이스 SDK에 대한 GitHub 리포지토리의 샘플 및 자습서에 대한 테스트 CA 인증서 관리를 참조하세요.
- OpenSSL을 사용하여 인증서를 생성하는 경우 먼저 프라이빗 키와 CSR(인증서 서명 요청) 파일을 생성해야 합니다. 다음 예제에서 <verification code>를 이전에 생성된 확인 코드로 바꿉니다.
```
openssl genpkey -out pop.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048

openssl req -new -key pop.key -out pop.csr

-----
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) []:<verification code>
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
```
그런 다음 루트 CA 또는 하위 CA 및 CSR 파일에 적절한 구성 파일을 사용하여 인증서를 만듭니다. 다음 예제에서는 OpenSSL을 사용하여 루트 CA 구성 파일 및 CSR 파일에서 인증서를 만드는 방법을 보여 줍니다.
```
openssl ca -config rootca.conf -in pop.csr -out pop.crt -extensions client_ext
```
자세한 내용은 자습서 - 테스트를 위한 인증서 만들기 및 업로드를 참조하세요.
인증서 세부 정보 보기에서 새 인증서를 선택합니다.
인증서를 업로드한 후 확인을 선택합니다. 인증서 상태가 확인됨으로 변경됩니다.

참조 항목

X.509 인증서 및 인증서가 IoT Hub 사용되는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.

다음을 통해 공유