TLS 証明書、KeyStore およびトラストストアファイルの管理

この章では、TLS 証明書とトラストストアファイルを生成するための情報と手順について説明します。

リリース 3.10.1 以降、Cisco Nexus Data Broker (NDB) は Cisco Nexus Dashboard Data Broker に名前が変更されました。ただし、GUI およびインストールフォルダ構造と対応させるため、一部の NDB のインスタンスがこのドキュメントには残されています。NDB/ Nexus Data Broker/ Nexus Dashboard Data Brokerという記述は、相互に交換可能なものとして用いられています。

NXAPI に対して NDB サーバーと NDB スイッチの間での TLS 自己署名証明書の生成

このセクションでは、NDB サーバーと NDB スイッチの間で TLS 自己署名証明書を生成する方法について説明します。TLS を有効にするには、スイッチごとに証明書とキーを生成する必要があります。NDB サーバーと NDB スイッチの間で TLS 通信は、ポート 443 のみを使用します。

NDB サーバーと NXAPI の NDB スイッチの間で TLS 自己署名証明書を生成するには、次の手順を実行します。

自己署名証明書とキーの生成
TLS トラストストアファイルの作成
TLS を使用した NDB の開始
Nexus Dashboard Data Broker での TLS KeyStore と TrustStore パスワードの構成

（注）

TLS を構成した後でポート 80 を使用して、通信するためのコントローラを構成できません。

自己署名証明書とキーの生成

このセクションでは、自己署名証明書とキーを生成する方法について説明します。

始める前に

スイッチの完全修飾ドメイン名（FQDN）として機能する各 NDB スイッチに対して ip domain-name コマンドを使用して、スイッチにドメイン名が設定されていることを確認します。次に例を示します。

conf t
ip domain-name cisco.com
hostname N9k-117
end

スイッチの FQDN は、N9K-117.cisco.com に対して構成されます。

手順

ステップ 1

サーバにログインします。

ステップ 2

openssl req コマンドを使用して、秘密キーと自己署名証明書を生成します。

例:


docker@docker-virtual-machine:~/TLS$ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out sw1-ca.pem -outform PEM -keyout sw1-ca.key

Generating a 2048 bit RSA private key
...+++
............................................+++
writing new private key to 'sw1-ca.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:CA
Locality Name (eg, city) []:SJ
Organization Name (eg, company) [Internet Widgits Pty Ltd]:cisco
Organizational Unit Name (eg, section) []:insbu
Common Name (e.g. server FQDN or YOUR name) []:N9K-117.cisco.com
Email Address []:myname@cisco.com

（注）

複数のスイッチがある場合、各スイッチに対して証明書ファイルとプライベートキーを生成します。

このコマンドは、証明書ファイル（sw1-ca.pem）およびプライベートキー（sw1-ca.key）を生成します。

ステップ 3

NDB スイッチにログインします。

ステップ 4

copy コマンドを使用して、証明書ファイル sw1-ca.pem とキーファイル sw1-ca.key をスイッチにコピーします。

例:

N9K-117# copy scp://docker@10.16.206.250/home/docker/Mallik/TLS_CA_june_23/sw1-ca.pem bootflash:
Enter vrf (If no input, current vrf 'default' is considered): management
docker@10.16.206.250's password: 
server.cer                                                                                                                                       100% 4676     4.6KB/s   00:00    
Copy complete, now saving to disk (please wait)...

N9K-117# copy scp://docker@10.16.206.250/home/docker/Mallik/TLS_CA_june_23/sw1-ca.key bootflash:
Enter vrf (If no input, current vrf 'default' is considered): management

docker@10.16.206.250's password: 
cert.key                                                                                                                                      100% 
Copy complete, now saving to disk (please wait)...

（注）

複数のスイッチをお持ちの場合、すべてのスイッチに対してこの手順を繰り返します。

ステップ 5

証明書ファイル、sw1-ca.pem、およびキーファイル、sw1-ca.key を nxapi コマンドを使用してスイッチで構成します。

例:

N9K-117 (config)# nxapi certificate httpskey keyfile bootflash:sw1-ca.key
Upload done. Please enable. Note cert and key must match.
N9K-117 (config)# 
N9K-117 (config)# nxapi certificate httpscrt certfile bootflash:sw1-ca.pem
Upload done. Please enable. Note cert and key must match.
 N9K-117 (config)#

（注）

複数のスイッチがある場合、各スイッチに対して対応する証明書ファイルとプライベートキーを構成します。

ステップ 6

nxapi certificate コマンドを使用して、スイッチの自己署名証明書を有効にします。.

例:

N9K-117 (config)# nxapi certificate enable
N9K-117 (config)#

（注）

スイッチで自己署名証明書を有効化する間にエラーがないことを確認します。

ステップ 7

サーバにログインします。

ステップ 8

copy コマンドを使用して、sw1-ca.key および sw1-ca.pem ファイルをコピーし、.PEM 形式に変換します。

例:

cp sw1-ca.key sw1-ndb-privatekey.pem
cp sw1-ca.pem sw1-ndb-cert.pem

ステップ 9

cat コマンドを使用して、秘密キーと証明書ファイルを連結します。

例:

docker@docker-virtual-machine:~/TLS$ cat sw1-ndb-privatekey.pem sw1-ndb-cert.pem > sw1-ndb.pem

ステップ 10

openssl コマンドを使用して、.pem ファイルを .p12 ファイル形式に変換します。パスワードで保護された .p12 証明書ファイルを作成するように指示メッセージが表示されたら、エクスポートパスワードを入力してください。

例:

docker@docker-virtual-machine:~/TLS$openssl pkcs12 -export -out sw1-ndb.p12 -in sw1-ndb.pem
Enter Export Password: cisco123
Verifying – Enter Export Password: cisco123
Enter a password at the prompt. Use the same password that you entered in the previous Step (cisco123)

ステップ 11

keytool コマンドを使用して、sw1-ndb.p12 をパスワード保護された Java キーストア（tlsKeyStore）ファイルに変換します。インストールされている java ディレクトリの jre/bin を使用します。

例:

docker@docker-virtual-machine:~/TLS$ ./(relativePath)/keytool -importkeystore -srckeystore sw1-ndb.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
Enter Destination Keystore password:cisco123
Re-enter new password:cisco123
Enter source keystore password:cisco123
Entry for alias 1 successfully imported.
Import command completed: 1 enteries successfully imported, 0 enteries failed or cancelled.

（注）

デフォルトでは、「1」という名前のエイリアスが最初のスイッチに対して、tlsKeyStore に保存されます。NDB コントローラが複数のスイッチを管理している場合は、すべてのスイッチに対してこの手順を繰り返します。2 番目のスイッチを追加すると、ユーティリティを使用して最初のスイッチエイリアスの名前を変更できます。以下に示された例を参照してください。


keytool -importkeystore -srckeystore sw2-ndb.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
keytool -importkeystore -srckeystore sw3-ndb.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks

ステップ 12

keytool コマンドを使用して、java tlsKeyStore のコンテンツをリストして検証します。

例:

docker@docker-virtual-machine:~/TLS$ keytool -list -v -keystore tlsKeyStore | more

次のタスク

後続のタスク、TLS TrustStore ファイルの作成に進みます。

TLS トラストストアファイルの作成

トラストストアは、1 つ以上のスイッチに対して生成された自己署名証明書から作成されます。コントローラ内に 1 つ以上のスイッチの証明書を保持します。このセクションでは、「自己署名証明書とキーの生成」セクションで作成した自己署名証明書を使用してトラストストアを作成する方法について説明します。コントローラに複数のスイッチがある場合、各スイッチには個別の証明書ファイルがあります（たとえば、sw1-ndb-cert.pem、sw2-ndb-cert.pem）。

手順

ステップ 1

サーバにログインします。

ステップ 2

keytool コマンドを使用して、証明書ファイル（たとえば、sw1-ndb-cert.pem）を Java トラストストア（tlsTrustStore）ファイルに変換します。パスワードで保護された Java トラストストア（tlsTrustStore）ファイルを作成するように求められたら、パスワードを入力します。パスワードは 6 文字以上にする必要があります。java ディレクトリにインストールされている jre/bin を使用します。

例:

docker@docker-virtual-machine:~/TLS$ ./(relativePath)/keytool -import -alias sw1 -file sw1-ndb-cert.pem -keystore tlsTrustStore -storetype jks
Enter Export Password: cisco123
Verifying – Enter Export Password: cisco123
Enter a password at the prompt. Use the same password that you entered in the previous Step (cisco123)

（注）

NDB コントローラが複数のスイッチを管理している場合は、すべてのスイッチに対してこの手順を繰り返して、すべてのスイッチキーを同じトラストストアに追加します。次に例を示します。

docker@docker-virtual-machine:~/TLS$ keytool -import -alias sw2 -file sw2-ndb-cert.pem -keystore tlsTrustStore
docker@docker-virtual-machine:~/TLS$ keytool -import -alias sw3 -file sw3-ndb-cert.pem -keystore tlsTrustStore
// Here sw2 and sw3 are alias for switch 2 and switch 3 for identification purpose.

ステップ 3

keytool コマンドを使用して、同じ tlsTrustStore 内の複数のスイッチのキーを一覧表示して確認します。

例:

docker@docker-virtual-machine:~/TLS$ keytool -list -v -keystore tlsTrustStore | more

TLS を使用した NDB の開始

TLS を使用して NDB を開始するには、次の手順を実行します。

手順

ステップ 1

NDB サーバーにログインします。

ステップ 2

runndb.sh コマンドを使用して、NDB アプリケーションを停止します (実行中の場合)。

例:

 ./runndb.sh -stop
Controller with PID: 17426 -- Stopped!

ステップ 3

作成した tlsKeystore および tlsTruststore ファイルを NDB の構成フォルダ（ndb/configuration）にコピーします。

例:


cp tlskeystore /root/ndb/configuration
cp tlsTrustStore /root/ndb/configuration

ステップ 4

runndb.sh スクリプトを使用して、TLS で NDB アプリケーションを開始します。

例:

./runndb.sh -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore

例:

デフォルトのユーザー名（admin）とデフォルト以外のパスワード（たとえば、pwd123）で NDB を起動するには:

./runndb.sh -osgiPasswordSync -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore
If ndb password is changed, OSGi webconsole password needs to be changed. 
To set non-default OSGi webconsole password, enter ndb Admin Password [default]: (Type the non-default password which was set)

（注）

TLS を無効にするには、./runndb.sh -notls コマンドを実行します。TLS を無効にして NDB を開始するには、./runndb.sh -notls -start コマンドを実行します。TLS を無効にする前に、必ず NDB を停止してください。TLS を無効にした後、NDB サーバーに接続されているデバイスのポート番号を 80 に変更する必要があります。

Nexus Dashboard Data Broker での TLS KeyStore と TrustStore パスワードの構成

Nexus Dashboard Data Broker がパスワードで保護された TLS キーストアおよびトラストストアファイルを読み取れるようにするには、TLS キーストアおよびトラストストアのパスワードを構成する必要があります。Nexus Dashboard Data Broker で TLS キーストアとトラストストアのパスワードを構成するには、次の手順を実行します。

手順

ステップ 1

Nexus Dashboard Data Broker サーバーにログインします。

ステップ 2

bin ディレクトリに移動します。

例:

cd ndb/bin

ステップ 3

ndb config-keystore-passwords コマンドを使用して、TLS キーストアとトラストストアのパスワードを構成します。

例:

./ndb config-keystore-passwords --user admin --password admin --url https://ip-address_localhost:8443 --verbose --prompt --keystore-password keystore_password --truststore-password truststore_password

Nexus Dashboard Data Broker が AAA (Tacacs/LDAP/Radius) で構成されており、上記のコマンドで ndb config-keystore-passwords が失敗し、401 未承認エラーが表示された場合：

ndb または xnc ディレクトリに移動します。
/runndb.sh -stop を使用して、Nexus Dashboard Data Broker サーバーを停止します。
Nexus Dashboard Data Broker config.ini ファイルで値を false から true に変更して、フラグ enable.LocalUser.Authentication を有効にします。
/runndb.sh -start を使用して、Nexus Dashboard Data Broker サーバーを起動します。

ndb config-keystore-passwords コマンドを再度実行します。

（注）

HA 環境では、クラスター内のすべての Nexus Dashboard Data Broker サーバーに対して上記の手順を実行する必要があります。

Nexus Dashboard Data Broker で TLS を有効にすると、Nexus Dashboard Data Broker サーバーと Nexus Dashboard Data Broker スイッチ間のすべての接続がポート 443 を使用して確立されます。ポート 443 を使用するように Nexus Dashboard Data Broker のデバイス接続を変更してください。

これらの手順を正常に完了すると、ポート 443 を使用してコントローラにネクサススイッチを追加できます。スイッチの FQDN を使用して、デバイスを exus Dashboard Data Broker コントローラに追加します。

スイッチの WebUI Sandbox を使用して証明書情報を確認できます。

NDB サーバーと NXAPI の NDB スイッチ間での TLS サードパーティ証明書の生成

このセクションでは、NDB サーバーと NDB スイッチの間で TLS サードパーティ証明書を生成する方法について説明します。ネットワーク内のスイッチごとに個別の証明書とキーを要求する必要があります。NDB サーバーと NDB スイッチの間で TLS 通信は、ポート 443 のみを使用します。

NDB サーバーと NXAPI の NDB スイッチの間で TLS サードパーティ証明書を生成するには、次の手順を実行します。

認証局から証明書の取得
NDB コントローラ用の Java tlsKeyStore および tlsTrustStore の生成
TLS を使用した NDB の開始
NDB での TLS キーストアおよびトラストストアパスワードの構成

（注）

両方のセクションのすべての手順を実行して、コントローラとスイッチ間の TLS での通信が正常に行われるようにします。

認証局から証明書の取得

2 つの方法で認証局（CA）から証明書を取得できます。秘密キーと証明書の両方に対して CA に直接アプローチすることができます。CA は、CA の署名を発行した公開キーを含む証明書とともに、あなたに代わって秘密キーを生成します。

もう 1 つのアプローチでは、openssl などのツールを使用して秘密キーを生成し、証明書発行機関への証明書署名要求（CSR）を生成できます。CA は CSR からのユーザー識別情報を使用して、公開キーで証明書を生成します。

始める前に

conf t
ip domain-name cisco.com
hostname N9k-117
end

スイッチの FQDN は、N9K-117.cisco.com に対して構成されます。

手順

ステップ 1

サーバにログインします。

ステップ 2

openssl コマンドを使用して、秘密鍵（cert.key）と証明書署名要求（cert.req）を生成します。

例:

docker@docker-virtual-machine:~/Mallik/TLS_CA$ openssl req -newkey rsa:2048 -sha256 -keyout cert.key -keyform PEM -out cert.req -outform PEM 

Generating a 2048 bit RSA private key
...............+++
....................+++
writing new private key to 'cert.key'
Enter PEM pass phrase:                            cisco123
Verifying - Enter PEM pass phrase:      cisco123
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:CA
Locality Name (eg, city) [Newbury]:SJ
Organization Name (eg, company) [My Company Ltd]:cisco
Organizational Unit Name (eg, section) []:insbu
Common Name (eg, your name or your server's hostname) []:N9K-117.cisco.com
Email Address []:myname@cisco.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:  cisco123
An optional company name []: cisco123


docker@docker-virtual-machine: # ls
cert.key  cert.req

ステップ 3

openssl コマンドを使用して CSR を確認します。

例:

docker@docker-virtual-machine:~/Mallik/TLS_CA$ openssl req -noout -text -in cert.req

ステップ 4

秘密キーはセキュリティパスフレーズで生成されます。秘密キーを復号する必要があります。秘密鍵からパスフレーズを削除するには、openssl コマンドを使用します。

例:

docker@docker-virtual-machine:~/Mk/TLS_CA$ ls
cert.key  cert.req 
docker@docker-virtual-machine:~/Mk/TLS_CA$cp cert.key  cert.keybkp
docker@docker-virtual-machine:~/Mk/TLS_CA$ rm cert.key
docker@docker-virtual-machine:~/Mk/TLS_CA$ openssl rsa -in cert.keybkp -out cert.key                                                                                   
Enter pass phrase for cert.keybkp: cisco123

（注）

この手順を繰り返して、すべてのスイッチの秘密キーからパスフレーズを削除します。

（注）

選択する CA の階層により、各 CSR に対して最大 3 つの証明書（証明書チェーン）を取得できます。このことは、各 NDB スイッチに対する CA から 3 つの証明書（root、中間、ドメイン）の取得を意味します。各タイプの証明書を識別するには、CA に確認する必要があります。証明書の命名規則は、認定機関ごとに異なる場合があります。例： test-root-ca-2048.cer (root)、test-ssl-ca.cer (intermediate)、N9K-117.cisco.com.cer (domain)

証明書はほとんどの場合、.PEM ファイル形式で共有されます。

cert.req ファイルデータは、サードパーティの証明機関に提出する必要があります。関連する手順に従って、3 つの（証明書）ファイルを取得してください。

ステップ 5

cat コマンドを使用して、3 つの証明書ファイルから 1 つの証明書ファイルを作成します。この連結は、ドメイン証明書、root 証明書、中間証明書の順番で行われます。cat コマンドのシンタックス： cat ドメイン証明書ルート証明書中間証明書 > server.cer

例:


$cat N9K-117.cisco.com.cer test-root-ca-2048.cer test-ssl-ca.cer > server.cer

ステップ 6

新しく作成した server.cer ファイルを編集して、連結された END 行と BEGIN 行を分割します。ファイルで何も削除しないでください。

例:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----


////// Modify the above line like this by adding a line feed between the two.
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

（注）

この手順をすべてのスイッチで繰り返します。

ステップ 7

NDB スイッチにログインします。

ステップ 8

秘密キー（cert.key）と CA からの証明書（server.cer）を copy コマンドを使用してスイッチにコピーします。

例:

N9K-117# copy scp://docker@10.16.206.250/home/docker/Mallik/TLS_CA_june_23/server.cer bootflash:
Enter vrf (If no input, current vrf 'default' is considered): management
docker@10.16.206.250's password: 
server.cer                                                                                                                                       100% 4676     4.6KB/s   00:00    
Copy complete, now saving to disk (please wait)...

N9K-117# copy scp://docker@10.16.206.250/home/docker/Mallik/TLS_CA_june_23/cert.key bootflash:
Enter vrf (If no input, current vrf 'default' is considered): management
docker@10.16.206.250's password: 
cert.key                                                                                                                                      100% 
Copy complete, now saving to disk (please wait)...

（注）

すべてのスイッチに対してこの手順を繰り返します。

ステップ 9

nxapi コマンドを使用して、スイッチに証明書ファイル sw1-ca.pem とキーファイル sw1-ca.key を設定します。

例:

N9K-117 (config)# nxapi certificate httpskey keyfile bootflash:cert.key
Upload done. Please enable. Note cert and key must match.
N9K-117 (config)# 
N9K-117 (config)# nxapi certificate httpscrt certfile bootflash:server.cer
Upload done. Please enable. Note cert and key must match.
 N9K-117 (config)#

（注）

複数のスイッチがある場合は、対応する証明書と秘密キーを各スイッチに構成します。

ステップ 10

nxapi certificate コマンドを使用して、スイッチの自己署名証明書を有効にします。.

例:

N9K-117 (config)# nxapi certificate enable
N9K-117 (config)#

（注）

スイッチで自己署名証明書を有効にするときにエラーがないことを確認します。

NDB コントローラの TLS キーストアと Truststore ファイルの作成

NDB は証明書とキーを使用して、スイッチ間の安全な通信を保護します。キーストアにキーと証明書を保存します。これらのファイルは、NDB に tlsTruststore および tlsKeystore ファイルとして保存されます。NDB コントローラの Java tlsKeyStore および tlsTrustStore ファイルを生成するには、次の手順を実行します。

手順

ステップ 1

TLS ディレクトリを作成し、それに移動します。

例:


mkdir -p TLS
cd TLS

ステップ 2

mypersonalca の下に 3 つのディレクトリと 2 つの前提条件ファイルを作成します。

例:


mkdir -p mypersonalca/certs
mkdir -p mypersonalca/private
mkdir -p mypersonalca/crl
echo "01" > mypersonalca/serial
touch mypersonalca/index.txt

コマンドを使用して、NDB に接続されている各スイッチの TLS 秘密キーと認証局（CA）ファイルを生成します。

ステップ 3

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out mypersonalca/certs/sw1-ca.pem -outform PEM -keyout mypersonalca/private/sw1-ca.key コマンドを使用して、NDB に接続された各スイッチの TLS 秘密鍵と認証局（CA）ファイルを生成します。

この手順により、2048 ビットのキー長の PEM 形式の TLS 秘密キーと CA ファイル（mypersonalca/certs/sw1-ca.pem、mypersonalca/private/sw1-ca.key）が生成されます。複数のスイッチがある場合は、これらのスイッチの CSR を生成するときに提供された正確な値を使用して、すべてのスイッチに対して sw1-ca.pem および sw1-ca.key ファイルを作成する必要があります。

（注）

「認証局からの証明書の取得」セクションで cert.key を生成するときに提供されたのと同じ入力を使用します。入力に不一致があると、新しいキーが生成されます。

例:


docker@docker-virtual-machine:~/TLS$ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out mypersonalca/certs/sw1-ca.pem -outform PEM -keyout mypersonalca/private/sw1-ca.key
Generating a 2048 bit RSA private key
...+++
............................................+++
writing new private key to 'mypersonalca/private/sw1-ca.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:CA
Locality Name (eg, city) []:SJ
Organization Name (eg, company) [Internet Widgits Pty Ltd]:cisco
Organizational Unit Name (eg, section) []:insbu
Common Name (e.g. server FQDN or YOUR name) []:N9K-117.cisco.com
Email Address []:myname@cisco.com

「認証局からの証明書の取得」セクションで作成した cert.key と server.cer を現在のディレクトリ（TLS）にコピーします。単一のスイッチの証明書とキーファイルを選択します。これらのファイルは、コントローラに接続しているスイッチに対して以前、生成されました。現在のスイッチの server.cer と cert.key を使用して、TLS キーストアファイルを作成します。

ステップ 4

複数のスイッチが接続されている場合、各スイッチに対して個別にこの手順を繰り返します。

ステップ 5

copy コマンドを使用して、server.cer および cert.key ファイルをコピーし、.PEM 形式に変換します。

例:

cp cert.key sw1-ndb-privatekey.pem
cp server.cer sw1-ndb-cert.pem

ステップ 6

cat コマンドを使用して、秘密キー（sw1-ndb-privatekey.pem）と証明書ファイル（sw1-ndb-cert.pem）を単一の .PEM ファイルに連結します。

例:

cat sw1-ndb-privatekey.pem sw1-ndb-cert.pem > sw1-ndb.pem

ステップ 7

openssl コマンドを使用して、.PEM ファイルを .P12 形式に変換します。指示メッセージが表示されたらエクスポートパスワードを入力します。パスワードには少なくとも 6 文字が含まれなければなりません。例：cisco123 sw1-ndb.pem ファイルはパスワード保護された sw1-ndb.p12 ファイルに変換されます。

例:

docker@docker-virtual-machine:~/TLS$openssl pkcs12 -export -out sw1-ndb.p12 -in sw1-ndb.pem
Enter Export Password: cisco123
Verifying – Enter Export Password: cisco123
Enter a password at the prompt. Use the same password that you entered in the previous Step (cisco123)

ステップ 8

keytool コマンドを使用して、sw1-ndb.p12 をパスワード保護された Java キーストア（tlsKeyStore）ファイルに変換します。このコマンドは、sw1-ndb.p12 ファイルをパスワード保護された tlsKeyStore ファイルに変換します。

例:

docker@docker-virtual-machine:~/TLS$ keytool -importkeystore -srckeystore sw1-ndb.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
Enter Destination Keystore password:cisco123

（注）

デフォルトでは、「1」というエイリアスが最初のスイッチの tlsKeyStore に保存されます。NDB コントローラが複数のスイッチを管理している場合は、すべてのスイッチに対してこの手順を繰り返します。2 番目のスイッチを追加すると、ユーティリティにより、最初のスイッチエイリアスの名前を変更し、新しいスイッチのエイリアスを名前変更するためにプロビジョニングします。たとえば、以下を参照してください。


keytool -importkeystore -srckeystore sw2-ndb.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
keytool -importkeystore -srckeystore sw3-ndb.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks

ステップ 9

keytool コマンドを使用して、java tlsKeyStore のコンテンツをリストして検証します。

例:

docker@docker-virtual-machine:~/TLS$ keytool -list -v -keystore tlsKeyStore | more

ステップ 10

keytool コマンドを使用して、証明書ファイル（sw1-ndb-cert.pem）を Java TrustStore（tlsTrustStore）ファイルに変換します。指示メッセージが表示されたときにパスワードを入力して、パスワード保護された Java TrustStore（tlsTrustStore）ファイルを作成します。パスワードは少なくとも 6 文字でなければなりません。

例:

docker@docker-virtual-machine:~/TLS$ keytool -import -alias sw1 -file sw1-ndb-cert.pem -keystore tlsTrustStore -storetype jks
Enter keystore password: cisco123
Re-enter new password: cisco123
Owner: EMAILADDRESS=myname@cisco.com, CN=localhost, OU=insbu, O=cisco, L=SJ, ST=CA, C=US
Issuer: EMAILADDRESS=myname@cisco.com, CN=localhost, OU=insbu, O=cisco, L=SJ, ST=CA, C=US
Serial number: c557f668a0dd2ca5
Valid from: Thu Jun 15 05:43:48 IST 2017 until: Sun Jun 13 05:43:48 IST 2027
Certificate fingerprints:
MD5: C2:7B:9E:26:31:7A:74:25:55:DF:A7:91:C9:5D:20:A3
SHA1: 3C:DF:66:96:72:12:CE:81:DB:AB:58:30:60:E7:CC:04:4D:DF:6D:B2
SHA256: DD:FB:3D:71:B4:B8:9E:CE:97:A3:E4:2D:D3:B6:90:CD:76:A8:5F:84:77:78:BE:49:6C:04:01:84:62:2C:2F:EB
Signature algorithm name: SHA256withRSA
Version: 3

Extensions: 

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 0D B3 CF 81 66 4A 33 4E EF 86 7E 26 C3 50 9B 73 ....fJ3N...&.P.s
0010: 38 EF DF 40 8..@
]
]

#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 0D B3 CF 81 66 4A 33 4E EF 86 7E 26 C3 50 9B 73 ....fJ3N...&.P.s
0010: 38 EF DF 40 8..@
]
]

Trust this certificate? [no]: yes
Certificate was added to keystore

（注）

NDB コントローラが複数のスイッチを管理する場合、すべてのスイッチに対してこの手順を繰り返して、同じ TrustStore にすべてのスイッチを追加してください。次に例を示します。

keytool -import -alias sw2 -file sw2-ndb-cert.pem -keystore tlsTrustStore
keytool -import -alias sw3 -file sw3-ndb-cert.pem -keystore tlsTrustStore

ステップ 11

keytool コマンドを使用して同じ tlsTrustStore のキーをリストし、検証します。

例:

docker@docker-virtual-machine:~/TLS$ keytool -list -v -keystore tlsTrustStore | more

TLS を使用した NDB の開始

TLS を使用して NDB を開始するには、次の手順を実行します。

手順

ステップ 1

NDB サーバーにログインします。

ステップ 2

runndb.sh コマンドを使用して、NDB アプリケーションを停止します (実行中の場合)。

例:

 ./runndb.sh -stop
Controller with PID: 17426 -- Stopped!

ステップ 3

作成した tlsKeystore および tlsTruststore ファイルを NDB の構成フォルダ（ndb/configuration）にコピーします。

例:


cp tlskeystore /root/ndb/configuration
cp tlsTrustStore /root/ndb/configuration

ステップ 4

runndb.sh スクリプトを使用して、TLS で NDB アプリケーションを開始します。

例:

./runndb.sh -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore

例:

デフォルトのユーザー名（admin）とデフォルト以外のパスワード（たとえば、pwd123）で NDB を起動するには:

./runndb.sh -osgiPasswordSync -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore
If ndb password is changed, OSGi webconsole password needs to be changed. 
To set non-default OSGi webconsole password, enter ndb Admin Password [default]: (Type the non-default password which was set)

（注）

Nexus Dashboard Data Broker での TLS KeyStore と TrustStore パスワードの構成

手順

ステップ 1

Nexus Dashboard Data Broker サーバーにログインします。

ステップ 2

bin ディレクトリに移動します。

例:

cd ndb/bin

ステップ 3

ndb config-keystore-passwords コマンドを使用して、TLS キーストアとトラストストアのパスワードを構成します。

例:

./ndb config-keystore-passwords --user admin --password admin --url https://ip-address_localhost:8443 --verbose --prompt --keystore-password keystore_password --truststore-password truststore_password

ndb または xnc ディレクトリに移動します。
/runndb.sh -stop を使用して、Nexus Dashboard Data Broker サーバーを停止します。
Nexus Dashboard Data Broker config.ini ファイルで値を false から true に変更して、フラグ enable.LocalUser.Authentication を有効にします。
/runndb.sh -start を使用して、Nexus Dashboard Data Broker サーバーを起動します。

ndb config-keystore-passwords コマンドを再度実行します。

（注）

HA 環境では、クラスター内のすべての Nexus Dashboard Data Broker サーバーに対して上記の手順を実行する必要があります。

スイッチの WebUI Sandbox を使用して証明書情報を確認できます。

WebUI ブラウザと NDB サーバーの間でTLS 自己署名証明書を生成する

自己署名証明書を使用して、集中モードで実行されている Web ブラウザと NDB サーバー間の通信を保護できます。このセクションでは、WebUI ブラウザと NDB アプリケーション間の通信を保護するための自己署名証明書を生成する方法について説明します。デフォルトでは、Cisco NDB は、Cisco NDB に発行され、デフォルトの有効性で Cisco NDB によって発行されるデフォルトの証明書とともに出荷されます。構成フォルダーの下にある generateWebUIcertificate.sh スクリプトを使用して、自己署名証明書を作成できます。Cisco NDB リリース 3.5 以前の場合、これらの証明書は 6 か月間有効です。Cisco NDB リリース 3.6 以降、証明書のデフォルトの有効期間は 6 か月ですが、証明書の有効期間を設定できます。

（注）

NDB の自己署名 TLS 証明書は、集中化モードでのみ作成できます。

WebUI ブラウザと集中モードで実行されている NDB サーバーの間で TLS 自己署名証明書を生成する

集中型環境で実行されている WebUI ブラウザと NDB サーバーの間で TLS 自己署名証明書を生成する

次の手順を実行して、WebUI ブラウザと集中モードで実行されている NDB サーバーの間で TLS 自己署名証明書を生成します。

手順

ステップ 1

NDB サーバーにログインし、現在のディレクトリ \ndb\configuration を変更します。

例:

[root@RHEL-VM-NDB-ACI]# cd \ndb\configuration

ステップ 2

generateWebUIcertificate.sh スクリプトを使用して、TLS 自己署名証明書を生成します。

例:

[root@RHEL-VM-NDB-ACI configuration]# ./generateWebUIcertificate.sh

***********************************
Entor Fully qualified domain name :
***********************************
NDB-browser This can be FQDN of the NDB java application as well
***************************
Enter Organizational unit :
***************************
INSBU
********************
Enter Organization :
********************
cisco
****************
Enter Location :
****************
SJ
*************
Enter State :
*************
CA
***************
Enter Country :
***************
USA
***************
Enter keypass :
***************
cisco123
*****************
Enter storepass :
******************
cisco123
**************************************
Enter the validity in number of days :
**************************************
365  in NDB 3.5 this script will let you to specify the certificate validity.
*********************************************************************************************************************************
Below process will rename the existing key file to <old_keystore>, will generate a new key file. Do you want to continue (y/n) ?
*********************************************************************************************************************************
y
*******************************
Self-Signed Certificate Created
*******************************
Alias name: cisco
Creation date: Jan 6, 2019
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Issuer: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Serial number: b404be5
Valid from: Sun Jan 06 20:22:05 PST 2019 until: Mon Jan 06 20:22:05 PST 2020
Certificate fingerprints:
         MD5:  71:07:F6:4E:57:6A:08:3A:AD:06:32:B3:6C:5F:8F:52
         SHA1: 04:08:B9:D5:B7:EB:ED:E0:F9:22:49:14:FA:C6:09:39:22:32:43:A2
         SHA256: 34:D9:EB:34:0A:52:D1:4A:DD:F1:8B:14:D0:84:E4:1C:57:8B:2B:99:9B:E5:A1:4C:C7:8C:CD:AE:24:31:49:75
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 63 8A 92 8F 6F 0F 45 BD   EE 55 C5 A8 99 3B F6 F7  c...o.E..U...;..
0010: AC FA 4A 21                                        ..J!
]
]

********************************
Displayed the generated keystore
********************************
****************************************************
Configured the keystore details on tomcat-server.xml
****************************************************
**********************************************************************************************
The newly generated key will used on next NDB restart. Do you want to restart NDB now (y/n) ?
**********************************************************************************************
y
Doesn't seem any Controller daemon is currently running
Running controller in background with PID: 13573, to connect to it please SSH to this host on port 2400
NDB GUI can be accessed using below URL:
[https://10.16.206.160:8443]
[https://[fe80::250:56ff:fe90:b764]:8443]
[https://10.16.206.159:8443]
[https://192.168.1.123:8443]
[https://[fe80::250:56ff:fe90:9c79]:8443]

*************
NDB Restarted
*************

（注）

generateWebUIcertificate.sh スクリプトは、NDB アプリケーションを再ロードして、ブラウザから NDB Java アプリケーションにアクセスしたときにブラウザがこの証明書の使用を開始するようにします。

ステップ 3

keytool -list -v -keystore keystore_Name コマンドを使用して、生成された証明書を復号化します。プロンプトが表示されたら、ストアパスワードを入力します。

例:

[root@RHEL-VM-NDB-ACI configuration]# keytool -list -v -keystore keystore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: cisco
Creation date: Jul 6, 2019
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Issuer: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Serial number: b404be5
Valid from: Sun Jan 06 20:22:05 PST 2019 until: Mon Jan 06 20:22:05 PST 2020
Certificate fingerprints:
         MD5:  71:07:F6:4E:57:6A:08:3A:AD:06:32:B3:6C:5F:8F:52
         SHA1: 04:08:B9:D5:B7:EB:ED:E0:F9:22:49:14:FA:C6:09:39:22:32:43:A2
         SHA256: 34:D9:EB:34:0A:52:D1:4A:DD:F1:8B:14:D0:84:E4:1C:57:8B:2B:99:9B:E5:A1:4C:C7:8C:CD:AE:24:31:49:75
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 63 8A 92 8F 6F 0F 45 BD   EE 55 C5 A8 99 3B F6 F7  c...o.E..U...;..
0010: AC FA 4A 21                                        ..J!
]
]

*******************************************
*******************************************

ステップ 4

自己署名証明書は、ブラウザと互換性のない JKS 形式で生成されます。したがって、ブラウザに証明書をインポートする前に、これらの証明書を PKCS12 形式に変換する必要があります。次の手順を関ry法して、JKS 形式の証明書を PKCS12 形式に変換します。keytool コマンドを使用して、JKS 形式の証明書を PKCS12 形式に変換します。

（注）

変換する前に必ず元の証明書のコピーをとっておいてください。

例:


 keytool -importkeystore -srckeystore keystore -srcstorepass cisco123 -srckeypass cisco123 -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias cisco -deststorepass cisco123 -destkeypass cisco123

（注）

keytool コマンドの入力は、UI 証明書の生成中に提供される入力と一致する必要があります。

（注）

結果として得られる証明書ファイル（keystore.p12）は PKSC12 形式です。

ステップ 5

この証明書をブラウザーの信頼されたルート証明書ストアに追加します。証明書を信頼ルート証明書ストアストアに追加する方法については、それぞれの Web ブラウザのヘルプを参照してください。

ゲストシェル環境を使用して、組み込みモードで実行されている Web ブラウザと NDB サーバー間で TLS 自己署名証明書を生成する

ゲストシェル環境を使用して、Web ブラウザと組み込みモードで実行されている NDB サーバーとの間で TLS 自己署名証明書を生成するには、次の手順を実行します。

手順

ステップ 1

guestshell コマンドを使用してゲストシェルに接続します。

例:

N9K-C93108TC-EX-108# guestshell
[admin@guestshell ~]$
[admin@guestshell ~]$

ステップ 2

現在のディレクトリを \ndb\configuration に変更します。

例:

[admin@guestshell ~]$ cd \ndb\configuration

ステップ 3

/home/admin/ndb/configuration/generateWebUIcertificate.sh スクリプトを使用して、TLS 自己署名証明書を生成します。

例:

[root@RHEL-VM-NDB-ACI configuration]# ./generateWebUIcertificate.sh

***********************************
Entor Fully qualified domain name :
***********************************
NDB-browser This can be FQDN of the NDB java application as well
***************************
Enter Organizational unit :
***************************
INSBU
********************
Enter Organization :
********************
cisco
****************
Enter Location :
****************
SJ
*************
Enter State :
*************
CA
***************
Enter Country :
***************
USA
***************
Enter keypass :
***************
cisco123
*****************
Enter storepass :
******************
cisco123
**************************************
Enter the validity in number of days :
**************************************
365  in NDB 3.5 this script will let you to specify the certificate validity.
*********************************************************************************************************************************
Below process will rename the existing key file to <old_keystore>, will generate a new key file. Do you want to continue (y/n) ?
*********************************************************************************************************************************
y
*******************************
Self-Signed Certificate Created
*******************************
Alias name: cisco
Creation date: Jan 6, 2019
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Issuer: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Serial number: b404be5
Valid from: Sun Jan 06 20:22:05 PST 2019 until: Mon Jan 06 20:22:05 PST 2020
Certificate fingerprints:
         MD5:  71:07:F6:4E:57:6A:08:3A:AD:06:32:B3:6C:5F:8F:52
         SHA1: 04:08:B9:D5:B7:EB:ED:E0:F9:22:49:14:FA:C6:09:39:22:32:43:A2
         SHA256: 34:D9:EB:34:0A:52:D1:4A:DD:F1:8B:14:D0:84:E4:1C:57:8B:2B:99:9B:E5:A1:4C:C7:8C:CD:AE:24:31:49:75
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 63 8A 92 8F 6F 0F 45 BD   EE 55 C5 A8 99 3B F6 F7  c...o.E..U...;..
0010: AC FA 4A 21                                        ..J!
]
]

********************************
Displayed the generated keystore
********************************
****************************************************
Configured the keystore details on jetty-ssl-context.xml
****************************************************
**********************************************************************************************
The newly generated key will used on next NDB restart. Do you want to restart NDB now (y/n) ?
**********************************************************************************************
n
*************
The newly generated key will be used on the next NDB restart.
*************

（注）

ブラウザから NDB Java アプリケーションにアクセスするときに、ブラウザがこの証明書の使用を開始するようにするには、guestshell reboot コマンドを使用して guestshell を手動でリブートします。

ステップ 4

keytool -list -v -keystore keystore_Name コマンドを使用して、生成された証明書をデコードします。プロンプトが表示されたら、ストアパスワードを入力します。

例:

[root@RHEL-VM-NDB-ACI configuration]#  keytool -list -v -keystore keystore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: cisco
Creation date: Jul 6, 2019
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Issuer: CN=NDB-browser, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA
Serial number: b404be5
Valid from: Sun Jan 06 20:22:05 PST 2019 until: Mon Jan 06 20:22:05 PST 2020
Certificate fingerprints:
         MD5:  71:07:F6:4E:57:6A:08:3A:AD:06:32:B3:6C:5F:8F:52
         SHA1: 04:08:B9:D5:B7:EB:ED:E0:F9:22:49:14:FA:C6:09:39:22:32:43:A2
         SHA256: 34:D9:EB:34:0A:52:D1:4A:DD:F1:8B:14:D0:84:E4:1C:57:8B:2B:99:9B:E5:A1:4C:C7:8C:CD:AE:24:31:49:75
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 63 8A 92 8F 6F 0F 45 BD   EE 55 C5 A8 99 3B F6 F7  c...o.E..U...;..
0010: AC FA 4A 21                                        ..J!
]
]

*******************************************
*******************************************

ステップ 5

自己署名証明書は、ブラウザと互換性のない JKS 形式で生成されます。ブラウザに証明書をインポートする前に、これらの証明書を PKCS12 形式に変換する必要があります。JKS 形式の証明書を PKCS12 形式に変換するには、次の手順を実行します。keytool コマンドを使用して、JKS 形式の証明書を PKCS12 形式に変換します。

（注）

変換する前に必ず元の証明書のコピーをとっておいてください。

例:


 keytool -importkeystore -srckeystore keystore -srcstorepass cisco123 -srckeypass cisco123 -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias cisco -deststorepass cisco123 -destkeypass cisco123

（注）

keytool コマンドの入力は、UI 証明書の生成中に提供される入力と一致する必要があります。

（注）

結果として得られる証明書ファイル（keystore.p12）は PKSC12 形式です。

ステップ 6

CA 証明書を Web ブラウザの信頼ルート証明書ストアにアップロードします。証明書を信頼ルート証明書ストアストアに追加する方法については、それぞれの Web ブラウザのヘルプを参照してください。証明書を Web ブラウザにアップロードするときにプロンプトが表示されたら、証明書の作成中に作成したパスワードを使用します。

ステップ 7

ゲストシェルを再起動して、NDB を再起動します。

WebUI ブラウザと NDB サーバー間の TLS サードパーティ証明書の生成

Web ブラウザと集中モードで実行されている NDB サーバー間の通信を保護できます。このセクションでは、CA 証明書を生成し、証明書を JKS 形式に変換し、証明書を Web ブラウザーにアップロードする方法について説明します。CA 証明書を生成するには、証明書署名要求（CSR）を生成し、認証局（CA）に送信して検証を受ける必要があります。オープンソースツールを使用して CSR を生成できます。

WebUI ブラウザと集中モードで実行されている NDB サーバーの間で TLS サードパーティ証明書を生成する

集中型モードで実行中の WebUI ブラウザと NDB サーバーの間での TLS サードパーティ証明書の生成

次の手順を実行して、WebUI ブラウザと集中モードで実行されている NDB サーバーとの間で TLS サードパーティ証明書を生成します。

手順

ステップ 1

openssl req コマンドを使用して証明書署名要求（CSR）を生成します。

例:

[root@NDB-server ~]# openssl req -newkey rsa:2048 -sha256 -keyout ndb-server.key -keyform PEM -out ndb-server.req -outform PEM
Generating a 2048 bit RSA private key
...+++
................................................+++
writing new private key to 'ndb-server.key'
Enter PEM pass phrase:  cisco123
Verifying - Enter PEM pass phrase:  cisco123
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:CA
Locality Name (eg, city) [Newbury]:SJ
Organization Name (eg, company) [My Company Ltd]:cisco
Organizational Unit Name (eg, section) []:insbu
Common Name (eg, your name or your server's hostname) []:ndb-server.cisco.com
Email Address []:chburra@cisco.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:cisco123
An optional company name []:cisco123



[root@NDB-server ~]# ls
ndb-server.req   ndb-server.key

（注）

ndb-server.req（CSR）ファイルは、証明書発行機関（CA）に提出されます。

（注）

CA が提供する証明書をブラウザにエクスポートする時と同じ情報を使用する必要があります。CSR ファイル、cert.req が CA に提出されます。

ステップ 2

CSR 要求を確認または表示するには、openssl req コマンドを使用します。

例:

[root@NDB-server ~]# openssl req -noout -text -in ndb-server.req
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=CA, L=SJ, O=cisco, OU=insbu, CN=ndb-server.cisco.com/emailAddress=chburra@cisco.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:b5:30:75:e8:c8:5f:05:3b:0e:4f:aa:00:d9:64:
                    8d:bf:b2:80:20:56:c3:be:b0:4c:e0:52:e5:be:d8:
                    d2:74:85:4e:8a:ba:d3:1e:30:76:bf:e5:de:7d:51:
                    11:79:8e:bc:96:38:7a:23:5a:26:31:50:50:fa:29:
                    44:ab:56:b6:0d:41:38:ba:d1:d5:b4:e3:ba:a3:6c:
                    4a:35:73:27:d9:fd:5c:4b:21:85:1a:f9:4d:b0:9e:
                    f3:ae:ce:49:98:ef:a2:f8:11:ab:bd:7e:64:ee:68:
                    68:19:6e:8f:3c:54:30:0f:28:01:13:b0:3d:34:b8:
                    f9:f5:cc:4a:84:d8:e5:d2:27:47:cc:83:76:92:ad:
                    92:62:f3:a3:35:be:14:ce:38:af:2a:c5:2e:fa:b8:
                    31:6b:71:cd:56:00:1f:0d:cc:b0:f8:fc:b0:52:91:
                    f8:9c:cf:45:13:c9:b5:86:fa:30:dd:88:78:01:15:
                    fb:5c:c9:6f:5b:b7:80:28:6c:86:54:c0:f2:5f:35:
                    70:82:49:5c:79:1c:f2:23:dd:50:d5:47:12:37:a3:
                    3f:f9:1d:90:8f:c0:e8:18:09:2e:66:8d:c3:72:17:
                    7f:7d:27:da:b1:cc:26:2d:8c:6b:ee:c5:e8:b5:78:
                    31:7c:bb:ba:6d:2c:e5:a3:29:7e:c1:4a:93:19:ed:
                    9a:e7
                Exponent: 65537 (0x10001)
        Attributes:
            unstructuredName         :cisco123
            challengePassword        :cisco123
    Signature Algorithm: sha256WithRSAEncryption
        9c:9a:51:e0:1d:e4:0b:8f:c1:c6:f5:e0:d2:f6:30:0e:18:af:
        a7:b2:a4:4a:57:d7:07:44:cd:9c:fa:2d:0e:8b:c9:31:5b:16:
        6b:84:42:0b:ed:06:5c:ed:30:d8:9b:ee:5d:79:f4:8a:e3:52:
        3c:b3:4a:eb:6c:22:a2:f4:35:80:28:3a:67:62:7f:5f:dc:80:
        e0:74:f0:3c:39:26:39:3a:76:6a:6a:98:e9:68:f9:b7:58:bf:
        e7:44:2e:e7:73:0a:9c:62:28:b2:c6:09:41:81:b2:53:46:14:
        e6:e4:dc:ca:90:81:5a:5e:dc:1b:dc:36:2c:86:5f:37:29:4c:
        b0:ee:85:2b:34:f2:82:8a:d4:fc:a0:ce:10:e4:44:4e:d0:7a:
        37:6d:3e:f9:ff:a1:19:8c:db:06:bf:be:87:57:a1:cb:05:15:
        0b:9f:6c:8b:c2:ad:22:25:10:f0:4d:0f:4d:b7:be:71:87:f7:
        85:24:e7:2d:f9:59:86:1a:b7:88:57:16:93:31:1f:d7:e5:07:
        42:77:00:f9:ac:44:3b:6c:35:0f:80:5d:00:6f:ea:be:fe:e7:
        28:53:0c:6b:5f:0c:76:bf:8c:a7:60:57:63:05:06:ff:ac:3d:
        f1:63:54:d0:d0:13:44:b1:e9:53:6b:32:11:e2:83:26:04:f5:
        23:67:6b:de

ステップ 3

秘密キー、ndb-server.key はパスフレーズでセキュアされます。証明書秘密キーを復号する必要があります。秘密キーは openssl rsa コマンドを使用して復号します。

例:

[root@NDB-server ~]# cp ndb-server.key  ndb-server.keybkp
[root@NDB-server ~]# rm ndb-server.key
 [root@NDB-server ~]# openssl rsa -in ndb-server.keybkp -out ndb-server.key
Enter pass phrase for ndb-server.keybkp: cisco123
writing RSA key

（注）

ndb-server.req ファイルのデータは、サードパーティの証明機関に提出する必要があります。関連する手順に従って、証明書ファイルを取得します。

選択する CA の階層により、各 CSR に対して最大 3 つの証明書（証明書チェーン）を取得できます。このことは、各 NDB スイッチに対する CA から 3 つの証明書（root、中間、ドメイン）の取得を意味します。証明書のそれぞれのタイプを識別するためには、CA を確認する必要があります。証明書の命名規則は、認定機関ごとに異なる場合があります。例：qvrca2.cer（root）、hydsslg2.cer（中間）、ndb-server.cisco.com-39891.cer（ドメイン）。

証明書はほとんどの場合、.PEM ファイル形式で共有されます。

ステップ 4

cat コマンドを使用して 3 つの証明書ファイルから 1 つの証明書ファイルを作成します。この連結は、ドメイン証明書、root 証明書、中間証明書の順番で行われます。cat コマンドのシンタックス：cat domain certificate root certificate intermediate certificate > ndb-server.cer

例:

[root@NDB-server ~]# cat ndb-server.cisco.com-39891.cer qvrca.cer hydsslg2.cer > ndb-server.cer

ステップ 5

新しく作成した server.cer ファイルを編集して、連結された END 行と BEGIN 行を分割します。ファイルで何かを削除しないでください。

例:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----


////// Modify the above line like this by adding a line feed between the two.
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

ステップ 6

ndb-server.cer および ndb-server.key ファイルを使用して TLS NDB サーバーキーストアファイルを作成します。copy コマンドを使用して、スイッチにファイルをコピーします。

例:

cp ndb-server.key ndb-server-ndb-privatekey.pem
      cp ndb-server.cer ndb-server-ndb-cert.pem

ステップ 7

cat コマンドを使用して、秘密鍵と証明書ファイルを単一の .PEM ファイルに結合します。

例:

cat ndb-server-ndb-privatekey.pem  ndb-server-ndb-cert.pem > ndb-server-ndb.pem

ステップ 8

CA が PEM 形式で証明書を提供し、証明書の拡張子は .pem です。PEM 形式の証明書を PKCS12 形式に変換する必要があります。PEM ファイルである ndb-server-ndb.pem を openssl pkcs12 コマンドを使用して、.P12 ファイル形式に変更します。指示メッセージが表示されたらエクスポートパスワードを入力します。パスワードには少なくとも 6 文字が含まれなければなりません。例：cisco123 ndb-server-ndb.pem ファイルはパスワード保護された ndb-server-ndb.p12 ファイルに変換されます。

例:

[root@NDB-server ~]# openssl pkcs12 -export -out ndb-server-ndb.p12 -in ndb-server-ndb.pem
Enter Export Password:cisco123
Verifying - Enter Export Password:cisco123

ステップ 9

keytool コマンドを使用して、ndb-server-ndb.p12 をパスワード保護された Java キーストア（ndb-server-keystore）ファイルに変換します。このコマンドは、sw1-ndb.p12 ファイルをパスワードで保護された ndb-server-keystore ファイルに変換します。宛先 JKS ストアの新しいパスワードを作成し、プロンプトが表示されたら送信元キーストアのパスワードを入力します。

例:

[root@NDB-server ~]# .(relativePath)/keytool -importkeystore -srckeystore ndb-server-ndb.p12 -srcstoretype pkcs12 -destkeystore ndb-server-keystore -deststoretype jks
Enter destination keystore password:cisco123
Re-enter new password:cisco123
Enter source keystore password:--cisco123
Entry for alias 1 successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
[root@NDB-server ~]#

ステップ 10

keytool コマンドを使用して、java tlsKeyStore のコンテンツをリストして検証します。

例:

[root@NDB-server ~]#.(relativePath)/keytool -list -v -keystore ndb-server-keystore

ステップ 11

証明書の生成中に提供されたキーストアパスワードを使用して、jetty-ssl-context.xml（ndb/configuration/etc に格納）を構成します。VI エディタを使用して、KeyStorePath、KeyStorePassword、TrustStorePath、TrustStorePassword で次の行を編集できます。

例:


<Set name="KeyStorePath"><Property name="jetty.base" default="." />/<Property name="jetty.sslContext.keyStorePath" deprecated="jetty.keystore" default="configuration/ndb-server-keystore"/></Set>
<Set name="KeyStorePassword"><Property name="jetty.sslContext.keyStorePassword" deprecated="jetty.keystore.password" default="cisco123"/></Set>

<Set name="KeyManagerPassword"><Property name="jetty.sslContext.keyManagerPassword" deprecated="jetty.keymanager.password" default="cisco123"/></Set>
<Set name="TrustStorePath"><Property name="jetty.base" default="." />/<Property name="jetty.sslContext.trustStorePath" deprecated="jetty.truststore" default="configuration/ndb-server-keystore"/></Set>

<Set name="TrustStorePassword"><Property name="jetty.sslContext.trustStorePassword" deprecated="jetty.truststore.password" default="cisco123"/></Set>

ステップ 12

NDB を再起動します。

ステップ 13

ゲストシェル環境を使用して、組み込みモードで実行されている Web ブラウザと NDB サーバー間で TLS サードパーティ証明書を生成する

ゲストシェル環境を使用して、組み込みモードで実行されている Web ブラウザと NDB サーバーの間で TLS サードパーティ証明書を生成するには、次の手順を実行します。

手順

ステップ 1

feature コマンドを使用して、スイッチで bash-shell 機能を有効にします。

例:

N9396TX-116(config)# feature bash-shell

ステップ 2

run コマンドを使用して、スイッチで bash-shell モードを開始します。

例:

N9396TX-116(config)# run bash
bash-4.2$

ステップ 3

openssl req コマンドを使用して証明書署名要求（CSR）を生成します。プロンプトが表示されたら、必要な情報を入力します。

例:

bash-4.2$ openssl req -newkey rsa:2048 -sha256 -keyout ndb-server.key -keyform PEM -out ndb-server.req -outform PEM
Generating a 2048 bit RSA private key
...+++
................................................+++
writing new private key to 'ndb-server.key'
Enter PEM pass phrase:  cisco123
Verifying - Enter PEM pass phrase:  cisco123
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:CA
Locality Name (eg, city) [Newbury]:SJ
Organization Name (eg, company) [My Company Ltd]:cisco
Organizational Unit Name (eg, section) []:insbu
Common Name (eg, your name or your server's hostname) []:ndb-server.cisco.com
Email Address []:chburra@cisco.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:cisco123
An optional company name []:cisco123



bash-4.2$ ls

ndb-server.req   ndb-server.key

（注）

openssl コマンドは、秘密キー ndb-server.key と証明書署名要求ファイル ndb-server.req を作成します。ndb-server.req（CSR）ファイルが証明書発行機関（CA）に送信されます。

（注）

CA が提供する証明書をブラウザにエクスポートするときは、同じ情報を使用する必要があります。CSR ファイル cert.req が CA に送信されます。

ステップ 4

コンテンツを表示したり、CSR 要求を確認したりするには、openssl req コマンドを使用します。

例:

bash-4.2$ openssl req -noout -text -in ndb-server.req
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=CA, L=SJ, O=cisco, OU=insbu, CN=ndb-server.cisco.com/emailAddress=chburra@cisco.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:b5:30:75:e8:c8:5f:05:3b:0e:4f:aa:00:d9:64:
                    8d:bf:b2:80:20:56:c3:be:b0:4c:e0:52:e5:be:d8:
                    d2:74:85:4e:8a:ba:d3:1e:30:76:bf:e5:de:7d:51:
                    11:79:8e:bc:96:38:7a:23:5a:26:31:50:50:fa:29:
                    44:ab:56:b6:0d:41:38:ba:d1:d5:b4:e3:ba:a3:6c:
                    4a:35:73:27:d9:fd:5c:4b:21:85:1a:f9:4d:b0:9e:
                    f3:ae:ce:49:98:ef:a2:f8:11:ab:bd:7e:64:ee:68:
                    68:19:6e:8f:3c:54:30:0f:28:01:13:b0:3d:34:b8:
                    f9:f5:cc:4a:84:d8:e5:d2:27:47:cc:83:76:92:ad:
                    92:62:f3:a3:35:be:14:ce:38:af:2a:c5:2e:fa:b8:
                    31:6b:71:cd:56:00:1f:0d:cc:b0:f8:fc:b0:52:91:
                    f8:9c:cf:45:13:c9:b5:86:fa:30:dd:88:78:01:15:
                    fb:5c:c9:6f:5b:b7:80:28:6c:86:54:c0:f2:5f:35:
                    70:82:49:5c:79:1c:f2:23:dd:50:d5:47:12:37:a3:
                    3f:f9:1d:90:8f:c0:e8:18:09:2e:66:8d:c3:72:17:
                    7f:7d:27:da:b1:cc:26:2d:8c:6b:ee:c5:e8:b5:78:
                    31:7c:bb:ba:6d:2c:e5:a3:29:7e:c1:4a:93:19:ed:
                    9a:e7
                Exponent: 65537 (0x10001)
        Attributes:
            unstructuredName         :cisco123
            challengePassword        :cisco123
    Signature Algorithm: sha256WithRSAEncryption
        9c:9a:51:e0:1d:e4:0b:8f:c1:c6:f5:e0:d2:f6:30:0e:18:af:
        a7:b2:a4:4a:57:d7:07:44:cd:9c:fa:2d:0e:8b:c9:31:5b:16:
        6b:84:42:0b:ed:06:5c:ed:30:d8:9b:ee:5d:79:f4:8a:e3:52:
        3c:b3:4a:eb:6c:22:a2:f4:35:80:28:3a:67:62:7f:5f:dc:80:
        e0:74:f0:3c:39:26:39:3a:76:6a:6a:98:e9:68:f9:b7:58:bf:
        e7:44:2e:e7:73:0a:9c:62:28:b2:c6:09:41:81:b2:53:46:14:
        e6:e4:dc:ca:90:81:5a:5e:dc:1b:dc:36:2c:86:5f:37:29:4c:
        b0:ee:85:2b:34:f2:82:8a:d4:fc:a0:ce:10:e4:44:4e:d0:7a:
        37:6d:3e:f9:ff:a1:19:8c:db:06:bf:be:87:57:a1:cb:05:15:
        0b:9f:6c:8b:c2:ad:22:25:10:f0:4d:0f:4d:b7:be:71:87:f7:
        85:24:e7:2d:f9:59:86:1a:b7:88:57:16:93:31:1f:d7:e5:07:
        42:77:00:f9:ac:44:3b:6c:35:0f:80:5d:00:6f:ea:be:fe:e7:
        28:53:0c:6b:5f:0c:76:bf:8c:a7:60:57:63:05:06:ff:ac:3d:
        f1:63:54:d0:d0:13:44:b1:e9:53:6b:32:11:e2:83:26:04:f5:
        23:67:6b:de

ステップ 5

秘密キー ndb-server.key は、パスフレーズで保護されています。証明書の秘密キーの暗号化を解除する必要があります。openssl rsa コマンドを使用して秘密キーの暗号化を解除します。

例:

bash-4.2$ cp ndb-server.key  ndb-server.keybkp
bash-4.2$ rm ndb-server.key
bash-4.2$ openssl rsa -in ndb-server.keybkp -out ndb-server.key
Enter pass phrase for ndb-server.keybkp: cisco123
writing RSA key

（注）

選択する CA の階層により、各 CSR に対して最大 3 つの証明書（証明書チェーン）を取得できます。このことは、各 NDB スイッチに対する CA から 3 つの証明書（root、中間、ドメイン）の取得を意味します。各タイプの証明書を識別するには、CA に確認する必要があります。証明書の命名規則は、認定機関ごとに異なる場合があります。例：qvrca2.cer（root）、hydsslg2.cer（中間）、ndb-server.cisco.com-39891.cer（ドメイン）。

証明書はほとんどの場合、.PEM ファイル形式で共有されます。

ステップ 6

例:

bash-4.2$ cat ndb-server.cisco.com-39891.cer qvrca.cer hydsslg2.cer > ndb-server.cer

ステップ 7

新しく作成した server.cer ファイルを編集して、連結された END 行と BEGIN 行を分割します。ファイルで何も削除しないでください。

例:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----


////// Modify the above line like this by adding a line feed between the two.
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

ステップ 8

例:

cp ndb-server.key ndb-server-ndb-privatekey.pem
      cp ndb-server.cer ndb-server-ndb-cert.pem

ステップ 9

cat コマンドを使用して、秘密キーと証明書ファイルを単一の .PEM ファイルに結合します。

例:

cat ndb-server-ndb-privatekey.pem  ndb-server-ndb-cert.pem > ndb-server-ndb.pem

ステップ 10

CA は PEM 形式の証明書を提供し、証明書の拡張子は .pem です。PEM 形式の証明書を PKCS12 形式に変換する必要があります。PEM ファイルである ndb-server-ndb.pem を openssl pkcs12 コマンドを使用して、.P12 ファイル形式に変更します。指示メッセージが表示されたらエクスポートパスワードを入力します。パスワードには少なくとも 6 文字が含まれなければなりません。例：cisco123 ndb-server-ndb.pem ファイルはパスワード保護された ndb-server-ndb.p12 ファイルに変換されます。

例:

bash-4.2$ openssl pkcs12 -export -out ndb-server-ndb.p12 -in ndb-server-ndb.pem
Enter Export Password:cisco123
Verifying - Enter Export Password:cisco123

ステップ 11

証明書ファイルを NDB 構成フォルダーにコピーします。

例:

bash-4.2$ sudo cp ndb-server-ndb.p12 /isan/vdc_1/virtual-instance/guestshell+/rootfs/usr/bin/ndb/configuration/

ステップ 12

exit コマンドを使用して、bash シェルモードを終了します。

例:

bash-4.2$ exit
exit
N9396TX-116#

ステップ 13

guestshell コマンドを使用してゲストシェルに接続します。

例:

N9396TX-116# guestshell
[admin@guestshell ~]$

ステップ 14

現在のディレクトリを ndb/configuration に変更します。

例:

[admin@guestshell ~]$ cd ndb/configuration

ステップ 15

keytool コマンドを使用して、ndb-server-ndb.p12 をパスワードで保護された Java KeyStore（ndb-server-keystore）ファイルに変換します。このコマンドは、ndb-server-ndb.p12 ファイルをパスワードで保護された ndb-server-keystore ファイルに変換します。宛先 JKS ストアの新しいパスワードを作成し、プロンプトが表示されたら送信元キーストアのパスワードを入力します。

例:

[admin@guestshell configuration]$ keytool -importkeystore -srckeystore ndb-server-ndb.p12 -srcstoretype pkcs12 -destkeystore ndb-server-keystore -deststoretype jks
Enter destination keystore password: cisco123
Re-enter new password: cisco123
Enter source keystore password: cisco123
Entry for alias 1 successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

ステップ 16

keytool コマンドを使用して、java tlsKeyStore のコンテンツをリストして検証します。

例:

[admin@guestshell configuration]$ keytool -list -v -keystore ndb-server-keystore

ステップ 17

証明書の生成中に提供されたキーストアパスワードを使用して、jetty-ssl-context.xml（ndb/etc に格納）を構成します。VI エディタを使用して、keystore および keystorepass で次の行を編集できます。

例:


<Set name="KeyStorePath"><Property name="jetty.base" default="." />/<Property name="jetty.sslContext.keyStorePath" deprecated="jetty.keystore" default="configuration/ndb-server-keystore"/></Set>
<Set name="KeyStorePassword"><Property name="jetty.sslContext.keyStorePassword" deprecated="jetty.keystore.password" default="cisco123"/></Set>

<Set name="KeyManagerPassword"><Property name="jetty.sslContext.keyManagerPassword" deprecated="jetty.keymanager.password" default="cisco123"/></Set>

<Set name="TrustStorePath"><Property name="jetty.base" default="." />/<Property name="jetty.sslContext.trustStorePath" deprecated="jetty.truststore" default="configuration/ndb-server-keystore"/></Set>

<Set name="TrustStorePassword"><Property name="jetty.sslContext.trustStorePassword" deprecated="jetty.truststore.password" default="cisco123"/></Set>

ステップ 18

ステップ 19

NDB を再起動します。

Cisco Nexus Dashboard Data Broker 構成ガイド、リリース 3.10.1

偏向のない言語

翻訳について

検索結果

章のタイトル： TLS 証明書、KeyStore およびトラストストア ファイルの管理

TLS 証明書、KeyStore およびトラストストア ファイルの管理

NXAPI に対して NDB サーバーと NDB スイッチの間での TLS 自己署名証明書の生成

自己署名証明書とキーの生成

始める前に

手順

例:

例:

例:

例:

例:

例:

例:

例:

例:

次のタスク

TLS トラストストア ファイルの作成

手順

例:

例:

TLS を使用した NDB の開始

手順

例:

例:

例:

例:

Nexus Dashboard Data Broker での TLS KeyStore と TrustStore パスワードの構成

手順

例:

例:

NDB サーバーと NXAPI の NDB スイッチ間での TLS サードパーティ証明書の生成

認証局から証明書の取得

始める前に

手順

例:

例:

例:

例:

例:

例:

例:

例:

NDB コントローラの TLS キーストアと Truststore ファイルの作成

手順

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

TLS を使用した NDB の開始

手順

例:

例:

例:

例:

Nexus Dashboard Data Broker での TLS KeyStore と TrustStore パスワードの構成

手順

例:

例:

WebUI ブラウザと NDB サーバー の間でTLS 自己署名証明書を生成する

集中型環境で実行されている WebUI ブラウザと NDB サーバーの間で TLS 自己署名証明書を生成する

手順

例:

例:

例:

例:

ゲスト シェル環境を使用して、組み込みモードで実行されている Web ブラウザと NDB サーバー間で TLS 自己署名証明書を生成する

手順

例:

例:

例:

章のタイトル： TLS 証明書、KeyStore およびトラストストアファイルの管理

TLS 証明書、KeyStore およびトラストストアファイルの管理

TLS トラストストアファイルの作成

WebUI ブラウザと NDB サーバーの間でTLS 自己署名証明書を生成する

ゲストシェル環境を使用して、組み込みモードで実行されている Web ブラウザと NDB サーバー間で TLS 自己署名証明書を生成する

ゲストシェル環境を使用して、組み込みモードで実行されている Web ブラウザと NDB サーバー間で TLS サードパーティ証明書を生成する