openssl CAを適切にセットアップして、sslクライアント証明書を生成する方法

最初のCAを構成しています。その目的は、httpsを介してEDIサービスにアクセスするためにクライアントを使用するクライアントに証明書を発行することです。そのため、sslクライアント証明書を生成する必要があります。証明書に署名するプロセス全体が今では機能しており、証明書を使用してサービスにアクセスできますが、次の1つについて心配しています。

生成された証明書の目的は、一般的な方法です。

$ 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署名」、「任意の目的のCA」、および「OCSPヘルパー」について心配する権利はあります。これらは通常、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

1行ずつ説明します。

basicConstraints証明書があること、および指定手段は、「あなたは、このビットを理解していない場合は、この証明書を拒否し、」これは、重要として設定されているCAません。誰かがソフトウェアを使用してこの証明書から証明書を発行したとしても、それは決して信頼されません。

拡張キーの使用法は必須ではありませんが、ソフトウェアによっては、それが存在し、特定の目的がリストされている必要があります。これには、クライアント認証（あなたが話していること）と、S / MIME電子メールの署名と暗号化が一覧表示されます。S / MIME目的が不要な場合は、安全に削除できます。

subjectAltNamesubjectフィールドに含めることができない主題に関する情報を含めることができます。サブジェクトの共通名属性で指定されたドメイン以外の証明書が使用される可能性があるドメイン名を含めるために、Webサーバー証明書でも使用されます。これらの証明書は、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電子メールなど）。この拡張機能を使用するソフトウェアについては知りませんが、一般的に使用されていないこともわかりません。通常、証明書に含まれています。

そのうち、本当に必要なのはbasicConstraintsandとextendedKeyUsage; 基本的な制約は本当に、本当に重要である必要があり（またはCA証明書を渡したばかりです！）、通常、拡張キーの使用はそうではありません。