SSL 클라이언트 인증서를 생성하기 위해 openssl CA를 올바르게 설정하는 방법

첫 번째 CA를 구성하고 있습니다. 클라이언트를 위해 인증서를 발급하여 클라이언트를 통해 EDI를 통해 EDI 서비스에 액세스하는 것이 목적입니다. 따라서 SSL 클라이언트 인증서를 생성해야합니다. 인증서 서명의 전체 프로세스는 지금까지 작동하며 인증서는 서비스에 액세스하는 데 성공적으로 사용될 수 있지만 한 가지 걱정이됩니다.

생성 된 인증서 목적은 다음을 일반화하는 방법입니다.

$ openssl x509 -purpose  -noout -in client.crt.pem
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

필자의 경우 SSL 클라이언트 및 S / MIME 서명 이외의 다른 목적은 없어야한다고 생각합니다. 내가 틀렸고 이것이 그대로 있어야합니까?

내가 정확하고 다른 목적을 비활성화해야한다면 openssl.cnf 구성에 무엇을 넣어야합니까?

여기 내 현재 설정이 있습니다 (조금 잘랐습니다).

[ CA_edi ]
# here was directory setup and some other stuff, cut it for clarity
x509_extensions = usr_cert      # The extentions to add to the cert

name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# stripped rest of config about validity days and such

[ usr_cert ]

basicConstraints=CA:FALSE
nsCertType = client, email
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

생성 된 인증서가 서버 사용을 허용하는 잘못된 점은 무엇입니까?

"CRL 서명", "Any Purpose CA"및 "OCSP Helper"에 대해 걱정할 권리가 있습니다.이 인증서는 일반적으로 CA 인증서 또는 인증서 해지 목록 (CRL)에 서명하기 위해 특별히 발급 된 인증서를 위해 예약되어 있습니다. 유효하지 않음) 또는 OCSP 서버 실행 (CRL과 유사하지만 인증서의 유효성 상태를 제공하는 온라인 서비스)

관련 OpenSSL 설명서 페이지는 x509 명령 및 x509v3_config에 대한 것입니다

클라이언트 인증서 생성에 사용하는 OpenSSL 구성은 다음과 같습니다.

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

한 줄씩 살펴 보겠습니다.

은 basicConstraints인증서가 있음을, 그리고 지정 수단 "이 비트를 이해하지 않는 경우이 인증서를 거부"하는 중요한로 설정 CA가 없습니다 . 누군가 소프트웨어를 사용하여이 인증서에서 인증서를 발급하더라도 신뢰할 수는 없습니다.

확장 키 사용법은 필수는 아니지만 일부 소프트웨어는 반드시 있어야하며 특정 목적이 나열되어 있습니다. 여기에는 클라이언트 인증 (말하려는 내용)과 S / MIME 이메일 서명 및 암호화가 나열됩니다. 필요하지 않은 경우 S / MIME 목적을 안전하게 제거 할 수 있습니다.

subjectAltNamesubject필드에 포함 할 수없는 주제에 대한 정보를 포함 할 수 있습니다 . 또한 웹 서버 인증서에서 주체의 공통 이름 속성에 지정된 도메인 이외의 인증서에 사용될 수있는 도메인 이름을 포함하기 위해 사용됩니다. 이러한 인증서를 SAN (주체 대체 이름) 인증서라고합니다. 이메일 주소를 subjectAltName제목 이 아닌 이메일 주소에 포함시키는 것이 일반적입니다. 이메일 주소를 전혀 포함하지 않아도되며 내선 번호를 생략 할 수 있습니다.

crlDistributionPoints발급 기관의 CRL이 제공되는 장소를 나열합니다. 인증서의 유효성을 검사하려는 소프트웨어에 "이 인증서가 여전히 유효한지 확인해야 할 곳이 있습니다." 인터넷 사용의 경우 http://URL이 가장 적합 할 수 있습니다 (CRL은 디지털 서명되어 있으므로 필요하지 않으며 https신뢰 루프 문제가 발생할 수 있음).

authorityKeyIdentifier일반적으로 발급하는 CA 공개 키의 SHA-1 해시입니다 (다른 값일 수도 있음). 이 확장을 포함 하면 값은 subjectKeyIdentifier발급 CA 인증서 의 값과 일치해야합니다 .

authorityInfoAccess약간 비슷 crlDistributionPoints하지만 CRL 대신 발급 CA 인증서 를 얻는 위치를 지정합니다 . 이는 신뢰 체인이 긴 경우에 유용합니다. 예를 들어 CA-1은 CA-2를 발행하고 CA-3을 발행하여 인증서를 발행합니다. 인증서 확인을 시도하는 소프트웨어는이 확장을 사용하여 CA-3 인증서를 가져온 다음 해당 인증서의 값을 사용하여 CA-2 인증서 등을 얻을 수 있습니다. 일반적으로 인증서 체인 (이 경우 CA-2 인증서) CA-3 인증서)는 주체의 인증서와 함께 번들로 제공됩니다 (예 : SSL 트랜잭션 또는 S / MIME 이메일). 이 확장을 사용하는 소프트웨어는 모르지만 일반적으로 사용되지는 않습니다. 일반적으로 인증서에 포함됩니다.

그 중에서도 오직 and 만 필요 합니다 . 기본 제약 조건은 실제로 중요 해야 하며 (또는 CA 인증서를 방금 배포했습니다!) 확장 된 키 사용은 일반적으로 중요하지 않습니다.basicConstraintsextendedKeyUsage