ssl/tls - f5 networks...2016/04/09 · 3 1. はじめに...
TRANSCRIPT
SSL/TLS 設定ガイド (v11.5.4対応) [基本編]サーバ証明書/クライアント証明書認証
F5 Networks Japan V1.0
Ⅹ
目次
1. はじめに .......................................................................................................................................................... 3
2. ネットワーク構成サンプル ................................................................................................................................. 4
3. ルート/中間/サーバ証明書の生成 .................................................................................................................... 5
3.1. デジタル証明書の連鎖 .............................................................................................................................. 5
3.2. 本ガイドで使う証明書の値 ........................................................................................................................ 6
3.3. ルート認証局 (F5J-CA) の生成 ............................................................................................................... 7
3.4. 中間認証局 01(InterCA01)の生成 .......................................................................................................... 10
3.5. 中間認証局 02(InterCA02)の生成 .......................................................................................................... 13
3.6. ABC社の秘密鍵とサーバ証明書の生成 ................................................................................................. 16
4. BIG-IPの基本設定 ........................................................................................................................................ 18
4.1. Platform設定 ......................................................................................................................................... 18
4.2. VLAN設定 ............................................................................................................................................. 18
4.3. Self IPの設定 ........................................................................................................................................ 19
4.4. Routing設定 .......................................................................................................................................... 19
4.5. NTPの設定 ........................................................................................................................................... 19
5. サーバ証明書関連の設定 .............................................................................................................................. 20
5.1. SSLハンドシェークフロー (例:RSA鍵交換) ........................................................................................... 20
5.2. 「SSLハンドシェークの事前準備」を行う .................................................................................................. 23
5.3. SAN (Subject Alternative Name)の設定 ................................................................................................ 37
5.4. SNI (Server Name Indication)の設定 .................................................................................................... 44
6. クライアント証明書の生成 .............................................................................................................................. 53
6.1. クライアント証明書向けフォルダの生成 ................................................................................................... 54
6.2. クライアント証明書の署名リクエスト(CSR)の生成 .................................................................................... 54
6.3. 中間認証局 02によるクライアント署名リクエスト(CSR)への署名 ............................................................. 54
6.4. クライアント証明書のフォーマット変換...................................................................................................... 55
7. クライアント証明書認証の設定 ....................................................................................................................... 56
7.1. クライアント証明書認証のフロー .............................................................................................................. 56
7.2. 「クライアント証明書認証の事前準備」を行う ............................................................................................ 59
8. クライアント証明書の失効管理 ....................................................................................................................... 65 8.1. CRL (Certificate Revocation List) .......................................................................................................... 65 8.2. OCSP (Online Certificate Status Protocol) ........................................................................................... 70 8.3. CRLDP (Certificate Revocation List Distribution Point) ........................................................................ 75
9. おわりに ........................................................................................................................................................ 84
10. [Appendix.1] SSL暗号を「できるかぎり」ひも解く ...................................................................................... 85
10.1. 暗号スイート (Cipher Suite) ............................................................................................................... 85
10.2. RSA とは ............................................................................................................................................ 86
10.3. Diffie-Hellman とは ............................................................................................................................. 90
10.4. DHE-RSAの SSLハンドシェークフロー .............................................................................................. 91
10.5. キーブロックの生成 ............................................................................................................................. 93
10.6. PRF (P_SHA256) のフロー ............................................................................................................... 94
10.7. データの生成 ...................................................................................................................................... 99
10.8. AES暗号 ......................................................................................................................................... 101
11. [Appendix.2] OpenLDAPの設定 .......................................................................................................... 111
11.1. OpenLDAPのインストールと起動 ..................................................................................................... 111
11.2. 管理者パスワードの設定 ................................................................................................................... 111
11.3. ドメインの設定 ................................................................................................................................... 111
12. [Appendix.3] OpenSSL コマンドのオプション解説 .................................................................................. 114
12.1. 署名リクエスト(CSR)と鍵の生成時のオプション ................................................................................. 114
12.2. 署名時のオプション ........................................................................................................................... 114
3
1. はじめに
このガイドでは、クライアント~BIG-IP間で SSL/TLS通信を行うための設定方法を解説します。
昨今、スマートデバイスの急速な普及に伴い、無線 LANアクセスポイントの成りすましによる盗聴や、アメリカ国家
安全保障局(NSA)によるインターネット傍受行為が内部告発されたことなどを背景に、暗号化通信:SSLへの注目が
高まってきており、今まで以上に多くの企業で SSL/TLS を導入するであろうことが予想されます。
SSL/TLSの挙動を確認したい場合、商用の認証局から発行されたサーバ証明書/クライアント証明書を行ってテスト
するのは、近々導入予定がある状況でなければ難しいと思います。
よって本ガイドは、OpenSSL を使って SSL通信用の X509デジタル証明書を独自に作り、それを使って BIG-IP を
設定して動作を確認する、という内容にしています。
本ガイドのテーマは大きく以下 2つです。
1) サーバ証明書を使った SSL通信
2) クライアント証明書を使ったクライアント認証
以降、以下の名称を使います。
ルート認証局のデジタル証明書: ルート証明書
中間認証局のデジタル証明書: 中間証明書
サーバのデジタル証明書: サーバ証明書
クライアントのデジタル証明書: クライアント証明書
本ガイドでは、CentOS 6.7の OpenSSL を利用しました。Versionは以下です。
# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
尚、本ガイドで利用する OpenSSL コマンドの詳細については、巻末:「[Appendix.3] OpenSSL コマンドのオプシ
ョン解説」に記載していますので、必要に応じてご参照ください。
4
2. ネットワーク構成サンプル
以下のネットワーク構成を使って、SSL動作を確認します。
10.99.100.210のサーバ(CentOS6.7)上の OpenSSL を使って、デジタル証明書を生成します。
クライアント証明書認証の CRLによる失効管理の際の、CRL ファイル転送用に Apache(Webサーバ)を使いま
す。
クライアント証明書認証の CRLDPによる失効管理の際に、OpenLDAP を使います。
5
3. ルート/中間/サーバ証明書の生成
まず、ルート証明書、中間証明書、サーバ証明書およびそれぞれの秘密鍵を生成します。
3.1. デジタル証明書の連鎖
以下は、秘密鍵とデジタル証明書の連鎖の様子を示しています。
ABC社は、中間認証局である InterCA02にサーバ証明書の発行を依頼した、と仮定します。
この証明書は、上図のような署名の連鎖によって信頼されます。
[解説]
① ABC社の秘密鍵は、ABC社の公開鍵と対を成しています。
② ABC社のサーバ証明書は、中間認証局 02の秘密鍵で署名されたものです。
③ 中間認証局 02の秘密鍵は、中間認証局 02の公開鍵と対を成しています。
④ 中間認証局 02の公開鍵を持つ中間証明書は、中間認証局 01の秘密鍵で署名されたものです。
⑤ 中間認証局 01の秘密鍵は、中間認証局 01の公開鍵と対を成しています。
⑥ 中間認証局 01の公開鍵を持つ中間証明書は、ルート認証局の秘密鍵で署名されたものです。
⑦ ルート認証局の秘密鍵は、ルート認証局の公開鍵と対を成しています。
⑧ ルート認証局の公開鍵を持つルート証明書は、自分自身の秘密鍵で署名されたもの※です。
※ 証明書の信頼性は上位認証局の署名によって証明されますが、ルート認証局は、自分自身で署名をします。
この自己署名が許されるルート認証局になるためには、認証局監査基準である「WebTrust for CA」を満たす必
要があります。
「WebTrust for CA」 とは:
IETFによって、RFC3647:Internet X.509 Public Key Infrastructure / Certificate Policy and Certification
Practices Frameworkが制定されており、これを基に「ANS X9.79」(PKI Practices and Policy Framework)が
生成されました。さらに ANS X9.79の成果を基に、認証局監査基準である「WebTrust for CA」が生成さました。
WebTrust for CAは、大きくは以下 3つで構成されています。
① 認証局業務の開示
② サービスインテグリティ (サービスの完全性)
③ 認証局環境の統制 (コントロール)
この厳しい基準をクリアしたルート認証局 (例:Verisignや CyberTrustなど) のルート証明書が、事前にWebブ
ラウザにインストールされています。
以降、このデジタル証明書の連鎖の通りに、OpenSSLを使って証明書を生成していきます。
6
3.2. 本ガイドで使う証明書の値
証明書を生成する際に利用する各値は、以下としました。
(1) ルート認証局 (F5J-CA)
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Tokyo
localityName 区市町村 Minato-ku
organizationName 会社名 F5J-CA, Ltd.
organizationalUnitName 組織名 CA
commonName 名称 f5jca.f5jp.local
(2) 中間認証局 (InterCA01)
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Saitama
localityName 区市町村 Soka
organizationName 会社名 InterCA01, Ltd.
organizationalUnitName 組織名 ICA01
commonName 名称 ica.interca01.local
(3) 中間認証局 (InterCA02)
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Chiba
localityName 区市町村 Funabashi
organizationName 会社名 InterCA02, Ltd.
organizationalUnitName 組織名 ICA02
commonName 名称 ica.interca02.local
(4) サーバ証明書の所有者 (ABC-Company)
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Kanagawa
localityName 区市町村 Yokohama
organizationName 会社名 ABC-Company, Ltd.
organizationalUnitName 組織名 IT
commonName 名称 www.abc-company.lab
7
3.3. ルート認証局 (F5J-CA) の生成
まず、ルート認証局の秘密鍵と証明書を生成します。
以下はその生成フローのイメージです。
① ルート認証局は、自身の秘密鍵を生成します。(cakey.pem)
② ルート認証局は、自身の署名リクエスト(CSR)を生成します。(careq.pem)
③ ルート認証局は、署名リクエスト(CSR)に対して、署名を行う認証局の情報(ルート認証局自身の情報)や有効期間
などを追加して、それを「tbsCertificate」とします。
④ この「tbsCertificate」を、SHA-2を使ってハッシュ値を計算します。
⑤ そのハッシュ値を、ルート認証局の秘密鍵を使って、RSAで暗号化します。これが署名です。
⑥ 「tbsCertificate」に署名を加えたものが、ルート認証局の証明書になります。
8
3.3.1. ルート認証局向けファイルの生成
ルート認証局の秘密鍵や証明書を生成する際に必要なファイルを生成します。
3.3.1.1. デフォルトのフォルダを確認
本ガイドでは、openssl.cnf内に記載された、デフォルトのフォルダをそのままルート認証局用に使うことにします。
CA のデフォルトのディレクトリは/etc/pki/CA となっていますので、そのまま利用します。
# less /etc/pki/tls/openssl.cnf
~略~
####################################################################
[ CA_default ]
dir = /etc/pki/CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
~略~
3.3.1.2. /etc/pki/CA/内に存在するディレクトリを確認
デフォルトで、以下のディレクトリが用意されています。
# ls -l /etc/pki/CA/
total 16
drwxr-xr-x. 2 root root 4096 Jan 9 03:43 certs
drwxr-xr-x. 2 root root 4096 Jan 9 03:43 crl
drwxr-xr-x. 2 root root 4096 Jan 9 03:43 newcerts
drwx------. 2 root root 4096 Jan 9 03:43 private
3.3.1.3. ファイルの生成
自己署名による証明書発行に必要なシリアル番号およびインデックス管理のためのファイルを生成します。
以下のコマンドを実行します。
(1) CA 用のフォルダへ移動
# cd /etc/pki/CA/
(2) ファイルの生成
# echo "01" > ./serial :openssl が利用する、シリアル番号管理のためのファイル
# touch ./index.txt :openssl が利用する、インデックス管理のためのファイル
9
3.3.2. ルート認証局の秘密鍵および署名リクエスト
認証局の秘密鍵および署名リクエスト(CSR)を生成します。
(1) 現在のフォルダの確認
# pwd
/etc/pki/CA
(2) 秘密鍵と署名リクエスト(CSR)の生成
ルート認証局自身が、秘密鍵と署名リクエスト(CSR)を生成します。
以下のコマンドを実行します。
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./private/cakey.pem -out ./careq.pem \
-subj "/C=JP/ST=Tokyo/L=Minato-ku/O=F5J-CA, Ltd./OU=CA/CN=f5jca.f5jp.local"
3.3.3. ルート認証局による自己署名
ルート認証局の証明書に自己署名します。
以下のコマンドを実行します。
# openssl ca -md sha256 -in ./careq.pem -keyfile ./private/cakey.pem -out ./cacert.pem \
-selfsign -extensions v3_ca -batch -days 3650
Using configuration from /etc/pki/tls/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Mar 16 06:21:18 2016 GMT
Not After : Mar 14 06:21:18 2026 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
organizationName = F5J-CA, Ltd.
organizationalUnitName = CA
commonName = f5jca.f5jp.local
X509v3 extensions:
X509v3 Subject Key Identifier:
AD:97:0E:CA:C3:1E:75:98:0B:87:1A:26:A4:44:C7:C8:BF:75:C2:71
X509v3 Authority Key Identifier:
keyid:AD:97:0E:CA:C3:1E:75:98:0B:87:1A:26:A4:44:C7:C8:BF:75:C2:71
X509v3 Basic Constraints:
CA:TRUE
Certificate is to be certified until Mar 14 06:21:18 2026 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
これでルート認証局の生成は完了です。
10
3.4. 中間認証局 01(InterCA01)の生成
ルート認証局から見て一段目の、中間認証局 01の秘密鍵と証明書を生成します。
以下はその生成フローイメージです。
① 中間認証局 01は、自身の秘密鍵を生成します。(interca01key.pem)
② 中間認証局 01は、自身の署名リクエスト(CSR)を生成します。(interca01req.pem)
③ 中間認証局 01は、署名リクエスト(CSR)をルート認証局に送ります。
④ ルート認証局は、署名リクエスト(CSR)に対して、署名を行う認証局の情報(ルート認証局自身の情報)や有効期間
などを追加して、それを「tbsCertificate」とします。
⑤ この「tbsCertificate」を、SHA-2を使ってハッシュ値を計算します。
⑥ そのハッシュ値を、ルート認証局の秘密鍵を使って、RSAで暗号化します。これが署名です。
⑦ 「tbsCertificate」と署名を一まとまりにしたものが、中間認証局 01の証明書になります。
⑧ ルート認証局は、その証明書を中間認証局 01へ送ります。
11
3.4.1. 中間認証局 01向けフォルダの生成
中間認証局 01(interCA01)の秘密鍵や証明書を保存するためのフォルダを生成します。
(1) 現在のフォルダの確認
# pwd
/etc/pki/CA
(2) フォルダの生成
本ガイドではこの/etc/pki/CAの下に、interCA01向けのフォルダを作ることにします。
以下のコマンドを実行します。
# mkdir ./interCA01
# mkdir ./interCA01/private
# mkdir ./interCA01/newcerts
3.4.2. 中間認証局 01の秘密鍵と署名リクエストの生成
中間認証局 01自身が、秘密鍵と署名リクエスト(CSR)を生成します。
以下のコマンドを実行します。
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./interCA01/private/interCA01key.pem \
-out ./interCA01/interCA01req.pem \
-subj "/C=JP/ST=Saitama/L=Soka/O=InterCA01, Ltd./OU=ICA01/CN=ica.interca01.local"
3.4.3. 中間認証局 01の CSRへの署名
上記で生成した署名リクエスト(CSR)へ、ひとつ上のルート認証局が署名します。
以下のコマンドを実行します。
# openssl ca -md sha256 -in ./interCA01/interCA01req.pem -keyfile ./private/cakey.pem \
-out ./interCA01/interCA01crt.pem -extensions v3_ca -batch -policy policy_anything -days 3650
Using configuration from /etc/pki/tls/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Mar 16 06:26:16 2016 GMT
Not After : Mar 14 06:26:16 2026 GMT
Subject:
countryName = JP
stateOrProvinceName = Saitama
localityName = Soka
organizationName = InterCA01, Ltd.
organizationalUnitName = ICA01
commonName = ica.interca01.local
X509v3 extensions:
X509v3 Subject Key Identifier:
7B:19:81:D8:B6:27:71:C1:8B:05:69:E9:B0:05:20:05:81:B7:EC:5C
X509v3 Authority Key Identifier:
keyid:AD:97:0E:CA:C3:1E:75:98:0B:87:1A:26:A4:44:C7:C8:BF:75:C2:71
X509v3 Basic Constraints:
CA:TRUE
12
Certificate is to be certified until Mar 14 06:26:16 2026 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
これで中間認証局 01の生成は完了です。
3.4.4. 中間認証局 01専用の openssl.cnfの生成
以降の中間認証局 02の生成の際に利用する、中間認証局 01専用の openssl.cnf を作っておきます。
① デフォルトの openssl.cnf をコピーします。
# cp /etc/pki/tls/openssl.cnf ./interCA01/openssl-interCA01.cnf
② 以下の赤文字部分の通りに編集します。
# vi ./interCA01/openssl-interCA01.cnf
[ CA_default ]
dir = /etc/pki/CA/interCA01 # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/interCA01crt.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/interCA01key.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
3.4.5. 中間認証局 01専用のシリアル/インデックス管理用ファイルの生成
以降の中間認証局 02の生成の際に利用する、中間認証局 01専用のシリアル番号およびインデックス管理のため
のファイルを生成します。
以下のコマンドを実行します。
# echo "01" > ./interCA01/serial :openssl が利用する、シリアル番号管理のためのファイル
# touch ./interCA01/index.txt :openssl が利用する、インデックス管理のためのファイル
13
3.5. 中間認証局 02(InterCA02)の生成
ルート認証局から見て二段目の、中間認証局 02の秘密鍵と証明書を生成します。
以下はその生成フローイメージです。
① 中間認証局 02は、自身の秘密鍵を生成します。(interca02key.pem)
② 中間認証局 02は、自身の署名リクエスト(CSR)を生成します。(interca02req.pem)
③ 中間認証局 02は、署名リクエスト(CSR)を中間認証局 01に送ります。
④ 中間認証局 01は、署名リクエスト(CSR)に対して、署名を行う認証局の情報(中間認証局 01自身の情報)や有効
期間などを追加して、それを「tbsCertificate」とします。
⑤ この「tbsCertificate」を、SHA-2を使ってハッシュ値を計算します。
⑥ そのハッシュ値を、中間認証局 01の秘密鍵を使って、RSAで暗号化します。これが署名です。
⑦ 「tbsCertificate」と署名を一まとまりにしたものが、中間認証局 02の証明書になります。
⑧ 中間認証局 01は、その証明書を中間認証局 02へ送ります。
14
3.5.1. 中間認証局 02向けフォルダの生成
中間認証局 02(interCA02)の秘密鍵や証明書を保存するためのフォルダを生成します。
(1) interCA01 フォルダへ移動
# cd /etc/pki/CA/interCA01
(2) フォルダおよびファイルの生成
本ガイドではこの/etc/pki/CA/interCA01の下に、interCA02向けのフォルダを作ることにします。
以下のコマンドを実行します。
# mkdir ./interCA02
# mkdir ./interCA02/private
# mkdir ./interCA02/newcerts
3.5.2. 中間認証局 02の秘密鍵と署名リクエストの生成
中間認証局 02自身が、秘密鍵と署名リクエスト(CSR)を生成します。
以下のコマンドを実行します。
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./interCA02/private/interCA02key.pem \
-out ./interCA02/interCA02req.pem \
-subj "/C=JP/ST=Chiba/L=Funabashi/O=InterCA02, Ltd./OU=ICA02/CN=ica.interca02.local"
3.5.3. 中間認証局 02の CSRへの署名
上記で生成した署名リクエスト(CSR)へ、ひとつ上の中間認証局 01が署名します。
以下のコマンドを実行します。
# openssl ca -md sha256 -in ./interCA02/interCA02req.pem -keyfile ./private/interCA01key.pem \
-out ./interCA02/interCA02crt.pem -extensions v3_ca -batch -policy policy_anything \
-config ./openssl-interCA01.cnf -days 3650
Using configuration from ./openssl-interCA01.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Mar 16 06:32:04 2016 GMT
Not After : Mar 14 06:32:04 2026 GMT
Subject:
countryName = JP
stateOrProvinceName = Chiba
localityName = Funabashi
organizationName = InterCA02, Ltd.
organizationalUnitName = ICA02
commonName = ica.interca02.local
X509v3 extensions:
X509v3 Subject Key Identifier:
27:D4:C0:71:A5:7E:7F:41:9D:BE:9E:AB:60:07:70:69:0D:BD:8B:8D
X509v3 Authority Key Identifier:
keyid:7B:19:81:D8:B6:27:71:C1:8B:05:69:E9:B0:05:20:05:81:B7:EC:5C
X509v3 Basic Constraints:
CA:TRUE
15
Certificate is to be certified until Mar 14 06:32:04 2026 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
これで中間認証局 02の生成は完了です。
3.5.4. 中間認証局 02専用の openssl.cnfの生成
以降のサーバ証明書やクライアント証明書の生成の際に利用する、中間認証局 02専用の openssl.cnf を作ってお
きます。
① デフォルトの openssl.cnf をコピーします。
# cp /etc/pki/tls/openssl.cnf ./interCA02/openssl-interCA02.cnf
② 以下の赤文字部分の通りに編集します。
# vi ./interCA02/openssl-interCA02.cnf
[ CA_default ]
dir = /etc/pki/CA/interCA01/interCA02 # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/interCA02crt.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/interCA02key.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
3.5.5. 中間認証局 02専用のシリアル/インデックス管理用ファイルの生成
以降のサーバ証明書およびクライアントの生成の際に利用する、中間認証局 02専用のシリアル番号およびインデ
ックス管理のためのファイルを生成します。
以下のコマンドを実行します。
# echo "01" > ./interCA02/serial :openssl が利用する、シリアル番号管理のためのファイル
# touch ./interCA02/index.txt :openssl が利用する、インデックス管理のためのファイル
16
3.6. ABC社の秘密鍵とサーバ証明書の生成
ABC社の秘密鍵とサーバ証明書を生成します。
以下はその生成フローイメージです。
① ABC社は、自身の秘密鍵を生成します。(abcCompany-key.pem)
② ABC社は、自身の署名リクエスト(CSR)を生成します。(abcCompany-req.pem)
③ ABC社は、署名リクエスト(CSR)を中間認証局 02に送ります。
④ 中間認証局 02は、署名リクエスト(CSR)に対して、署名を行う認証局の情報(中間認証局 02自身の情報)や有効
期間などを追加して、それを「tbsCertificate」とします。
⑤ この「tbsCertificate」を、SHA-2を使ってハッシュ値を計算します。
⑥ そのハッシュ値を、中間認証局 02の秘密鍵を使って、RSAで暗号化します。これが署名です。
⑦ 「tbsCertificate」と署名を一まとまりにしたものが、ABC社のサーバ証明書になります。
⑧ 中間認証局 02は、そのサーバ証明書を ABC社へ送ります。
17
3.6.1. サーバ証明書用のフォルダの生成
サーバ証明書や秘密鍵を保存するために必要なフォルダを生成します。
(1) interCA02 フォルダへ移動
# cd /etc/pki/CA/interCA01/interCA02
(2) サーバ証明書用フォルダの生成
# mkdir ./SERVER
3.6.2. ABC社の秘密鍵とサーバ証明書の署名リクエスト(CSR)の生成
ABC 社自身が、秘密鍵と署名リクエスト(CSR)を生成します。以下のコマンドを実行します。
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./SERVER/abcCompany-key.pem \
-out ./SERVER/abcCompany-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=ABC-Company, Ltd./OU=IT/CN=www.abc-company.lab"
3.6.3. 認証局による署名リクエスト(CSR)への署名
上記で生成した署名リクエスト(CSR)へ、ひとつ上の中間認証局 02が署名します。以下のコマンドを実行します。
# openssl ca -md sha256 -in ./SERVER/abcCompany-req.pem -out ./SERVER/abcCompany-crt.pem \
-keyfile ./private/interCA02key.pem -batch -policy policy_anything \
-config ./openssl-interCA02.cnf -days 3650
Using configuration from ./openssl-interCA02.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Mar 16 06:37:02 2016 GMT
Not After : Mar 14 06:37:02 2026 GMT
Subject:
countryName = JP
stateOrProvinceName = Kanagawa
localityName = Yokohama
organizationName = ABC-Company, Ltd.
organizationalUnitName = IT
commonName = www.abc-company.lab
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
FB:17:4B:4F:5A:01:DA:8F:8F:23:E0:5A:F4:2F:0B:1D:4F:7A:E2:19
X509v3 Authority Key Identifier:
keyid:27:D4:C0:71:A5:7E:7F:41:9D:BE:9E:AB:60:07:70:69:0D:BD:8B:8D
Certificate is to be certified until Mar 14 06:37:02 2026 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
これで、サーバ証明書の生成は完了です。
18
4. BIG-IPの基本設定
本ガイドのネットワーク構成サンプルに合わせて、まず、BIG-IPのネットワーク等の基本的な部分を設定します。
4.1. Platform設定
以下は、初期ウィザードの流れの中で設定します。
設定した内容は、「System」→「Platform」で確認できます。
4.2. VLAN設定
「Network」→「VLANs」で、以下の状態になるように設定します。
ホスト名。FQDN形式で指定。
Asia/Tokyo を選択。
CLIアクセス用 rootアカウントの
パスワード
WebUIアクセス用 adminアカウントの
パスワード
19
4.3. Self IPの設定
「Network」→「Self IPs」で、以下の状態になるように設定します。
4.4. Routing設定
「Network」→「Routes」で、以下の状態になるように設定します。
4.5. NTPの設定
OpenSSLサーバとの時刻を合わせておきます。
「System」→「Configuration」→「Device」→「NTP」で表示された画面で、以下のように設定します。
NTPサーバのアドレスを指定して、
「Add」ボタンを押す。
20
5. サーバ証明書関連の設定
サーバ証明書を使った SSL通信を行うための設定を行います。
5.1. SSLハンドシェークフロー (例:RSA鍵交換)
以降の BIG-IP設定で、今どの設定を行っているのかを理解するために、まず RSA鍵交換を使った場合の SSLハ
ンドシェークのイメージを示します。
21
5.1.1. SSLハンドシェークの事前準備
SSLハンドシェークが行えるようにするためには、大きくは以下の 5つの設定が必要です。
① クライアント PC上に、ルート認証局(F5J-CA)の証明書をインポートします。
(Verisignや CyberTrustなど、正規の認証局から発行された証明書であれば、Webブラウザにプリインストール
されているので、このステップは不要です。)
② BIG-IPに、ABC社の秘密鍵をインポートします。
③ BIG-IPに、中間認証局 02が署名した、ABC社のサーバ証明書をインポートします。
④ BIG-IPに、中間認証局 01 と 02の証明書をインポートします。
⑤ BIG-IPに、ABC社のサーバ証明書と中間認証局(01 と 02)の証明書を同時にクライアントに送れるように設定し
ます。
5.1.2. SSLハンドシェーク (RSA鍵交換の場合)
事前準備が完了していれば、以降は自動的に行われるフローですが、この事前準備が何のために必要なのかを理
解するために、SSLハンドシェークフローの概要を記載しておきます。
① クライアントからの Client Helloにて、主に以下 2つの情報がサーバ (BIG-IP) へ送られます。
A) クライアントがサポートしている暗号アルゴリズムのリスト
B) クライアントが生成したランダムな値 (クライアントランダム)
② BIG-IPからの Server Helloにて、主に以下 2つの情報がクライアントへ送られます。
A) クライアントから提示された暗号アルゴリズムの中から一つ選んだ暗号アルゴリズム
B) サーバが生成したランダムな値 (サーバランダム)
③ BIG-IPから、中間証明書 01,中間証明書 02, ABC社のサーバ証明書がクライアントへ送られます。
④ クライアントは ABC社のサーバ証明書から tbcCertificate と署名を分離します。
⑤ ABC社の tbsCertificateのハッシュを計算します。
⑥ ABC社の RSAで署名されている署名値を、中間認証局 02の公開鍵で復号化し、ハッシュ値を取り出します。
⑦ ⑤と⑥で得られたハッシュ値を比較。一致すれば、この証明書は改ざんされていないものとして、中間認証局 02
の証明書によって、証明されます。
⑧ また⑦の結果、ABC社のサーバ証明書内の公開鍵も中間認証局 02の証明書によって、信頼できると判断され
ます。
⑨ 今度は下図のように、中間証明書 02、中間証明書 01が信頼できるか、の検証が行われます。
22
a) 中間認証局 02の中間証明書の署名と tbsCertificateを分離します。
b) 中間認証局 02の tbsCertificateのハッシュを計算します。
c) RSAで署名されている署名値を、中間認証局 01の公開鍵で復号化し、ハッシュ値を取り出します。
d) b)と c)で得られたハッシュ値を比較。一致すれば、中間証明書 01によって、この証明書は改ざんされて
いない=信頼できるものとして扱われます。
e) また d)の結果、ABC社の中間認証局 02の証明書内の公開鍵も、中間証明書 01によって、信頼できる
と判断されます。
f) ~ j) は、中間証明書 02 と同様の処理によって、今度は中間証明書 01がルート証明書によって信頼さ
れます。
この⑨の処理が完了して初めて、ABC社のサーバ証明書(公開鍵)が信頼されます。
⑩ クライアントは、共通鍵などを生成するために必要な「プリマスターシークレット」値を生成します。
⑪ この「プリマスターシークレット」値を、ABC社の公開鍵で暗号化します。
⑫ 暗号化された⑩の値を、BIG-IPへ送ります。
⑬ BIG-IPは、その暗号化された「プリマスターシークレット」を ABC社の秘密鍵で復号化します。
⑭ 結果、「プリマスターシークレット」を、クライアントとサーバの間で共有できます。
23
5.2. 「SSLハンドシェークの事前準備」を行う
SSLハンドシェークを行うための事前準備となる設定を行います。
5.2.1. BIG-IPの設定
まずクライアント PCよりも先に BIG-IPの設定を行うことにします。
5.2.1.1. ABC社の秘密鍵およびサーバ証明書のインポート
ここまでのステップで生成した秘密鍵および証明書のうち、以下 4つを使います。
① abcCompany-key.pem ABC社の秘密鍵
② abcCompany-crt.pem ABC社の証明書
③ interCA01crt.pem 中間認証局 01の証明書
④ interCA02crt.pem 中間認証局 02の証明書
(1) これらのファイルを、BIG-IPの GUIへアクセスするコンソール PCへ (WinSCPなどを使って) コピーしておきま
す。
(2) ABC社の秘密鍵および証明書をインポートします。
「System」→「File Management」→「SSL Certificate List」で表示された画面の右上の「Import」ボタンを押して現
れた画面で、以下のように設定します。
(3) 秘密鍵ファイルの Importが完了した状態です。Nameの部分:「abcCompany」をクリックします。
「Key」を選択。
名称(任意)を指定。
アップロードする秘密鍵ファイルを指定。
24
(4) 今度は、秘密鍵ファイルに紐づいたサーバ証明書を Import します。以下の状態で「Import」ボタンを押します。
(5) Uploadするサーバ証明書を指定し、「Import」ボタンを押します。
(6) abc-company.labの証明書と秘密鍵が Import された状態です。
これで、秘密鍵とサーバ証明書のインポートは完了です。
Uploadする証明書を選択。
25
5.2.1.2. 中間認証局の証明書のインポート
BIG-IPに、中間認証局 01 と 02の証明書をインポートします。
「System」→「File Management」→「SSL Certificate List」で表示された画面の右上の「Import」ボタンを押して現
れた画面で、以下のように設定します。
(1) 中間認証局 01
(2) 中間認証局 02
(3) インポートされた 2つの中間証明書と秘密鍵は以下の状態になります。
26
5.2.1.3. 複数の中間証明書をまとめてチェーン証明書を作る
2つ以上の中間認証局が存在していると、それぞれの証明書を 1つのファイルにまとめる必要があります。
これは BIG-IP の仕様です。
sol13302: Configuring the BIG-IP system to use an SSL chain certificate (11.x - 12.x) https://support.f5.com/kb/en-us/solutions/public/13000/300/sol13302.html
以降、チェーン証明書を生成します。
(1) BIG-IPに SSHでログインします。
(2) BIG-IPにインポートした中間証明書/サーバ証明書は、BIG-IPの以下のフォルダに入っています。
/config/filestore/files_d/Common_d/certificate_d/
(3) このフォルダ内の中間証明書 (interCA01.crt_XXXXX_1, interCA02.crt_YYYYY_1) を、bashの cat コマンドを
使って、1つのファイルにします。(注: XXXXX,YYYYYの値はインポートの都度、動的に割り当てられます。)
# cat \
/config/filestore/files_d/Common_d/certificate_d/\:Common\:interCA01.crt_78240_1 <(echo -e \\r) \
/config/filestore/files_d/Common_d/certificate_d/\:Common\:interCA02.crt_78243_1 \
> /var/tmp/mychain.crt
(4) openssl verifyコマンドで、生成したmychain.crt ファイルが正しく動作するかを確認します。
ここではエラーになります。
# openssl verify -purpose sslserver -CAfile /var/tmp/mychain.crt \
/config/filestore/files_d/Common_d/certificate_d/\:Common\:abcCompany.crt_78237_1
/config/filestore/files_d/Common_d/certificate_d/:Common:abcCompany.crt_78237_1: C = JP, ST =
Saitama, O = "InterCA01, Ltd.", OU = ICA01, CN = ica.interca01.local
error 2 at 2 depth lookup:unable to get issuer certificate
これは、opensslの仕様です。
ルート認証局の証明書も 1つのファイルになっていなければ、openssl verify コマンドではエラーとなってしまいます。
(5) ルート認証局の証明書 (cacert.pem) をインポート
ルート認証局の証明書:cacert.pem をコンソール PCにコピーし、BIG-IPにインポートします。
「System」→「File Management」→「SSL Certificate List」で表示された画面の右上の「Import」ボタンを押して現
れた画面で、以下のように設定します。
27
以下の状態になります。
(6) ルート認証局の証明書を、mychain.crtの先頭に追加する
生成済みの mychain.crtの先頭に、ルート証明書を加えます。
# cat \
/config/filestore/files_d/Common_d/certificate_d/\:Common\:F5J-CA.crt_77952_1 <(echo -e \\r) \
/var/tmp/mychain.crt > /var/tmp/mychain_w_root.crt
(7) openssl verify コマンドで、生成したmychain_w_root.crt ファイルが正しく動作するかを確認します。
今度は OKになります。
# openssl verify -purpose sslserver -CAfile /var/tmp/mychain_w_root.crt \
/config/filestore/files_d/Common_d/certificate_d/\:Common\:abcCompany.crt_78237_1
/config/filestore/files_d/Common_d/certificate_d/:Common:abcCompany.crt_78237_1: OK
OpenSSLの仕様で、ルート証明書まで含んだチェーン証明書になっていないと、OKになりません。
5.2.1.4. チェーン証明書をインポートする
中間認証局のチェーン証明書をインポートします。
ルート認証局が含まれたチェーン証明書でも問題ありませんが、不要なものは含まないほうがデータ量の節約にも
なりますので、ルート証明書を含まないほうのチェーン証明書:mychain.crt を使うことにします。
(1) 以下の tmsh コマンドで、中間認証局のチェーン証明書(mychain.crt)をインポートします。
[root@big213:Active:Standalone] tmp # tmsh
root@(big213)(cfg-sync Standalone)(Active)(/Common)(tmos)# install sys crypto cert MyChain from-
local-file /var/tmp/mychain.crt
28
(2) WebUIで見ると、以下の状態になります。
5.2.1.5. Client SSL Profileの設定
インポートした ABC社のサーバ証明書と秘密鍵を Virtual Serverで利用するためには、Client SSL Profileの設定
が必要です。
「Local Traffic」→「Profile」→「SSL」→「Client」で表示された画面の右上の「Create」ボタンを押して現れた画面で、
以下のように設定します。
~略~
任意の名称を入力。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
29
5.2.1.6. Poolの設定
ロードバランシング対象の Poolを設定します。
「Local Traffic」→「Pools」で表示された画面の右上の「Create」ボタンを押して現れた画面で、以下のように設定し
ます。
任意の名称を入力。
ヘルスモニタを選択。
Pool メンバーを追加。
30
5.2.1.7. Virtual Serverの設定
SSL通信を受け付ける Virtual Server を設定します。
「Local Traffic」→「Virtual Servers」で表示された画面の右上の「Create」ボタンを押して現れた画面で以下のように
設定します。
~略~
~略~
任意の名称を入力。
VSのアドレスとポートを設定。
生成した
Client SSL Profile
を指定。
生成した Pool を選択。
必要に応じて設定。
必要に応じて設定。
31
5.2.2. Windows クライアントの設定
5.2.2.1. ルート認証局の証明書のインポート
SSLハンドシェークを成立させるためには、ルート認証局(F5J-CA)の証明書を、クライアント PCのWebブラウザ
へインポートする必要があります。
ここまでのステップで生成済みの、ルート認証局 (F5J-CA) のルート証明書を使います。
Opensslサーバのフォルダ: /etc/pki/CA/
ファイル名:cacert.pem
このファイルを、(WinSCPなどを使って) Windows クライアント PCへコピーしてください。
そして、以下の手順でクライアント PCのWebブラウザ (例:Internet Explorer 11) へインポートします。
(1) Internet Explorer 11の「ツール」 → 「インターネットオプション」 → 「コンテンツ」タブを選び、「証明書」ボタンを
押します。
(2) 「信頼されたルート証明機関」タブを選択し、「インポート」ボタンを押して下ださい。
32
(3) 「次へ」を押して下さい。
(4) インポートするファイルとして、認証局の証明書:cacert.pem を選び、「次へ」を押してください。
(「参照」ボタンを押した後、「***.pem」はデフォルト状態では表示されないかもしれません。その場合は左下の「すべて
のファイル(*.*)」を選択してください。)
33
(5) 証明書ストアが「信頼されたルート証明機関」であることを確認し、「次へ」を押してください。
(6) 「完了」を押してください。
(7) 警告が出ますが、「はい」を押してください。
34
(8) 完了です。「OK」を押してください。
(9) 「信頼されたルート証明機関」に、f5jca.f5jp.localのルート証明書がインポートされました。
これで、「信頼されたルート証明機関」として、本ガイドの認証局(F5J-CA)が登録されました。
基本的にはこれで証明書のセキュリティ警告は表示されなくなります。
しかし、DNSによる名前解決ができない環境においては、次のステップも必要です。
5.2.2.2. [参考]クライアント PCの hosts ファイルの編集
DNSによる名前解決ができない環境の場合、Webブラウザの URLにはサーバの IPアドレスを入力してアクセス
することになります。
その場合クライアント PCへルート認証局の証明書が正しくインポートされていても、まだ、以下の画面をみることに
なります。
これは、Virtual Serverへアクセスして、Webサーバからサーバ証明書を受け取ったものの、サーバ証明書に記載
された Common Name と、Webブラウザが接続を要求した FQDN (≒URL) が一致しないことが原因です。
35
これを簡易的に回避するためには、クライアント PC:Windowsの hosts ファイルを編集することです。
本例では、サーバ証明書の Common Nameは「www.abc-company.lab」です。
(1) メモ帳を、管理者権限で実行します。
(2) C:¥Windows¥System32¥drivers¥etc¥hosts を、以下のように編集します。
36
5.2.2.3. 接続確認
クライアントのWebブラウザへ入力する URLは、IPアドレスではなく FQDN (https://www.abc-company.lab) で
入力します。
これで、SSL証明書のセキュリティ警告を見ることなく、Webサーバ(Virtual Server) へ接続することができるように
なります。
(1) 証明書の連鎖の様子を確認してみます。 (例:Internet Exploer)
(2) 以下のように、証明書の連鎖で信頼されていることがわかります。
①
②
37
5.3. SAN (Subject Alternative Name)の設定
SAN (Subject Alternative Name) を使うことで、1枚のサーバ証明書で複数の FQDN を受け付けることができる
ようになります。
SANに対応するには、サーバ証明書を生成する際に、SAN用の拡張領域に複数の FQDN を指定します。
本ガイドでは、SAN用サーバ証明書の生成に、以下の値を利用することにします。
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Kanagawa
localityName 区市町村 Yokohama
organizationName 会社名 ABC000-Company, Ltd.
organizationalUnitName 組織名 IT
commonName 名称 www.abc000-company.lab
Subject Alternative Name www.abc123-company.lab www.abc456-company.lab www.abc789-company.lab
38
5.3.1. SAN用 openssl.cnfの編集
SAN用の openssl.cnf を別途作っておき、それを編集することにします。
(1) 現在のフォルダの確認
# pwd
/etc/pki/CA/interCA01/interCA02
(2) SAN用に openssl.cnf をコピー
# cp ./openssl-interCA02.cnf openssl-interCA02-san.cnf
(3) openssl-interCA02-san.cnf を編集
以下の赤文字部分を追加します。
# vi openssl-interCA02-san.cnf
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.abc123-company.lab
DNS.2 = www.abc456-company.lab
DNS.3 = www.abc789-company.lab
5.3.2. 秘密鍵とサーバ証明書の署名リクエスト(CSR)の生成
SAN付証明書を要求する側(企業側)が、秘密鍵と署名リクエスト(CSR)を生成します。
以下のコマンドを実行します。
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./SERVER/abc000company-key.pem \
-out ./SERVER/abc000company-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=ABC000-Company, Ltd./OU=IT/CN=www.abc000-company.lab"
5.3.3. 署名時に SANを付与する
上記で生成した署名リクエスト(CSR)へ、ひとつ上の中間認証局 02が署名します。
署名を行うときに、SAN設定した openssl-interCA02-san.cnf を使い、extentionsオプションで、追加設定した
v3_reqを指定します。
# openssl ca -md sha256 -in ./SERVER/abc000company-req.pem -out ./SERVER/abc000company-crt.pem \
-keyfile ./private/interCA02key.pem -batch -policy policy_anything \
-config ./openssl-interCA02-san.cnf -extensions v3_req
Using configuration from ./openssl-interCA02-san.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
39
Validity
Not Before: Mar 16 06:56:31 2016 GMT
Not After : Mar 16 06:56:31 2017 GMT
Subject:
countryName = JP
stateOrProvinceName = Kanagawa
localityName = Yokohama
organizationName = ABC000-Company, Ltd.
organizationalUnitName = IT
commonName = www.abc000-company.lab
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
DNS:www.abc123-company.lab, DNS:www.abc456-company.lab, DNS:www.abc789-company.lab
Certificate is to be certified until Mar 16 06:56:31 2017 GMT (365 days)
Write out database with 1 new entries
Data Base Updated
これで、SAN付のサーバ証明書が生成は完了です。
40
5.3.4. SAN付きサーバ証明書と秘密鍵のインポート
生成した SAN付きサーバ証明書と秘密鍵をコンソール PCにコピーし、BIG-IPにインポートします。
以下の状態になります。
SAN付のサーバ証明書をクリックして内容を確認すると、SANが付与されていることがわかります。
41
5.3.5. Client SSL Profileの設定
インポートした SAN付サーバ証明書と秘密鍵を Virtual Serverで利用するためには、Client SSL Profileの設定が
必要です。
「Local Traffic」→「Profile」→「SSL」→「Client」で表示された画面の右上の「Create」ボタンを押して現れた画面で、
以下のように設定します。
~略~
任意の名称を入力。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
42
5.3.6. Virtual Serverの設定変更
SAN付 Client SSL Profile を Virtual Serverに割り当てます。
「Local Traffic」→「Virtual Servers」で表示された画面で、該当する VSをクリックして、以下のように設定変更しま
す。
~略~
生成した SAN用の
Client SSL Profile
を指定。
43
5.3.7. Windows クライアントの設定
DNSによる名前解決ができない環境の場合、Windowsの Hostsへ、SANに登録した FQDN を追加します。
(1) Hostsへの追加
(2) 接続確認
以下の FQDNに対しては、正しく SSL接続できます。
www.abc123-company.lab www.abc456-company.lab www.abc789-company.lab
しかし、以下の FQDNは SSLのセキュリティ警告が出ます。
www.abc000-company.lab
これは Common Nameに設定されているものの、SANに登録されていないことが原因です。
SANを利用する場合で、Common Name も対象としたい場合には、Common Name と同じ FQDN を SANにも追
加してください。
44
5.4. SNI (Server Name Indication)の設定
SNI (Server Name Indication) を使うことで、一つの Virtual Serverに複数のサーバ証明書を持たせることが出来
るようになります。
SSLハンドシェークを開始する際に、クライアントが Client Hello とともにアクセスしたい FQDN を通知してくれる(図
中の Server Name:の部分)ので、BIG-IP側はその Server Nameを元に、該当するサーバ証明書を使って SSLハン
ドシェークを行うことができます。これが SNIです。
但し、比較的新しい機能なので、やや古いWebブラウザでは SNIに対応していない可能性もある点には注意が必
要です。
本セクションでは、SNI用に以下の値を使って、新しく 3つの証明書を作ります。
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Kanagawa
localityName 区市町村 Yokohama
organizationName 会社名 def123-Company, Ltd.
organizationalUnitName 組織名 IT
commonName 名称 www.def123-company.lab
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Kanagawa
localityName 区市町村 Yokohama
organizationName 会社名 def456-Company, Ltd.
organizationalUnitName 組織名 IT
commonName 名称 www.def456-company.lab
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Kanagawa
localityName 区市町村 Yokohama
organizationName 会社名 def789-Company, Ltd.
organizationalUnitName 組織名 IT
commonName 名称 www.def789-company.lab
45
5.4.1. SNIサーバ証明書の生成
ABC社のサーバ証明書生成したときと同様の方法で、上記の値を使って 3つ作ります。
SAN と違い、SNI を行う場合においてはサーバ証明書に特別な指定は必要ありません。
(1) 現在のフォルダを確認
# pwd
/etc/pki/CA/interCA01/interCA02
(2) def123社用の秘密鍵とサーバ証明書の生成
① 秘密鍵と署名リクエスト(CSR)の生成
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./SERVER/def123Company-key.pem \
-out ./SERVER/def123Company-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=def123-Company, Ltd./OU=IT/CN=www.def123-company.lab"
② CSR へ署名
# openssl ca -md sha256 -in ./SERVER/def123Company-req.pem -out ./SERVER/def123Company-crt.pem \
-keyfile ./private/interCA02key.pem -batch -policy policy_anything \
-config ./openssl-interCA02.cnf -days 3650
(3) def456社用の秘密鍵とサーバ証明書の生成
① 秘密鍵と署名リクエスト(CSR)の生成
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./SERVER/def456Company-key.pem \
-out ./SERVER/def456Company-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=def456-Company, Ltd./OU=IT/CN=www.def456-company.lab"
② CSR へ署名
# openssl ca -md sha256 -in ./SERVER/def456Company-req.pem -out ./SERVER/def456Company-crt.pem \
-keyfile ./private/interCA02key.pem -batch -policy policy_anything \
-config ./openssl-interCA02.cnf -days 3650
(4) def789社用の秘密鍵とサーバ証明書の生成
① 秘密鍵と署名リクエスト(CSR)の生成
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./SERVER/def789Company-key.pem \
-out ./SERVER/def789Company-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=def789-Company, Ltd./OU=IT/CN=www.def789-company.lab"
② CSRへ署名
# openssl ca -md sha256 -in ./SERVER/def789Company-req.pem -out ./SERVER/def789Company-crt.pem \
-keyfile ./private/interCA02key.pem -batch -policy policy_anything \
-config ./openssl-interCA02.cnf -days 3650
46
5.4.2. 秘密鍵とサーバ証明書のインポート
SNI設定を行う 3つのサーバ証明書と秘密鍵を、コンソール PCにコピーし、BIG-IPにインポートします。
以下の状態になります。
47
5.4.3. Client SSL Profileの設定
5.4.3.1. SNIのベースプロファイル
SNIのベースになる Client SSL Profile を作ります。
「Local Traffic」→「Profile」→「SSL」→「Client」で表示された画面の右上の「Create」ボタンを押して現れた画面で、
以下のように設定します。
~略~
[参考] SNIのベースプロファイルはなぜ必要か?
ベースプロファイルを生成しなくても、デフォルトの clientsslプロファイルを利用することで動作はします。
しかし、何らか設定変更を行いたい場合に、この Base を変更して全体に反映する必要があるので、作っておいたほ
うがよいです。
例えば、SNIの状態でクライアント証明書認証を行いたい場合、以降で設定する、一つ一つ個別のプロファイルの設
定変更はできないので、ベースプロファイルの設定を変更して、全プロファイルに反映する必要があります。
名前(任意)を指定。
48
5.4.3.2. SNIの fallback用プロファイル
SNI指定できないブラウザからのアクセスの際に利用されます。
本ガイドでは、ABC社の証明書を利用することにします。
~略~
~略~
名前(任意)を指定。
生成済みのベースプロファイルを選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
Advanced を選択。
←チェックを入れる
49
5.4.3.3. def123社/def456社/def789社用プロファイル
SNI用の Client SSL profileには、以下のように Server Nameに FQDN を入力します。
(1) def123社用
~略~
~略~
(2) def456社用
~略~
~略~
名前(任意)を指定。
生成済みのベースプロファイルを選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
Advanced を選択。
FQDNを入力。
名前(任意)を指定。
生成済みのベースプロファイルを選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
Advanced を選択。
FQDNを入力。
50
(3) def789社用
~略~
~略~
名前(任意)を指定。
生成済みのベースプロファイルを選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
Advanced を選択。
FQDNを入力。
51
5.4.4. Virtual Serverの設定変更
SNI用に作成したプロファイル 3つと、Fallback用プロファイルの合計 4つを、Virtual Serverの SSL Profile
(Client)に設定します。
~略~
生成した SNI用の
Client SSL Profile
を指定。
52
5.4.5. Windows クライアントの設定
DNSによる名前解決ができない環境の場合、Windowsの Hostsへ、SNI として設定した FQDN を追加します。
(1) Hostsへの追加
(2) 接続確認
def123 / def1456 / def789のどの FQDNに対しても、SSLのセキュリティ警告なしでアクセスできることを確認して
ください。
53
6. クライアント証明書の生成
クライアント証明書認証用の秘密鍵と証明書を生成します。
以下はその生成フローのイメージです。
① ABC社は、abc-client001の秘密鍵を生成します。(abcClient001-key.pem)
② ABC社は、abc-client001の署名リクエスト(CSR)を生成します。(abcClient001-req.pem)
③ ABC社は、その署名リクエスト(CSR)を中間認証局 02に送ります。
④ 中間認証局 02は、署名リクエスト(CSR)に対して、署名を行う認証局の情報(中間認証局 02自身の情報)や有効
期間などを追加して、それを「tbsCertificate」とします。
⑤ この「tbsCertificate」を、SHA-2を使ってハッシュ値を計算します。
⑥ そのハッシュ値を、中間認証局 02の秘密鍵を使って、RSAで暗号化します。これが署名です。
⑦ 「tbsCertificate」と署名を一まとまりにしたものが、abc-client001のクライアント証明書です。
⑧ 中間認証局 02は、そのクライアント証明書を ABC社へ送ります。
⑨ ABC社は、abc-client001用の証明書と秘密鍵を、Windowsへインポートしやすいように、PKCS#12形式に変
換し、Windows PCへインポートします。
54
本ガイドでは、クライアント証明書の生成に、以下の値を利用することにします。
OpenSSL 項目 意味 値
countryName 国 JP
stateOrProvinceName 都道府県 Kanagawa
localityName 区市町村 Yokohama
organizationName 会社名 ABC-Company, Ltd.
organizationalUnitName 組織名 Systems Engineer
commonName 名称 abc-client001.abc-company.lab
6.1. クライアント証明書向けフォルダの生成
クライアント PCの秘密鍵や証明書を生成するためのフォルダおよびファイルを生成します。
(1) 現在のフォルダの確認
# pwd
/etc/pki/CA/interCA01/interCA02
(2) フォルダの作成
# mkdir ./CLIENT
6.2. クライアント証明書の署名リクエスト(CSR)の生成
「abc-client001」という名称のクライアント証明書の秘密鍵と署名リクエスト(CSR)を生成します。
以下のコマンドを実行します。
(以降、いくつか同様のものを生成するので、環境変数を利用して簡単に生成できるようにしています。)
# export user=abc-client001
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./CLIENT/${user}-key.pem \
-out ./CLIENT/${user}-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=ABC-Company, Ltd./OU=SE/CN=${user}.abc-company.lab"
6.3. 中間認証局 02によるクライアント署名リクエスト(CSR)への署名
クライアント署名リクエスト(CSR)へ、中間認証局 02が署名を行います。
以下のコマンドを実行します。
# openssl ca -md sha256 -in ./CLIENT/${user}-req.pem -keyfile ./private/interCA02key.pem \
-out ./CLIENT/${user}-crt.pem -batch -policy policy_anything \
-config ./openssl-interCA02.cnf -days 730
Using configuration from ./openssl-interCA02.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 6 (0x6)
Validity
Not Before: Mar 16 07:19:30 2016 GMT
Not After : Mar 16 07:19:30 2018 GMT
Subject:
countryName = JP
stateOrProvinceName = Kanagawa
localityName = Yokohama
organizationName = ABC-Company, Ltd.
55
organizationalUnitName = SE
commonName = abc-client001.abc-company.lab
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
77:88:B1:3F:2B:15:86:8B:E2:98:2B:75:8A:67:87:0A:1E:21:58:80
X509v3 Authority Key Identifier:
keyid:27:D4:C0:71:A5:7E:7F:41:9D:BE:9E:AB:60:07:70:69:0D:BD:8B:8D
Certificate is to be certified until Mar 16 07:19:30 2018 GMT (730 days)
Write out database with 1 new entries
Data Base Updated
これでクライアント証明書の生成は完了です。
6.4. クライアント証明書のフォーマット変換
ここでは、Internet Explorer等のブラウザに簡単に読み込み可能なフォーマットである PKCS#12 に変換します。
PKCS#12は証明書と秘密鍵の両方を保持することができるフォーマットです。
こうすることで、この PKCS#12 ファイルのみで秘密鍵とクライアント証明書の両方を一度にインポートすることが可
能となります。
# openssl pkcs12 -export -in ./CLIENT/${user}-crt.pem -inkey ./CLIENT/${user}-key.pem \
-out ./CLIENT/${user}.p12
(Internet Explorer等でインポートする際に必要となるパスワードの入力を求められます。"f5demo"としました。)
Enter Export Password:f5demo
Verifying - Enter Export Password:f5demo
これで、abc-client001.p12 というファイル(クライアント証明書&秘密鍵)が生成されました。
56
7. クライアント証明書認証の設定
クライアント証明書を使った認証設定を行います。
7.1. クライアント証明書認証のフロー
以降の BIG-IP設定で、今どの設定を行っているのかを理解するために、クライアント証明書のフローイメージを示し
ます。
クライアント証明書認証は SSLハンドシェーク内で行われますが、ここではクライアント証明書認証に関連する部分
のみ抜き出しています。
57
7.1.1. クライアント証明書認証の事前準備
クライアント証明書認証が行えるようにするためには、大きくは以下の 2つの設定が必要です。
① クライアント PC上に、PKCS#12形式ファイルを使って、クライアント証明書と秘密鍵をインポートします。
② 中間認証局 02,中間認証局 01,ルート認証局の証明書にて、そのクライアント証明書の検証を行えるように、
BIG-IPを設定します。
7.1.2. クライアント証明書認証
事前準備が完了していれば、以降は自動的に行われるフローですが、この事前準備が何のために必要なのかを理
解するために、クライアント証明書認証のフローの概要を記載しておきます。
① BIG-IPからクライアントに対して、クライアント証明書の送信要求が送られます(Certificate Request)。
② クライアント(abc-client001)は、クライアント証明書を BIG-IPに送ります(Certificate)。
③ BIG-IPは tbsCertificate と署名を分離します。
④ tbsCertificateのハッシュを計算します。
⑤ RSAで署名されている署名値を、中間認証局 02の公開鍵で復号化し、ハッシュ値を取り出します。
⑥ ④と⑤で得られたハッシュ値を比較。一致すれば、この証明書は改ざんされていないものとして、中間認証局 02
によって証明されます。
⑦ また⑦の結果、abc-client001のクライアント証明書内の公開鍵も中間認証局 02によって、信頼できると判断さ
れます。
⑧ 今度は下図のように、中間証明書 02、中間証明書 01が信頼できるか、の検証が行われます。
a) 中間認証局 02の中間証明書の署名と tbsCertificateを分離します。
58
b) 中間認証局 02の tbsCertificateのハッシュを計算します。
c) RSAで署名されている署名値を、中間認証局 01の公開鍵で復号化し、ハッシュ値を取り出します。
d) b)と c)で得られたハッシュ値を比較。一致すれば、中間証明書 01によって、この証明書は改ざんされて
いない=信頼できるものとして扱われます。
e) また d)の結果、ABC社の中間認証局 02の証明書内の公開鍵も、中間証明書 01によって、信頼できる
と判断されます。
f) ~ j) は、中間証明書 02 と同様の処理によって、今度は中間証明書 01がルート証明書によって信頼さ
れます。
この⑧の処理が完了して初めて、abc-client001のクライアント証明書が信頼されます。
⑨ クライアントは、ここまでの SSLハンドシェークでやり取りした情報から Certificate Verify値を生成します。
(SSLハンドシェークのフローで記載したやり取り部分は、本セクションでは省略していますが、実際のクライアント
証明書認証は一連の SSLハンドシェークフローの中で行われます。)
⑩ この Certificate Verify値を、abc-client001の秘密鍵で暗号化します。
⑪ 暗号化された⑨の値を、サーバへ送ります。
⑫ BIG-IPは、その暗号化された「Certificate Verify」を abc-client001の公開鍵で復号化します。
⑬ BIG-IP自身で算出した Certificate Verify と⑫の値を比較して、一致すればクライアント証明書は信頼できる、と
判断されます。
59
7.2. 「クライアント証明書認証の事前準備」を行う
クライアント証明書認証に必要な設定を行っていきます。
7.2.1. BIG-IPの設定
本ガイドでは、まずクライアント PCよりも先に BIG-IPの設定を行うことにします。
7.2.1.1. ルートを含むチェーン証明書のインポート
クライアント証明書が中間認証局から発行されたものである場合、クライアント証明書認証には、ルート認証局の証
明書を含んだチェーン証明書が必要になります。
本ガイドでは、中間証明書を取り込む際に、すでにルート証明書を含んだチェーン証明書を作成しているので、それ
を利用することにします。
(1) 以下のコマンドを実行し、チェーン証明書をインポートします。
root@(big213)(cfg-sync Standalone)(Active)(/Common)(tmos)# install sys crypto cert MyChain_w_root
from-local-file /var/tmp/mychain_w_root.crt
(2) 以下の状態になります。
60
7.2.1.2. Client SSL Profileの設定変更
クライアント証明書認証を行うためには、Client SSL Profileの設定変更が必要です。
本ガイドでは、ABC社のクライアントに対してのクライアント証明書認証を行う、というシナリオを想定し、設定済み
の abcCompany-clientssl-profileを利用することにします。
「Local Traffic」→「Profile」→「SSL」タブ→「Client」で表示された画面上の「abcCompany-clientssl-profile」をクリッ
クして現れた画面で、以下のように設定を変更します。
~略~
~略~
Require を選択。
ルートを含むチェーン証明書を選択。
中間認証局 02の証明書を選択。
61
7.2.1.3. Virtual Serverの設定変更
Virtual Serverに、ABC社の Client SSL Profile:abcCompany-clientssl-profile を割り当てます。
~略~
~略~
クライアント証明書認証の
設定を行った
Profile を割り当てる。
62
7.2.2. クライアント証明書をクライアント PCへインポート
生成した abc-client001.p12 を (既述のWinSCPなどを利用して)クライアント PCへコピーしてください。
Windows上のこのファイルをダブルクリックすると、インポートが始まります。
(1) 「次へ」を押してください。
(2) 「次へ」を押してください。
63
(3) パスワードは「f5demo」を入力し、「次へ」を押してください。
(4) 「証明書の種類に基づいて~」が選択されていることを確認し、「次へ」を押してください。
(5) 「完了」を押して下さい。
設定したパスフレーズ:f5demoを入力。
64
(6) 「OK」を押してください。
(7) 以下のように、クライアント証明書がインポートされます。
クライアント証明書認証設定は以上です。
7.2.3. Windows クライアントからのアクセス
WindowsのWebブラウザ(IE)で「https://www.abc-company.lab」へアクセスすると、以下の画面が出ます。
「OK」を押した後、Web画面が表示されれば、クライアント証明書認証は成功です。
クライアント証明書がインポートされた状態
65
8. クライアント証明書の失効管理
クライアント証明書の失効管理には大きく 3つの方法があります。
① CRL (Certificate Revocation List)
② OCSP (Online Certificate Status Protocol)
③ CRLDP (Certificate Revocation List Distribution Point)
それぞれの方式について解説し、設定してみます。
8.1. CRL (Certificate Revocation List)
CRLは、効力を失った証明書を管理するリストです。
まず、OpenSSLでクライアント証明書を失効させてから、失効リスト(CRL)を生成します。
その失効リスト(CRL)ファイルを BIG-IPに取り込みます。
BIG-IPは、SSLハンドシェークの都度、その CRL ファイルを参照し、失効しているクライアント証明書とは SSLハ
ンドシェークを完了させないので、結果、通信させないように制御できます。
8.1.1. 複数のクライアント証明書の生成
失効されたものが接続できず、失効されていないものは接続できる状態にあることを確認するために、クライアント
証明書を複数生成しておきます。
既述のクライアント証明書の生成ステップの、「export user=abc-client001」を、
「export user=abc-client002」、
「export user=abc-client003」
に変更して、同様のステップを繰り返してください。
66
8.1.2. クライアント証明書のインポートと通信確認
(1) 以下のように 3つのクライアント証明書を一つのクライアント PCにインポートします。
(一つの PCに複数のクライアント証明書をインポートする、ということは一般的にあまり行われないと思いますが、失
効したクライアント証明書でアクセスできず、失効していないクライアント証明書ではアクセスできる、という差を見るこ
とを目的としていますので、このようにしました。)
(2) Webブラウザで https://www.abc-company.lab へアクセスすると、以下のように証明書の選択を促す画面が出
ます。
それぞれ 3つのクライアント証明書で通信が成立することを確認してください。
67
8.1.3. クライアント証明書の失効
OpenSSLで、クライアント証明書を失効させます。
8.1.3.1. フォルダとファイルの生成
(1) 現在のフォルダの確認
# pwd
/etc/pki/CA/interCA01/interCA02
(2) フォルダおよびファイルの生成
CRLの生成に必要なフォルダとファイルを生成します。
# mkdir ./crl
# echo "01" > ./crlnumber
8.1.3.2. CRLの生成
(1) 失効処理前の index.txt ファイル内容の確認
失効処理が行われる前の index.txtは、以下のように、先頭がすべて Vの状態になっています。
# cat index.txt ~略~
V 180316071930Z 06 unknown ~略~/OU=SE/CN=abc-client001.abc-company.lab
V 180316073032Z 07 unknown ~略~/OU=SE/CN=abc-client002.abc-company.lab
V 180316073107Z 08 unknown ~略~/OU=SE/CN=abc-client003.abc-company.lab
(2) 失効処理(abc-client001)
例えば、abc-client001を失効してみます。
# openssl ca -revoke ./CLIENT/abc-client001-crt.pem -config ./openssl-interCA02.cnf
Using configuration from ./openssl-interCA02.cnf
Revoking Certificate 06.
Data Base Updated
(3) 失効処理後の index.txtの確認
失効処理がなされると、index.txtでは、以下のように先頭に Rが付きます。
# cat index.txt
~略~
R 180316071930Z 160316073758Z 06 unknown ~略~/OU=SE/CN=abc-client001.abc-company.lab
V 180316073032Z 07 unknown ~略~/OU=SE/CN=abc-client002.abc-company.lab
V 180316073107Z 08 unknown ~略~/OU=SE/CN=abc-client003.abc-company.lab
(4) CRLの生成
以下のコマンドで CRLを生成します。
# openssl ca -gencrl -out ./crl/list.crl -config ./openssl-interCA02.cnf
Using configuration from ./openssl-interCA02.cnf
68
(5) CRLの内容確認
CRLの中身は以下のコマンドで確認できます。
シリアル番号が 06のユーザ(=abc-client001)が失効している状態を表しています。
# openssl crl -in ./crl/list.crl -text
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=JP/ST=Chiba/L=Funabashi/O=InterCA02, Ltd./OU=ICA02/CN=ica.interca02.local
Last Update: Mar 15 07:25:13 2016 GMT
Next Update: Apr 14 07:25:13 2016 GMT
CRL extensions:
X509v3 CRL Number:
1
Revoked Certificates:
Serial Number: 06
Revocation Date: Mar 15 07:20:52 2016 GMT
Signature Algorithm: sha1WithRSAEncryption
a9:9b:12:66:20:58:b2:c4:54:c2:3c:fd:92:56:09:36:7f:c0:
~略~
(6) CRL ファイルのコピー
BIG-IPが CRL ファイルを取得する際には、HTTPが利用できます。
Webサーバのコンテンツを置く場所に、生成した CRL ファイルをコピーします。
# cp ./crl/list.crl /var/www/html/
(/var/www/html は Apacheのコンテンツ用のデフォルトフォルダです。)
69
8.1.4. BIG-IPの設定
CRLのための BIG-IP設定を行います。
8.1.4.1. BIG-IPで CRLを取り込む
BIG-IP tmshで、以下のコマンドを実行し、サーバから CRL ファイルを取り込みます。
root@(big213)(cfg-sync Standalone)(Active)(/Common)(tmos)# create sys file ssl-crl abc-company-
crl source-path http://10.99.100.210/list.crl
Copying file "http://10.99.100.210/list.crl" ...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
102 715 102 715 0 0 64385 0 --:--:-- --:--:-- --:--:-- 698k
8.1.4.2. Client SSL Profileの設定変更
ABC社の Client SSL Profile(abcCompany-clientssl-profile)で、以下のように設定変更します。
~略~
~略~
8.1.5. Windows クライアントからのアクセス
クライアント PCからアクセスすると、以下の状態になることを確認してください。
① abc-client001 NG
② abc-client002 OK
③ abc-client003 OK
取り込んだ CRL を選択。
70
8.2. OCSP (Online Certificate Status Protocol)
クライアント証明書が失効されていないかどうかを、OCSP Responderへ問合せる方式です。
BIG-IPは、SSLハンドシェークの都度、その OCSP Reponderへの問合せを実施し、失効しているクライアント証
明書であることが通知されると SSLハンドシェークを完了させないので、結果、通信できないように制御できます。
OpenSSLは、OCSP Responder としても機能しますので、本ガイドではそれを使います。
71
8.2.1. クライアント証明書の失効
前セクションの CRL と同じ結果だと、OCSPによる効果が分かり難いので、OpenSSLでもう一つクライアント証明書
を失効させます。
(1) 現在のフォルダの確認
# pwd
/etc/pki/CA/interCA01/interCA02
(2) 失効処理(abc-client002)
例えば、abc-client002 も失効させます。
# openssl ca -revoke ./CLIENT/abc-client002-crt.pem -config ./openssl-interCA02.cnf
(3) 失効処理後の index.textの確認
# cat index.txt
~略~
R 180316071930Z 160316073758Z 06 unknown ~略~/OU=SE/CN=abc-client001.abc-company.lab
R 180316073032Z 160316075141Z 07 unknown ~略~/OU=SE/CN=abc-client002.abc-company.lab
V 180316073107Z 08 unknown ~略~/OU=SE/CN=abc-client003.abc-company.lab
8.2.2. OCSP Responderの起動
OpenSSLの以下のコマンドで、OCSP Responder を起動します。
OCSPの受信 TCPポート番号は「8181」としています。
# openssl ocsp -index ./index.txt -port 8181 -rsigner ./interCA02crt.pem -CA ./interCA02crt.pem \
-text -out test.log -rkey ./private/interCA02key.pem
Waiting for OCSP client connections...
72
8.2.3. BIG-IPの設定
BIG-IPに、OCSP用の設定を行います。
8.2.3.1. NTPによる時刻設定の確認
OCSPの場合、BIG-IP と OSCP Responder との時刻差の許容範囲はデフォルトで 300秒となっています。
NTPで時刻同期を行っておけば確実にこの範囲に収まるので、以下のコマンドで同期できていることを確認します。
[root@big213:Active:Standalone] config # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.99.100.210 60.56.214.78 2 u 55 64 377 3.177 -6.538 3.087
8.2.3.2. OCSPの設定
BIG-IPの Virtual Serverに割り当てる、OCSPの Authentication Profile を生成するまでの手順を示します。
(1) OCSP Responderの設定
「Local Traffic」→「Profiles」→「Authentication」→「OCSP Responders」で表示された画面の右上の「Create」ボタ
ンを押して現れた画面で、以下のように設定します。
(2) OCSP Configurationの設定
「Local Traffic」→「Profiles」→「Authentication」→「Configurations」で表示された画面の右上の「Create」ボタンを
押して現れた画面で、以下のように設定します。
名前(任意)を指定。
OCSP Responder を指定。
ルートを含んだチェーン証明書を指定。
名前(任意)を指定。
SSL OCSPを選択。
生成済みの
OCSP Responder を
「<<」で選択。
73
(3) OCSP Profileの設定
「Local Traffic」→「Profiles」→「Authentication」→「Profiles」で表示された画面の右上の「Create」ボタンを押して
現れた画面で、以下のように設定します。
8.2.3.3. Client SSL Profileの設定変更
先のセクションで CRL設定を行っていますが、OCSP時には不要です。
よって、利用する Client SSL profile(abcCompany-Clientssl-profile)の CRL設定を「None」に変更します。
~略~
~略~
名前(任意)を指定。
SSL OCSPを選択。
生成済みの OCSP Configuration を選択。
None を選択。
74
8.2.3.4. Virtual Serverの設定変更
利用する Virtual Serverに、生成した OCSPの Authentication Profileを割り当てます。
~略~
~略~
設定は以上です。
8.2.4. Windows クライアントからのアクセス
クライアント PCからアクセスすると、以下の状態になることを確認してください。
① abc-client001 NG
② abc-client002 NG
③ abc-client003 OK
「Advanced」を選択。
生成した
OCSP Profile を
選択。
75
8.3. CRLDP (Certificate Revocation List Distribution Point)
クライアント証明書が失効されていないかどうかを確認するために、CRLDPへ問合せて CRL ファイルを取得する
方式です。
BIG-IPは、SSLハンドシェークが発生すると、クライアント証明書に記載された CRLDP情報を確認します。
BIG-IPは、その CRLDPへの問合せを実施し、CRLを取得します。
BIG-IPは、取得した CRLから、そのクライアント証明書が失効しているかを確認し、失効していれば SSLハンドシ
ェークを完了させないので、結果、通信させないように制御できます。
尚、一旦取得した CRLをキャッシュすることができますので、SSLハンドシェークの都度 CRLDPへアクセスしない
ように制御することが可能です。 (デフォルトのキャッシュは 24時間です。)
※ LTMだけで CRLDP を行う場合には、LDAPアクセスのみのサポートとなっています。(~v12.0.0)
※ APM を利用すれば、HTTPアクセスも利用可能です。
76
8.3.1. CRLDPを持つクライアント証明書の生成
CRLDP を利用するためには、クライアント証明書に CRLDP情報を付与する必要があります。
CRLDP情報を持つクライアント証明書として、2つ追加することにします。
以下にその生成方法を示します。
8.3.1.1. openssl.cnfの編集 (CRLDP用)
署名を行う際に CRDLP情報を付与できるよう、中間認証局 02の openssl.cnf を編集します。
(1) 現在のフォルダの確認
# pwd
/etc/pki/CA/interCA01/interCA02
(2) openssl-interCA02.cnfの編集
openssl-interCA02.cnfに、以下の赤文字部分を追加します。
# vi openssl-interCA02.cnf
[my-crldp]
crlDistributionPoints=@crldp1_section
[crldp1_section]
URI=ldap://crldp.f5jp.local/CN=crldp,DC=f5jp,DC=local?certificateRevocationList?base?objectClass=
cRLDistributionPoint
8.3.1.2. CRLDP情報付きクライアント証明書の生成
署名の際に、証明書の拡張領域(extensions)に、CRLDP情報を追加するための指定を行って、クライアント証明書
を生成します。
(1) abc-client004の生成
① 環境変数
# export user=abc-client004
② 秘密鍵を署名リクエスト(CSR)
# openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./CLIENT/${user}-key.pem \
-out ./CLIENT/${user}-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=ABC-Company, Ltd./OU=SE/CN=${user}.abc-company.lab"
③ 署名 (拡張領域に、CRLDP情報を追加する指定)
# openssl ca -md sha256 -in ./CLIENT/${user}-req.pem -keyfile ./private/interCA02key.pem \
-out ./CLIENT/${user}-crt.pem -batch -policy policy_anything \
-config ./openssl-interCA02.cnf -days 730 -extensions my-crldp
Using configuration from ./openssl-interCA02.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 9 (0x9)
77
Validity
Not Before: Mar 16 07:57:30 2016 GMT
Not After : Mar 16 07:57:30 2018 GMT
Subject:
countryName = JP
stateOrProvinceName = Kanagawa
localityName = Yokohama
organizationName = ABC-Company, Ltd.
organizationalUnitName = SE
commonName = abc-client004.abc-company.lab
X509v3 extensions:
X509v3 CRL Distribution Points:
Full Name:
URI:ldap://crldp.f5jp.local/CN=crldp,DC=f5jp,DC=local?certificateRevocationList?base?objectClass=cRLDistribu
tionPoint
Certificate is to be certified until Mar 16 07:57:30 2018 GMT (730 days)
Write out database with 1 new entries
Data Base Updated
④ PKCS#12へ変換
# openssl pkcs12 -export -in ./CLIENT/${user}-crt.pem -inkey ./CLIENT/${user}-key.pem \
-out ./CLIENT/${user}.p12
(2) abc-client005の生成
環境変数を abc-client005に変更して、もう一つ同様のクライアント証明書を作ります。
# export user=abc-client005
8.3.1.3. クライアント証明書認証の動作確認 (CRLDPなしの状態)
新しく生成した 2つのクライアント証明書が正しく生成できているかの確認のため、接続確認を行います。
(1) 前のセクションで OCSP設定を行っているので、Virtual Serverの Authentication Profileからその設定を外して
ください。
(2) abc-client004 と abc-client005で接続できることを確認してください。
78
8.3.2. CRLの生成
abc-client004および abc-client005のどちらかを失効させ、CRLDPによる失効管理ができることを確認します。
ここでは、abc-client004 を失効させることにします。
(1) 失効処理(abc-client004)
abc-client004を失効させます。
# openssl ca -revoke ./CLIENT/abc-client004-crt.pem -config ./openssl-interCA02.cnf
Using configuration from ./openssl.cnf
Enter pass phrase for /etc/pki/CA/interCA01/interCA02/private/interCA02key.pem:
Revoking Certificate 0E.
Data Base Updated
(2) 失効処理後の index.txtの確認
前のセクションまでで失効処理した abc-client001,abc-client002に加え、abc-client004が失効されていることを確
認します。
# cat index.txt
~略~
R 180316071930Z 160316073758Z 06 unknown ~略~/OU=SE/CN=abc-client001.abc-company.lab
R 180316073032Z 160316075141Z 07 unknown ~略~/OU=SE/CN=abc-client002.abc-company.lab
V 180316073107Z 08 unknown ~略~/OU=SE/CN=abc-client003.abc-company.lab
R 180316075730Z 160316090806Z 09 unknown ~略~/OU=SE/CN=abc-client004.abc-company.lab
V 180316075856Z 0A unknown ~略~/OU=SE/CN=abc-client005.abc-company.lab
(3) CRLの生成
以下のコマンドで CRLを生成します。
# openssl ca -gencrl -out ./crl/list.crl -config ./openssl-interCA02.cnf
Using configuration from ./openssl-interCA02.cnf
(4) CRLの内容確認
CRLの中身は以下のコマンドで確認できます。
以下はシリアル番号が 06,07,09のユーザが失効している状態を表しています。
# openssl crl -in ./crl/list.crl -text
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=JP/ST=Chiba/L=Funabashi/O=InterCA02, Ltd./OU=ICA02/CN=ica.interca02.local
Last Update: Mar 16 09:10:27 2016 GMT
Next Update: Apr 15 09:10:27 2016 GMT
CRL extensions:
X509v3 CRL Number:
2
Revoked Certificates:
Serial Number: 06
Revocation Date: Mar 16 07:37:58 2016 GMT
Serial Number: 07
79
Revocation Date: Mar 16 07:51:41 2016 GMT
Serial Number: 09
Revocation Date: Mar 16 09:08:06 2016 GMT
~略~
(5) CRLをバイナリ形式(DER形式)に変換
CRLを LDAPで扱えるように、以下のコマンドでバイナリ形式(DER形式)に変換します。
# openssl crl -inform PEM -outform DER -in ./crl/list.crl -out ./crl/list.der
8.3.3. LDAPへの登録
LDAPに CRLDP となるユーザを登録します。
(1) LDAPのインストール
本ガイド環境用の LDAP インストール・設定方法については、「[Appendix.2] OpenLDAPの設定」を参照してく
ださい。
(2) フォルダの移動
openldap フォルダに移動します(必須ではありません)。
# cd /etc/openldap
(3) CRLDP用の ldifの作成
CRLDP となるユーザを LDAP上に作るため、viエディタなどを使って、以下の赤文字部分の内容を持つファイルを
生成します。
# vi crl.ldif
dn: cn=crldp,dc=f5jp,dc=local
objectclass: cRLDistributionPoint
certificateRevocationList;binary:< file:///etc/pki/CA/interCA01/interCA02/crl/list.der
(4) CRLDPを LDAPへ登録
以下のコマンドで、上記で生成した ldif を LDAPへ登録します。
# ldapadd -x -D cn=Manager,dc=f5jp,dc=local -W -f crl.ldif
Enter LDAP Password:(LDAP パスワード)
adding new entry "cn=crldp,dc=f5jp,dc=local"
(5) [参考]LDAPに登録されたユーザの確認
以下のコマンドで、LDAPに登録されたユーザの状態を確認できます。
# ldapsearch -x -h localhost -b cn=crldp,dc=f5jp,dc=local
80
8.3.4. BIG-IPの設定
Virutal Serverに割り当てる、CRLDPの Authentication Profile を設定するまでの手順を示します。
8.3.4.1. CRLDPの設定
BIG-IPに CRLDP用の設定を行います。
(1) CRLDP Serverの設定
「Local Traffic」→「Profiles」→「Authentication」→「CRLDP Servers」で表示された画面の右上の「Create」ボタン
を押して現れた画面で、以下のように設定します。
(2) CRLDP Configurationの設定
「Local Traffic」→「Profiles」→「Authentication」→「Configurations」で表示された画面の右上の「Create」ボタンを
押して現れた画面で、以下のように設定します。
※デフォルトでは、取り込んだ CRLを 24時間キャッシュする設定になっていますが、そのままだと検証環境では
CRLDPの設定変更後の挙動を即座に確認しにくいので、小さめの値にしています。
名前(任意)を指定。
LDAPのアドレスを指定。
LDAPを選択(デフォルト)。
LDAPのベースドメイン名を指定。
名前(任意)を指定。
CRLDPを選択。
※検証環境用に小さい値を設定。
設定済みの
CRLDP Serverを
<<で選択。
81
(3) CRLDP Profileの設定
「Local Traffic」→「Profiles」→「Authentication」→「Profiles」で表示された画面の右上の「Create」ボタンを押して
現れた画面で、以下のように設定します。
名前(任意)を指定。
CRLDPを選択。
設定済みの CRLDP Configuration を選択。
82
8.3.4.2. Virtual Serverの設定変更
Virtual Serverに、生成した CRLDPの Authentication Profile を割り当てます。
~略~
~略~
「Advanced」を選択。
生成した
CRLDP Profile を
選択。
83
8.3.4.3. Hostsの登録
CRLDPに指定した FQDN を Hostsに登録します。
(DNS解決ができる環境においては、この設定は不要です。)
「System」→「Configuration」→「Device」→「Hosts」で現れた画面で、以下のように設定します。
8.3.5. Windows クライアントからのアクセス
クライアント PCからアクセスすると、以下の状態になることを確認してください。
① abc-client001 NG クライアント証明書が CRLDP情報を持っていないため
② abc-client002 NG 〃
③ abc-client003 NG 〃
④ abc-client004 NG CRLDPから失効が通知されたため
⑤ abc-client005 OK
8.3.6. [参考] LDAP上での CRLDPの更新
新しくクライアント証明書の失効処理を行った場合に CRLDPに反映するためには、LDAPの CRLDPユーザの削
除&追加がスムーズです。
(1) CRLDPユーザの削除
# ldapdelete -x -D cn=Manager,dc=f5jp,dc=local -W "cn=crldp,dc=f5jp,dc=local"
Enter LDAP Password: (LDAP のパスワード)
(2) 再追加
# ldapadd -x -D cn=Manager,dc=f5jp,dc=local -W -f crl.ldif
Enter LDAP Password: (LDAP のパスワード)
adding new entry "cn=crldp,dc=f5jp,dc=local"
IP Address と
Hostname を指定して
「Add」ボタンを押して登録。
84
9. おわりに
基本的な SSL/TLS設定に関しては以上で終了となります。
BIG-IPシリーズ製品ラインナップにおいては、ソフトウェアモジュールライセンスを追加することで、サーバ負荷分散
はもちろんのこと、ネットワークファイアウォール機能、ウェブアプリケーションファイアウォール機能、リモートアクセス
機能など、アプリケーションアクセスを最適化する為の多彩な機能が使用できるモジュールがあり、それぞれにおい
て、SSL/TLSによる暗号化が可能となっています。
詳細は各種WEBサイトにてご確認いただくか、購入元にお問い合わせください。
<F5ネットワークスWEBサイトの紹介>
F5ネットワークスジャパン総合サイト
https://f5.com/jp/
AskF5:ナレッジベース総合サイト(英語) http://support.f5.com/kb/en-us.html
DevCentral:F5ユーザコミュニティサイト(英語:アカウント登録が必要です) https://devcentral.f5.com/
以上
F5ネットワークスジャパン合同会社
〒107-0052東京都港区赤坂 4-15-1 赤坂ガーデンシティ 19階
本資料は F5ネットワークスジャパンのエンジニアが特定のソフトウェアバージョンの動作仕様に基づいて作成した構築・設計を補助するための資
料であり、メーカー公式資料とは異なります。資料の記載内容に誤りがあった際には指摘に基づいて修正を行いますが、内容についての責任は一
切負いません。また、修正、変更、改訂は予告無く行われます。
85
10. [Appendix.1] SSL暗号を「できるかぎり」ひも解く
SSL暗号の仕組みはインターネット検索でたくさんヒットしますが、一連の流れとしてまとまったものがなかなか見つ
けられないので、情報はたくさんあれど、理解しにくいと感じています。
SSLは正しく設定できていれば、あとは自動的に動いてくれるので、フローの詳細はまぁ理解しなくても大丈夫か
な、と思えてしまいますが、SSLの脆弱性が発覚したときや、どの処理が BIG-IPのパフォーマンスに影響するのか
等、どこでどのような処理が行われているのかを、ある程度把握したいときがあります。
ということで、暗号スイートを一つピックアップし、RFCやインターネット検索で得た情報から、SSL暗号をできるだけ
ひも解いていくことにします。
内部処理に踏み込んで実際の動きを確認するのは難しいので、多少の推測も含まれていることをご了承ください。
10.1. 暗号スイート (Cipher Suite)
以下の暗号スイートを例にとります。
[OpenSSL表記] DHE-RSA-AES128-SHA256
[IANA表記] TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
(1) DHE
プリマスターシークレットを交換する方式を表しています。
Diffie-Hellman Ephemeral の略です。
PFS(Perfect Forward Secrecy)の観点から、RSAよりも安全と考えられており、DHEの方が主流になってきて
いる印象を受けます。
(2) RSA
サーバ証明書の署名方式を表しています。
その他にも ECDSAなどの署名方式も存在しますが、今も尚、署名には RSAが一般的だと思われます。
(3) AES128 / AES_128_CBC
共有鍵による暗号通信を行う際の暗号方式を表しています。
DESの脆弱性が報告されて以降、AESが主流となっている感じです。
AES暗号とともに使われる CBCモードも今だ多く使われている方式です。
(4) SHA256
共有鍵による暗号化が行われる前に、改ざん検知を目的として、ある一定のデータブロック単位にハッシュを取り
ます。それを「MACダイジェスト」といいます。その方式を表しています。
そのほかにも、後ほど登場する HMAC関数で使うハッシュ方式の意味も持っています。
86
10.2. RSA とは
まず先に RSAについて解説します。
鍵交換にも署名にも使われる RSAですが、ここでは主に署名として使う場合の解説を行います。
RSAは、以下の 2つがポイントです。
ある数を法 (Modulo) とする世界では、ある「べき乗」を行うと元の数に戻る、というべき乗数が必ず存在する。
大きな素数の掛け算は、どんな数を掛け合わせているのかの解読が難しい。
具体的な例を用いて説明します。
10.2.1. 法 (Modulo) とは
法 (Modulo) を簡単に説明すると、「ある数を、法で割り算した余り」です。
例えば、「33」を法とした世界で、100はどうなるか、というと、
100 mod 33 = 1
となります。100を 33で割ると、余りは 1、という意味です。
10.2.2. Moduloの世界では元の数字に戻る「べき乗」が必ず存在する
Moduloの世界では、ある数のべき乗を行うことで必ず元の値に戻る、という性質があります。
例えば「33」を法とする世界では、そのべき乗は「11」と「21」です。
例えば、6 をべき乗の底とする場合、
611 (mod 33) = 6 621 (mod 33) = 6
となり、元の数字に戻ります。
その他の数字も同様に、法 33の世界では、「11」と「21」のべき乗で元の数字に戻ります。
87
10.2.3. 元の数字に戻る「べき乗」の算出
本ガイドの例では、「33」を法としています。
「33」は、素数「3」と素数「11」の掛け算です。 (以降の計算式説明の都合上、変数を使います。)
P = 3 Q =11
「33」を法とする世界で、元の数字に戻る"べき乗"の「11」と「21」は、以下の 2つの公式どちらかで導き出されます。
① n×((P-1)と(Q-1)の最小公倍数) + 1
3-1=2 と 11-1=10の最小公倍数は 10。
n=1 とすると、1×10+1=11
n=2 とすると、2×10+1=21
n=3 とすると、3×10+1=31 (nを増やせば、11,21以外にも該当する値がある)
② n×(P-1)×(Q-1) + 1
n=1 とすると、1×(3-1)×(11-1) + 1 = 21
n=2 とすると、2×(3-1)×(11-1) + 1 = 41 (nを増やせば、21以外にも該当する値がある)
n=3 とすると、3×(3-1)×(11-1) + 1 = 61 (同上)
n=4 とすると、4×(3-1)×(11-1) + 1 = 81 (同上)
10.2.4. RSAによる署名
RSAは、この「ある法の世界で、暗号化対象のメッセージに、いくらの数のべき乗を行えば再び元のメッセージに戻
るか?」の"べき乗"を秘密にするのがポイントです。
この法則を使って、RSAでは以下の形が定義されています。
(me)d mod n = m
(md)e mod n = m
n: 法(素数 P×Q)
e: 公開鍵
d: 秘密鍵
m: メッセージ
「n」を法とする世界で、メッセージ「m」を「e×d」(または「d×e」)でべき乗したら、元のメッセージ「m」に戻る、という形
が定義されています。
よって、この「m」のべき乗数「e×d」は、2つの数の掛け算として成り立つ必要があります。
法を「33」とするこの例では、「21」が 3×7で成り立つので、3か 7のどちらかを公開鍵、どちらかを秘密鍵として利
用します。
ここでは、以下とします。
「7」が秘密鍵 d=7
「3」が公開鍵 e=3
法 n=33 ←これも公開されます。
元メッセージ m=14
88
以下のフローを使って、説明します。
① tbsCertificateからハッシュ値を算出します。ここでは、"14"というハッシュ結果になったと仮定します。(m=14)
② 秘密鍵を用いて、そのハッシュ値に RSA署名を行います。
147 mod 33 =20
この「20」が署名値です。
③ tbsCertificate と RSA署名を合わせたものが、ABC社のサーバ証明書です。
④ ABC社のサーバ証明書を ABC社に送付され、ABC社のサーバまたは BIG-IPにインポートされます。
⑤ クライアントは、ABC社からサーバ証明書を受け取ります。
⑥ クライアントは、tbsCertificate と署名を分離します。
⑦ tbsCertificateのハッシュ値を算出します(m=14)
⑧ 認証局の公開鍵(e=3, n=33)を用いて、署名を検証します。
m = 203 mod 33 = 14
⑨ ⑦と⑧の結果を比較。一致すれば改ざんされていない=このサーバ証明書を信頼します。
⑩ サーバ証明書が信頼された=その証明書内の ABC社の公開鍵も信頼されます。
89
10.2.5. RSAのまとめ
RSAは、「元のメッセージを、どの数値でべき乗したら元に戻るのか?」を隠すのがポイントですが、その値は、既述
の通り、法を構成する 2つの素数を使った公式で導き出されます。
よって、その 2つの素数がわかってしまえば、解読できてしまいます。
例として使った法:「33」は、素数 3 と素数 11 を掛け合わせたもの、というのは人間でも簡単にわかってしまいます。
しかし、これが大きい素数の掛け算になると解読するのはとてつもなく難しい、というのが RSAの根幹にあります。
現在では、法が 2048bitになるような大きな 2つの素数の掛け算を使うのが一般的で、これを解読するには現存す
るコンピュータでは相当難しい、とされています。
ここではあくまでイメージを掴むことを目的として、簡単な計算で求められる範囲にとどめていますが、公開鍵/秘密
鍵となる e, d値の算出ロジックの詳細については、Wikipediaの「RSA (cryptosystem)」をご参照ください。
[ 参考 URL ]
https://www.maitou.gr.jp/rsa/rsa10.php https://en.wikipedia.org/wiki/RSA_(cryptosystem)
90
10.3. Diffie-Hellman とは
プリマスターシークレットの交換に使われる Diffie-Hellmanについて解説します。
RSAの場合は、暗号化はしているものの、プリマスターシークレット (鍵のタネになるもの) をネットワーク上で交換
します。 (既述:「SSLハンドシェークフロー (例:RSA鍵交換)」を参照)
一方、Diffie-Hellmanの場合は、プリマスターシークレットを生成する計算に必要な値を交換するだけで、それ自体
をネットワーク上で交換しません。
その代わりに、計算に必要なパラメータを受け取ったら、その値からクライアント/サーバそれぞれがプリマスターシ
ークレットを算出する、という方式です。
よって、「ネットワーク上にプリマスターシークレットが流れない」というのが Diffie-Hellmanの特徴です。
また、「その算出に使う値はすべて暗号化されていない」というのも特徴的です。
以下に、小さな数字を用いて、Diffie-Hellmanのフローを示します。
① クライアント/サーバそれぞれが、秘密の値「Secret」を生成します。これは絶対に公開しません。
サーバ:x=9,クライアント:y=3
② modulo計算に使う「g」の値「2」をサーバからクライアントへ送り、共有します。
③ modulo計算に使う「p」の値「53」をサーバからクライアントへ送り、共有します。
④ サーバは、「g」「p」「x」の値から、図中の Modulo計算を行い、値を算出します。それが「A=35」です。
⑤ この「A=35」をサーバからクライアントへ送り、共有します。
⑥ クライアントは、「g」「p」「y」の値から、図中の Modulo計算を行い、値を算出します。それが「B=8」です。
⑦ この「B=8」をクライアントからサーバへ送り、共有します。
⑧ ここまでで交換した値を用いて、クライアント/サーバそれぞれが図中の Modulo計算を行うと、結果が同じになる
=プリマスターシークレット(KA=51 と KB=51)を共有できる、という仕組みです。
[ 参考 URL ]
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
91
10.4. DHE-RSAの SSLハンドシェークフロー
プリマスターシークレットの交換に DHE と、署名に RSA を使った、具体的な SSLハンドシェークフローを示します。
92
上図の SSLハンドシェークのところから解説します。
① クライアントからの Client Helloにて、主に以下 2つの情報がサーバ (BIG-IP) へ送られます。
A) クライアントがサポートしている暗号アルゴリズムのリスト
B) クライアントが生成したランダムな値 (クライアントランダム)
② BIG-IPからの Server Helloにて、主に以下 2つの情報がクライアントへ送られます。
A) クライアントから提示された暗号アルゴリズムの中から一つ選んだ暗号アルゴリズム
ここでは「DHE-RSA-AES128-SHA256」が選択された、とします。
B) サーバが生成したランダムな値 (サーバランダム)
③ BIG-IPから、ABC社のサーバ証明書がクライアントへ送られます。
④ クライアントは tbcCertificate と署名を分離します。
⑤ tbsCertificateのハッシュを計算します。
⑥ RSAで署名されている署名値を、F5J-CA証明書内の公開鍵で復号化し、ハッシュ値を取り出します。
⑦ ⑤と⑥で得られたハッシュ値を比較。一致すれば、この証明書は改ざんされていない=信頼できるものとして扱わ
れます。
⑧ また⑦の結果、ABC社のサーバ証明書内の公開鍵も信頼できると判断されます。
⑨ サーバは、Diffie-Hellmanの計算に必要なパラメータを生成します(Diffie-Hellman Server Parameters)。
その Diffie-Hellman Server Parametersは、サーバランダム/クライアントランダム値と合わせてハッシュ計算され
ます。そしてそのハッシュ値を、サーバ証明書と同じ方式(RSA)で署名します。
⑩ サーバは、ServerKeyExchangeにて、⑨の値をクライアントに送ります。
⑪ クライアントは、⑩で得た Diffie-Hellman Server Parameters とサーバランダム/クライアントランダムを合わせて
ハッシュを計算します。
⑫ クライアントは、⑩で得た署名を、ABC社の公開鍵で復号化して、ハッシュ値を取り出します。
⑬ クライアントは、⑪と⑫で得られたハッシュ値を比較。一致すれば信頼できるものとして扱います。
⑭ クライアントは、Diffie-Hellman Server Parametersで得た「g」と「p」値と、自身の Secret値「y」から図中の計算
を行い、Diffie-Hellman Client Parameters を生成します。
⑮ クライアントは、ClientKeyExchangeにて、⑭の値をサーバに送ります。
⑯ クライアントおよびサーバはそれぞれ、ここまでで得た Diffie-Hellmanのパラメータを使って図中の計算を行い、
同じ結果を得ます。
これで、プリマスターシークレットの共有が出来ました。
93
10.5. キーブロックの生成
SSLハンドシェークで秘密裏に交換した「プリマスターシークレット」、公に交換した「サーバランダム」、「クライアント
ランダム」から、まず「マスターシークレット」を生成します。
その生成された「マスターシークレット」を使って、共通鍵暗号(AES128)に使う「キーブロック」を生成します。
「キーブロック」とは、AES暗号鍵そのものや、AES暗号時に使うイニシャルベクター(IV)などを含むデータの固まり
のことです。
「マスターシークレット」&「キーブロック」の生成には、PRF (PseudoRandom Function) という方式が使われます。
PRFについて(RFC5246より):
PRFについては、RFC5246:The Transport Layer Security (TLS) Protocol Version 1.2には以下のように定
義されています。
"5. HMAC and the Pseudorandom Function"
~略~
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed)+ HMAC_hash(secret, A(2) + seed)+ HMAC_hash(secret, A(3) + seed)+ ... where + indicates concatenation. A() is defined as: A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) P_hash can be iterated as many times as necessary to produce the required quantity of data. For
example, if P_SHA256 is being used to create 80 bytes of data, it will have to be iterated three times (through A(3)), creating 96 bytes of output data; the last 16 bytes of the final iteration will then be discarded, leaving 80 bytes of output data.
TLS's PRF is created by applying P_hash to the secret as: PRF(secret, label, seed) = P_<hash>(secret, label + seed)
また、「プリマスターシークレット」から「マスターシークレット」を算出する場合には、同様に RFC5246には以下の
ように定義されています。
"8.1. Computing the Master Secret"
~略~
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
さらに鍵の算出についても、同様に RFC5246には以下のように定義されています。
"6.3. Key Calculation"
~略~
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
この RFCの文章だけではとてもわかりにくいので、以降、これを図示します。
ちなみに hashには、今回選んだ暗号スイート:「TLS_DHE_RSA_WITH_AES_128_CBC_SHA256」の末尾の
SHA256が使われます。
94
10.6. PRF (P_SHA256) のフロー
以下の図を用いて、「マスターシークレット」および「キーブロック」を生成するまでのフローを示します。
95
10.6.1. マスターシークレットの生成
① プリマスターシークレットが 64byteより長い場合、SHA256でハッシュ (※理由は後述の HMACのところで解
説) されたものが、PRFの一つ目の入力値です。
(これを、「#プリマスターシークレット」と呼ぶことにします。)
② Label として"master secret"の固定文字がつけられ、後続にクライアントランダムとサーバランダムを連結した文
字列が PRFの 2つ目の入力値です。
③ ①と②を入力値として、HMAC-SHA256の計算が行われ、結果=A(1)が出力されます。
④ A(1)と②が連結されたものと、①の「#プリマスターシークレット」の 2つの値を入力値として、HMAC-SHA256の
計算が行われます。
⑤ ④の結果が、マスターシークレットの一つ目の 32Byte ブロックです。
⑥ A(1)と「#プリマスターシークレット」を入力値として、HMAC-SHA256の計算が行われ、結果=A(2)が出力されま
す。
⑦ A(2)と②が連結されたものと、①の「#プリマスターシークレット」を入力値として、HMAC-SHA256の計算が行わ
れます。
⑧ ⑦の結果が、マスターシークレットの二つ目の 32Byte ブロックです。
⑨ マスターシークレットは 48Byte と決められているので、⑤と⑧の連結の 64byteから先頭 48byte を切り出した値
をマスターシークレットにします。
10.6.2. キーブロックの生成
① マスターシークレットが PRFの一つ目の入力値です。
② Label として"key extpansion"の固定文字がつけられ、後続にクライアントランダム(32Byte)とサーバランダム
(32byte)を連結した文字列が PRFの 2つ目の入力値です。
③ ①と②の 2つの値を入力値として、HMAC-SHA256の計算が行われ、結果=A(1)が出力されます。
④ ③で出力された A(1)と②の値が連結されたものと、①の「マスターシークレット」の 2つの値を入力値として、
HMAC-SHA256の計算が行われます。
⑤ ④の結果が、キーブロックの一つ目の 32Byteブロックです。
⑥ ③の結果=A(1)と「マスターシークレット」の 2つの値を入力値として、HMAC-SHA256の計算が行われます。
⑦ ~ ⑪まで、類似の処理が繰り返されます。
⑫ キーブロックが必要な長さになるまで、同様の処理が繰り返されます。
96
10.6.3. キーブロックの内容
生成されたキーブロックの内容は以下のようになっています。
10.6.3.1. MAC Key
暗号化されたデータの改ざんを検知する目的の値:MAC (Message authentication code) を算出するために使わ
れる鍵です。
今回選定している暗号スイートでは SHA256が使われるので、32byte(256bit)の MAC Keyがクライアント用とサ
ーバ用にそれぞれ一つずつ生成されます。
① client write MAC key 32byte (256bit) HMAC-SHA256用
② server write MAC key 32byte (256bit) 〃
MACの生成については、後述します。
10.6.3.2. Encryption key
AES暗号に使う鍵です。今回選定している暗号スイートでは AE128が使われるので、16Byte(128it)の暗号鍵がク
ライアント用とサーバ用にそれぞれ一つずつ生成されます。
① client write encryption key 16byte (128bit) AES128用
② server write encryption key 16byte (128bit) 〃
AES暗号については、後述します。
10.6.3.3. Inital Vector
AESのようなブロック暗号は、例えば CBC(Cipher Block Chaining)の場合、一つ前の暗号ブロックとの XORを行
ってから AES暗号化処理を行います。
この場合、一番先頭の暗号ブロックは当然ながらそれより前の暗号ブロックが存在しないので、その代わりにこの
IVを使って XORを行います。今回選定している暗号スイートでは AES128-CBCが使われるので、16Byte(128bit)の
IVがクライアント用とサーバ用それぞれに一つずつ生成されます。
① client write Initial Vector 16byte (128bit) AES128-CBC用
② server write Initial Vector 16byte (128bit) 〃
CBCについては、AES暗号ともに後述します。
[参考]各鍵のサイズについては以下から推測:
RFC5246の 6.3. Key Calculation より;
~略~
Implementation note: The currently defined cipher suite which requires the most material is AES_256_CBC_SHA256. It requires 2 x 32 byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key material.
97
10.6.4. HMAC-SHA256
PRF内で使われる HMACについて解説します。
HMACについては、RFC2104に定義されており、以下の式で表されます。
H: ハッシュ関数 (SHA256)
K:シークレット値 (プリマスターシークレット or マスターシークレット)
ハッシュ関数が必要とするブロックサイズになるまで、右側に 0を追加する。
または、ブロックサイズより大きい場合は、オリジナルのキーをハッシュして必要な長さに変える。
m: メッセージ(ラベルとシード)
||: 文字列をくっつける。
opad: Outerパディング: 0x5c5c5c…5c5c,
ipad: Innerパディング: 0x363636…3636,
これも分かりにくいので、図示します。
PRFでマスターシークレットを生成するフロー図(既述)の、最初の HMAC-SHA256を例に解説します。
98
① プリマスターシークレットが 64Byteより大きい場合、SHA256でハッシュします。
(これを「#プリマスターシークレット」と呼ぶことにします。)
[理由]RFC2104に HMACが定義されており、その中に以下の記載があります。
"2. Definition of HMAC"
~略~
We assume H to be a cryptographic hash function where data is hashed by iterating a basic compression function on blocks of data.We denote by B the byte-length of such blocks (B=64 for all the above mentioned examples of hash functions), and by L the byte-length of hash outputs (L=16 for MD5, L=20 for SHA-1). The authentication key K can be of any length up to B, the block length of the hash function. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC.
~略~
② 「#プリマスターシークレット」に 00(Hex)を 64Byteになるまで付加します。
③ ②と ipad (0x363636....) との XORを算出します。
④ ③の XOR結果と、ラベル&シードを連結します。
⑤ ④を SHA256でハッシュします。
⑥ 「#プリマスターシークレット」に 00(Hex)を 64Byteになるように付加します。
⑦ ⑥と opad (0x5c5c5c....) との XORを算出します。
⑧ ⑤の Hash値と⑦の XOR結果を連結します。
⑨ ⑧を SHA256でハッシュします。
⑩ 32Byteの出力結果が得られます。
PRFは、既述の通り、この HMAC処理の繰り返しで構成されています。
99
10.7. データの生成
ここまでの処理で、暗号化に使う鍵は全て生成されました。
このセクションでは、それらの鍵の暗号化対象となるデータを作るまでの流れを示します。
暗号化されるデータは、改ざん検知のために、MAC(Message Authentication Code) という値をつける処理が行わ
れます。
クライアントから出力されるデータの例:
① SSLより上位の層 (アプリケーション層) から受け取ったデータは、TLSPlaintext という構造の中に入れられま
す。
② TLSPlaintextのデータ部が圧縮されて、TLSCompressed という構造の中に入れられます。
(圧縮方法は Client Hello/Server Hello内でネゴシエーションされます。)
③ PRF (既述) によって生成された Client MAC keyです。MACを生成するための HMAC-SHA256の一つ目の
入力値として利用されます。
④ TLSCompressedに対して、シーケンス番号 (データ送出バイト数のカウント) が付与されたものが、HMAC-
SHA256の 2つ目の入力値です。
100
(シーケンス番号=データ送出バイト数のカウントは、送信側と受信側しか知りえない情報であることから、認証の
役割も果たしています。)
⑤ ③と④を入力値として、HMAC-SHA256の処理が行われます。
⑥ ⑤の出力結果が MAC値です。
⑦ TLSCompressedに MAC値を付与します。
⑧ さらに、AES128の暗号処理に合うよう、128bitの倍数になるようにパディング処理が行われます。
(Padding lengthの 1byte も含めて、128bitの倍数になるようにパディングされます。)
10.7.1. MACの生成(HMAC-SHA256)
MACを生成する HMAC-SHA256 も参考までに図示します。
PRFのセクションで紹介した HMAC-SHA256 と同じ処理であり、入力値が異なるだけです。
これで、AES暗号化前のデータの準備が整いました。
以降は、AES128による暗号化通信です。
101
10.8. AES暗号
生成した TLS Ciphertextを、AESで暗号化して送り出すまでの処理フローを示します。
ざっくりいうと、AESは「鍵を XORで加えながら、データをかき混ぜる」という感じです。
10.8.1. AES128-CBC暗号データの送出フロー
以下は、クライアントからサーバへ AES暗号化されたデータを送りだすまでの処理の例です。
102
① Client write encryption key(128bit)を一定の法則で撹拌して、Round-keyを 10個作ります。(後述)
② データ部分の先頭から 128bit を取り出します。
③ ②と Client write Initial Vector(128bit)で XORを算出します=CBCの最初の処理
[AESの Initial Round]
④ ③の結果と Client write encryption key(128bit)で XOR を算出します。
[AESの 9 Rounds]
⑤ ④の結果に対して、SubBytes処理を行います。(後述)
⑥ ⑤の結果に対して、ShiftRows処理を行います。(後述)
⑦ ⑥の結果に対して、MixColumns処理を行います。(後述)
⑧ ⑦の結果に対して、RoundKey 1 との XORを算出します。
※⑤~⑧を合計 9回繰り返します。(実施回数毎に、回数と同じ番号の RoundKeyが使われます。)
[AESの Final Round]
⑨ 9回行われた後の⑧の結果に対して、SubBytes処理を行います。(後述)
⑩ ⑨の結果に対して、ShiftRows処理を行います。(後述)
⑪ ⑩の結果に対して、RoundKey 10 との XORを算出します。
⑫ 128bitの暗号化ブロックが完成しました。
[次の 128bit ブロックの暗号化処理]
⑬ データ部分から次の 128bit を取り出します。
⑭ ⑬と、一つ前の 128bit暗号ブロック(⑫)との XORを算出します=CBC処理
⑮ AES暗号化処理を実施します(④~⑪と同じ処理)
⑯ 2つ目の 128bitの暗号化ブロックが完成しました。
[さらに次の 128bit ブロックの暗号化処理]
⑰ データ部分からさらに次の 128bitを取り出します。
⑱ ⑰と、一つ前の 128bit暗号ブロック(⑯)の XORを算出します=CBC処理
⑲ AES暗号化処理を実施します(④~⑪と同じ処理)
⑳ 3つ目の 128bitの暗号化ブロックが完成しました。
この処理が、後続のデータの 128bit毎に繰り返されて、TLSCiphertextが作られます。
この TLSCiphertextがサーバに送られます。
103
10.8.2. CBC (cipher block chaining) について
CBCは、一つ前の暗号ブロック(128bit)との XORを行う処理です。
上図⑭、⑱は、一つ前の暗号ブロックがあるので、それとの XORを行うことができますが、③は、前の暗号ブロック
が存在しません。
よって、最初のデータブロックだけは、キーブロックから生成したイニシャルベクター (クライアント→サーバへの送出
時は Client Write Initial Vector) との XORを行います(上図③)。
10.8.3. RoundKey の生成
AESの AddRoundKeyの処理で、データとの XORを行うための 10個の RoundKey(1~10)を生成するフローで
す。
既述のフロー通り、AddRoundKeyは合計で 11回実施されますが、1回目(Initial Round)ではキーブロックから生
成された Encryption Keyを使います。
以降は、その Encryption Keyを元にして生成された 10個の RoundKeyが使われます。
10.8.3.1. RoundKey 1の生成フロー
(1) 1列目
RoundKeyの 1列目だけは、やや複雑な処理がなされます。
104
① Client write encryption key:128bit(16Byte)を 4行 4列に並べたものから、4列目を取り出します。
② 1番上の 1byteを一番下に持ってきます。
③ Client write encryption keyの 1列目を取り出します。
④ ②の Byte列を、S-box対応表の値に置き換えます。
⑤ RCONから一列目を取り出します。
⑥ ③, ④, ⑤の XORを算出します。
⑦ ⑥の結果が、RoundKey 1の一列目になります。
RCON も S-box も、これらの概念を理解するのはなかなか難しそう(ガロア有限体、など)ですが、RoundKeyの生
成時には、上図のように、それぞれの表の値を使う、という理解でよさそうです。
[参考 URL] http://www.slideshare.net/oliynykov/aes-effecitve-software-implementation
RCON: https://en.wikipedia.org/wiki/Rijndael_key_schedule
S-box: https://en.wikipedia.org/wiki/Rijndael_S-box http://www.cqpub.co.jp/dwm/contents/0074/dwm007401521.pdf
(2) 2~4列目
2~4列目以降は、比較的簡単な処理が行われます。
① Client write encryption key:128bit(16Byte)を 4行 4列に並べたものから、2列目を取り出します。
② RoundKey 1の 1列目を取り出します。
③ ①と②の XORを算出します。
④ ③の結果が、RoundKey 1の 2列目です。
⑤ Client write encryption key:128bit(16Byte)を 4行 4列に並べたものから、3列目を取り出します。
⑥ RoundKey 1の 2列目を取り出します。
⑦ ⑤と⑥の XORを算出します。
⑧ ⑦の結果が、RoundKey 1の 3列目です。
⑨ Client write encryption key:128bit(16Byte)を 4行 4列に並べたものから、4列目を取り出します。
⑩ RoundKey 1の 3列目を取り出します。
⑪ ⑨と⑩の XORを算出します。
⑫ ⑪の結果が、RoundKey 1の 3列目です。
これで、RoundKey 1が完成しました。
105
10.8.3.2. RoundKey 2の生成フロー
Roundkey 2 の場合も、RoundKey 1の一列目の生成と同様のフローですが、以下 2点が異なります。
a) 生成のベースとなる Key として、Encryption Keyではなく、ひとつ前の RoundKey 1 を使う。
b) RCONは二列目を使う。
(RoundKey 1 と同様の処理フローなので、図の解説は省略します。)
(1) 1列目
(2) 2~4列目
これを繰り返して、RoundKeyを 10個生成します。
106
10.8.4. AddRoundkey
AES暗号前のデータと、Encryption Keyで、単純に XOR を算出します。
10.8.5. SubBytes
S-box表を使って、対応する値に変換します。
10.8.6. ShiftRows
以下のように Byte単位でずらします。
107
10.8.7. MixColumns
ある表 (Circulant MDS Matrix) との掛合せを行う処理です。
上記 3つの処理と異なり、これだけはちょっとややこしいです。
10.8.7.1. 算出方法
MixColumnsの一つ目の値の算出例を示します。
例えば、{2.d4} は、d4に 2 をかける、という意味合いではあるのですが、単純に 2倍、という処理ではなく、以下の
ような計算が必要です。
(1) {2.d4}
① d4を bit列にします。 d4= 11010100
② 左へ 1bitシフトして、後ろに”0”を足します。 10101000
③ d4の先頭 bitが 1なので、00011011 (1b)との XOR を計算します。
(※先頭 bitが 0だとこの処理は行いません。)
10101000
XOR 00011011
--------------
10110011
(2) {3.bf}
① bf を bit列にします。 bf= 10111111
② "3"は、2進数だと 11なので、「10 XOR 01」と表せます。
③ よって、以下の計算式として表せます。
{3.bf} = {10 XOR 01} . {10111111} = {10 . 10111111} XOR {01 . 10111111}
108
④ {01 . 10111111} は、bfに 1をかけているだけなので、bfのままになります。よって、以下の形になります。
= {10 . 10111111} XOR {10111111}
⑤ {10 . 10111111} は、bfに 2をかけているので、{2 . d4}の計算に倣って、同様の計算を行います。
bf を左へ 1bitシフトして、後ろに”0”を足します。 01111110
bfの先頭 bitが"1"なので、その値と、00011011 (1b)との XORを計算します。
01111110
XOR 00011011
--------------
01100101
⑥ この⑤の結果と、{10111111} との XORを取ります。
= {01100101} XOR {10111111} = 11011010
⑦ 以下 2つは、1を掛合わせるので、値は変化しません。
{1.5d} = {01 . 01011101} = {01011101}
{1.30} = {01 . 00110000} = {00110000}
⑧ 算出した 4つの値の XOR を取ります。
10110011 {2.d4}
11011010 {3.bf}
01011101 {1.5d}
XOR 00110000 {1.30}
-----------------------
00000100 = 0x04
これで、1つ目の Byte「04」が計算されました。 以降の Byte も類似の計算式で導き出されます。
[ 参考 URL ] http://www.angelfire.com/biz7/atleast/mix_columns.pdf
109
10.8.8. AES128-CBC暗号データの受信フロー
サーバが、クライアントからの AES暗号データを受け取った際の復号処理フローです。
概ね「暗号化と逆の処理を行うことで復号化する」という感じですが、InvSubBytesや InvMixColumnsについては、
復号用のものを使います。
(下図は、下から上への流れになっています。)
110
10.8.9. InvSubBytes
復号時の SubBytesは、以下の Inverse S-boxが使われます。
(数字は 16進数です。)
10.8.10. InvMixColumns
復号時の MixColumnsの Circulant MDS Matrixは、以下が使われます。
(数字は 10進数です。)
以上が、SSLハンドシェークから暗号化/復号化までの一連の流れです。
[その他の参照 URL] https://www.youtube.com/watch?v=ySq88y0e8u4 https://en.wikipedia.org/wiki/Hash-based_message_authentication_code http://www.cqpub.co.jp/dwm/contents/0074/dwm007401521.pdf http://www.atmarkit.co.jp/ait/articles/0007/15/news001.html
111
11. [Appendix.2] OpenLDAPの設定
本ガイドの CRLDPのセクションで使った、CentOS上の OpenLDAPの設定手順です。
11.1. OpenLDAPのインストールと起動
以下のコマンドを実行。
# yum -y install openldap-servers openldap-clients
# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
# chown ldap. /var/lib/ldap/DB_CONFIG
# service slapd start
Starting slapd: [ OK ]
# chkconfig slapd on
11.2. 管理者パスワードの設定
(1) 管理者パスワードの生成
# slappasswd
New password:default
Re-enter new password:default
{SSHA}uo07Q1Yzioj6T+V8SWmjRAllu/6+1/e9
(2) 管理者用 ldifの作成
# vi chrootpw.ldif
以下の内容のファイルを生成する。
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}uo07Q1Yzioj6T+V8SWmjRAllu/6+1/e9 ※ここに(1)の値を Copy&Paste。
(3) 管理者用 ldif を LDAPへ追加
# ldapadd -Y EXTERNAL -H ldapi:/// -f chrootpw.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={0}config,cn=config"
11.3. ドメインの設定
(1) ディレクトリマネージャーパスワードの生成
# slappasswd
New password:default
Re-enter new password:default
{SSHA}ILiSLLyrQY7tW4wqEB3ClDNX2MH4j83h
112
(2) ディレクトリマネージャ用 ldifの作成
# vi chdomain.ldif
以下の内容のファイルを生成する。
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
read by dn.base="cn=Manager,dc=f5jp,dc=local" read by * none
dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=f5jp,dc=local
dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=Manager,dc=f5jp,dc=local
dn: olcDatabase={2}bdb,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}ILiSLLyrQY7tW4wqEB3ClDNX2MH4j83h ※ここに(1)の値を Copy&Paste。
dn: olcDatabase={2}bdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by
dn="cn=Manager,dc=f5jp,dc=local" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=Manager,dc=f5jp,dc=local" write by * read
(3) 作成したディレクトリマネージャ用 ldifで編集
# ldapmodify -Y EXTERNAL -H ldapi:/// -f chdomain.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}monitor,cn=config"
modifying entry "olcDatabase={2}bdb,cn=config"
modifying entry "olcDatabase={2}bdb,cn=config"
modifying entry "olcDatabase={2}bdb,cn=config"
ldap_modify: Inappropriate matching (18)
additional info: modify/add: olcRootPW: no equality matching rule
113
(4) ベースドメイン用 ldifの作成
# vi basedomain.ldif
以下の内容のファイルを生成する。
dn: dc=f5jp,dc=local
objectClass: top
objectClass: dcObject
objectclass: organization
o: f5jp local
dc: f5jp
dn: cn=Manager,dc=f5jp,dc=local
objectClass: organizationalRole
cn: Manager
description: Directory Manager
dn: ou=People,dc=f5jp,dc=local
objectClass: organizationalUnit
ou: People
dn: ou=Group,dc=f5jp,dc=local
objectClass: organizationalUnit
ou: Group
(5) ベースドメイン用 ldifの追加
# ldapadd -x -D cn=Manager,dc=f5jp,dc=local -W -f basedomain.ldif
Enter LDAP Password: default
adding new entry "dc=f5jp,dc=local"
adding new entry "cn=Manager,dc=f5jp,dc=local"
adding new entry "ou=People,dc=f5jp,dc=local"
adding new entry "ou=Group,dc=f5jp,dc=local"
OpenLDAP 設定は以上です。
[参照 URL]
http://www.server-world.info/query?os=CentOS_6&p=ldap
114
12. [Appendix.3] OpenSSL コマンドのオプション解説
12.1. 署名リクエスト(CSR)と鍵の生成時のオプション
本ガイドで利用した、署名リクエスト(CSR)と鍵の生成時のオプションは概ね共通ですので、ここでは ABC社のもの
を生成した際のコマンドを例に解説します。
ABC社の署名リクエストと鍵の出力例:
openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout ./SERVER/abcCompany-key.pem \
-out ./SERVER/abcCompany-req.pem \
-subj "/C=JP/ST=Kanagawa/L=Yokohama/O=ABC-Company, Ltd./OU=IT/CN=www.abc-company.lab"
オプション 解説
openssl req -new 署名リクエスト(CSR)を新規に生成する。
-newkey rsa:2048 RSAの鍵長 2048bitの鍵を新しく生成する。
-nodes 鍵をパスフレーズで暗号化しない。
-sha256 署名リクエストに対して、SHA256でダイジェスト(ハッシュ値)を出力
する。
-keyout ./SERVER/abcCompany-key.pem 鍵をファイル出力する。
-out ./SERVER/abcCompany-req.pem 署名リクエスト(CSR)をファイル出力する。
-subj
"/C=JP/ST=Kanagawa/L=Yokohama/O=ABC-
Company, Ltd./OU=IT/CN=www.abc-
company.lab"
署名リクエストに記載する値を指定する:
C: countryName ST: stateOrProvinceName L: localityName O: organizationName OU: organizationalUnitName
CN: commonName
12.2. 署名時のオプション
本ガイドで利用した、署名時のオプションはいくつかパターンがあるので、それぞれ解説します。
12.2.1. 認証局への署名
中間認証局 02への署名の例:
openssl ca -md sha256 -in ./interCA02/interCA02req.pem -keyfile ./private/interCA01key.pem \
-out ./interCA02/interCA02crt.pem -extensions v3_ca -batch -policy policy_anything \
-config ./openssl-interCA01.cnf -days 3650
オプション 解説
openssl ca 署名リクエスト(CSR)に署名する。
-md sha256 署名時のダイジェスト(ハッシュ値)に SHA256 を使う。
-in ./interCA02/interCA02req.pem 入力ファイルとして、署名リクエスト(CSR)を指定。
-keyfile ./private/interCA01key.pem 署名を行う認証局の秘密鍵を指定。
-out ./interCA02/interCA02crt.pem 証明書をファイル出力する。
-extensions v3_ca 証明書の拡張領域に、openssl.cnf内の[v3_ca]に記載された内容を
追加する。
-batch 作成時の「Yes/No?」といった質問形式を省く。
-policy policy_anything openssl.cnf内の[policy_anything]に記載されたポリシーに従う。
※
-config ./openssl-interCA01.cnf デフォルトの openssl.cnfではなく、編集した別名のコンフィグファイ
ルを使いたい場合の指定。
-days 3650 有効期限を 3650日(10年間)とする指定。
115
※ 「"-policy policy_anything"」オプションについて
デフォルトでは、countryName(国名), stateOrProvinceName(都道府県), organizationName(組織名)が、認証局
の証明書と署名リクエストで同じ値でなければ受け付けてくれない設定になっています。
# vi /etc/pki/tls/openssl.cnf
<<デフォルト >>
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
"-policy policy_anything"のオプション指定を行うことで、openssl.cnf 内の以下のポリシーが適用されるの
で、国名や県名が認証局と一致しなくても証明書が生成できます。
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
12.2.2. SANつき証明書作成時の署名
上記の「認証局への署名」とほぼ同じですが、以下の一点だけが異なります。
例:
openssl ca -md sha256 -in ./SERVER/abc000company-req.pem -out ./SERVER/abc000company-crt.pem \
-keyfile ./private/interCA02key.pem -batch -policy policy_anything \
-config ./openssl-interCA02-san.cnf -extensions v3_req
オプション 解説
-extensions v3_req 証明書の拡張領域に、openssl.cnf内の[v3_req]に記載された内容
を追加する。
12.2.3. CRLDPつきクライアント証明書作成時の署名
こちらも上記とは一点だけ異なります。
例:
openssl ca -md sha256 -in ./CLIENT/${user}-req.pem -keyfile ./private/interCA02key.pem \
-cert ./interCA02crt.pem -out ./CLIENT/${user}-crt.pem -batch -policy policy_anything \
-config ./openssl-interCA02.cnf -days 730 -extensions my-crldp
オプション 解説
-extensions my-crldp 証明書の拡張領域に、openssl.cnf内の[my-crldp]に記載された内
容を追加する。
以上