1

Transcription

1 SSL/TLS 設定ガイド (v 対応 ) [ 基本編 ] サーバ証明書 / クライアント証明書認証 F5 Networks Japan V1.0

2 目次 1. はじめに ネットワーク構成サンプル ルート / 中間 / サーバ証明書の生成 デジタル証明書の連鎖 本ガイドで使う証明書の値 ルート認証局 (F5J-CA) の生成 中間認証局 01(InterCA01) の生成 中間認証局 02(InterCA02) の生成 ABC 社の秘密鍵とサーバ証明書の生成 BIG-IP の基本設定 Platform 設定 VLAN 設定 Self IP の設定 Routing 設定 NTP の設定 サーバ証明書関連の設定 SSL ハンドシェークフロー ( 例 :RSA 鍵交換 ) SSL ハンドシェークの事前準備 を行う SAN (Subject Alternative Name) の設定 SNI (Server Name Indication) の設定 クライアント証明書の生成 クライアント証明書向けフォルダの生成 クライアント証明書の署名リクエスト (CSR) の生成 中間認証局 02 によるクライアント署名リクエスト (CSR) への署名 クライアント証明書のフォーマット変換 クライアント証明書認証の設定 クライアント証明書認証のフロー クライアント証明書認証の事前準備 を行う クライアント証明書の失効管理 CRL (Certificate Revocation List) OCSP (Online Certificate Status Protocol) CRLDP (Certificate Revocation List Distribution Point) おわりに [Appendix.1] SSL 暗号を できるかぎり ひも解く 暗号スイート (Cipher Suite) RSA とは Diffie-Hellman とは DHE-RSA の SSL ハンドシェークフロー キーブロックの生成 PRF (P_SHA256) のフロー データの生成 AES 暗号 [Appendix.2] OpenLDAP の設定 OpenLDAP のインストールと起動 管理者パスワードの設定 ドメインの設定 [Appendix.3] OpenSSL コマンドのオプション解説 署名リクエスト (CSR) と鍵の生成時のオプション 署名時のオプション Ⅹ

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 コマンドのオプション解説 に記載していますので 必要に応じてご参照ください 3

4 2. ネットワーク構成サンプル 以下のネットワーク構成を使って SSL 動作を確認します のサーバ (CentOS6.7) 上の OpenSSL を使って デジタル証明書を生成します クライアント証明書認証の CRL による失効管理の際の CRL ファイル転送用に Apache(Web サーバ ) を使います クライアント証明書認証の CRLDP による失効管理の際に OpenLDAP を使います 4

5 3. ルート / 中間 / サーバ証明書の生成 まず ルート証明書 中間証明書 サーバ証明書およびそれぞれの秘密鍵を生成します 3.1. デジタル証明書の連鎖以下は 秘密鍵とデジタル証明書の連鎖の様子を示しています ABC 社は 中間認証局である InterCA02 にサーバ証明書の発行を依頼した と仮定します この証明書は 上図のような署名の連鎖によって信頼されます [ 解説 ] 1 ABC 社の秘密鍵は ABC 社の公開鍵と対を成しています 2 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 つで構成されています 1 認証局業務の開示 2 サービスインテグリティ ( サービスの完全性 ) 3 認証局環境の統制 ( コントロール ) この厳しい基準をクリアしたルート認証局 ( 例 :Verisign や CyberTrust など ) のルート証明書が 事前に Web ブラウザにインストールされています 以降 このデジタル証明書の連鎖の通りに OpenSSL を使って証明書を生成していきます 5

6 3.2. 本ガイドで使う証明書の値 証明書を生成する際に利用する各値は 以下としました (1) ルート認証局 (F5J-CA) OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Tokyo localityname 区市町村 Minato-ku organizationname 会社名 F5J-CA, Ltd. organizationalunitname 組織名 CA commonname 名称 f5jca.f5jp.local (2) 中間認証局 (InterCA01) OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Saitama localityname 区市町村 Soka organizationname 会社名 InterCA01, Ltd. organizationalunitname 組織名 ICA01 commonname 名称 ica.interca01.local (3) 中間認証局 (InterCA02) OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Chiba localityname 区市町村 Funabashi organizationname 会社名 InterCA02, Ltd. organizationalunitname 組織名 ICA02 commonname 名称 ica.interca02.local (4) サーバ証明書の所有者 (ABC-Company) OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Kanagawa localityname 区市町村 Yokohama organizationname 会社名 ABC-Company, Ltd. organizationalunitname 組織名 IT commonname 名称 6

7 3.3. ルート認証局 (F5J-CA) の生成 まず ルート認証局の秘密鍵と証明書を生成します 以下はその生成フローのイメージです 1 ルート認証局は 自身の秘密鍵を生成します (cakey.pem) 2 ルート認証局は 自身の署名リクエスト (CSR) を生成します (careq.pem) 3 ルート認証局は 署名リクエスト (CSR) に対して 署名を行う認証局の情報 ( ルート認証局自身の情報 ) や有効期間などを追加して それを tbscertificate とします 4 この tbscertificate を SHA-2 を使ってハッシュ値を計算します 5 そのハッシュ値を ルート認証局の秘密鍵を使って RSA で暗号化します これが署名です 6 tbscertificate に署名を加えたものが ルート認証局の証明書になります 7

8 ルート認証局向けファイルの生成 ルート認証局の秘密鍵や証明書を生成する際に必要なファイルを生成します デフォルトのフォルダを確認 本ガイドでは 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 ~ 略 ~ /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 root root 4096 Jan 9 03:43 private ファイルの生成 自己署名による証明書発行に必要なシリアル番号およびインデックス管理のためのファイルを生成します 以下のコマンドを実行します (1) CA 用のフォルダへ移動 # cd /etc/pki/ca/ (2) ファイルの生成 # echo "01" >./serial :openssl が利用する シリアル番号管理のためのファイル # touch./index.txt :openssl が利用する インデックス管理のためのファイル 8

9 ルート認証局の秘密鍵および署名リクエスト 認証局の秘密鍵および署名リクエスト (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" ルート認証局による自己署名 ルート認証局の証明書に自己署名します 以下のコマンドを実行します # 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: GMT Not After : Mar 14 06:21: 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: GMT (3650 days) Write out database with 1 new entries Data Base Updated これでルート認証局の生成は完了です 9

10 3.4. 中間認証局 01(InterCA01) の生成 ルート認証局から見て一段目の 中間認証局 01 の秘密鍵と証明書を生成します 以下はその生成フローイメージです 1 中間認証局 01 は 自身の秘密鍵を生成します (interca01key.pem) 2 中間認証局 01 は 自身の署名リクエスト (CSR) を生成します (interca01req.pem) 3 中間認証局 01 は 署名リクエスト (CSR) をルート認証局に送ります 4 ルート認証局は 署名リクエスト (CSR) に対して 署名を行う認証局の情報 ( ルート認証局自身の情報 ) や有効期間などを追加して それを tbscertificate とします 5 この tbscertificate を SHA-2 を使ってハッシュ値を計算します 6 そのハッシュ値を ルート認証局の秘密鍵を使って RSA で暗号化します これが署名です 7 tbscertificate と署名を一まとまりにしたものが 中間認証局 01 の証明書になります 8 ルート認証局は その証明書を中間認証局 01 へ送ります 10

11 中間認証局 01 向けフォルダの生成 中間認証局 01(interCA01) の秘密鍵や証明書を保存するためのフォルダを生成します (1) 現在のフォルダの確認 # pwd /etc/pki/ca (2) フォルダの生成 本ガイドではこの /etc/pki/ca の下に interca01 向けのフォルダを作ることにします 以下のコマンドを実行します # mkdir./interca01 # mkdir./interca01/private # mkdir./interca01/newcerts 中間認証局 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" 中間認証局 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: GMT Not After : Mar 14 06:26: 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

12 Certificate is to be certified until Mar 14 06:26: GMT (3650 days) Write out database with 1 new entries Data Base Updated これで中間認証局 01 の生成は完了です 中間認証局 01 専用の openssl.cnf の生成 以降の中間認証局 02 の生成の際に利用する 中間認証局 01 専用の openssl.cnf を作っておきます 1 デフォルトの openssl.cnf をコピーします # cp /etc/pki/tls/openssl.cnf./interca01/openssl-interca01.cnf 2 以下の赤文字部分の通りに編集します # vi./interca01/openssl-interca01.cnf [ CA_default ] dir = /etc/pki/ca/interca01 # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. #unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/interca01crt.pem # The CA certificate serial = $dir/serial # The current serial number crlnumber = $dir/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/private/interca01key.pem # The private key RANDFILE = $dir/private/.rand # private random number file 中間認証局 01 専用のシリアル / インデックス管理用ファイルの生成 以降の中間認証局 02 の生成の際に利用する 中間認証局 01 専用のシリアル番号およびインデックス管理のためのファイルを生成します 以下のコマンドを実行します # echo "01" >./interca01/serial :openssl が利用する シリアル番号管理のためのファイル # touch./interca01/index.txt :openssl が利用する インデックス管理のためのファイル 12

13 3.5. 中間認証局 02(InterCA02) の生成 ルート認証局から見て二段目の 中間認証局 02 の秘密鍵と証明書を生成します 以下はその生成フローイメージです 1 中間認証局 02 は 自身の秘密鍵を生成します (interca02key.pem) 2 中間認証局 02 は 自身の署名リクエスト (CSR) を生成します (interca02req.pem) 3 中間認証局 02 は 署名リクエスト (CSR) を中間認証局 01 に送ります 4 中間認証局 01 は 署名リクエスト (CSR) に対して 署名を行う認証局の情報 ( 中間認証局 01 自身の情報 ) や有効期間などを追加して それを tbscertificate とします 5 この tbscertificate を SHA-2 を使ってハッシュ値を計算します 6 そのハッシュ値を 中間認証局 01 の秘密鍵を使って RSA で暗号化します これが署名です 7 tbscertificate と署名を一まとまりにしたものが 中間認証局 02 の証明書になります 8 中間認証局 01 は その証明書を中間認証局 02 へ送ります 13

14 中間認証局 02 向けフォルダの生成 中間認証局 02(interCA02) の秘密鍵や証明書を保存するためのフォルダを生成します (1) interca01 フォルダへ移動 # cd /etc/pki/ca/interca01 (2) フォルダおよびファイルの生成 本ガイドではこの /etc/pki/ca/interca01 の下に interca02 向けのフォルダを作ることにします 以下のコマンドを実行します # mkdir./interca02 # mkdir./interca02/private # mkdir./interca02/newcerts 中間認証局 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" 中間認証局 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: GMT Not After : Mar 14 06:32: 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

15 Certificate is to be certified until Mar 14 06:32: GMT (3650 days) Write out database with 1 new entries Data Base Updated これで中間認証局 02 の生成は完了です 中間認証局 02 専用の openssl.cnf の生成 以降のサーバ証明書やクライアント証明書の生成の際に利用する 中間認証局 02 専用の openssl.cnf を作っておきます 1 デフォルトの openssl.cnf をコピーします # cp /etc/pki/tls/openssl.cnf./interca02/openssl-interca02.cnf 2 以下の赤文字部分の通りに編集します # vi./interca02/openssl-interca02.cnf [ CA_default ] dir = /etc/pki/ca/interca01/interca02 # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. #unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/interca02crt.pem # The CA certificate serial = $dir/serial # The current serial number crlnumber = $dir/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/private/interca02key.pem # The private key RANDFILE = $dir/private/.rand # private random number file 中間認証局 02 専用のシリアル / インデックス管理用ファイルの生成 以降のサーバ証明書およびクライアントの生成の際に利用する 中間認証局 02 専用のシリアル番号およびインデックス管理のためのファイルを生成します 以下のコマンドを実行します # echo "01" >./interca02/serial :openssl が利用する シリアル番号管理のためのファイル # touch./interca02/index.txt :openssl が利用する インデックス管理のためのファイル 15

16 3.6. ABC 社の秘密鍵とサーバ証明書の生成 ABC 社の秘密鍵とサーバ証明書を生成します 以下はその生成フローイメージです 1 ABC 社は 自身の秘密鍵を生成します (abccompany-key.pem) 2 ABC 社は 自身の署名リクエスト (CSR) を生成します (abccompany-req.pem) 3 ABC 社は 署名リクエスト (CSR) を中間認証局 02 に送ります 4 中間認証局 02 は 署名リクエスト (CSR) に対して 署名を行う認証局の情報 ( 中間認証局 02 自身の情報 ) や有効期間などを追加して それを tbscertificate とします 5 この tbscertificate を SHA-2 を使ってハッシュ値を計算します 6 そのハッシュ値を 中間認証局 02 の秘密鍵を使って RSA で暗号化します これが署名です 7 tbscertificate と署名を一まとまりにしたものが ABC 社のサーバ証明書になります 8 中間認証局 02 は そのサーバ証明書を ABC 社へ送ります 16

17 サーバ証明書用のフォルダの生成 サーバ証明書や秘密鍵を保存するために必要なフォルダを生成します (1) interca02 フォルダへ移動 # cd /etc/pki/ca/interca01/interca02 (2) サーバ証明書用フォルダの生成 # mkdir./server 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= 認証局による署名リクエスト (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: GMT Not After : Mar 14 06:37: GMT Subject: countryname = JP stateorprovincename = Kanagawa localityname = Yokohama organizationname = ABC-Company, Ltd. organizationalunitname = IT commonname = 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: GMT (3650 days) Write out database with 1 new entries Data Base Updated これで サーバ証明書の生成は完了です 17

18 4. BIG-IP の基本設定 本ガイドのネットワーク構成サンプルに合わせて まず BIG-IP のネットワーク等の基本的な部分を設定します 4.1. Platform 設定 以下は 初期ウィザードの流れの中で設定します 設定した内容は System Platform で確認できます ホスト名 FQDN 形式で指定 Asia/Tokyo を選択 CLI アクセス用 root アカウントのパスワード WebUI アクセス用 admin アカウントのパスワード 4.2. VLAN 設定 Network VLANs で 以下の状態になるように設定します 18

19 4.3. Self IP の設定 Network Self IPs で 以下の状態になるように設定します 4.4. Routing 設定 Network Routes で 以下の状態になるように設定します 4.5. NTP の設定 OpenSSL サーバとの時刻を合わせておきます System Configuration Device NTP で表示された画面で 以下のように設定します NTP サーバのアドレスを指定して Add ボタンを押す 19

20 5. サーバ証明書関連の設定 サーバ証明書を使った SSL 通信を行うための設定を行います 5.1. SSL ハンドシェークフロー ( 例 :RSA 鍵交換 ) 以降の BIG-IP 設定で 今どの設定を行っているのかを理解するために まず RSA 鍵交換を使った場合の SSL ハンドシェークのイメージを示します 20

21 SSL ハンドシェークの事前準備 SSL ハンドシェークが行えるようにするためには 大きくは以下の 5 つの設定が必要です 1 クライアント PC 上に ルート認証局 (F5J-CA) の証明書をインポートします (Verisign や CyberTrust など 正規の認証局から発行された証明書であれば Web ブラウザにプリインストールされているので このステップは不要です ) 2 BIG-IP に ABC 社の秘密鍵をインポートします 3 BIG-IP に 中間認証局 02 が署名した ABC 社のサーバ証明書をインポートします 4 BIG-IP に 中間認証局 01 と 02 の証明書をインポートします 5 BIG-IP に ABC 社のサーバ証明書と中間認証局 (01 と 02) の証明書を同時にクライアントに送れるように設定します SSL ハンドシェーク (RSA 鍵交換の場合 ) 事前準備が完了していれば 以降は自動的に行われるフローですが この事前準備が何のために必要なのかを理解するために SSL ハンドシェークフローの概要を記載しておきます 1 クライアントからの Client Hello にて 主に以下 2 つの情報がサーバ (BIG-IP) へ送られます A) クライアントがサポートしている暗号アルゴリズムのリスト B) クライアントが生成したランダムな値 ( クライアントランダム ) 2 BIG-IP からの Server Hello にて 主に以下 2 つの情報がクライアントへ送られます A) クライアントから提示された暗号アルゴリズムの中から一つ選んだ暗号アルゴリズム B) サーバが生成したランダムな値 ( サーバランダム ) 3 BIG-IP から 中間証明書 01, 中間証明書 02, ABC 社のサーバ証明書がクライアントへ送られます 4 クライアントは ABC 社のサーバ証明書から tbccertificate と署名を分離します 5 ABC 社の tbscertificate のハッシュを計算します 6 ABC 社の RSA で署名されている署名値を 中間認証局 02 の公開鍵で復号化し ハッシュ値を取り出します 7 5 と 6 で得られたハッシュ値を比較 一致すれば この証明書は改ざんされていないものとして 中間認証局 02 の証明書によって 証明されます 8 また 7 の結果 ABC 社のサーバ証明書内の公開鍵も中間認証局 02 の証明書によって 信頼できると判断されます 9 今度は下図のように 中間証明書 02 中間証明書 01 が信頼できるか の検証が行われます 21

22 a) 中間認証局 02 の中間証明書の署名と tbscertificate を分離します b) 中間認証局 02 の tbscertificate のハッシュを計算します c) RSA で署名されている署名値を 中間認証局 01 の公開鍵で復号化し ハッシュ値を取り出します d) b) と c) で得られたハッシュ値を比較 一致すれば 中間証明書 01 によって この証明書は改ざんされて いない= 信頼できるものとして扱われます e) また d) の結果 ABC 社の中間認証局 02 の証明書内の公開鍵も 中間証明書 01 によって 信頼できる と判断されます f) ~ j) は 中間証明書 02 と同様の処理によって 今度は中間証明書 01 がルート証明書によって信頼さ れます この 9 の処理が完了して初めて ABC 社のサーバ証明書 ( 公開鍵 ) が信頼されます 10 クライアントは 共通鍵などを生成するために必要な プリマスターシークレット 値を生成します 11 この プリマスターシークレット 値を ABC 社の公開鍵で暗号化します 12 暗号化された 10 の値を BIG-IP へ送ります 13 BIG-IP は その暗号化された プリマスターシークレット を ABC 社の秘密鍵で復号化します 14 結果 プリマスターシークレット を クライアントとサーバの間で共有できます 22

23 5.2. SSL ハンドシェークの事前準備 を行う SSL ハンドシェークを行うための事前準備となる設定を行います BIG-IP の設定まずクライアント PC よりも先に BIG-IP の設定を行うことにします ABC 社の秘密鍵およびサーバ証明書のインポートここまでのステップで生成した秘密鍵および証明書のうち 以下 4 つを使います 1 abccompany-key.pem 2 abccompany-crt.pem 3 interca01crt.pem 4 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

24 (4) 今度は 秘密鍵ファイルに紐づいたサーバ証明書を Import します 以下の状態で Import ボタンを押します (5) Upload するサーバ証明書を指定し Import ボタンを押します Upload する証明書を選択 (6) abc-company.lab の証明書と秘密鍵が Import された状態です これで 秘密鍵とサーバ証明書のインポートは完了です 24

25 中間認証局の証明書のインポート BIG-IP に 中間認証局 01 と 02 の証明書をインポートします System File Management SSL Certificate List で表示された画面の右上の Import ボタンを押して現れた画面で 以下のように設定します (1) 中間認証局 01 (2) 中間認証局 02 (3) インポートされた 2 つの中間証明書と秘密鍵は以下の状態になります 25

26 複数の中間証明書をまとめてチェーン証明書を作る 2 つ以上の中間認証局が存在していると それぞれの証明書を 1 つのファイルにまとめる必要があります これは BIG-IP の仕様です sol13302: Configuring the BIG-IP system to use an SSL chain certificate (11.x - 12.x) 以降 チェーン証明書を生成します (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

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 になりません チェーン証明書をインポートする 中間認証局のチェーン証明書をインポートします ルート認証局が含まれたチェーン証明書でも問題ありませんが 不要なものは含まないほうがデータ量の節約にもなりますので ルート証明書を含まないほうのチェーン証明書 :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

28 (2) WebUI で見ると 以下の状態になります Client SSL Profile の設定 インポートした ABC 社のサーバ証明書と秘密鍵を Virtual Server で利用するためには Client SSL Profile の設定が必要です Local Traffic Profile SSL Client で表示された画面の右上の Create ボタンを押して現れた画面で 以下のように設定します 任意の名称を入力 インポートしたサーバ証明書と秘密鍵およびチェーンとなるバンドル証明書を選択し Add ボタンを押す ~ 略 ~ 28

29 Pool の設定 ロードバランシング対象の Pool を設定します Local Traffic Pools で表示された画面の右上の Create ボタンを押して現れた画面で 以下のように設定します 任意の名称を入力 ヘルスモニタを選択 Pool メンバーを追加 29

30 Virtual Server の設定 SSL 通信を受け付ける Virtual Server を設定します Local Traffic Virtual Servers で表示された画面の右上の Create ボタンを押して現れた画面で以下のように設定します 任意の名称を入力 VS のアドレスとポートを設定 必要に応じて設定 生成した Client SSL Profile を指定 ~ 略 ~ 必要に応じて設定 ~ 略 ~ 生成した Pool を選択 30

31 Windows クライアントの設定 ルート認証局の証明書のインポート 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

32 (3) 次へ を押して下さい (4) インポートするファイルとして 認証局の証明書 :cacert.pem を選び 次へ を押してください ( 参照 ボタンを押した後 ***.pem はデフォルト状態では表示されないかもしれません その場合は左下の すべてのファイル (*.*) を選択してください ) 32

33 (5) 証明書ストアが 信頼されたルート証明機関 であることを確認し 次へ を押してください (6) 完了 を押してください (7) 警告が出ますが はい を押してください 33

34 (8) 完了です OK を押してください (9) 信頼されたルート証明機関 に f5jca.f5jp.local のルート証明書がインポートされました これで 信頼されたルート証明機関 として 本ガイドの認証局 (F5J-CA) が登録されました 基本的にはこれで証明書のセキュリティ警告は表示されなくなります しかし DNS による名前解決ができない環境においては 次のステップも必要です [ 参考 ] クライアント PC の hosts ファイルの編集 DNS による名前解決ができない環境の場合 Web ブラウザの URL にはサーバの IP アドレスを入力してアクセスすることになります その場合クライアント PC へルート認証局の証明書が正しくインポートされていても まだ 以下の画面をみることになります これは Virtual Server へアクセスして Web サーバからサーバ証明書を受け取ったものの サーバ証明書に記載された Common Name と Web ブラウザが接続を要求した FQDN ( URL) が一致しないことが原因です 34

35 これを簡易的に回避するためには クライアント PC:Windows の hosts ファイルを編集することです 本例では サーバ証明書の Common Name は です (1) メモ帳を 管理者権限で実行します (2) C: Windows System32 drivers etc hosts を 以下のように編集します 35

36 接続確認 クライアントの Web ブラウザへ入力する URL は IP アドレスではなく FQDN ( で入力します これで SSL 証明書のセキュリティ警告を見ることなく Web サーバ (Virtual Server) へ接続することができるようになります (1) 証明書の連鎖の様子を確認してみます ( 例 :Internet Exploer) 1 2 (2) 以下のように 証明書の連鎖で信頼されていることがわかります 36

37 5.3. SAN (Subject Alternative Name) の設定 SAN (Subject Alternative Name) を使うことで 1 枚のサーバ証明書で複数の FQDN を受け付けることができるようになります SAN に対応するには サーバ証明書を生成する際に SAN 用の拡張領域に複数の FQDN を指定します 本ガイドでは SAN 用サーバ証明書の生成に 以下の値を利用することにします OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Kanagawa localityname 区市町村 Yokohama organizationname 会社名 ABC000-Company, Ltd. organizationalunitname 組織名 IT commonname 名称 Subject Alternative Name

38 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] DNS.1 = DNS.2 = DNS.3 = 秘密鍵とサーバ証明書の署名リクエスト (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= 署名時に 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

39 Validity Not Before: Mar 16 06:56: GMT Not After : Mar 16 06:56: GMT Subject: countryname = JP stateorprovincename = Kanagawa localityname = Yokohama organizationname = ABC000-Company, Ltd. organizationalunitname = IT commonname = X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Subject Alternative Name: DNS: DNS: DNS: Certificate is to be certified until Mar 16 06:56: GMT (365 days) Write out database with 1 new entries Data Base Updated これで SAN 付のサーバ証明書が生成は完了です 39

40 SAN 付きサーバ証明書と秘密鍵のインポート 生成した SAN 付きサーバ証明書と秘密鍵をコンソール PC にコピーし BIG-IP にインポートします 以下の状態になります SAN 付のサーバ証明書をクリックして内容を確認すると SAN が付与されていることがわかります 40

41 Client SSL Profile の設定 インポートした SAN 付サーバ証明書と秘密鍵を Virtual Server で利用するためには Client SSL Profile の設定が必要です Local Traffic Profile SSL Client で表示された画面の右上の Create ボタンを押して現れた画面で 以下のように設定します 任意の名称を入力 インポートしたサーバ証明書と秘密鍵およびチェーンとなるバンドル証明書を選択し Add ボタンを押す ~ 略 ~ 41

42 Virtual Server の設定変更 SAN 付 Client SSL Profile を Virtual Server に割り当てます Local Traffic Virtual Servers で表示された画面で 該当する VS をクリックして 以下のように設定変更します ~ 略 ~ 生成した SAN 用の Client SSL Profile を指定 42

43 Windows クライアントの設定 DNS による名前解決ができない環境の場合 Windows の Hosts へ SAN に登録した FQDN を追加します (1) Hosts への追加 (2) 接続確認 以下の FQDN に対しては 正しく SSL 接続できます しかし 以下の FQDN は SSL のセキュリティ警告が出ます これは Common Name に設定されているものの SAN に登録されていないことが原因です SAN を利用する場合で Common Name も対象としたい場合には Common Name と同じ FQDN を SAN にも追加してください 43

44 5.4. SNI (Server Name Indication) の設定 SNI (Server Name Indication) を使うことで 一つの Virtual Server に複数のサーバ証明書を持たせることが出来るようになります SSL ハンドシェークを開始する際に クライアントが Client Hello とともにアクセスしたい FQDN を通知してくれる ( 図中の Server Name: の部分 ) ので BIG-IP 側はその Server Name を元に 該当するサーバ証明書を使って SSL ハンドシェークを行うことができます これが SNI です 但し 比較的新しい機能なので やや古い Web ブラウザでは SNI に対応していない可能性もある点には注意が必要です 本セクションでは SNI 用に以下の値を使って 新しく 3 つの証明書を作ります OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Kanagawa localityname 区市町村 Yokohama organizationname 会社名 def123-company, Ltd. organizationalunitname 組織名 IT commonname 名称 OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Kanagawa localityname 区市町村 Yokohama organizationname 会社名 def456-company, Ltd. organizationalunitname 組織名 IT commonname 名称 OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Kanagawa localityname 区市町村 Yokohama organizationname 会社名 def789-company, Ltd. organizationalunitname 組織名 IT commonname 名称 44

45 SNI サーバ証明書の生成 ABC 社のサーバ証明書生成したときと同様の方法で 上記の値を使って 3 つ作ります SAN と違い SNI を行う場合においてはサーバ証明書に特別な指定は必要ありません (1) 現在のフォルダを確認 # pwd /etc/pki/ca/interca01/interca02 (2) def123 社用の秘密鍵とサーバ証明書の生成 1 秘密鍵と署名リクエスト (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= 2 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 社用の秘密鍵とサーバ証明書の生成 1 秘密鍵と署名リクエスト (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= 2 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 社用の秘密鍵とサーバ証明書の生成 1 秘密鍵と署名リクエスト (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= 2 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

46 秘密鍵とサーバ証明書のインポート SNI 設定を行う 3 つのサーバ証明書と秘密鍵を コンソール PC にコピーし BIG-IP にインポートします 以下の状態になります 46

47 Client SSL Profile の設定 SNI のベースプロファイル SNI のベースになる Client SSL Profile を作ります Local Traffic Profile SSL Client で表示された画面の右上の Create ボタンを押して現れた画面で 以下のように設定します 名前 ( 任意 ) を指定 ~ 略 ~ [ 参考 ] SNI のベースプロファイルはなぜ必要か? ベースプロファイルを生成しなくても デフォルトの clientssl プロファイルを利用することで動作はします しかし 何らか設定変更を行いたい場合に この Base を変更して全体に反映する必要があるので 作っておいたほうがよいです 例えば SNI の状態でクライアント証明書認証を行いたい場合 以降で設定する 一つ一つ個別のプロファイルの設定変更はできないので ベースプロファイルの設定を変更して 全プロファイルに反映する必要があります 47

48 SNI の fallback 用プロファイル SNI 指定できないブラウザからのアクセスの際に利用されます 本ガイドでは ABC 社の証明書を利用することにします 名前 ( 任意 ) を指定 生成済みのベースプロファイルを選択 Advanced を選択 インポートしたサーバ証明書と秘密鍵およびチェーンとなるバンドル証明書を選択し Add ボタンを押す ~ 略 ~ ~ 略 ~ チェックを入れる 48

49 def123 社 /def456 社 /def789 社用プロファイル SNI 用の Client SSL profile には 以下のように Server Name に FQDN を入力します (1) def123 社用 名前 ( 任意 ) を指定 生成済みのベースプロファイルを選択 Advanced を選択 インポートしたサーバ証明書と秘密鍵およびチェーンとなるバンドル証明書を選択し Add ボタンを押す ~ 略 ~ FQDN を入力 ~ 略 ~ (2) def456 社用 名前 ( 任意 ) を指定 生成済みのベースプロファイルを選択 Advanced を選択 インポートしたサーバ証明書と秘密鍵およびチェーンとなるバンドル証明書を選択し Add ボタンを押す ~ 略 ~ FQDN を入力 ~ 略 ~ 49

50 (3) def789 社用 名前 ( 任意 ) を指定 生成済みのベースプロファイルを選択 Advanced を選択 インポートしたサーバ証明書と秘密鍵およびチェーンとなるバンドル証明書を選択し Add ボタンを押す ~ 略 ~ FQDN を入力 ~ 略 ~ 50

51 Virtual Server の設定変更 SNI 用に作成したプロファイル 3 つと Fallback 用プロファイルの合計 4 つを Virtual Server の SSL Profile (Client) に設定します ~ 略 ~ 生成した SNI 用の Client SSL Profile を指定 51

52 Windows クライアントの設定 DNS による名前解決ができない環境の場合 Windows の Hosts へ SNI として設定した FQDN を追加します (1) Hosts への追加 (2) 接続確認 def123 / def1456 / def789 のどの FQDN に対しても SSL のセキュリティ警告なしでアクセスできることを確認してください 52

53 6. クライアント証明書の生成 クライアント証明書認証用の秘密鍵と証明書を生成します 以下はその生成フローのイメージです 1 ABC 社は abc-client001 の秘密鍵を生成します (abcclient001-key.pem) 2 ABC 社は abc-client001 の署名リクエスト (CSR) を生成します (abcclient001-req.pem) 3 ABC 社は その署名リクエスト (CSR) を中間認証局 02 に送ります 4 中間認証局 02 は 署名リクエスト (CSR) に対して 署名を行う認証局の情報 ( 中間認証局 02 自身の情報 ) や有効期間などを追加して それを tbscertificate とします 5 この tbscertificate を SHA-2 を使ってハッシュ値を計算します 6 そのハッシュ値を 中間認証局 02 の秘密鍵を使って RSA で暗号化します これが署名です 7 tbscertificate と署名を一まとまりにしたものが abc-client001 のクライアント証明書です 8 中間認証局 02 は そのクライアント証明書を ABC 社へ送ります 9 ABC 社は abc-client001 用の証明書と秘密鍵を Windows へインポートしやすいように PKCS#12 形式に変換し Windows PC へインポートします 53

54 本ガイドでは クライアント証明書の生成に 以下の値を利用することにします OpenSSL 項目 意味 値 countryname 国 JP stateorprovincename 都道府県 Kanagawa localityname 区市町村 Yokohama organizationname 会社名 ABC-Company, Ltd. organizationalunitname 組織名 Systems Engineer commonname 名称 abc-client001.abc-company.lab 6.1. クライアント証明書向けフォルダの生成 クライアント PC の秘密鍵や証明書を生成するためのフォルダおよびファイルを生成します (1) 現在のフォルダの確認 # pwd /etc/pki/ca/interca01/interca02 (2) フォルダの作成 # mkdir./client 6.2. クライアント証明書の署名リクエスト (CSR) の生成 abc-client001 という名称のクライアント証明書の秘密鍵と署名リクエスト (CSR) を生成します 以下のコマンドを実行します ( 以降 いくつか同様のものを生成するので 環境変数を利用して簡単に生成できるようにしています ) # export user=abc-client001 # openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout./client/${user}-key.pem \ -out./client/${user}-req.pem \ -subj "/C=JP/ST=Kanagawa/L=Yokohama/O=ABC-Company, Ltd./OU=SE/CN=${user}.abc-company.lab" 6.3. 中間認証局 02 によるクライアント署名リクエスト (CSR) への署名 クライアント署名リクエスト (CSR) へ 中間認証局 02 が署名を行います 以下のコマンドを実行します # openssl ca -md sha256 -in./client/${user}-req.pem -keyfile./private/interca02key.pem \ -out./client/${user}-crt.pem -batch -policy policy_anything \ -config./openssl-interca02.cnf -days 730 Using configuration from./openssl-interca02.cnf Check that the request matches the signature Signature ok Certificate Details: Serial Number: 6 (0x6) Validity Not Before: Mar 16 07:19: GMT Not After : Mar 16 07:19: GMT Subject: countryname = JP stateorprovincename = Kanagawa localityname = Yokohama organizationname = ABC-Company, Ltd. 54

55 organizationalunitname = SE commonname = abc-client001.abc-company.lab X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 77:88:B1:3F:2B:15:86:8B:E2:98:2B:75:8A:67:87:0A:1E:21:58:80 X509v3 Authority Key Identifier: keyid:27:d4:c0:71:a5:7e:7f:41:9d:be:9e:ab:60:07:70:69:0d:bd:8b:8d Certificate is to be certified until Mar 16 07:19: 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

56 7. クライアント証明書認証の設定 クライアント証明書を使った認証設定を行います 7.1. クライアント証明書認証のフロー 以降の BIG-IP 設定で 今どの設定を行っているのかを理解するために クライアント証明書のフローイメージを示します クライアント証明書認証は SSL ハンドシェーク内で行われますが ここではクライアント証明書認証に関連する部分のみ抜き出しています 56

57 クライアント証明書認証の事前準備 クライアント証明書認証が行えるようにするためには 大きくは以下の 2 つの設定が必要です 1 クライアント PC 上に PKCS#12 形式ファイルを使って クライアント証明書と秘密鍵をインポートします 2 中間認証局 02, 中間認証局 01, ルート認証局の証明書にて そのクライアント証明書の検証を行えるように BIG-IP を設定します クライアント証明書認証 事前準備が完了していれば 以降は自動的に行われるフローですが この事前準備が何のために必要なのかを理解するために クライアント証明書認証のフローの概要を記載しておきます 1 BIG-IP からクライアントに対して クライアント証明書の送信要求が送られます (Certificate Request) 2 クライアント (abc-client001) は クライアント証明書を BIG-IP に送ります (Certificate) 3 BIG-IP は tbscertificate と署名を分離します 4 tbscertificate のハッシュを計算します 5 RSA で署名されている署名値を 中間認証局 02 の公開鍵で復号化し ハッシュ値を取り出します 6 4 と 5 で得られたハッシュ値を比較 一致すれば この証明書は改ざんされていないものとして 中間認証局 02 によって証明されます 7 また 7 の結果 abc-client001 のクライアント証明書内の公開鍵も中間認証局 02 によって 信頼できると判断されます 8 今度は下図のように 中間証明書 02 中間証明書 01 が信頼できるか の検証が行われます a) 中間認証局 02 の中間証明書の署名と tbscertificate を分離します 57

58 b) 中間認証局 02 の tbscertificate のハッシュを計算します c) RSA で署名されている署名値を 中間認証局 01 の公開鍵で復号化し ハッシュ値を取り出します d) b) と c) で得られたハッシュ値を比較 一致すれば 中間証明書 01 によって この証明書は改ざんされて いない= 信頼できるものとして扱われます e) また d) の結果 ABC 社の中間認証局 02 の証明書内の公開鍵も 中間証明書 01 によって 信頼できる と判断されます f) ~ j) は 中間証明書 02 と同様の処理によって 今度は中間証明書 01 がルート証明書によって信頼さ れます この 8 の処理が完了して初めて abc-client001 のクライアント証明書が信頼されます 9 クライアントは ここまでの SSL ハンドシェークでやり取りした情報から Certificate Verify 値を生成します (SSL ハンドシェークのフローで記載したやり取り部分は 本セクションでは省略していますが 実際のクライアント証明書認証は一連の SSL ハンドシェークフローの中で行われます ) 10 この Certificate Verify 値を abc-client001 の秘密鍵で暗号化します 11 暗号化された 9 の値を サーバへ送ります 12 BIG-IP は その暗号化された Certificate Verify を abc-client001 の公開鍵で復号化します 13 BIG-IP 自身で算出した Certificate Verify と 12 の値を比較して 一致すればクライアント証明書は信頼できる と判断されます 58

59 7.2. クライアント証明書認証の事前準備 を行う クライアント証明書認証に必要な設定を行っていきます BIG-IP の設定 本ガイドでは まずクライアント PC よりも先に BIG-IP の設定を行うことにします ルートを含むチェーン証明書のインポート クライアント証明書が中間認証局から発行されたものである場合 クライアント証明書認証には ルート認証局の証明書を含んだチェーン証明書が必要になります 本ガイドでは 中間証明書を取り込む際に すでにルート証明書を含んだチェーン証明書を作成しているので それを利用することにします (1) 以下のコマンドを実行し チェーン証明書をインポートします Standalone)(Active)(/Common)(tmos)# install sys crypto cert MyChain_w_root from-local-file /var/tmp/mychain_w_root.crt (2) 以下の状態になります 59

60 Client SSL Profile の設定変更 クライアント証明書認証を行うためには Client SSL Profile の設定変更が必要です 本ガイドでは ABC 社のクライアントに対してのクライアント証明書認証を行う というシナリオを想定し 設定済みの abccompany-clientssl-profile を利用することにします Local Traffic Profile SSL タブ Client で表示された画面上の abccompany-clientssl-profile をクリックして現れた画面で 以下のように設定を変更します ~ 略 ~ Require を選択 ルートを含むチェーン証明書を選択 中間認証局 02 の証明書を選択 ~ 略 ~ 60

61 Virtual Server の設定変更 Virtual Server に ABC 社の Client SSL Profile:abcCompany-clientssl-profile を割り当てます ~ 略 ~ ~ 略 ~ クライアント証明書認証の設定を行った Profile を割り当てる 61

62 クライアント証明書をクライアント PC へインポート 生成した abc-client001.p12 を ( 既述の WinSCP などを利用して ) クライアント PC へコピーしてください Windows 上のこのファイルをダブルクリックすると インポートが始まります (1) 次へ を押してください (2) 次へ を押してください 62

63 (3) パスワードは f5demo を入力し 次へ を押してください 設定したパスフレーズ :f5demo を入力 (4) 証明書の種類に基づいて ~ が選択されていることを確認し 次へ を押してください (5) 完了 を押して下さい 63

64 (6) OK を押してください (7) 以下のように クライアント証明書がインポートされます クライアント証明書がインポートされた状態 クライアント証明書認証設定は以上です Windows クライアントからのアクセス Windows の Web ブラウザ (IE) で へアクセスすると 以下の画面が出ます OK を押した後 Web 画面が表示されれば クライアント証明書認証は成功です 64

65 8. クライアント証明書の失効管理 クライアント証明書の失効管理には大きく 3 つの方法があります 1 CRL (Certificate Revocation List) 2 OCSP (Online Certificate Status Protocol) 3 CRLDP (Certificate Revocation List Distribution Point) それぞれの方式について解説し 設定してみます 8.1. CRL (Certificate Revocation List) CRL は 効力を失った証明書を管理するリストです まず OpenSSL でクライアント証明書を失効させてから 失効リスト (CRL) を生成します その失効リスト (CRL) ファイルを BIG-IP に取り込みます BIG-IP は SSL ハンドシェークの都度 その CRL ファイルを参照し 失効しているクライアント証明書とは SSL ハンドシェークを完了させないので 結果 通信させないように制御できます 複数のクライアント証明書の生成 失効されたものが接続できず 失効されていないものは接続できる状態にあることを確認するために クライアント証明書を複数生成しておきます 既述のクライアント証明書の生成ステップの export user=abc-client001 を export user=abc-client002 export user=abc-client003 に変更して 同様のステップを繰り返してください 65

66 クライアント証明書のインポートと通信確認 (1) 以下のように 3 つのクライアント証明書を一つのクライアント PC にインポートします ( 一つの PC に複数のクライアント証明書をインポートする ということは一般的にあまり行われないと思いますが 失効したクライアント証明書でアクセスできず 失効していないクライアント証明書ではアクセスできる という差を見ることを目的としていますので このようにしました ) (2) Web ブラウザで へアクセスすると 以下のように証明書の選択を促す画面が出ます それぞれ 3 つのクライアント証明書で通信が成立することを確認してください 66

67 クライアント証明書の失効 OpenSSL で クライアント証明書を失効させます フォルダとファイルの生成 (1) 現在のフォルダの確認 # pwd /etc/pki/ca/interca01/interca02 (2) フォルダおよびファイルの生成 CRL の生成に必要なフォルダとファイルを生成します # mkdir./crl # echo "01" >./crlnumber CRL の生成 (1) 失効処理前の index.txt ファイル内容の確認 失効処理が行われる前の index.txt は 以下のように 先頭がすべて V の状態になっています # cat index.txt ~ 略 ~ V Z 06 unknown ~ 略 ~/OU=SE/CN=abc-client001.abc-company.lab V Z 07 unknown ~ 略 ~/OU=SE/CN=abc-client002.abc-company.lab V Z 08 unknown ~ 略 ~/OU=SE/CN=abc-client003.abc-company.lab (2) 失効処理 (abc-client001) 例えば abc-client001 を失効してみます # openssl ca -revoke./client/abc-client001-crt.pem -config./openssl-interca02.cnf Using configuration from./openssl-interca02.cnf Revoking Certificate 06. Data Base Updated (3) 失効処理後の index.txt の確認 失効処理がなされると index.txt では 以下のように先頭に R が付きます # cat index.txt ~ 略 ~ R Z Z 06 unknown ~ 略 ~/OU=SE/CN=abc-client001.abc-company.lab V Z 07 unknown ~ 略 ~/OU=SE/CN=abc-client002.abc-company.lab V Z 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

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: GMT Next Update: Apr 14 07:25: GMT CRL extensions: X509v3 CRL Number: 1 Revoked Certificates: Serial Number: 06 Revocation Date: Mar 15 07:20: 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

69 BIG-IP の設定 CRL のための BIG-IP 設定を行います BIG-IP で CRL を取り込む BIG-IP tmsh で 以下のコマンドを実行し サーバから CRL ファイルを取り込みます Standalone)(Active)(/Common)(tmos)# create sys file ssl-crl abc-companycrl source-path Copying file " % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed :--:-- --:--:-- --:--:-- 698k Client SSL Profile の設定変更 ABC 社の Client SSL Profile(abcCompany-clientssl-profile) で 以下のように設定変更します ~ 略 ~ ~ 略 ~ 取り込んだ CRL を選択 Windows クライアントからのアクセス クライアント PC からアクセスすると 以下の状態になることを確認してください abc-client001 NG abc-client002 OK abc-client003 OK 69

70 8.2. OCSP (Online Certificate Status Protocol) クライアント証明書が失効されていないかどうかを OCSP Responder へ問合せる方式です BIG-IP は SSL ハンドシェークの都度 その OCSP Reponder への問合せを実施し 失効しているクライアント証明書であることが通知されると SSL ハンドシェークを完了させないので 結果 通信できないように制御できます OpenSSL は OCSP Responder としても機能しますので 本ガイドではそれを使います 70

71 クライアント証明書の失効 前セクションの 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 Z Z 06 unknown ~ 略 ~/OU=SE/CN=abc-client001.abc-company.lab R Z Z 07 unknown ~ 略 ~/OU=SE/CN=abc-client002.abc-company.lab V Z 08 unknown ~ 略 ~/OU=SE/CN=abc-client003.abc-company.lab OCSP Responder の起動 OpenSSL の以下のコマンドで OCSP Responder を起動します OCSP の受信 TCP ポート番号は 8181 としています # openssl ocsp -index./index.txt -port rsigner./interca02crt.pem -CA./interCA02crt.pem \ -text -out test.log -rkey./private/interca02key.pem Waiting for OCSP client connections... 71

72 BIG-IP の設定 BIG-IP に OCSP 用の設定を行います NTP による時刻設定の確認 OCSP の場合 BIG-IP と OSCP Responder との時刻差の許容範囲はデフォルトで 300 秒となっています NTP で時刻同期を行っておけば確実にこの範囲に収まるので 以下のコマンドで同期できていることを確認します config # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== * u 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

73 (3) OCSP Profile の設定 Local Traffic Profiles Authentication Profiles で表示された画面の右上の Create ボタンを押して現れた画面で 以下のように設定します 名前 ( 任意 ) を指定 SSL OCSP を選択 生成済みの OCSP Configuration を選択 Client SSL Profile の設定変更 先のセクションで CRL 設定を行っていますが OCSP 時には不要です よって 利用する Client SSL profile(abccompany-clientssl-profile) の CRL 設定を None に変更します ~ 略 ~ None を選択 ~ 略 ~ 73

74 Virtual Server の設定変更 利用する Virtual Server に 生成した OCSP の Authentication Profile を割り当てます Advanced を選択 ~ 略 ~ 生成した OCSP Profile を選択 ~ 略 ~ 設定は以上です Windows クライアントからのアクセス クライアント PC からアクセスすると 以下の状態になることを確認してください abc-client001 NG abc-client002 NG abc-client003 OK 74

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 アクセスも利用可能です 75

76 CRLDP を持つクライアント証明書の生成 CRLDP を利用するためには クライアント証明書に CRLDP 情報を付与する必要があります CRLDP 情報を持つクライアント証明書として 2 つ追加することにします 以下にその生成方法を示します 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 CRLDP 情報付きクライアント証明書の生成 署名の際に 証明書の拡張領域 (extensions) に CRLDP 情報を追加するための指定を行って クライアント証明書を生成します (1) abc-client004 の生成 1 環境変数 # export user=abc-client004 2 秘密鍵を署名リクエスト (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" 3 署名 ( 拡張領域に 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

77 Validity Not Before: Mar 16 07:57: GMT Not After : Mar 16 07:57: 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: GMT (730 days) Write out database with 1 new entries Data Base Updated 4 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-client クライアント証明書認証の動作確認 (CRLDP なしの状態 ) 新しく生成した 2 つのクライアント証明書が正しく生成できているかの確認のため 接続確認を行います (1) 前のセクションで OCSP 設定を行っているので Virtual Server の Authentication Profile からその設定を外してください (2) abc-client004 と abc-client005 で接続できることを確認してください 77

78 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 Z Z 06 unknown ~ 略 ~/OU=SE/CN=abc-client001.abc-company.lab R Z Z 07 unknown ~ 略 ~/OU=SE/CN=abc-client002.abc-company.lab V Z 08 unknown ~ 略 ~/OU=SE/CN=abc-client003.abc-company.lab R Z Z 09 unknown ~ 略 ~/OU=SE/CN=abc-client004.abc-company.lab V Z 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: GMT Next Update: Apr 15 09:10: GMT CRL extensions: X509v3 CRL Number: 2 Revoked Certificates: Serial Number: 06 Revocation Date: Mar 16 07:37: GMT Serial Number: 07 78

79 Revocation Date: Mar 16 07:51: GMT Serial Number: 09 Revocation Date: Mar 16 09:08: GMT ~ 略 ~ (5) CRL をバイナリ形式 (DER 形式 ) に変換 CRL を LDAP で扱えるように 以下のコマンドでバイナリ形式 (DER 形式 ) に変換します # openssl crl -inform PEM -outform DER -in./crl/list.crl -out./crl/list.der 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

80 BIG-IP の設定 Virutal Server に割り当てる CRLDP の Authentication Profile を設定するまでの手順を示します 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

81 (3) CRLDP Profile の設定 Local Traffic Profiles Authentication Profiles で表示された画面の右上の Create ボタンを押して現れた画面で 以下のように設定します 名前 ( 任意 ) を指定 CRLDP を選択 設定済みの CRLDP Configuration を選択 81

82 Virtual Server の設定変更 Virtual Server に 生成した CRLDP の Authentication Profile を割り当てます Advanced を選択 ~ 略 ~ 生成した CRLDP Profile を選択 ~ 略 ~ 82

83 Hosts の登録 CRLDP に指定した FQDN を Hosts に登録します (DNS 解決ができる環境においては この設定は不要です ) System Configuration Device Hosts で現れた画面で 以下のように設定します IP Address と Hostname を指定して Add ボタンを押して登録 Windows クライアントからのアクセス クライアント PC からアクセスすると 以下の状態になることを確認してください 1 abc-client001 NG クライアント証明書が CRLDP 情報を持っていないため 2 abc-client002 NG 3 abc-client003 NG 4 abc-client004 NG CRLDP から失効が通知されたため 5 abc-client005 OK [ 参考 ] 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

84 9. おわりに 基本的な SSL/TLS 設定に関しては以上で終了となります BIG-IP シリーズ製品ラインナップにおいては ソフトウェアモジュールライセンスを追加することで サーバ負荷分散はもちろんのこと ネットワークファイアウォール機能 ウェブアプリケーションファイアウォール機能 リモートアクセス機能など アプリケーションアクセスを最適化する為の多彩な機能が使用できるモジュールがあり それぞれにおいて SSL/TLS による暗号化が可能となっています 詳細は各種 WEB サイトにてご確認いただくか 購入元にお問い合わせください <F5 ネットワークス WEB サイトの紹介 > F5 ネットワークスジャパン総合サイト AskF5: ナレッジベース総合サイト ( 英語 ) DevCentral:F5 ユーザコミュニティサイト ( 英語 : アカウント登録が必要です ) 以上 F5 ネットワークスジャパン合同会社 東京都港区赤坂 赤坂ガーデンシティ 19 階 本資料は F5 ネットワークスジャパンのエンジニアが特定のソフトウェアバージョンの動作仕様に基づいて作成した構築 設計を補助するための資料であり メーカー公式資料とは異なります 資料の記載内容に誤りがあった際には指摘に基づいて修正を行いますが 内容についての責任は一切負いません また 修正 変更 改訂は予告無く行われます 84

85 10. [Appendix.1] SSL 暗号を できるかぎり ひも解く SSL 暗号の仕組みはインターネット検索でたくさんヒットしますが 一連の流れとしてまとまったものがなかなか見つけられないので 情報はたくさんあれど 理解しにくいと感じています SSL は正しく設定できていれば あとは自動的に動いてくれるので フローの詳細はまぁ理解しなくても大丈夫かな と思えてしまいますが SSL の脆弱性が発覚したときや どの処理が BIG-IP のパフォーマンスに影響するのか等 どこでどのような処理が行われているのかを ある程度把握したいときがあります ということで 暗号スイートを一つピックアップし RFC やインターネット検索で得た情報から SSL 暗号をできるだけひも解いていくことにします 内部処理に踏み込んで実際の動きを確認するのは難しいので 多少の推測も含まれていることをご了承ください 暗号スイート (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

86 10.2. RSA とは まず先に RSA について解説します 鍵交換にも署名にも使われる RSA ですが ここでは主に署名として使う場合の解説を行います RSA は 以下の 2 つがポイントです ある数を法 (Modulo) とする世界では ある べき乗 を行うと元の数に戻る というべき乗数が必ず存在する 大きな素数の掛け算は どんな数を掛け合わせているのかの解読が難しい 具体的な例を用いて説明します 法 (Modulo) とは 法 (Modulo) を簡単に説明すると ある数を 法で割り算した余り です 例えば 33 を法とした世界で 100 はどうなるか というと 100 mod 33 = 1 となります 100 を 33 で割ると 余りは 1 という意味です Modulo の世界では元の数字に戻る べき乗 が必ず存在する Modulo の世界では ある数のべき乗を行うことで必ず元の値に戻る という性質があります 例えば 33 を法とする世界では そのべき乗は 11 と 21 です 例えば 6 をべき乗の底とする場合 6 11 (mod 33) = (mod 33) = 6 となり 元の数字に戻ります その他の数字も同様に 法 33 の世界では 11 と 21 のべき乗で元の数字に戻ります 86

87 元の数字に戻る べき乗 の算出 本ガイドの例では 33 を法としています 33 は 素数 3 と素数 11 の掛け算です ( 以降の計算式説明の都合上 変数を使います ) P = 3 Q =11 33 を法とする世界で 元の数字に戻る " べき乗 " の 11 と 21 は 以下の 2 つの公式どちらかで導き出されます 1 n ((P-1) と (Q-1) の最小公倍数 ) =2 と 11-1=10 の最小公倍数は 10 n=1 とすると =11 n=2 とすると =21 n=3 とすると =31 (n を増やせば 11,21 以外にも該当する値がある ) 2 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 ( 同上 ) RSA による署名 RSA は この ある法の世界で 暗号化対象のメッセージに いくらの数のべき乗を行えば再び元のメッセージに戻るか? の " べき乗 " を秘密にするのがポイントです この法則を使って RSA では以下の形が定義されています (m e ) d mod n = m (m d ) 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 87

88 以下のフローを使って 説明します tbscertificate からハッシュ値を算出します ここでは "14" というハッシュ結果になったと仮定します (m=14) 秘密鍵を用いて そのハッシュ値に RSA 署名を行います 14 7 mod 33 =20 この 20 が署名値です tbscertificate と RSA 署名を合わせたものが ABC 社のサーバ証明書です ABC 社のサーバ証明書を ABC 社に送付され ABC 社のサーバまたは BIG-IP にインポートされます クライアントは ABC 社からサーバ証明書を受け取ります クライアントは tbscertificate と署名を分離します tbscertificate のハッシュ値を算出します (m=14) 認証局の公開鍵 (e=3, n=33) を用いて 署名を検証します m = 20 3 mod 33 = 14 7と8の結果を比較 一致すれば改ざんされていない=このサーバ証明書を信頼します サーバ証明書が信頼された=その証明書内の ABC 社の公開鍵も信頼されます 88

89 RSA のまとめ RSA は 元のメッセージを どの数値でべき乗したら元に戻るのか? を隠すのがポイントですが その値は 既述の通り 法を構成する 2 つの素数を使った公式で導き出されます よって その 2 つの素数がわかってしまえば 解読できてしまいます 例として使った法 : 33 は 素数 3 と素数 11 を掛け合わせたもの というのは人間でも簡単にわかってしまいます しかし これが大きい素数の掛け算になると解読するのはとてつもなく難しい というのが RSA の根幹にあります 現在では 法が 2048bit になるような大きな 2 つの素数の掛け算を使うのが一般的で これを解読するには現存するコンピュータでは相当難しい とされています ここではあくまでイメージを掴むことを目的として 簡単な計算で求められる範囲にとどめていますが 公開鍵 / 秘密鍵となる e, d 値の算出ロジックの詳細については Wikipedia の RSA (cryptosystem) をご参照ください [ 参考 URL ]

90 10.3. Diffie-Hellman とは プリマスターシークレットの交換に使われる Diffie-Hellman について解説します RSA の場合は 暗号化はしているものの プリマスターシークレット ( 鍵のタネになるもの ) をネットワーク上で交換します ( 既述 : SSL ハンドシェークフロー ( 例 :RSA 鍵交換 ) を参照 ) 一方 Diffie-Hellman の場合は プリマスターシークレットを生成する計算に必要な値を交換するだけで それ自体をネットワーク上で交換しません その代わりに 計算に必要なパラメータを受け取ったら その値からクライアント / サーバそれぞれがプリマスターシークレットを算出する という方式です よって ネットワーク上にプリマスターシークレットが流れない というのが Diffie-Hellman の特徴です また その算出に使う値はすべて暗号化されていない というのも特徴的です 以下に 小さな数字を用いて Diffie-Hellman のフローを示します 1 クライアント / サーバそれぞれが 秘密の値 Secret を生成します これは絶対に公開しません サーバ :x=9, クライアント :y=3 2 modulo 計算に使う g の値 2 をサーバからクライアントへ送り 共有します 3 modulo 計算に使う p の値 53 をサーバからクライアントへ送り 共有します 4 サーバは g p x の値から 図中の Modulo 計算を行い 値を算出します それが A=35 です 5 この A=35 をサーバからクライアントへ送り 共有します 6 クライアントは g p y の値から 図中の Modulo 計算を行い 値を算出します それが B=8 です 7 この B=8 をクライアントからサーバへ送り 共有します 8 ここまでで交換した値を用いて クライアント / サーバそれぞれが図中の Modulo 計算を行うと 結果が同じになる = プリマスターシークレット (KA=51 と KB=51) を共有できる という仕組みです [ 参考 URL ] 90

91 10.4. DHE-RSA の SSL ハンドシェークフロー プリマスターシークレットの交換に DHE と 署名に RSA を使った 具体的な SSL ハンドシェークフローを示します 91

92 上図の SSL ハンドシェークのところから解説します 1 クライアントからの Client Hello にて 主に以下 2 つの情報がサーバ (BIG-IP) へ送られます A) クライアントがサポートしている暗号アルゴリズムのリスト B) クライアントが生成したランダムな値 ( クライアントランダム ) 2 BIG-IP からの Server Hello にて 主に以下 2 つの情報がクライアントへ送られます A) クライアントから提示された暗号アルゴリズムの中から一つ選んだ暗号アルゴリズムここでは DHE-RSA-AES128-SHA256 が選択された とします B) サーバが生成したランダムな値 ( サーバランダム ) 3 BIG-IP から ABC 社のサーバ証明書がクライアントへ送られます 4 クライアントは tbccertificate と署名を分離します 5 tbscertificate のハッシュを計算します 6 RSA で署名されている署名値を F5J-CA 証明書内の公開鍵で復号化し ハッシュ値を取り出します 7 5 と 6 で得られたハッシュ値を比較 一致すれば この証明書は改ざんされていない = 信頼できるものとして扱われます 8 また 7 の結果 ABC 社のサーバ証明書内の公開鍵も信頼できると判断されます 9 サーバは Diffie-Hellman の計算に必要なパラメータを生成します (Diffie-Hellman Server Parameters) その Diffie-Hellman Server Parameters は サーバランダム / クライアントランダム値と合わせてハッシュ計算されます そしてそのハッシュ値を サーバ証明書と同じ方式 (RSA) で署名します 10 サーバは ServerKeyExchange にて 9 の値をクライアントに送ります 11 クライアントは 10 で得た Diffie-Hellman Server Parameters とサーバランダム / クライアントランダムを合わせてハッシュを計算します 12 クライアントは 10 で得た署名を ABC 社の公開鍵で復号化して ハッシュ値を取り出します 13 クライアントは 11 と 12 で得られたハッシュ値を比較 一致すれば信頼できるものとして扱います 14 クライアントは Diffie-Hellman Server Parameters で得た g と p 値と 自身の Secret 値 y から図中の計算を行い Diffie-Hellman Client Parameters を生成します 15 クライアントは ClientKeyExchange にて 14 の値をサーバに送ります 16 クライアントおよびサーバはそれぞれ ここまでで得た Diffie-Hellman のパラメータを使って図中の計算を行い 同じ結果を得ます これで プリマスターシークレットの共有が出来ました 92

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 が使われます 93

94 10.6. PRF (P_SHA256) のフロー 以下の図を用いて マスターシークレット および キーブロック を生成するまでのフローを示します 94

95 マスターシークレットの生成 プリマスターシークレットが 64byte より長い場合 SHA256 でハッシュ ( 理由は後述の HMAC のところで解説 ) されたものが PRF の一つ目の入力値です ( これを # プリマスターシークレット と呼ぶことにします ) Label として "master secret" の固定文字がつけられ 後続にクライアントランダムとサーバランダムを連結した文字列が PRF の 2 つ目の入力値です 1 と 2 を入力値として HMAC-SHA256 の計算が行われ 結果 =A(1) が出力されます A(1) と 2 が連結されたものと 1 の # プリマスターシークレット の 2 つの値を入力値として HMAC-SHA256 の計算が行われます 4 の結果が マスターシークレットの一つ目の 32Byte ブロックです A(1) と # プリマスターシークレット を入力値として HMAC-SHA256 の計算が行われ 結果 =A(2) が出力されます A(2) と 2 が連結されたものと 1 の # プリマスターシークレット を入力値として HMAC-SHA256 の計算が行われます 7 の結果が マスターシークレットの二つ目の 32Byte ブロックです マスターシークレットは 48Byte と決められているので 5 と 8 の連結の 64byte から先頭 48byte を切り出した値をマスターシークレットにします キーブロックの生成 マスターシークレットが PRF の一つ目の入力値です Label として "key extpansion" の固定文字がつけられ 後続にクライアントランダム (32Byte) とサーバランダム (32byte) を連結した文字列が PRF の 2 つ目の入力値です 1 と 2 の 2 つの値を入力値として HMAC-SHA256 の計算が行われ 結果 =A(1) が出力されます 3 で出力された A(1) と 2 の値が連結されたものと 1 の マスターシークレット の 2 つの値を入力値として HMAC-SHA256 の計算が行われます 4 の結果が キーブロックの一つ目の 32Byte ブロックです 3 の結果 =A(1) と マスターシークレット の 2 つの値を入力値として HMAC-SHA256 の計算が行われます ~ 11 まで 類似の処理が繰り返されます 12 キーブロックが必要な長さになるまで 同様の処理が繰り返されます 95

96 キーブロックの内容 生成されたキーブロックの内容は以下のようになっています MAC Key 暗号化されたデータの改ざんを検知する目的の値 :MAC (Message authentication code) を算出するために使われる鍵です 今回選定している暗号スイートでは SHA256 が使われるので 32byte(256bit) の MAC Key がクライアント用とサーバ用にそれぞれ一つずつ生成されます 1 client write MAC key 32byte (256bit) HMAC-SHA256 用 2 server write MAC key 32byte (256bit) MAC の生成については 後述します Encryption key AES 暗号に使う鍵です 今回選定している暗号スイートでは AE128 が使われるので 16Byte(128it) の暗号鍵がクライアント用とサーバ用にそれぞれ一つずつ生成されます 1 client write encryption key 16byte (128bit) AES128 用 2 server write encryption key 16byte (128bit) AES 暗号については 後述します Inital Vector AES のようなブロック暗号は 例えば CBC(Cipher Block Chaining) の場合 一つ前の暗号ブロックとの XOR を行ってから AES 暗号化処理を行います この場合 一番先頭の暗号ブロックは当然ながらそれより前の暗号ブロックが存在しないので その代わりにこの IV を使って XOR を行います 今回選定している暗号スイートでは AES128-CBC が使われるので 16Byte(128bit) の IV がクライアント用とサーバ用それぞれに一つずつ生成されます 1 client write Initial Vector 16byte (128bit) AES128-CBC 用 2 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. 96

97 HMAC-SHA256 PRF 内で使われる HMAC について解説します HMAC については RFC2104 に定義されており 以下の式で表されます H: ハッシュ関数 (SHA256) K: シークレット値 ( プリマスターシークレット or マスターシークレット ) ハッシュ関数が必要とするブロックサイズになるまで 右側に 0 を追加する または ブロックサイズより大きい場合は オリジナルのキーをハッシュして必要な長さに変える m: メッセージ ( ラベルとシード ) : 文字列をくっつける opad: Outer パディング : 0x5c5c5c 5c5c, ipad: Inner パディング : 0x , これも分かりにくいので 図示します PRF でマスターシークレットを生成するフロー図 ( 既述 ) の 最初の HMAC-SHA256 を例に解説します 97

98 1 プリマスターシークレットが 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. ~ 略 ~ 2 # プリマスターシークレット に 00(Hex) を 64Byte になるまで付加します 3 2 と ipad (0x ) との XOR を算出します 4 3 の XOR 結果と ラベル & シードを連結します 5 4 を SHA256 でハッシュします 6 # プリマスターシークレット に 00(Hex) を 64Byte になるように付加します 7 6 と opad (0x5c5c5c...) との XOR を算出します 8 5 の Hash 値と 7 の XOR 結果を連結します 9 8 を SHA256 でハッシュします 10 32Byte の出力結果が得られます PRF は 既述の通り この HMAC 処理の繰り返しで構成されています 98

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 つ目の入力値です 99

100 ( シーケンス番号 = データ送出バイト数のカウントは 送信側と受信側しか知りえない情報であることから 認証の役割も果たしています ) と 4 を入力値として HMAC-SHA256 の処理が行われます 5 の出力結果が MAC 値です TLSCompressed に MAC 値を付与します さらに AES128 の暗号処理に合うよう 128bit の倍数になるようにパディング処理が行われます (Padding length の 1byte も含めて 128bit の倍数になるようにパディングされます ) MAC の生成 (HMAC-SHA256) MAC を生成する HMAC-SHA256 も参考までに図示します PRF のセクションで紹介した HMAC-SHA256 と同じ処理であり 入力値が異なるだけです これで AES 暗号化前のデータの準備が整いました 以降は AES128 による暗号化通信です 100

101 10.8. AES 暗号生成した TLS Ciphertext を AES で暗号化して送り出すまでの処理フローを示します ざっくりいうと AES は 鍵を XOR で加えながら データをかき混ぜる という感じです AES128-CBC 暗号データの送出フロー以下は クライアントからサーバへ AES 暗号化されたデータを送りだすまでの処理の例です 101

102 1 Client write encryption key(128bit) を一定の法則で撹拌して Round-key を 10 個作ります ( 後述 ) 2 データ部分の先頭から 128bit を取り出します 3 2 と Client write Initial Vector(128bit) で XOR を算出します =CBC の最初の処理 [AES の Initial Round] 4 3 の結果と Client write encryption key(128bit) で XOR を算出します [AES の 9 Rounds] 5 4 の結果に対して SubBytes 処理を行います ( 後述 ) 6 5 の結果に対して ShiftRows 処理を行います ( 後述 ) 7 6 の結果に対して MixColumns 処理を行います ( 後述 ) 8 7 の結果に対して RoundKey 1 との XOR を算出します 5~8 を合計 9 回繰り返します ( 実施回数毎に 回数と同じ番号の RoundKey が使われます ) [AES の Final Round] 9 9 回行われた後の 8 の結果に対して SubBytes 処理を行います ( 後述 ) 10 9 の結果に対して ShiftRows 処理を行います ( 後述 ) の結果に対して RoundKey 10 との XOR を算出します bit の暗号化ブロックが完成しました [ 次の 128bit ブロックの暗号化処理 ] 13 データ部分から次の 128bit を取り出します と 一つ前の 128bit 暗号ブロック (12) との XOR を算出します =CBC 処理 15 AES 暗号化処理を実施します (4~11 と同じ処理 ) 16 2 つ目の 128bit の暗号化ブロックが完成しました [ さらに次の 128bit ブロックの暗号化処理 ] 17 データ部分からさらに次の 128bit を取り出します と 一つ前の 128bit 暗号ブロック (16) の XOR を算出します =CBC 処理 19 AES 暗号化処理を実施します (4~11 と同じ処理 ) 20 3 つ目の 128bit の暗号化ブロックが完成しました この処理が 後続のデータの 128bit 毎に繰り返されて TLSCiphertext が作られます この TLSCiphertext がサーバに送られます 102

103 CBC (cipher block chaining) について CBC は 一つ前の暗号ブロック (128bit) との XOR を行う処理です 上図 は 一つ前の暗号ブロックがあるので それとの XOR を行うことができますが 3 は 前の暗号ブロックが存在しません よって 最初のデータブロックだけは キーブロックから生成したイニシャルベクター ( クライアント サーバへの送出時は Client Write Initial Vector) との XOR を行います ( 上図 3) RoundKey の生成 AES の AddRoundKey の処理で データとの XOR を行うための 10 個の RoundKey(1~10) を生成するフローです 既述のフロー通り AddRoundKey は合計で 11 回実施されますが 1 回目 (Initial Round) ではキーブロックから生成された Encryption Key を使います 以降は その Encryption Key を元にして生成された 10 個の RoundKey が使われます RoundKey 1 の生成フロー (1) 1 列目 RoundKey の 1 列目だけは やや複雑な処理がなされます 103

104 Client write encryption key:128bit(16byte) を 4 行 4 列に並べたものから 4 列目を取り出します 1 番上の 1byte を一番下に持ってきます Client write encryption key の 1 列目を取り出します 2の Byte 列を S-box 対応表の値に置き換えます RCON から一列目を取り出します 3, 4, 5の XOR を算出します 6の結果が RoundKey 1 の一列目になります RCON も S-box も これらの概念を理解するのはなかなか難しそう ( ガロア有限体 など ) ですが RoundKey の生成時には 上図のように それぞれの表の値を使う という理解でよさそうです [ 参考 URL] RCON: S-box: (2) 2~4 列目 2~4 列目以降は 比較的簡単な処理が行われます Client write encryption key:128bit(16byte) を 4 行 4 列に並べたものから 2 列目を取り出します RoundKey 1 の 1 列目を取り出します 1と2の XOR を算出します 3の結果が RoundKey 1 の 2 列目です Client write encryption key:128bit(16byte) を 4 行 4 列に並べたものから 3 列目を取り出します RoundKey 1 の 2 列目を取り出します 5と6の XOR を算出します 7の結果が RoundKey 1 の 3 列目です Client write encryption key:128bit(16byte) を 4 行 4 列に並べたものから 4 列目を取り出します RoundKey 1 の 3 列目を取り出します 9と10の XOR を算出します 11の結果が RoundKey 1 の 3 列目です これで RoundKey 1 が完成しました 104

105 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

106 AddRoundkey AES 暗号前のデータと Encryption Key で 単純に XOR を算出します SubBytes S-box 表を使って 対応する値に変換します ShiftRows 以下のように Byte 単位でずらします 106

107 MixColumns ある表 (Circulant MDS Matrix) との掛合せを行う処理です 上記 3 つの処理と異なり これだけはちょっとややこしいです 算出方法 MixColumns の一つ目の値の算出例を示します 例えば {2.d4} は d4 に 2 をかける という意味合いではあるのですが 単純に 2 倍 という処理ではなく 以下のような計算が必要です (1) {2.d4} 1 d4 を bit 列にします d4= 左へ 1bit シフトして 後ろに 0 を足します d4 の先頭 bit が 1 なので (1b) との XOR を計算します ( 先頭 bit が 0 だとこの処理は行いません ) (2) {3.bf} XOR bf を bit 列にします bf= "3" は 2 進数だと 11 なので 10 XOR 01 と表せます 3 よって 以下の計算式として表せます {3.bf} = {10 XOR 01}. { } = { } XOR { } 107

108 4 { } は bf に 1 をかけているだけなので bf のままになります よって 以下の形になります = { } XOR { } 5 { } は bf に 2 をかけているので {2. d4} の計算に倣って 同様の計算を行います bf を左へ 1bit シフトして 後ろに 0 を足します bf の先頭 bit が "1" なので その値と (1b) との XOR を計算します XOR この 5 の結果と { } との XOR を取ります = { } XOR { } = 以下 2 つは 1 を掛合わせるので 値は変化しません {1.5d} = { } = { } {1.30} = { } = { } 8 算出した 4 つの値の XOR を取ります {2.d4} {3.bf} {1.5d} XOR {1.30} = 0x04 これで 1 つ目の Byte 04 が計算されました 以降の Byte も類似の計算式で導き出されます [ 参考 URL ] 108

109 AES128-CBC 暗号データの受信フロー サーバが クライアントからの AES 暗号データを受け取った際の復号処理フローです 概ね 暗号化と逆の処理を行うことで復号化する という感じですが InvSubBytes や InvMixColumns については 復号用のものを使います ( 下図は 下から上への流れになっています ) 109

110 InvSubBytes 復号時の SubBytes は 以下の Inverse S-box が使われます ( 数字は 16 進数です ) InvMixColumns 復号時の MixColumns の Circulant MDS Matrix は 以下が使われます ( 数字は 10 進数です ) 以上が SSL ハンドシェークから暗号化 / 復号化までの一連の流れです [ その他の参照 URL]