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
Ⅹ
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 コマンドのオプシ
ョン解説」に記載していますので、必要に応じてご参照ください。
3
2. ネットワーク構成サンプル
以下のネットワーク構成を使って、SSL 動作を確認します。
10.99.100.210 のサーバ(CentOS6.7)上の OpenSSL を使って、デジタル証明書を生成します。
クライアント証明書認証の CRL による失効管理の際の、CRL ファイル転送用に Apache(Web サーバ)を使いま
す。
クライアント証明書認証の CRLDP による失効管理の際に、OpenLDAP を使います。
4
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 を使って証明書を生成していきます。
5
3.2. 本ガイドで使う証明書の値
証明書を生成する際に利用する各値は、以下としました。
(1) ルート認証局 (F5J-CA)
OpenSSL 項目
countryName
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
意味
国
都道府県
区市町村
会社名
組織名
名称
値
JP
Tokyo
Minato-ku
F5J-CA, Ltd.
CA
f5jca.f5jp.local
意味
国
都道府県
区市町村
会社名
組織名
名称
値
JP
Saitama
Soka
InterCA01, Ltd.
ICA01
ica.interca01.local
意味
国
都道府県
区市町村
会社名
組織名
名称
値
JP
Chiba
Funabashi
InterCA02, Ltd.
ICA02
ica.interca02.local
(2) 中間認証局 (InterCA01)
OpenSSL 項目
countryName
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
(3) 中間認証局 (InterCA02)
OpenSSL 項目
countryName
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
(4) サーバ証明書の所有者 (ABC-Company)
OpenSSL 項目
countryName
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
意味
国
都道府県
区市町村
会社名
組織名
名称
値
JP
Kanagawa
Yokohama
ABC-Company, Ltd.
IT
www.abc-company.lab
6
3.3. ルート認証局 (F5J-CA) の生成
まず、ルート認証局の秘密鍵と証明書を生成します。
以下はその生成フローのイメージです。
① ルート認証局は、自身の秘密鍵を生成します。(cakey.pem)
② ルート認証局は、自身の署名リクエスト(CSR)を生成します。(careq.pem)
③ ルート認証局は、署名リクエスト(CSR)に対して、署名を行う認証局の情報(ルート認証局自身の情報)や有効期間
などを追加して、それを「tbsCertificate」とします。
④ この「tbsCertificate」を、SHA-2 を使ってハッシュ値を計算します。
⑤ そのハッシュ値を、ルート認証局の秘密鍵を使って、RSA で暗号化します。これが署名です。
⑥ 「tbsCertificate」に署名を加えたものが、ルート認証局の証明書になります。
7
3.3.1. ルート認証局向けファイルの生成
ルート認証局の秘密鍵や証明書を生成する際に必要なファイルを生成します。
3.3.1.1. デフォルトのフォルダを確認
本ガイドでは、openssl.cnf 内に記載された、デフォルトのフォルダをそのままルート認証局用に使うことにします。
CA のデフォルトのディレクトリは/etc/pki/CA となっていますので、そのまま利用します。
# less /etc/pki/tls/openssl.cnf
～略～
####################################################################
[ CA_default ]
dir
certs
crl_dir
database
#unique_subject
=
=
=
=
=
new_certs_dir
= $dir/newcerts
certificate
serial
crlnumber
= $dir/cacert.pem
= $dir/serial
= $dir/crlnumber
crl
private_key
RANDFILE
～略～
/etc/pki/CA
$dir/certs
$dir/crl
$dir/index.txt
no
#
#
#
#
#
#
#
#
#
#
#
= $dir/crl.pem
#
= $dir/private/cakey.pem#
= $dir/private/.rand
#
Where everything is kept
Where the issued certs are kept
Where the issued crl are kept
database index file.
Set to 'no' to allow creation of
several ctificates with same subject.
default place for new certs.
The CA certificate
The current serial number
the current crl number
must be commented out to leave a V1 CRL
The current CRL
The private key
private random number file
3.3.1.2. /etc/pki/CA/内に存在するディレクトリを確認
デフォルトで、以下のディレクトリが用意されています。
# ls -l /etc/pki/CA/
total 16
drwxr-xr-x. 2 root root
drwxr-xr-x. 2 root root
drwxr-xr-x. 2 root root
drwx------. 2 root root
4096
4096
4096
4096
Jan
Jan
Jan
Jan
9
9
9
9
03:43
03:43
03:43
03:43
certs
crl
newcerts
private
3.3.1.3. ファイルの生成
自己署名による証明書発行に必要なシリアル番号およびインデックス管理のためのファイルを生成します。
以下のコマンドを実行します。
(1) CA 用のフォルダへ移動
# cd /etc/pki/CA/
(2) ファイルの生成
# echo "01" > ./serial
# touch ./index.txt
：openssl が利用する、シリアル番号管理のためのファイル
：openssl が利用する、インデックス管理のためのファイル
8
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
これでルート認証局の生成は完了です。
9
3.4. 中間認証局 01(InterCA01)の生成
ルート認証局から見て一段目の、中間認証局 01 の秘密鍵と証明書を生成します。
以下はその生成フローイメージです。
① 中間認証局 01 は、自身の秘密鍵を生成します。(interca01key.pem)
② 中間認証局 01 は、自身の署名リクエスト(CSR)を生成します。(interca01req.pem)
③ 中間認証局 01 は、署名リクエスト(CSR)をルート認証局に送ります。
④ ルート認証局は、署名リクエスト(CSR)に対して、署名を行う認証局の情報(ルート認証局自身の情報)や有効期間
などを追加して、それを「tbsCertificate」とします。
⑤ この「tbsCertificate」を、SHA-2 を使ってハッシュ値を計算します。
⑥ そのハッシュ値を、ルート認証局の秘密鍵を使って、RSA で暗号化します。これが署名です。
⑦ 「tbsCertificate」と署名を一まとまりにしたものが、中間認証局 01 の証明書になります。
⑧ ルート認証局は、その証明書を中間認証局 01 へ送ります。
10
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
11
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
certs
crl_dir
database
#unique_subject
=
=
=
=
=
new_certs_dir
= $dir/newcerts
certificate
serial
crlnumber
= $dir/interCA01crt.pem
= $dir/serial
= $dir/crlnumber
crl
private_key
RANDFILE
/etc/pki/CA/interCA01
$dir/certs
$dir/crl
$dir/index.txt
no
#
#
#
#
#
#
#
Where everything is kept
Where the issued certs are kept
Where the issued crl are kept
database index file.
Set to 'no' to allow creation of
several ctificates with same subject.
default place for new certs.
# The CA certificate
# The current serial number
# the current crl number
# must be commented out to leave a V1 CRL
= $dir/crl.pem
# The current CRL
= $dir/private/interCA01key.pem # The private key
= $dir/private/.rand
# private random number file
3.4.5. 中間認証局 01 専用のシリアル/インデックス管理用ファイルの生成
以降の中間認証局 02 の生成の際に利用する、中間認証局 01 専用のシリアル番号およびインデックス管理のため
のファイルを生成します。
以下のコマンドを実行します。
# echo "01" > ./interCA01/serial
# touch ./interCA01/index.txt
：openssl が利用する、シリアル番号管理のためのファイル
：openssl が利用する、インデックス管理のためのファイル
12
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 へ送ります。
13
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
14
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
certs
crl_dir
database
#unique_subject
new_certs_dir
certificate
serial
crlnumber
crl
private_key
RANDFILE
=
=
=
=
=
/etc/pki/CA/interCA01/interCA02
# Where everything is kept
$dir/certs
# Where the issued certs are kept
$dir/crl
# Where the issued crl are kept
$dir/index.txt
# database index file.
no
# Set to 'no' to allow creation of
# several ctificates with same subject.
= $dir/newcerts
# default place for new certs.
= $dir/interCA02crt.pem
# The CA certificate
= $dir/serial
# The current serial number
= $dir/crlnumber
# the current crl number
# must be commented out to leave a V1 CRL
= $dir/crl.pem
# The current CRL
= $dir/private/interCA02key.pem # The private key
= $dir/private/.rand
# private random number file
3.5.5. 中間認証局 02 専用のシリアル/インデックス管理用ファイルの生成
以降のサーバ証明書およびクライアントの生成の際に利用する、中間認証局 02 専用のシリアル番号およびインデ
ックス管理のためのファイルを生成します。
以下のコマンドを実行します。
# echo "01" > ./interCA02/serial
# touch ./interCA02/index.txt
：openssl が利用する、シリアル番号管理のためのファイル
：openssl が利用する、インデックス管理のためのファイル
15
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 社へ送ります。
16
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
これで、サーバ証明書の生成は完了です。
17
4. BIG-IP の基本設定
本ガイドのネットワーク構成サンプルに合わせて、まず、BIG-IP のネットワーク等の基本的な部分を設定します。
4.1. Platform 設定
以下は、初期ウィザードの流れの中で設定します。
設定した内容は、「System」→「Platform」で確認できます。
ホスト名。FQDN 形式で指定。
Asia/Tokyo を選択。
CLI アクセス用 root アカウントの
パスワード
WebUI アクセス用 admin アカウントの
パスワード
4.2. VLAN 設定
「Network」→「VLANs」で、以下の状態になるように設定します。
18
4.3. Self IP の設定
「Network」→「Self IPs」で、以下の状態になるように設定します。
4.4. Routing 設定
「Network」→「Routes」で、以下の状態になるように設定します。
4.5. NTP の設定
OpenSSL サーバとの時刻を合わせておきます。
「System」→「Configuration」→「Device」→「NTP」で表示された画面で、以下のように設定します。
NTP サーバのアドレスを指定して、
「Add」ボタンを押す。
19
5. サーバ証明書関連の設定
サーバ証明書を使った SSL 通信を行うための設定を行います。
5.1. SSL ハンドシェークフロー (例：RSA 鍵交換)
以降の BIG-IP 設定で、今どの設定を行っているのかを理解するために、まず RSA 鍵交換を使った場合の SSL ハ
ンドシェークのイメージを示します。
20
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 が信頼できるか、の検証が行われます。
21
a)
b)
c)
d)
e)
f)
中間認証局 02 の中間証明書の署名と tbsCertificate を分離します。
中間認証局 02 の tbsCertificate のハッシュを計算します。
RSA で署名されている署名値を、中間認証局 01 の公開鍵で復号化し、ハッシュ値を取り出します。
b)と c)で得られたハッシュ値を比較。一致すれば、中間証明書 01 によって、この証明書は改ざんされて
いない＝信頼できるものとして扱われます。
また d)の結果、ABC 社の中間認証局 02 の証明書内の公開鍵も、中間証明書 01 によって、信頼できる
と判断されます。
～ j) は、中間証明書 02 と同様の処理によって、今度は中間証明書 01 がルート証明書によって信頼さ
れます。
この⑨の処理が完了して初めて、ABC 社のサーバ証明書(公開鍵)が信頼されます。
⑩ クライアントは、共通鍵などを生成するために必要な「プリマスターシークレット」値を生成します。
⑪ この「プリマスターシークレット」値を、ABC 社の公開鍵で暗号化します。
⑫ 暗号化された⑩の値を、BIG-IP へ送ります。
⑬ BIG-IP は、その暗号化された「プリマスターシークレット」を ABC 社の秘密鍵で復号化します。
⑭ 結果、「プリマスターシークレット」を、クライアントとサーバの間で共有できます。
22
5.2. 「SSL ハンドシェークの事前準備」を行う
SSL ハンドシェークを行うための事前準備となる設定を行います。
5.2.1. BIG-IP の設定
まずクライアント PC よりも先に BIG-IP の設定を行うことにします。
5.2.1.1. ABC 社の秘密鍵およびサーバ証明書のインポート
ここまでのステップで生成した秘密鍵および証明書のうち、以下 4 つを使います。
①
②
③
④
abcCompany-key.pem
abcCompany-crt.pem
interCA01crt.pem
interCA02crt.pem
ABC 社の秘密鍵
ABC 社の証明書
中間認証局 01 の証明書
中間認証局 02 の証明書
(1) これらのファイルを、BIG-IP の GUI へアクセスするコンソール PC へ (WinSCP などを使って) コピーしておきま
す。
(2) ABC 社の秘密鍵および証明書をインポートします。
「System」→「File Management」→「SSL Certificate List」で表示された画面の右上の「Import」ボタンを押して現
れた画面で、以下のように設定します。
「Key」を選択。
名称(任意)を指定。
アップロードする秘密鍵ファイルを指定。
(3) 秘密鍵ファイルの Import が完了した状態です。Name の部分：「abcCompany」をクリックします。
23
(4) 今度は、秘密鍵ファイルに紐づいたサーバ証明書を Import します。以下の状態で「Import」ボタンを押します。
(5) Upload するサーバ証明書を指定し、「Import」ボタンを押します。
Upload する証明書を選択。
(6) abc-company.lab の証明書と秘密鍵が Import された状態です。
これで、秘密鍵とサーバ証明書のインポートは完了です。
24
5.2.1.2. 中間認証局の証明書のインポート
BIG-IP に、中間認証局 01 と 02 の証明書をインポートします。
「System」→「File Management」→「SSL Certificate List」で表示された画面の右上の「Import」ボタンを押して現
れた画面で、以下のように設定します。
(1) 中間認証局 01
(2) 中間認証局 02
(3) インポートされた 2 つの中間証明書と秘密鍵は以下の状態になります。
25
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」ボタンを押して現
れた画面で、以下のように設定します。
26
以下の状態になります。
(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 fromlocal-file /var/tmp/mychain.crt
27
(2) WebUI で見ると、以下の状態になります。
5.2.1.5. Client SSL Profile の設定
インポートした ABC 社のサーバ証明書と秘密鍵を Virtual Server で利用するためには、Client SSL Profile の設定
が必要です。
「Local Traffic」→「Profile」→「SSL」→「Client」で表示された画面の右上の「Create」ボタンを押して現れた画面で、
以下のように設定します。
任意の名称を入力。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
～略～
28
5.2.1.6. Pool の設定
ロードバランシング対象の Pool を設定します。
「Local Traffic」→「Pools」で表示された画面の右上の「Create」ボタンを押して現れた画面で、以下のように設定し
ます。
任意の名称を入力。
ヘルスモニタを選択。
Pool メンバーを追加。
29
5.2.1.7. Virtual Server の設定
SSL 通信を受け付ける Virtual Server を設定します。
「Local Traffic」→「Virtual Servers」で表示された画面の右上の「Create」ボタンを押して現れた画面で以下のように
設定します。
任意の名称を入力。
VS のアドレスとポートを設定。
必要に応じて設定。
生成した
Client SSL Profile
を指定。
～略～
必要に応じて設定。
～略～
生成した Pool を選択。
30
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) 「信頼されたルート証明機関」タブを選択し、「インポート」ボタンを押して下ださい。
31
(3) 「次へ」を押して下さい。
(4) インポートするファイルとして、認証局の証明書：cacert.pem を選び、「次へ」を押してください。
(「参照」ボタンを押した後、「***.pem」はデフォルト状態では表示されないかもしれません。その場合は左下の「すべて
のファイル(*.*)」を選択してください。)
32
(5) 証明書ストアが「信頼されたルート証明機関」であることを確認し、「次へ」を押してください。
(6) 「完了」を押してください。
(7) 警告が出ますが、「はい」を押してください。
33
(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) が一致しないことが原因です。
34
これを簡易的に回避するためには、クライアント PC：Windows の hosts ファイルを編集することです。
本例では、サーバ証明書の Common Name は「www.abc-company.lab」です。
(1) メモ帳を、管理者権限で実行します。
(2) C:¥Windows¥System32¥drivers¥etc¥hosts を、以下のように編集します。
35
5.2.2.3. 接続確認
クライアントの Web ブラウザへ入力する URL は、IP アドレスではなく FQDN (https://www.abc-company.lab) で
入力します。
これで、SSL 証明書のセキュリティ警告を見ることなく、Web サーバ(Virtual Server) へ接続することができるように
なります。
(1) 証明書の連鎖の様子を確認してみます。 (例：Internet Exploer)
①
②
(2) 以下のように、証明書の連鎖で信頼されていることがわかります。
36
5.3. SAN (Subject Alternative Name)の設定
SAN (Subject Alternative Name) を使うことで、1 枚のサーバ証明書で複数の FQDN を受け付けることができる
ようになります。
SAN に対応するには、サーバ証明書を生成する際に、SAN 用の拡張領域に複数の FQDN を指定します。
本ガイドでは、SAN 用サーバ証明書の生成に、以下の値を利用することにします。
OpenSSL 項目
countryName
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
Subject Alternative Name
意味
国
都道府県
区市町村
会社名
組織名
名称
値
JP
Kanagawa
Yokohama
ABC000-Company, Ltd.
IT
www.abc000-company.lab
www.abc123-company.lab
www.abc456-company.lab
www.abc789-company.lab
37
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)
38
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 付のサーバ証明書が生成は完了です。
39
5.3.4. SAN 付きサーバ証明書と秘密鍵のインポート
生成した SAN 付きサーバ証明書と秘密鍵をコンソール PC にコピーし、BIG-IP にインポートします。
以下の状態になります。
SAN 付のサーバ証明書をクリックして内容を確認すると、SAN が付与されていることがわかります。
40
5.3.5. Client SSL Profile の設定
インポートした SAN 付サーバ証明書と秘密鍵を Virtual Server で利用するためには、Client SSL Profile の設定が
必要です。
「Local Traffic」→「Profile」→「SSL」→「Client」で表示された画面の右上の「Create」ボタンを押して現れた画面で、
以下のように設定します。
任意の名称を入力。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
～略～
41
5.3.6. Virtual Server の設定変更
SAN 付 Client SSL Profile を Virtual Server に割り当てます。
「Local Traffic」→「Virtual Servers」で表示された画面で、該当する VS をクリックして、以下のように設定変更しま
す。
生成した SAN 用の
Client SSL Profile
を指定。
～略～
42
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 にも追
加してください。
43
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
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
意味
国
都道府県
区市町村
会社名
組織名
名称
値
JP
Kanagawa
Yokohama
def456-Company, Ltd.
IT
www.def456-company.lab
OpenSSL 項目
countryName
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
意味
国
都道府県
区市町村
会社名
組織名
名称
値
JP
Kanagawa
Yokohama
def789-Company, Ltd.
IT
www.def789-company.lab
44
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
45
5.4.2. 秘密鍵とサーバ証明書のインポート
SNI 設定を行う 3 つのサーバ証明書と秘密鍵を、コンソール PC にコピーし、BIG-IP にインポートします。
以下の状態になります。
46
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 の状態でクライアント証明書認証を行いたい場合、以降で設定する、一つ一つ個別のプロファイルの設
定変更はできないので、ベースプロファイルの設定を変更して、全プロファイルに反映する必要があります。
47
5.4.3.2. SNI の fallback 用プロファイル
SNI 指定できないブラウザからのアクセスの際に利用されます。
本ガイドでは、ABC 社の証明書を利用することにします。
名前(任意)を指定。
生成済みのベースプロファイルを選択。
Advanced を選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
～略～
←チェックを入れる
～略～
48
5.4.3.3. def123 社/def456 社/def789 社用プロファイル
SNI 用の Client SSL profile には、以下のように Server Name に FQDN を入力します。
(1) def123 社用
名前(任意)を指定。
生成済みのベースプロファイルを選択。
Advanced を選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
～略～
FQDN を入力。
～略～
(2) def456 社用
名前(任意)を指定。
生成済みのベースプロファイルを選択。
Advanced を選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
～略～
FQDN を入力。
～略～
49
(3) def789 社用
名前(任意)を指定。
生成済みのベースプロファイルを選択。
Advanced を選択。
インポートしたサーバ証明書と秘密鍵および
チェーンとなるバンドル証明書を選択し、
「Add」ボタンを押す。
～略～
FQDN を入力。
～略～
50
5.4.4. Virtual Server の設定変更
SNI 用に作成したプロファイル 3 つと、Fallback 用プロファイルの合計 4 つを、Virtual Server の SSL Profile
(Client)に設定します。
生成した SNI 用の
Client SSL Profile
を指定。
～略～
51
5.4.5. Windows クライアントの設定
DNS による名前解決ができない環境の場合、Windows の Hosts へ、SNI として設定した FQDN を追加します。
(1) Hosts への追加
(2) 接続確認
def123 / def1456 / def789 のどの FQDN に対しても、SSL のセキュリティ警告なしでアクセスできることを確認して
ください。
52
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 へインポートします。
53
本ガイドでは、クライアント証明書の生成に、以下の値を利用することにします。
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.
54
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 というファイル(クライアント証明書＆秘密鍵)が生成されました。
55
7. クライアント証明書認証の設定
クライアント証明書を使った認証設定を行います。
7.1. クライアント証明書認証のフロー
以降の BIG-IP 設定で、今どの設定を行っているのかを理解するために、クライアント証明書のフローイメージを示し
ます。
クライアント証明書認証は SSL ハンドシェーク内で行われますが、ここではクライアント証明書認証に関連する部分
のみ抜き出しています。
56
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 を分離します。
57
b)
c)
d)
e)
f)
中間認証局 02 の tbsCertificate のハッシュを計算します。
RSA で署名されている署名値を、中間認証局 01 の公開鍵で復号化し、ハッシュ値を取り出します。
b)と c)で得られたハッシュ値を比較。一致すれば、中間証明書 01 によって、この証明書は改ざんされて
いない＝信頼できるものとして扱われます。
また d)の結果、ABC 社の中間認証局 02 の証明書内の公開鍵も、中間証明書 01 によって、信頼できる
と判断されます。
～ j) は、中間証明書 02 と同様の処理によって、今度は中間証明書 01 がルート証明書によって信頼さ
れます。
この⑧の処理が完了して初めて、abc-client001 のクライアント証明書が信頼されます。
⑨ クライアントは、ここまでの SSL ハンドシェークでやり取りした情報から Certificate Verify 値を生成します。
(SSL ハンドシェークのフローで記載したやり取り部分は、本セクションでは省略していますが、実際のクライアント
証明書認証は一連の SSL ハンドシェークフローの中で行われます。)
⑩ この Certificate Verify 値を、abc-client001 の秘密鍵で暗号化します。
⑪ 暗号化された⑨の値を、サーバへ送ります。
⑫ BIG-IP は、その暗号化された「Certificate Verify」を abc-client001 の公開鍵で復号化します。
⑬ BIG-IP 自身で算出した Certificate Verify と⑫の値を比較して、一致すればクライアント証明書は信頼できる、と
判断されます。
58
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) 以下の状態になります。
59
7.2.1.2. Client SSL Profile の設定変更
クライアント証明書認証を行うためには、Client SSL Profile の設定変更が必要です。
本ガイドでは、ABC 社のクライアントに対してのクライアント証明書認証を行う、というシナリオを想定し、設定済み
の abcCompany-clientssl-profile を利用することにします。
「Local Traffic」→「Profile」→「SSL」タブ→「Client」で表示された画面上の「abcCompany-clientssl-profile」をクリッ
クして現れた画面で、以下のように設定を変更します。
～略～
Require を選択。
ルートを含むチェーン証明書を選択。
中間認証局 02 の証明書を選択。
～略～
60
7.2.1.3. Virtual Server の設定変更
Virtual Server に、ABC 社の Client SSL Profile：abcCompany-clientssl-profile を割り当てます。
～略～
クライアント証明書認証の
設定を行った
Profile を割り当てる。
～略～
61
7.2.2. クライアント証明書をクライアント PC へインポート
生成した abc-client001.p12 を (既述の WinSCP などを利用して)クライアント PC へコピーしてください。
Windows 上のこのファイルをダブルクリックすると、インポートが始まります。
(1) 「次へ」を押してください。
(2) 「次へ」を押してください。
62
(3) パスワードは「f5demo」を入力し、「次へ」を押してください。
設定したパスフレーズ：f5demo を入力。
(4) 「証明書の種類に基づいて～」が選択されていることを確認し、「次へ」を押してください。
(5) 「完了」を押して下さい。
63
(6) 「OK」を押してください。
(7) 以下のように、クライアント証明書がインポートされます。
クライアント証明書がインポートされた状態
クライアント証明書認証設定は以上です。
7.2.3. Windows クライアントからのアクセス
Windows の Web ブラウザ(IE)で「https://www.abc-company.lab」へアクセスすると、以下の画面が出ます。
「OK」を押した後、Web 画面が表示されれば、クライアント証明書認証は成功です。
64
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」
に変更して、同様のステップを繰り返してください。
65
8.1.2. クライアント証明書のインポートと通信確認
(1) 以下のように 3 つのクライアント証明書を一つのクライアント PC にインポートします。
(一つの PC に複数のクライアント証明書をインポートする、ということは一般的にあまり行われないと思いますが、失
効したクライアント証明書でアクセスできず、失効していないクライアント証明書ではアクセスできる、という差を見るこ
とを目的としていますので、このようにしました。)
(2) Web ブラウザで https://www.abc-company.lab へアクセスすると、以下のように証明書の選択を促す画面が出
ます。
それぞれ 3 つのクライアント証明書で通信が成立することを確認してください。
66
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
V 180316073032Z
V 180316073107Z
06
07
08
unknown ～略～/OU=SE/CN=abc-client001.abc-company.lab
unknown ～略～/OU=SE/CN=abc-client002.abc-company.lab
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
67
(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 のコンテンツ用のデフォルトフォルダです。)
68
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-companycrl 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)で、以下のように設定変更します。
～略～
取り込んだ CRL を選択。
～略～
8.1.5. Windows クライアントからのアクセス
クライアント PC からアクセスすると、以下の状態になることを確認してください。
①
②
③
abc-client001 NG
abc-client002 OK
abc-client003 OK
69
8.2. OCSP (Online Certificate Status Protocol)
クライアント証明書が失効されていないかどうかを、OCSP Responder へ問合せる方式です。
BIG-IP は、SSL ハンドシェークの都度、その OCSP Reponder への問合せを実施し、失効しているクライアント証
明書であることが通知されると SSL ハンドシェークを完了させないので、結果、通信できないように制御できます。
OpenSSL は、OCSP Responder としても機能しますので、本ガイドではそれを使います。
70
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
R 180316073032Z
V 180316073107Z
160316073758Z 06 unknown ～略～/OU=SE/CN=abc-client001.abc-company.lab
160316075141Z 07 unknown ～略～/OU=SE/CN=abc-client002.abc-company.lab
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...
71
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」ボタ
ンを押して現れた画面で、以下のように設定します。
名前(任意)を指定。
OCSP Responder を指定。
ルートを含んだチェーン証明書を指定。
(2) OCSP Configuration の設定
「Local Traffic」→「Profiles」→「Authentication」→「Configurations」で表示された画面の右上の「Create」ボタンを
押して現れた画面で、以下のように設定します。
名前(任意)を指定。
SSL OCSP を選択。
生成済みの
OCSP Responder を
「<<」で選択。
72
(3) OCSP Profile の設定
「Local Traffic」→「Profiles」→「Authentication」→「Profiles」で表示された画面の右上の「Create」ボタンを押して
現れた画面で、以下のように設定します。
名前(任意)を指定。
SSL OCSP を選択。
生成済みの OCSP Configuration を選択。
8.2.3.3. Client SSL Profile の設定変更
先のセクションで CRL 設定を行っていますが、OCSP 時には不要です。
よって、利用する Client SSL profile(abcCompany-Clientssl-profile)の CRL 設定を「None」に変更します。
～略～
None を選択。
～略～
73
8.2.3.4. Virtual Server の設定変更
利用する Virtual Server に、生成した OCSP の Authentication Profile を割り当てます。
「Advanced」を選択。
～略～
生成した
OCSP Profile を
選択。
～略～
設定は以上です。
8.2.4. Windows クライアントからのアクセス
クライアント PC からアクセスすると、以下の状態になることを確認してください。
①
②
③
abc-client001 NG
abc-client002 NG
abc-client003 OK
74
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 アクセスも利用可能です。
75
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)
76
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 で接続できることを確認してください。
77
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
R 180316073032Z
V 180316073107Z
R 180316075730Z
V 180316075856Z
160316073758Z 06
unknown ～略～/OU=SE/CN=abc-client001.abc-company.lab
160316075141Z 07
unknown ～略～/OU=SE/CN=abc-client002.abc-company.lab
08
unknown ～略～/OU=SE/CN=abc-client003.abc-company.lab
160316090806Z 09
unknown ～略～/OU=SE/CN=abc-client004.abc-company.lab
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
78
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
79
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」ボタン
を押して現れた画面で、以下のように設定します。
名前(任意)を指定。
LDAP のアドレスを指定。
LDAP を選択(デフォルト)。
LDAP のベースドメイン名を指定。
(2) CRLDP Configuration の設定
「Local Traffic」→「Profiles」→「Authentication」→「Configurations」で表示された画面の右上の「Create」ボタンを
押して現れた画面で、以下のように設定します。
名前(任意)を指定。
CRLDP を選択。
※検証環境用に小さい値を設定。
設定済みの
CRLDP Server を
<<で選択。
※デフォルトでは、取り込んだ CRL を 24 時間キャッシュする設定になっていますが、そのままだと検証環境では
CRLDP の設定変更後の挙動を即座に確認しにくいので、小さめの値にしています。
80
(3) CRLDP Profile の設定
「Local Traffic」→「Profiles」→「Authentication」→「Profiles」で表示された画面の右上の「Create」ボタンを押して
現れた画面で、以下のように設定します。
名前(任意)を指定。
CRLDP を選択。
設定済みの CRLDP Configuration を選択。
81
8.3.4.2. Virtual Server の設定変更
Virtual Server に、生成した CRLDP の Authentication Profile を割り当てます。
「Advanced」を選択。
～略～
生成した
CRLDP Profile を
選択。
～略～
82
8.3.4.3. Hosts の登録
CRLDP に指定した FQDN を Hosts に登録します。
(DNS 解決ができる環境においては、この設定は不要です。)
「System」→「Configuration」→「Device」→「Hosts」で現れた画面で、以下のように設定します。
IP Address と
Hostname を指定して
「Add」ボタンを押して登録。
8.3.5. Windows クライアントからのアクセス
クライアント PC からアクセスすると、以下の状態になることを確認してください。
①
②
③
④
⑤
abc-client001
abc-client002
abc-client003
abc-client004
abc-client005
NG
NG
NG
NG
OK
クライアント証明書が CRLDP 情報を持っていないため
〃
〃
CRLDP から失効が通知されたため
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"
83
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 ネットワークスジャパンのエンジニアが特定のソフトウェアバージョンの動作仕様に基づいて作成した構築・設計を補助するための資
料であり、メーカー公式資料とは異なります。資料の記載内容に誤りがあった際には指摘に基づいて修正を行いますが、内容についての責任は一
切負いません。また、修正、変更、改訂は予告無く行われます。
84
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 関数で使うハッシュ方式の意味も持っています。
85
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」のべき乗で元の数字に戻ります。
86
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=3 とすると、3×(3-1)×(11-1) + 1 = 61
n=4 とすると、4×(3-1)×(11-1) + 1 = 81
(n を増やせば、21 以外にも該当する値がある)
(同上)
(同上)
10.2.4. RSA による署名
RSA は、この「ある法の世界で、暗号化対象のメッセージに、いくらの数のべき乗を行えば再び元のメッセージに戻
るか？」の"べき乗"を秘密にするのがポイントです。
この法則を使って、RSA では以下の形が定義されています。
(me)d mod n = m
(md)e mod n = m
n：
e：
d：
m：
法(素数 P×Q)
公開鍵
秘密鍵
メッセージ
「n」を法とする世界で、メッセージ「m」を「e×d」(または「d×e」)でべき乗したら、元のメッセージ「m」に戻る、という形
が定義されています。
よって、この「m」のべき乗数「e×d」は、2 つの数の掛け算として成り立つ必要があります。
法を「33」とするこの例では、「21」が 3×7 で成り立つので、3 か 7 のどちらかを公開鍵、どちらかを秘密鍵として利
用します。
ここでは、以下とします。
「7」が秘密鍵
「3」が公開鍵
法
元メッセージ
d=7
e=3
n=33 ←これも公開されます。
m=14
87
以下のフローを使って、説明します。
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩
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 社の公開鍵も信頼されます。
88
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)
89
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
90
10.4. DHE-RSA の SSL ハンドシェークフロー
プリマスターシークレットの交換に DHE と、署名に RSA を使った、具体的な SSL ハンドシェークフローを示します。
91
上図の SSL ハンドシェークのところから解説します。
① クライアントからの Client Hello にて、主に以下 2 つの情報がサーバ (BIG-IP) へ送られます。
A)
B)
クライアントがサポートしている暗号アルゴリズムのリスト
クライアントが生成したランダムな値 (クライアントランダム)
② BIG-IP からの Server Hello にて、主に以下 2 つの情報がクライアントへ送られます。
A)
B)
クライアントから提示された暗号アルゴリズムの中から一つ選んだ暗号アルゴリズム
ここでは「DHE-RSA-AES128-SHA256」が選択された、とします。
サーバが生成したランダムな値 (サーバランダム)
③ 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 のパラメータを使って図中の計算を行い、
同じ結果を得ます。
これで、プリマスターシークレットの共有が出来ました。
92
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 が使われます。
93
10.6. PRF (P_SHA256) のフロー
以下の図を用いて、「マスターシークレット」および「キーブロック」を生成するまでのフローを示します。
94
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 の計算が行われます。
⑦
～ ⑪まで、類似の処理が繰り返されます。
⑫
キーブロックが必要な長さになるまで、同様の処理が繰り返されます。
95
10.6.3. キーブロックの内容
生成されたキーブロックの内容は以下のようになっています。
10.6.3.1. MAC Key
暗号化されたデータの改ざんを検知する目的の値：MAC (Message authentication code) を算出するために使わ
れる鍵です。
今回選定している暗号スイートでは SHA256 が使われるので、32byte(256bit)の MAC Key がクライアント用とサ
ーバ用にそれぞれ一つずつ生成されます。
①
②
client write MAC key
server write MAC key
32byte (256bit)
32byte (256bit)
HMAC-SHA256 用
〃
MAC の生成については、後述します。
10.6.3.2. Encryption key
AES 暗号に使う鍵です。今回選定している暗号スイートでは AE128 が使われるので、16Byte(128it)の暗号鍵がク
ライアント用とサーバ用にそれぞれ一つずつ生成されます。
①
②
client write encryption key
server write encryption key
16byte (128bit)
16byte (128bit)
AES128 用
〃
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
server write Initial Vector
16byte (128bit)
16byte (128bit)
AES128-CBC 用
〃
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.
96
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 を例に解説します。
97
① プリマスターシークレットが 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 処理の繰り返しで構成されています。
98
10.7. データの生成
ここまでの処理で、暗号化に使う鍵は全て生成されました。
このセクションでは、それらの鍵の暗号化対象となるデータを作るまでの流れを示します。
暗号化されるデータは、改ざん検知のために、MAC(Message Authentication Code) という値をつける処理が行わ
れます。
クライアントから出力されるデータの例：
①
SSL より上位の層 (アプリケーション層) から受け取ったデータは、TLSPlaintext という構造の中に入れられま
す。
②
TLSPlaintext のデータ部が圧縮されて、TLSCompressed という構造の中に入れられます。
(圧縮方法は Client Hello/Server Hello 内でネゴシエーションされます。)
③
PRF (既述) によって生成された Client MAC key です。MAC を生成するための HMAC-SHA256 の一つ目の
入力値として利用されます。
④
TLSCompressed に対して、シーケンス番号 (データ送出バイト数のカウント) が付与されたものが、HMACSHA256 の 2 つ目の入力値です。
99
(シーケンス番号＝データ送出バイト数のカウントは、送信側と受信側しか知りえない情報であることから、認証の
役割も果たしています。)
⑤
③と④を入力値として、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 による暗号化通信です。
100
10.8. AES 暗号
生成した TLS Ciphertext を、AES で暗号化して送り出すまでの処理フローを示します。
ざっくりいうと、AES は「鍵を XOR で加えながら、データをかき混ぜる」という感じです。
10.8.1. AES128-CBC 暗号データの送出フロー
以下は、クライアントからサーバへ AES 暗号化されたデータを送りだすまでの処理の例です。
101
① 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 がサーバに送られます。
102
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 列目だけは、やや複雑な処理がなされます。
103
①
②
③
④
⑤
⑥
⑦
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 が完成しました。
104
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 個生成します。
105
10.8.4. AddRoundkey
AES 暗号前のデータと、Encryption Key で、単純に XOR を算出します。
10.8.5. SubBytes
S-box 表を使って、対応する値に変換します。
10.8.6. ShiftRows
以下のように Byte 単位でずらします。
106
10.8.7. MixColumns
ある表 (Circulant MDS Matrix) との掛合せを行う処理です。
上記 3 つの処理と異なり、これだけはちょっとややこしいです。
10.8.7.1. 算出方法
MixColumns の一つ目の値の算出例を示します。
例えば、{2.d4} は、d4 に 2 をかける、という意味合いではあるのですが、単純に 2 倍、という処理ではなく、以下の
ような計算が必要です。
(1) {2.d4}
① d4 を bit 列にします。
d4=
② 左へ 1bit シフトして、後ろに”0”を足します。
11010100
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}
107
④ {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
108
10.8.8. AES128-CBC 暗号データの受信フロー
サーバが、クライアントからの AES 暗号データを受け取った際の復号処理フローです。
概ね「暗号化と逆の処理を行うことで復号化する」という感じですが、InvSubBytes や InvMixColumns については、
復号用のものを使います。
(下図は、下から上への流れになっています。)
109
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
110
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
111
(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
112
(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
113
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
-newkey rsa:2048
-nodes
-sha256
-keyout ./SERVER/abcCompany-key.pem
-out ./SERVER/abcCompany-req.pem
-subj
"/C=JP/ST=Kanagawa/L=Yokohama/O=ABCCompany, Ltd./OU=IT/CN=www.abccompany.lab"
解説
署名リクエスト(CSR)を新規に生成する。
RSA の鍵長 2048bit の鍵を新しく生成する。
鍵をパスフレーズで暗号化しない。
署名リクエストに対して、SHA256 でダイジェスト(ハッシュ値)を出力
する。
鍵をファイル出力する。
署名リクエスト(CSR)をファイル出力する。
署名リクエストに記載する値を指定する：
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
-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
解説
署名リクエスト(CSR)に署名する。
署名時のダイジェスト(ハッシュ値)に SHA256 を使う。
入力ファイルとして、署名リクエスト(CSR)を指定。
署名を行う認証局の秘密鍵を指定。
証明書をファイル出力する。
証明書の拡張領域に、openssl.cnf 内の[v3_ca]に記載された内容を
追加する。
作成時の「Yes/No?」といった質問形式を省く。
openssl.cnf 内の[policy_anything]に記載されたポリシーに従う。
※
デフォルトの openssl.cnf ではなく、編集した別名のコンフィグファイ
ルを使いたい場合の指定。
有効期限を 3650 日(10 年間)とする指定。
114
※ 「"-policy policy_anything"」オプションについて
デフォルトでは、countryName(国名), stateOrProvinceName(都道府県), organizationName(組織名)が、認証局
の証明書と署名リクエストで同じ値でなければ受け付けてくれない設定になっています。
# vi /etc/pki/tls/openssl.cnf
<<デフォルト >>
[ policy_match ]
countryName
stateOrProvinceName
organizationName
organizationalUnitName
commonName
emailAddress
=
=
=
=
=
=
match
match
match
optional
supplied
optional
"-policy policy_anything"のオプション指定を行うことで、openssl.cnf 内の以下のポリシーが適用されるの
で、国名や県名が認証局と一致しなくても証明書が生成できます。
[ policy_anything ]
countryName
stateOrProvinceName
localityName
organizationName
organizationalUnitName
commonName
emailAddress
=
=
=
=
=
=
=
optional
optional
optional
optional
optional
supplied
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]に記載された内
容を追加する。
以上
115
© Copyright 2024 Paperzz
