SSL証明書の設定

開発および実稼働環境用に証明書署名要求の生成、署名、キーストアとトラストストアの作成を行うための一般的な手順。

クライアントとノード間の暗号化とノード間の暗号化にはSSL証明書を使用します。DataStaxでは、一般的なCAによって署名された証明書をノードごとに使用したSSL、またはBring Your Own（BYO）ルート認証局を使用したSSLをサポートしています。

注: DataStaxでは、SSL証明書管理タスクを軽減するために、CAによって署名された証明書を使用することを推奨しています。ただし、DSEで自己署名証明書を使用することも可能です。

以下の手順では、OpenSSLおよびJava keytoolを使用してSSL証明書を生成し、配布するための一般的なプロセスを順を追って説明します。実稼働環境でSSLを安全に実装するため、中間証明書チェーンを使用します。OpenSSLルートCAの手順を参照してください。

OpsCenter Lifecycle Managerでは、クライアントとノード間およびノード間の暗号化を使用し、サーバー証明書の作成プロセスを自動化するように、DataStax Enterpriseクラスターを構成できます。

始める前に

完全に暗号化され、ネットワークから恒久的に分離されている専用のCAサーバーで、以下の手順を実行します。BYO CAを使用する場合、必ずセキュアな環境で証明書の署名用にルート・ペアを作成してください。ルートCAファイルにアクセスできれば誰でもルート・ペアを使用して証明書に署名できることになります。

注: DataStaxでは、DSE環境の外にあるコンピューターを使用してSSL証明書を生成し管理することを推奨しています。

SSL証明書を生成するために使用するコモン・ネーム（CN）は、DNSの解決可能なホスト名と一致している必要があります。CNとノード・ホスト名が一致していない場合、例外が生じ、接続は拒否されます。

手順

サードパーティの署名済み証明書を使用する場合、または既存のrootCAを使用してノードを追加する場合は、ステップ3に進んでください。

BYOルートCAのみ：ノード証明書に署名するために、独自のルートCAを作成します。

CA用のディレクトリーを作成し、そのディレクトリーに変更します。
```
mkdir -p dse/root/ca cd dse/root/ca
```
注: これらの手順で作成したルートCAファイルが完全に分離されたCA証明書管理専用のコンピューター上で保護されていることを確認してください。
caディレクトリーに構成ファイルを作成します。
```
# gen_rootCa_cert.conf
[ req ]
distinguished_name	= req_distinguished_name
prompt				= no
output_password		= myPass
default_bits		= 2048

[ req_distinguished_name ]
C					= US
O					= org_name
OU					= cluster_name
CN					= rootCa
```
ここで、お使いの環境に合わせて変数を以下のように定義します。
- gen_rootCa_cert.confは構成ファイル名です。
- myPassはCAパスワードです。
- USは2文字の国コードです。
- org_nameは組織名です。
- cluster_nameはDataStax Enterpriseクラスターの名前です。
ルート・ペアを作成します。
```
openssl req -config gen_rootCa_cert.conf \ -new -x509 -nodes \ -subj /CN=rootCa/OU=cluster_name/O=DataStax/C=US/ \ -keyout rootCa.key \ -out rootCa.crt \ -days 365
```
ルート・ペア、rootCa.keyキー・ファイル、およびrootCa.crtが作成されました。これらの手順は開発およびテスト環境用であり、実稼働環境では、これらのファイルはOpenSSLドキュメントに記載されているように慎重に保護します。

ルート証明書を確認します。

openssl x509 -in rootCa.crt -text -noout

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 14793138693831603662 (0xcd4bc943beeb35ce)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=datastax, OU=pw-j-dse, CN=rootCa
        Validity
            Not Before: Jan 23 20:15:06 2017 GMT
            Not After : Jan 23 20:15:06 2018 GMT
        Subject: C=US, O=datastax, OU=pw-j-dse, CN=rootCa
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d8:71:e0:51:07:ad:f1:f7:0b:4d:2c:10:4c:24:
                    19:9f:1f:d4:2a:a1:a6:89:3d:e1:12:81:3b:4d:bd:
                    2d:da:fb:9e:d5:c5:ba:ed:82:80:28:35:e5:00:86:
                    96:2b:67:18:37:c9:80:32:3e:40:0a:25:5d:c2:d5:
                    1c:bf:de:29:7a:fa:d6:32:20:35:39:03:e6:0a:35:
                    96:9d:8e:ca:88:b2:71:24:50:d2:94:1c:80:de:dd:
                    39:35:57:38:b2:09:39:ba:b3:9b:60:a1:5a:c7:f3:
                    04:35:73:f9:b6:05:1e:09:a2:e1:0e:1c:eb:6f:5e:
                    66:71:ec:38:08:99:6e:a3:d5:2a:0f:af:99:f5:19:
                    c0:6d:4d:b0:ae:0f:6e:7b:c9:78:7d:29:37:3c:3d:
                    38:7a:74:da:d1:16:38:5a:2b:f1:ac:a0:39:91:4a:
                    83:6f:1e:92:b5:66:fd:7f:5f:57:77:5f:c5:c6:ca:
                    23:63:95:d5:36:04:c2:c3:94:6f:2d:56:7e:96:4b:
                    e1:f2:ca:cd:4a:d6:9d:50:1a:5d:6e:1b:76:57:b4:
                    cd:a6:1a:6a:bb:82:d3:32:b4:b6:85:34:b1:d3:6c:
                    31:f7:a1:51:2e:1f:48:c7:c9:04:d2:c4:38:d7:84:
                    c8:cb:08:10:04:a8:a6:12:cf:48:54:88:b6:f7:bc:
                    f2:5d
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         43:8d:98:8c:d7:26:52:41:ad:de:c9:80:8d:4f:d6:6e:21:69:
         81:7d:eb:af:93:6e:15:ad:9d:fe:ee:1a:60:d6:aa:92:86:a2:
         fd:e1:8f:95:b9:ee:db:59:63:fd:cd:05:72:63:d6:6b:14:cf:
         34:8c:15:cd:38:0a:ef:0d:41:de:9d:55:f2:2a:eb:1d:ca:44:
         21:f8:18:41:42:d9:e2:fb:c4:97:80:9c:ac:8b:61:d8:d9:33:
         38:9d:98:79:39:04:06:a8:b0:8e:e2:0e:49:5b:13:95:0b:42:
         2f:64:8c:9d:4a:6e:84:ca:40:26:7e:c8:a2:f3:e0:09:fc:9c:
         e8:a7:8a:6d:d2:cd:37:1f:0a:b8:61:c8:c3:f6:17:83:0f:24:
         0e:06:09:bc:73:09:32:70:f0:2f:9f:b1:7e:b8:ff:36:5c:3c:
         a9:28:69:58:fd:6b:55:2c:1f:8e:28:9c:8d:c9:37:66:9d:28:
         d7:4c:e5:fe:67:45:52:41:68:36:88:26:b1:95:f5:27:43:b3:
         1e:01:23:85:64:14:86:ff:b8:93:9e:06:78:ad:8b:2f:27:d8:
         35:06:49:37:d4:9f:d6:6f:a8:78:1f:b5:cf:96:2b:d7:da:02:
         2c:94:6f:1d:66:5c:e8:a6:a8:c9:e6:65:6a:6a:99:4a:61:a9:
         fe:7d:3e:c8

単一のトラストストアを作成します。
```
keytool -keystore dse-truststore.jks \ -alias rootCa -importcert -file '../ca/rootCa.crt' \ -keypass myPass \ -storepass truststorePass \ -noprompt
```
ヒント: 一般的な認証局を使用する場合でも、DataStaxでは署名CA証明書（またはお使いのCAの指示に従っている証明書チェーン）を使用してトラストストアを作成することを推奨しています。最も一般的なCA証明書は、DSE Java実装から既に使用できます。
トラストストアには、単一のエントリーが含まれます。以下のコマンドを使用して、トラストストアを確認します。
```
keytool -list \ -keystore dse-truststore.jks \ -storepass truststorePass
```

サードパーティのCAを使用する場合、またはSSLが有効な既存のDSE環境にノードを追加する場合は、次のステップから開始します。

クラスター内のノードごとに、ノードのFQDNを使用してキーストアとキー・ペア、および証明書署名要求を作成します。
1. キーストアを格納するディレクトリーを作成し、そのディレクトリーに変更します。
```
mkdir -p dse/keystores cd dse/keystores
```
2. ノードごとに、キー・ペアを使用してキーストアを生成します。
```
keytool -genkeypair -keyalg RSA \ -alias node_name \ -keystore keystore_name.jks \ -storepass myKeyPass \ -keypass myKeyPass \ -validity 365 \ -keysize 2048 \ -dname "CN=host_name, OU=cluster_name, O=org_name, C=US"
```
  ここで、host_nameはFQDN（完全修飾ドメイン名）です。
  重要:
  ノードごとにDNSの解決可能なFQDN（完全修飾ドメイン名）を使用し、使用している情報が正しいことを確認するため、以下のコマンドを各ノードで実行します。
  nslookup $(hostname --fqdn) && hostname --fqdn && hostname -i
  Server: 10.200.1.10 Address: 10.200.1.10#53 Name: node.example.com Address: 10.200.182.183 node.example.com 10.200.182.183
3. 各SSLキーストアとキー・ペアを確認します。
```
keytool -list -keystore keystore_name.jks -storepass myKeyPass
```
  別名node1の単一のエントリーを持つキーストアの場合、結果は以下のようになります。
```
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

node1, Jan 23, 2017, PrivateKeyEntry,
Certificate fingerprint (SHA1): 12:B7:45:AA:AD:F0:22:23:3F:13:FC:2C:3D:A4:4F:84:16:96:58:66
```
4. 各キーストアからの署名要求を作成します。
```
keytool -keystore keystore_name.jks \ -alias node_name \ -certreq -file signing_request.csr \ -keypass myKeyPass \ -storepass myKeyPass \ -dname "CN=host_name, OU=cluster_name, O=org_name, C=US"
```
  証明書署名要求ファイル（signing_request.csr）が作成されました。ノードごとにこれらの手順を繰り返し、dname情報がノード情報に一致していることを確認します。
各ノードの証明書署名要求に署名します。
- BYOルートCAの場合：ステップ1で作成したルートCAを使用して、各ノードの証明書に署名します。
```
openssl x509 -req -CA '../ca/rootCa.crt' \ -CAkey '../ca/rootCa.key' \ -in node0.csr \ -out node0.crt_signed \ -days 365 \ -CAcreateserial \ -passin pass:myPass
```
  署名済み証明書ファイルが作成されます。適切に署名されていることを確認します。
```
openssl verify -CAfile '../ca/rootCa.crt' node0.crt_signed
```
```
node0.crt_signed: OK
```
- 署名を得るため、証明書署名要求を一般的なCAに送信します。
クラスター内のノードごとに、署名済み証明書をキーストアにインポートします。
1. ルート証明書を各ノードのキーストアにインポートします。
```
keytool -keystore node0.keystore.jks \ -alias rootCa \ -importcert -file '../ca/rootCa.crt' \ -noprompt -keypass myKeyPass \ -storepass myKeyPass
```
  警告: そのノードの署名済み証明書がルート証明書よりも先にインポートされていると、「keytool error: java.lang.Exception: Failed to establish chain from reply」というエラーが発生します。
2. そのノードの署名済み証明書を対応するキーストアにインポートします。
```
keytool -keystore node0.keystore.jks \ -alias node_name \ -importcert -noprompt \ -file node0.crt_signed \ -keypass myKeyPass \ -storepass myKeyPass
```
  ここで、別名は、ステップ3.dで署名要求を生成するために使用した別名と一致している必要があります。
  インストールの確認が表示されます。各ノードのキーストアで両方の手順を繰り返します。
```
Certificate reply was installed in keystore
```
トラストストアとキーストアをDSEノードにアクセスできるコンピューターに移動し、各ノードに配布します。
1. 各ノードのDSE構成ディレクトリーに証明書用のディレクトリーを作成します。
```
mkdir -p dse/conf/certs
```
2. 一般名を使用して、トラストストアを各ノードにコピーします。
```
scp dse-truststore.jks \ node0:dse/conf/certs/truststore.jks
```
  すべてのノードで同じ名前と場所を使用することで、cassandra.yaml内のSSLの構成が同じになります。
3. 一般名を使用して、対応するキーストアを各ノードにコピーします。
```
scp node0.keystore.jks \ node0:dse/conf/certs/keystore.jks
```
  重要: 適切なキーストアを適切なノードに確実にコピーしてください。