OpenSSLを使用した証明書の署名
クライアント・システムを制御できない環境では、常に認識された独立したCAを使用して証明書に署名する必要があります。 OSおよびソフトウェア・ベンダーは、CA検証証明書を配布するソフトウェアとともに含めるために、独立したCAと交渉します。 主要なCAプロバイダから検証証明書を取得することは、ほとんどのユーザーが各自の信頼できるCA証明書リストを管理する必要がないことを意味します。 HTTPS経由でWebサイトにアクセスするブラウザは、CA署名を自身のストアにあるCA証明書と照合することで、サイトの公開証明書を検証できます。
クライアント・システムを制御できる場合は、クライアントに自己署名証明書を直接提供するか、組織内で使用されるすべての証明書に署名してCA証明書をクライアントに配布するようにプライベートCA証明書を設定できます。 2番目のアプローチを使用すると、組織内で署名されたすべての証明書が検証されるため、組織内の証明書のセキュリティをより厳密に制御できるため、インフラストラクチャ・コストが削減される可能性があります。
テストおよび開発用の自己署名証明書の作成
自己署名証明書は、多くの場合、開発およびテストの目的で作成されます。 これらの証明書は信頼できるCAによって検証されないため、これらの証明書の信頼は手動で構成する必要があります。 秘密キーが危険にさらされた場合、その秘密キーは取り消すことはできませんが、トラスト許可リストから手動で削除する必要があります。 これらの証明書は、本番環境では使用しないでください。 CA署名証明書は、常に自己署名証明書よりも優先されます。 ただし、自己署名証明書を使用すると、独自のCAを管理したりテスト・プラットフォームごとにCA署名証明書を取得する手間をかけずに、コストを抑え、テストと開発に役立てることができます。
opensslコマンドを使用すると、すぐに使用できる自己署名証明書を生成できます。 このコマンドは、秘密キーのCSRを作成し、CSRから直接X.509証明書を生成し、それ自体で証明書に署名します。
このため、コマンドは秘密キーとCSRを作成するために実行するコマンドに似ていますが、有効期間も指定する必要がある点が異なります。 よい方法として、自己署名証明書は、テストの目的で必要な期間にのみ生成します。 これにより、秘密キーの安全性が損なわれた場合、有効期間が制限され、古い証明書の期限が切れたときに新しい証明書を生成できます。
たとえば、次のコマンドを使用して、30日間有効な自己署名付きX.509証明書を作成します:
sudo openssl req -new -x509 -days 30 -nodes -newkey rsa:2048 -keyout private.key \ -out public.cert -subj '/C=US/ST=Ca/L=Sunnydale/CN=www.example.com'
生成されたprivate.keyファイルには秘密キーが含まれ、public.certファイルには自己署名証明書が含まれます。 通常、どの証明書とキーがどのホストとドメイン名に適用されるかを追跡できるように、これらのファイルに共通名と同じ値を使用して名前を付けます。
-newkey値は、カスタム・アルゴリズムおよびキー・サイズの要件にあわせて設定できることに注意してください。 この例では、アルゴリズムはRSAに設定され、キー・サイズは2048ビットに設定されています。
自己署名証明書ファイルは任意のクライアント・システムの信頼できる証明書ストアにコピーでき、クライアント・システムは、証明書を提供するホストに接続するたびに、証明書が一致することを検証します。
keytoolコマンドを使用して自己署名証明書を生成することもできますが、このコマンドの主な目的は、Javaアプリケーションで使用するJSSE (Java Secure Socket Extension)デジタル証明書をインストールおよび管理することです。 詳細は、Javaを参照してください。
プライベート認証局の作成
プライベート認証局(CA)を作成することによって、組織内のすべての証明書のCSRを処理できます。 また、独自の証明書失効リスト(CRL)を管理することもでき、これを使用して、クライアント・システムは、証明書がまだ有効であるか、失効しているかを検出できます。
この方法は、失効を制御できるため、自己署名証明書を使用するよりも優れています。 ただし、CA証明書は、組織内の公開証明書を検証する必要があるすべてのクライアント・システムに配布する必要があります。
CAルートの作成
CAルートはCAの基本的な証明書であり、サーバー証明書やクライアント証明書の署名にはあまり使用されません。 CAルートは、通常、1つ以上の中間証明書に署名して、他の証明書に署名する権限を付与するために使用されます。 このモデルは、CA中間秘密キーが侵害された場合、CA仲介者を証明書失効リストに追加でき、仲介者によって署名されたすべての証明書が自動的に無効化されることを意味します。
このモデルは、公開キー・インフラストラクチャ全体の整合性の保護に役立ちます。 CAルートがない場合、公開キー・インフラストラクチャはありません。CAルートは、階層内のすべての証明書を検証する信頼チェーンの作成に使用されます。 CAルートは、最小限のネットワーク・アクセスまたはインターネットへの直接アクセスなしで完全に分離されたシステムで作成および保守することをお薦めします。 CAルートを中心に実装されるセキュリティ対策は、公開キー・インフラストラクチャ全体のセキュリティにとって重要です。 CAルートの秘密キーが漏洩した場合、チェーン全体によって署名されたすべての証明書も侵害される可能性があります。
組織のCAルートを作成するには、CA構成および発行された証明書のメタデータのデータベースを管理するためにOpenSSLが使用できる定義済の構成に従って、ルート・キー・ペアを作成する必要があります。
CAルートの作成にはいくつかのステップが含まれます。このステップと例で説明します。
CAディレクトリ構造の作成
CAルートによって管理されるすべての証明書およびメタデータは、事前構成された一部のファイル内の特定のディレクトリ構造に格納されます。 特定の要件に従って体系を作成しますが、次の一般的なステップに従います:
CAルート構成ファイルの作成
すべてのCA関連コンテンツが格納されているディレクトリにCAルート構成を作成します。 たとえば、/etc/pki/ca/ca-root.confにファイルを作成し、次のコンテンツを移入します:
[default]
name = root-ca
domain_suffix = example.com
aia_url = http://$name.$domain_suffix/$name.crt
crl_url = http://$name.$domain_suffix/$name.crl
ocsp_url = http://ocsp.$name.$domain_suffix:9080
default_ca = ca_default
name_opt = utf8,esc_ctrl,multiline,lname,align
[ca_dn]
countryName = "AU"
organizationName = "Example Org"
commonName = "Root CA"
[ca_default]
home = .
database = $home/db/index.txt
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 = 30
default_md = sha256
policy = policy_strict
[policy_strict]
# The root CA should only sign intermediary certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName = match
stateOrProvinceName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[policy_loose]
# Allow the intermediary CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` manual page.
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[req]
# Standard Req options
default_bits = 4096
encrypt_key = yes
default_md = sha256
utf8 = yes
string_mask = utf8only
prompt = no
distinguished_name = ca_dn
req_extensions = ca_ext
[ca_ext]
# Extensions for a the CA root (`man x509v3_config`).
basicConstraints = critical,CA:true
keyUsage = critical,keyCertSign,cRLSign
subjectKeyIdentifier = hash
[intermediary_ext]
# Extensions for an intermediary CA.
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[server_ext]
# Extensions for server certificates.
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[client_ext]
# Extensions for client certificates.
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
[crl_ext]
# Extension for CRLs.
authorityKeyIdentifier=keyid:always
[ocsp]
# Extension for OCSP signing certificates.
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning前述の例は、OpenSSLで様々な操作を実行する際に役立つ多数のオプション・エントリを含む構成を示しています。 最も重要なことは、構成で、証明書に有効な操作のタイプを検証するために様々な証明書タイプに適用できる拡張機能が定義されることです。 この構成では、証明書の署名時に適用できる様々なポリシーも定義されます。 たとえば、厳密なポリシーを使用して、特定のメタデータが指定されていること、および証明書が署名される必要がある場合はCSR内のCA値と一致することを確認できます。 このポリシーは、中間CA証明書を生成するために重要です。 CAルートまたはいずれかの中間によって署名された他の証明書には、制限の少ないポリシーを適用できます。
この構成ファイル内の様々なセクションの説明は次のとおりです。
- [デフォルト]
-
defaultセクションでは、ルート証明書やこのCAの公開済失効リストなどの情報が公開される可能性があるURLなどの基本的な構成情報を定義します。 ここでの
nameエントリとdomain_suffixエントリは、これらのURLの一部を構成するための変数として使用され、キー・ファイルおよび証明書の名前と参照にも使用されます。 これらの値には、システム・ホスト名とシステム・ドメインを使用できます。 この構成エントリは、ca_defaultにあるデフォルトのCA構成エントリの場所も参照します。 - [ca_dn]
-
このセクションでは、このCAの識別名に対して生成される証明書のデフォルト値を定義します。 これらの値は、CSRおよびCAルート証明書用に生成された自己署名証明書に書き込まれます。
- [ca_default]
-
このセクションでは、CA全体を制御する構成を指定します。 提供されるこの情報は、OpenSSLがファイルを正しく更新し、証明書とキーを正しい場所に格納できるように、このCA用に作成されたディレクトリを構成にマップします。 このセクションでは、証明書の有効日数や、証明書失効リストの有効日数など、いくつかのデフォルト値も定義します。 この構成はルートCA用であるため、証明書の有効期間は10年に設定できます。これは、ルートCAを変更すると、インフラストラクチャ内のそれ以降の証明書もすべて再発行する必要があるためです。 すべての構成ファイル・オプションは、
CA(1)マニュアル・ページで表示できます。 - [policy_strict]
-
この項では、中間CA証明書など、一部の証明書に署名する際に従う必要がある厳密なポリシーについて説明します。 ポリシーは、証明書内のメタデータに関するルールを定義します。 たとえば、国名と組織名がCA証明書と一致するルールです。 その他のフィールドはオプションですが、共通名を指定する必要があります。
- [policy_loose]
-
このセクションは、制限の少ないポリシーが許可される、このCAとCA中間によって署名された他の証明書に使用されます。 このポリシー・エントリでは、ほとんどのフィールドがオプションになり、共通名が指定されていることのみが必要です。
- [req]
-
このセクションは、CA証明書リクエストを作成するために1回使用され、証明書リクエストの生成時に使用するデフォルト・オプション(ルートCAのキー長4096ビットなど)を定義します。 別のオプションは、証明書リクエスト内で使用するデフォルト値を取得するために、この構成ファイルの
ca_dnセクションを参照するCA識別名を指します。 - [ca_ext]
-
この拡張セクションでは、証明書が有効な操作を定義します。 ルートCAの場合、この証明書はすべての中間CA証明書に署名するために有効であり、事実上完全な権限を持っている必要があります。 拡張機能の詳細は、
X509V3_CONFIG(5)マニュアル・ページを参照してください。 - [intermediary_ext]
-
このセクションは、中間CAとして署名された証明書の個別の拡張構成です。 この証明書にはルートCAと同じ権限がありますが、証明書の
basicConstraintsオプション内のpathlen:0で制御される、それ以上の中間CAの証明書に署名することはできません。 - [server_ext]
-
この項では、サーバー側証明書の一般的な拡張オプションについて説明します。サーバー側証明書は、HTTPSやサーバー側メール・サービスなどのサービスによく使用されます。 これらの証明書は、検証および暗号化のために発行され、署名権限がありません。 この目的で証明書に署名するときに、構成エントリを参照できます。
- [client_ext]
-
このセクションには、ユーザーがシステムへのアクセスを検証および認証するための証明書を提供できる、リモート認証によく使用されるクライアント側の証明書が含まれています。 これらの証明書には、使用方法を制御する特定の拡張機能もあります。 この構成エントリは、クライアント側の証明書に署名するときに使用して、証明書に正しい拡張機能が適用されるようにすることができます。
- [crl_ext]
-
この拡張機能はCRLの作成時に自動的に適用されますが、この拡張機能は完全性のために提供されています。 証明書失効リストの管理を参照してください
- [ocsp]
-
オンライン証明書ステータス・プロトコル(OCSP)は、CRLとは異なるアプローチです。 OCSPサーバーは、クライアント・ソフトウェアによるリクエストを処理して、署名付き証明書で参照されているリソースから証明書のステータスを取得するように設定できます。 この目的のために特別な拡張機能が存在します。 詳細は、
OCSP(1)マニュアル・ページを参照してください。 OCSPサーバーの構成および実行も参照してください。
CAルート・キー・ペアの作成および検証
このタスクでは、ca-root.confファイルに指定された構成値を使用してCAルートの秘密キーと証明書署名リクエストを作成し、秘密キーをprivate/root-ca.keyに保存する方法を示します。
これはインフラストラクチャ全体で最も価値のあるキーであるため、長い適切なパスフレーズを使用して保護してください:
sudo openssl req -new -config ca-root.conf -out root-ca.csr -keyout private/root-ca.key
次に、CSRおよびca-root.confファイルを使用して自己署名証明書を作成します。 証明書が構成のca_extセクションで定義された拡張機能を使用する必要があることを指定してください。
sudo openssl ca -selfsign -config ca-root.conf -in root-ca.csr -out root-ca.crt -extensions ca_ext
Using configuration from ca-root.conf
Enter pass phrase for ./private/root-ca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
8f:75:11:1a:8e:33:b2:d1:09:a8:bf:07:9c:67:c8:3e
Issuer:
countryName = AU
organizationName = Example Org
commonName = Root CA
Validity
Not Before: Oct 29 12:23:04 2019 GMT
Not After : Oct 26 12:23:04 2029 GMT
Subject:
countryName = AU
organizationName = Example Org
commonName = Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:b9:41:d6:10:36:d4:12:d3:5d:52:29:60:fc:e0:
90:34:f6:fb:3e:99:10:33:a1:1d:54:77:3c:11:37:
2d:78:c3:3c:3f:40:69:37:fc:de:59:20:c1:1c:07:
83:f7:ae:2b:19:03:a7:e8:c6:d6:88:03:b4:ec:60:
36:3d:f6:da:59:58:cc:18:18:3e:43:c9:79:11:5b:
cf:9e:15:a7:29:fe:dc:4f:7b:0b:93:f0:9a:2b:97:
0f:ab:3e:38:7c:e7:c7:d3:5e:34:e2:40:d0:fd:f2:
e4:5e:2c:8a:8e:11:83:de:6b:c4:5c:b8:ec:4b:9c:
d2:3f:06:3d:53:a6:4b:a6:e3:c6:f6:24:a2:8c:fb:
bf:9e:19:d7:60:4b:c5:b6:48:e4:5d:60:4f:2c:47:
ca:4a:31:79:bc:7b:5a:25:90:fc:d2:44:a1:79:73:
2e:e1:88:a0:73:1f:82:d3:63:3e:67:94:20:f8:be:
21:9b:c3:14:4d:3e:9b:19:33:be:9b:cb:e5:54:9f:
a7:3f:05:d1:64:56:5f:43:62:65:5b:89:f4:f1:e3:
24:e8:1c:d5:03:36:86:ce:9e:76:c7:52:dc:88:f5:
d9:87:62:00:82:4d:14:de:a3:60:21:54:12:83:da:
8e:8e:5f:63:c3:93:5a:e2:b9:60:16:74:06:c7:46:
49:6d:c2:7e:6c:3a:50:3b:bf:c5:d6:20:65:bd:21:
a9:ad:b2:1c:4c:13:bf:fd:b8:e1:04:b8:46:c9:6c:
29:db:f3:a6:50:3d:2b:9b:83:49:bb:61:c2:8e:94:
08:52:84:f2:6d:33:4b:1f:e0:90:ea:a8:ec:d6:ff:
97:b8:3d:74:9a:64:d0:f7:22:7d:22:fc:93:47:68:
54:63:7c:10:0a:82:2f:84:3f:56:28:cf:8a:03:76:
77:b9:db:af:02:6d:b9:36:7e:63:da:f5:d2:a5:6d:
54:86:e1:be:f0:e1:54:13:dd:63:0a:53:8e:55:24:
90:40:af:f6:38:47:d3:00:0c:ba:66:6a:cc:4b:df:
28:fe:02:74:eb:28:15:11:ca:da:a7:86:0f:1f:bd:
c4:ac:b9:b1:c7:cc:2a:2a:db:6e:fd:e6:8e:7b:02:
17:5e:a7:7d:08:53:e2:a4:69:ca:6b:1f:f1:74:5b:
ac:86:2a:f2:b0:80:ea:b7:30:c5:14:c8:12:1e:66:
5e:2f:f5:d5:a8:09:39:b4:23:25:fc:ca:35:d5:c0:
73:79:a0:8a:12:25:27:ee:f5:ce:9a:97:c0:27:31:
ac:21:98:8f:34:25:a5:7a:42:5c:a0:a1:5d:64:39:
aa:6a:5e:54:50:5e:ad:c4:fe:c7:93:b1:c0:f7:c9:
91:43:93
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
3C:D9:C3:56:BD:C0:45:83:C8:2B:C7:0F:96:30:CF:2A:55:23:B5:9D
Certificate is to be certified until Oct 26 12:23:04 2029 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
続行するために秘密キー・パスフレーズの入力を求められます。 証明書の値が表示されたら、証明書に署名するよう求められます。 証明書に署名した後、CAデータベースにコミットできます。 データベース・ファイルは、公開キー・インフラストラクチャ内でこの証明書を追跡するように更新されます。
db/index.txtファイルを表示して、CAルート証明書エントリを表示できます。
sudo cat db/index.txt V 291026122304Z 8F75111A8E33B2D109A8BF079C67C83E unknown /C=AU/O=Example Org/CN=Root CA
データベース索引内の各行に表示される値は、次のとおりです。
-
ステータス(有効の場合は
V、失効の場合はR、期限切れの場合はE)。 -
YYMMDDHHMMSSZ形式の有効期限。 -
失効日または失効しない場合は空(この出力例では、フィールドは空です)。
-
16進のシリアル番号。
-
ファイルの場所、または不明な場合は
unknown。 -
識別名。
中間CAの作成
インフラストラクチャを作成する次のステップは、すべてのサーバー証明書およびクライアント証明書を処理できる中間CAを作成することです。 中間CA秘密キーの安全性が損なわれた場合、ルートCAはその証明書を取り消して、その中間によって発行されたその他の証明書を無効にする可能性があるため、これは重要です。
中間CAは、ほとんどの証明書リクエストを処理するため、より広いアクセス権を持つ別のサーバーでホストすることをお薦めします。 中間CAはルートCAの正確なモデルですが、それ自体の証明書がルートCAによって署名されることと、署名リクエストを処理するための適切な拡張機能が構成されていることが異なります。
CAディレクトリ構造の作成
中間CAホストで、ルートCAディレクトリ構造を作成するために実行したのと同じ操作を実行しますが、構成が仲介者向けであることが明らかになるように、親ディレクトリに適切な名前を付けます。次に例を示します:
sudo mkdir /etc/pki/ca-intermediary
sudo cd /etc/pki/ca-intermediary/
sudo mkdir certs db crl newcerts private
sudo chmod 700 private
sudo touch db/index.txt
sudo openssl rand -hex 16 > db/serial
sudo echo 1001 |sudo tee db/crlnumber中間CA構成の作成
中間CA構成は、CAルート用に作成した構成とほぼ同じですが、中間に固有のいくつかの変更があります。 変更は、次の例のboldのテキストで示されています。
[default] name = sub-ca domain_suffix = example.com aia_url = http://$name.$domain_suffix/$name.crt crl_url = http://$name.$domain_suffix/$name.crl ocsp_url = http://ocsp.$name.$domain_suffix:9080 default_ca = ca_default name_opt = utf8,esc_ctrl,multiline,lname,align [ca_dn] countryName = "AU" organizationName = "Example Org" commonName = "Intermediary CA" [ca_default] home = . database = $home/db/index.txt 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 = 30 default_md = sha256 policy = policy_strict [policy_strict] # The root CA should only sign intermediary certificates that match. # See the POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = optional organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [policy_loose] # Allow the intermediary CA to sign a more diverse range of certificates. # See the POLICY FORMAT section of the `ca` manual page. countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [req] # Standard Req options default_bits = 4096 encrypt_key = yes default_md = sha256 utf8 = yes string_mask = utf8only prompt = no distinguished_name = ca_dn req_extensions = intermediary_ext [ca_ext] # Extensions for a the CA root (`man x509v3_config`). basicConstraints = critical,CA:true keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [intermediary_ext] # Extensions for an intermediary CA. subjectKeyIdentifier = hash # authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [server_ext] # Extensions for server certificates. basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth [client_ext] # Extensions for client certificates. basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtection [crl_ext] # Extension for CRLs. authorityKeyIdentifier=keyid:always [ocsp] # Extension for OCSP signing certificates. basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
intermediary_extセクションでは、仲介者に使用可能な発行者証明書がないため、authorityKeyIdentifierを含む行がコメント・アウトされています。 証明書が署名されるまで、中間は証明書発行者を認識しません。 この行が構成にまだ含まれているときにCSRを作成しようとすると、失敗します。
構成ファイルをintermediary.confとして保存します。
中間CAのCSRの作成
中間証明書のCSRを作成します。
sudo openssl req -new -config intermediary.conf -out sub-ca.csr -keyout private/sub-ca.key
この証明書は署名証明書でもあるため、パスフレーズで保護して、不正な使用を防止し、インフラストラクチャのセキュリティを維持することが重要です。 要求されたら、パスフレーズを入力します。
中間CAの署名付き証明書の作成
前のステップで生成したsub-ca.csrを、ルートCAがホストされているシステムの/etc/pki/caディレクトリにコピーします。 ルートCAホストで、次のコマンドを実行してCSRから署名付き証明書を生成し、中間署名拡張機能を適用します。
sudo cd /etc/pki/ca sudo openssl ca -config ca-root.conf -in sub-ca.csr -out newcerts/sub-ca.crt \ -extensions intermediary_ext
ルートCAパスフレーズの入力を求められ、証明書の内容が表示され、署名するよう求められます。 署名する前に、証明書の内容が適切であることを確認してください。 証明書がルートCAによって発行され、サブジェクトに中間CAが含まれていることがわかります。 また、正しい拡張機能が証明書に適用されていることも確認できます。
証明書に署名すると、データベースを更新するように求められます。
新しく署名された証明書は、newcerts/sub-ca.crtとして作成されます。
証明書チェーン・ファイルの作成
ルートCA証明書を認識するシステムがないため、新しく作成された中間CA証明書を使用して、ルートCAのパブリック証明書を含む証明書チェーンを作成することをお薦めします。 この方法では、ホストは、中間CAによって発行される証明書を検証するために、チェーン証明書のコピーのみを必要とします。 証明書チェーンを作成するには、ルートCAホストで次のコマンドを実行して、2つのパブリック証明書を結合します:
sudo cat root-ca.crt newcerts/sub-ca.crt > newcerts/chained-sub-ca.crt sudo chmod 444 newcerts/chained-sub-ca.crt
newcerts/sub-ca.crtおよびnewcerts/chained-sub-ca.crt証明書を中間CAホストの/root/ca-intermediary/ディレクトリにコピーします。 これで、この証明書を使用して、サーバーとクライアントのCSRを処理し、CRLを生成できるようになりました。
特定のCSRの署名付き証明書を返却する場合は、chained-sub-ca.crt証明書を含めて、証明書が使用され、署名付き証明書を検証する必要があるクライアントに配布されるホストにインストールできるようにします。
CSRの処理および証明書への署名
システムは、「OpenSSLを使用した証明書署名リクエストの作成」で説明されているプロセスを使用してCSRを生成するため、署名のためにCSRをCAに送信する必要があります。
サーバー証明書およびクライアント側証明書の以降のすべてのCSR処理は、環境内または外部のサード・パーティCAによって構成された中間CAによって実行する必要があります。
CSRを処理するには、中間CAホスト上の/root/ca-intermediaryディレクトリにコピーし、openssl caコマンドを使用して適切な拡張構成で署名します。
たとえば、www.example.com.csrという名前のCSRのサーバー側証明書に署名するには、次のコマンドを実行します。
sudo openssl ca -config intermediary.conf -extensions server_ext -days 375 \ -in www.example.com.csr -out newcerts/www.example.com.crt
証明書を有効にする日数を指定することに注意してください。 サーバー側証明書の場合、日数はCA証明書の有効性よりはるかに少ない値に制限する必要があります。 証明書に適用する適切な拡張機能を選択することが重要です。 これらの拡張は、構成ファイル内の定義にマップされます。
中間CAキー・パスフレーズの入力を求められ、証明書に署名してデータベースを更新するように求められます。
証明書を連鎖したCA証明書とともに返して、証明書を検証するために配布できるようにします。
証明書失効リストの管理
証明書失効リストは、署名CAによって発行されて取り消された証明書を識別するために使用されます。 このリストは、証明書が取り消された理由も追跡します。
CRLの生成
各CAホストで、証明書を取り消す必要があるときに更新できる空のCRLを作成する必要があります。 たとえば、中間CAでは次のコマンドを使用します。
sudo cd /etc/pki/ca-intermediary sudo openssl ca -config intermediary.conf -gencrl -out crl/sub-ca.crl
CRLは、CAによって取り消された証明書を追跡するために、構成ファイルで定義されているURLに公開する必要があります。 可能な場合は、sub-ca.crlを提供するようにWebサービスを構成する必要があります。
CRLの内容は、次のようにして確認できます。
sudo openssl crl -in crl/sub-ca.crl -noout -textCRLが作成されたばかりの場合は空です。 default_crl_daysのCA構成ファイルに設定されている構成値に基づいて、新しいCRLを定期的に作成する必要があります。 デフォルトでは、30日ごとに設定されます。
証明書の取消し
すべての署名付き証明書には、署名CAによって発行されたシリアル番号が含まれます。 証明書内のこのシリアル番号は、次のようにして表示できます。
sudo openssl x509 -serial -noout -in server.crt
このシリアル番号は、CA署名データベース内の証明書を識別し、CAが証明書を取り消せるように、署名したCAによって格納された証明書を識別するためにも使用できます。
証明書が発行されたCAで、certsディレクトリ内でシリアル番号が一致する証明書を見つけることができます。 たとえば、中間ホストでは、シリアル番号が8F75111A8E33B2D109A8BF079C67C83Fの証明書の場合、次のようになります。
sudo cd /etc/pki/ca-intermediary
sudo ls certs/8F75111A8E33B2D109A8BF079C67C83F*
certs/8F75111A8E33B2D109A8BF079C67C83F.pemCAデータベースの証明書の詳細を確認することもできます。
sudo grep 8F75111A8E33B2D109A8BF079C67C83F db/index.txtこの証明書を取り消すには、署名CAが次のコマンドを発行する必要があります。
sudo openssl ca -config intermediary.conf -revoke certs/8F75111A8E33B2D109A8BF079C67C83F.pem \ -crl_reason keyCompromise
証明書を取り消す理由は証明書失効リストで使用されるため、この理由を指定する必要があることに注意してください。 オプションには、unspecified、keyCompromise、CACompromise、affiliationChanged、superseded、cessationOfOperation、certificateHold,およびremoveFromCRLがあります。 詳細は、CA(1)マニュアル・ページを参照してください。
証明書が取り消されると、CAデータベースがこの変更を反映するように更新され、db/index.txtファイルにリストされている証明書のステータスはRに設定されます。
データベース・ファイルは、CRLが作成されるたびにCRLを生成するために使用されます。 証明書を取り消すとすぐに新しいCRLを生成することをお薦めします。 このようにして、このリストは最新の状態に保たれます。 詳細は、CRLの生成を参照してください。
OCSPサーバーの構成および実行
オンライン証明書ステータス・プロトコル(OCSP)は、CRLの代替手段であり、独自の発行メカニズムを備えています。 OpenSSLには、OCSP問合せに応答できるOCSPサーバーとして実行するオプションが含まれています。
OCSPはCRLより優先されることに注意してください。 通常、OCSPサーバーがCAに対して実行されていることを確認することをお薦めします。特に、OCSP URLが構成に表示されている場合は、このURLがCAによって署名された各証明書に含まれているためです。 クライアント・ソフトウェアは、OCSPサーバーを問い合せることによって、証明書の失効ステータスを確認できます。
任意のCAに対して、OCSPサーバーのキーとCSRを作成します。
sudo openssl req -new -newkey rsa:2048 -subj "/C=AU/O=Example Org/CN=OCSP Responder" \
-keyout private/ocsp.key -out ocsp.csrocsp.csr CSRファイルから署名付き証明書を作成します。
sudo openssl ca -config intermediary.conf -extensions ocsp -days 187 -in ocsp.csr \ -out newcerts/ocsp.crt
OCSP証明書は失効の処理を担当するため、取り消すことはできません。 したがって、証明書の有効期間を管理可能ですが、比較的短い期間に設定することをお薦めします。 この例では、有効期間は187日に設定されています。つまり、6か月ごとにリフレッシュする必要があります。
現在のCAでOCSPサーバーを実行するには、OpenSSL内で提供されているツールを使用できます。 たとえば、次のコマンドを使用します。
sudo openssl ocsp -port 9080 -index db/index.txt -rsigner newcerts/ocsp.crt \ -rkey private/ocsp.key -CA sub-ca.crt -text
このコマンドはCA db/index.txtファイルを直接指定するため、証明書が取り消されると、OCSPサーバーはそれらを自動的に認識します。 コマンドを実行すると、OCSPキー・パスフレーズの入力を求められます。 サーバーは、Ctrl-Cなどの制御シーケンスを使用してプロセスまたはエスケープを終了するまで実行し続けます。
ocsp.crtファイルをチェックして、サービスをテストできます。 OCSP問合せを実行するには、次のようにopensslコマンドを使用します:
sudo openssl ocsp -issuer sub-ca.crt -CAfile chained-sub-ca.crt -cert newcerts/ocsp.crt \
-url http://127.0.0.1:9080
Response verify OK
newcerts/ocsp.crt: good
This Update: Oct 30 15:48:11 2019 GMT前の例のレスポンスは、検証が成功したかどうかを示し、証明書が失効していない場合はgoodのステータスを示します。 失効している場合は、ステータスrevokedが返されます。