SSL/TLS - F5 Networks...2016/04/09 · 3 1. はじめにこのガイドでは、クライアント～BIG-IP 間でSSL/TLS 通信を行うための設定方法を解説します。

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)


countryName 国 JP

stateOrProvinceName 都道府県 Saitama

localityName 区市町村 Soka

organizationName 会社名 InterCA01, Ltd.

organizationalUnitName 組織名 ICA01

commonName 名称 ica.interca01.local

(3) 中間認証局 (InterCA02)


countryName 国 JP

stateOrProvinceName 都道府県 Chiba

localityName 区市町村 Funabashi

organizationName 会社名 InterCA02, Ltd.

organizationalUnitName 組織名 ICA02

commonName 名称 ica.interca02.local

(4) サーバ証明書の所有者 (ABC-Company)


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)の秘密鍵や証明書を保存するためのフォルダを生成します。


# 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


Signature ok



Validity


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:


7B:19:81:D8:B6:27:71:C1:8B:05:69:E9:B0:05:20:05:81:B7:EC:5C


keyid:AD:97:0E:CA:C3:1E:75:98:0B:87:1A:26:A4:44:C7:C8:BF:75:C2:71


CA:TRUE

12



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







certificate = $dir/interCA01crt.pem # The CA certificate





private_key = $dir/private/interCA01key.pem # The private key


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」とします。


⑥ そのハッシュ値を、中間認証局 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


Signature ok



Validity


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:


27:D4:C0:71:A5:7E:7F:41:9D:BE:9E:AB:60:07:70:69:0D:BD:8B:8D


keyid:7B:19:81:D8:B6:27:71:C1:8B:05:69:E9:B0:05:20:05:81:B7:EC:5C


CA:TRUE

15



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







certificate = $dir/interCA02crt.pem # The CA certificate





private_key = $dir/private/interCA02key.pem # The private key


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に送ります。





⑦ 「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 \




Signature ok



Validity


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:


CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate


FB:17:4B:4F:5A:01:DA:8F:8F:23:E0:5A:F4:2F:0B:1D:4F:7A:E2:19


keyid:27:D4:C0:71:A5:7E:7F:41:9D:BE:9E:AB:60:07:70:69:0D:BD:8B:8D



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の証明書をインポートします。



(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にインポートします。



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」ボタンを押して現れた画面で、

以下のように設定します。

～略～

任意の名称を入力。

インポートしたサーバ証明書と秘密鍵および

チェーンとなるバンドル証明書を選択し、


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用サーバ証明書の生成に、以下の値を利用することにします。


countryName 国 JP



organizationName 会社名 ABC000-Company, Ltd.


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 を別途作っておき、それを編集することにします。


# 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



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 \


-config ./openssl-interCA02-san.cnf -extensions v3_req

Using configuration from ./openssl-interCA02-san.cnf


Signature ok



39

Validity


Not After : Mar 16 06:56:31 2017 GMT

Subject:

countryName = JP



organizationName = ABC000-Company, Ltd.

organizationalUnitName = IT

commonName = www.abc000-company.lab

X509v3 extensions:


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



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の設定が

必要です。



～略～





42

5.3.6. Virtual Serverの設定変更

SAN付 Client SSL Profile を Virtual Serverに割り当てます。

「Local Traffic」→「Virtual Servers」で表示された画面で、該当する VSをクリックして、以下のように設定変更しま

す。

～略～

生成した SAN用の

Client SSL Profile

を指定。

43


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つの証明書を作ります。


countryName 国 JP



organizationName 会社名 def123-Company, Ltd.


commonName 名称 www.def123-company.lab


countryName 国 JP







countryName 国 JP






45

5.4.1. SNIサーバ証明書の生成

ABC社のサーバ証明書生成したときと同様の方法で、上記の値を使って 3つ作ります。

SAN と違い、SNI を行う場合においてはサーバ証明書に特別な指定は必要ありません。

(1) 現在のフォルダを確認

# pwd


(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 \








② CSR へ署名









② CSRへ署名




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 を作ります。



～略～

[参考] SNIのベースプロファイルはなぜ必要か？

ベースプロファイルを生成しなくても、デフォルトの clientsslプロファイルを利用することで動作はします。

しかし、何らか設定変更を行いたい場合に、この Base を変更して全体に反映する必要があるので、作っておいたほ

うがよいです。

例えば、SNIの状態でクライアント証明書認証を行いたい場合、以降で設定する、一つ一つ個別のプロファイルの設

定変更はできないので、ベースプロファイルの設定を変更して、全プロファイルに反映する必要があります。

名前(任意)を指定。

48

5.4.3.2. SNIの fallback用プロファイル

SNI指定できないブラウザからのアクセスの際に利用されます。

本ガイドでは、ABC社の証明書を利用することにします。

～略～

～略～


生成済みのベースプロファイルを選択。




Advanced を選択。

←チェックを入れる

49

5.4.3.3. def123社/def456社/def789社用プロファイル

SNI用の Client SSL profileには、以下のように Server Nameに FQDN を入力します。

(1) def123社用

～略～

～略～

(2) def456社用

～略～

～略～







FQDNを入力。







FQDNを入力。

50

(3) def789社用

～略～

～略～







FQDNを入力。

51

5.4.4. Virtual Serverの設定変更

SNI用に作成したプロファイル 3つと、Fallback用プロファイルの合計 4つを、Virtual Serverの SSL Profile

(Client)に設定します。

～略～

生成した SNI用の

Client SSL Profile

を指定。

52


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に送ります。





⑦ 「tbsCertificate」と署名を一まとまりにしたものが、abc-client001のクライアント証明書です。

⑧ 中間認証局 02は、そのクライアント証明書を ABC社へ送ります。

⑨ ABC社は、abc-client001用の証明書と秘密鍵を、Windowsへインポートしやすいように、PKCS#12形式に変

換し、Windows PCへインポートします。

54

本ガイドでは、クライアント証明書の生成に、以下の値を利用することにします。


countryName 国 JP



organizationName 会社名 ABC-Company, Ltd.

organizationalUnitName 組織名 Systems Engineer

commonName 名称 abc-client001.abc-company.lab

6.1. クライアント証明書向けフォルダの生成

クライアント PCの秘密鍵や証明書を生成するためのフォルダおよびファイルを生成します。


# pwd


(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 \




Signature ok



Validity


Not After : Mar 16 07:19:30 2018 GMT

Subject:

countryName = JP




55

organizationalUnitName = SE

commonName = abc-client001.abc-company.lab

X509v3 extensions:


CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate


77:88:B1:3F:2B:15:86:8B:E2:98:2B:75:8A:67:87:0A:1E:21:58:80


keyid:27:D4:C0:71:A5:7E:7F:41:9D:BE:9E:AB:60:07:70:69:0D:BD:8B:8D



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. 「クライアント証明書認証の事前準備」を行う

クライアント証明書認証に必要な設定を行っていきます。


本ガイドでは、まずクライアント 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つのクライアント証明書で通信が成立することを確認してください。

https://www.abc-company.com/

67

8.1.3. クライアント証明書の失効

OpenSSLで、クライアント証明書を失効させます。

8.1.3.1. フォルダとファイルの生成


# pwd


(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



(2) 失効処理(abc-client001)

例えば、abc-client001を失効してみます。

# openssl ca -revoke ./CLIENT/abc-client001-crt.pem -config ./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



(4) CRLの生成

以下のコマンドで CRLを生成します。

# openssl ca -gencrl -out ./crl/list.crl -config ./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


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


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


ABC社の Client SSL Profile(abcCompany-clientssl-profile)で、以下のように設定変更します。

～略～

～略～


クライアント 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でもう一つクライアント証明書

を失効させます。


# pwd



例えば、abc-client002 も失効させます。


(3) 失効処理後の index.textの確認

# cat index.txt

～略～




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


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」ボタンを押して

現れた画面で、以下のように設定します。


先のセクションで CRL設定を行っていますが、OCSP時には不要です。

よって、利用する Client SSL profile(abcCompany-Clientssl-profile)の CRL設定を「None」に変更します。

～略～

～略～


SSL OCSPを選択。

生成済みの OCSP Configuration を選択。

None を選択。

74


利用する Virtual Serverに、生成した OCSPの Authentication Profileを割り当てます。

～略～

～略～

設定は以上です。



① 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 を編集します。


# pwd


(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の生成

① 環境変数


② 秘密鍵を署名リクエスト(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



Signature ok



77

Validity


Not After : Mar 16 07:57:30 2018 GMT

Subject:

countryName = JP




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



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に変更して、もう一つ同様のクライアント証明書を作ります。


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 を失効させることにします。


abc-client004を失効させます。


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

～略～





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


(4) CRLの内容確認

CRLの中身は以下のコマンドで確認できます。

以下はシリアル番号が 06,07,09のユーザが失効している状態を表しています。

# openssl crl -in ./crl/list.crl -text

Certificate Revocation List (CRL):

Version 2 (0x1)


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


Serial Number: 07

79


Serial Number: 09


～略～

(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


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


Virtual Serverに、生成した CRLDPの Authentication Profile を割り当てます。

～略～

～略～

「Advanced」を選択。

生成した

CRLDP Profile を

選択。

83

8.3.4.3. Hostsの登録

CRLDPに指定した FQDN を Hostsに登録します。

(DNS解決ができる環境においては、この設定は不要です。)

「System」→「Configuration」→「Device」→「Hosts」で現れた画面で、以下のように設定します。



① 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ネットワークスジャパンのエンジニアが特定のソフトウェアバージョンの動作仕様に基づいて作成した構築・設計を補助するための資

料であり、メーカー公式資料とは異なります。資料の記載内容に誤りがあった際には指摘に基づいて修正を行いますが、内容についての責任は一

切負いません。また、修正、変更、改訂は予告無く行われます。

https://f5.com/jp/homepage

http://support.f5.com/kb/en-us.html

https://devcentral.f5.com/

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


changetype: modify

replace: olcRootDN

olcRootDN: cn=Manager,dc=f5jp,dc=local


changetype: modify

add: olcRootPW

olcRootPW: {SSHA}ILiSLLyrQY7tW4wqEB3ClDNX2MH4j83h ※ここに(1)の値を Copy&Paste。


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"



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 \



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 \


-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]に記載された内

容を追加する。

以上

Documents

SSL/TLS - F5 Networks...2016/04/09 · 3 1. はじめに このガイドでは、クライアント～BIG-IP 間でSSL/TLS 通信を行うための設定方法を解説します。

SSL/TLS - F5 Networks...2016/04/09 · 3 1. はじめにこのガイドでは、クライアント～BIG-IP 間でSSL/TLS 通信を行うための設定方法を解説します。