Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

gNOI証明書管理サービス

gNOI CertificateManagement サービスを使用して、ターゲットネットワーク要素上の証明書を管理します。

概要

gnoi.certificateパッケージ内のgNOICertificateManagementサービスは、ターゲットネットワーク要素での証明書管理を処理します。プロト定義ファイルは https://github.com/openconfig/gnoi/blob/master/cert/cert.proto にあります。

公開鍵基盤(PKI)は、公開暗号化鍵の配布と識別をサポートします。これにより、ユーザーはインターネットなどのネットワーク上で安全にデータを交換したり、相手の身元を確認することができます。Junos PKIを使用すると、証明書のダウンロード、生成、検証など、Junosデバイス上の公開キー証明書を管理できます。gNOI CertificateManagement サービスは、Junos PKI を介して行われる証明書管理の操作を定義します。主な操作は以下の2つです。

  • インストール—ターゲットネットワークデバイスに新しい証明書IDを使用して新しい証明書をインストールします。証明書IDが既に存在する場合、操作はエラーを返します。

  • ローテーション—ターゲットネットワークデバイス上で、すでに既存の証明書IDを持っている既存の証明書を置き換えます。プロセス中にストリームが中断したり、ステップが失敗したりした場合、デバイスは元の証明書にロールバックします。

図1は、Install()Rotate()の操作のワークフローの概要を示しています。どちらの操作でも、クライアントは証明書署名要求(CSR)自体を生成するか、ターゲットにCSRの生成をリクエストできます。いずれの場合も、クライアントはCSRを認証機関(CA)に転送して、デジタル証明書をリクエストします。次に、クライアントは、Install()操作用の新しい証明書 ID、またはRotate()操作用の既存の証明書IDを使用して、ターゲットに証明書をロードします。Rotate()操作の場合、クライアントは交換証明書も検証し、検証の成功または失敗に基づいてRotate()操作を確定またはキャンセルする必要があります。クライアントが操作をキャンセルすると、サーバーは証明書、キーペア、およびCAバンドル(リクエストに存在する場合)をロールバックします。

Junos OS Evolvedリリース23.1R1以降、 Install()Rotate()、または LoadCertificate() 操作中に、gNOIサーバーは対応するCA証明書を使用して新しいエンドエンティティ証明書を検証します。したがって、gNOIサーバーのPKIには、新しい証明書を検証するルートCA証明書が含まれている必要があります。必要なCA証明書をgNOI CAバンドルの一部として読み込むことも、個別に読み込むこともできます。検証に失敗した場合、デバイスは新しい証明書をインストールしません。

図1:gNOI証明書管理サービスのインストールとローテーション操作 Sequence diagram of certificate management with gNOI: gNOI Client requests a CSR from gNOI Server, CA Server signs it, and certificate rotation is completed.

gNOIサーバーは、gNOIサービス用に1つのグローバルCA証明書バンドルのみをサポートします。gNOI CertificateManagement サービスを使用してCAバンドルを読み込む場合、以下のステートメントが適用されます。

  • CertificateManagementサービスは、常にca-profile-group予約済み識別子gnoi-ca-bundleを使用して、CA証明書バンドルを読み込みます。

  • CertificateManagementサービスを使用してCA証明書バンドルを読み込む場合、デバイスは暗黙的に相互認証を使用します。

  • CertificateManagementサービスが新しいCA証明書バンドルを読み込むリクエストを送信すると、サーバーはデバイスから以前のCAバンドルの証明書をクリアし、新しい証明書を読み込みます。

  • CertificateManagementサービスを使用してCA証明書バンドルを読み込み、デバイス構成で相互認証を明示的に設定する場合は、設定されたステートメントが優先されます。

したがって、最初にgNOIサーバーでサーバー専用認証を設定してから、 Install() RPCを使用してCA証明書を読み込むことができます。gNOI を使用して初期 CA 証明書バンドルを読み込むと、デバイスは以下の手順を実行します。

  • Junos PKIにCA証明書を追加します。
  • ca-profile-group識別子gnoi-ca-bundleを使用して、[edit security pki]階層レベルでgNOI CA証明書バンドルを自動的に設定します。
  • サーバーのみの認証から相互認証にスイッチします。

Rotate() RPCは、回転操作中の認証モード間の切り替えをサポートしていません。したがって、Rotate()は、操作中にデバイスがサーバーのみの認証から相互認証に切り替わる原因となるため、gNOIサーバーへのCA証明書バンドルの初めての読み込みをサポートしていません。認証モードが変更されると、ネットワークデバイスはgRPCスタックを再起動する必要があり、接続は失われます。ストリームが中断した場合、クライアントはローテーション要求を完了できず、デバイスはRotate()要求が開始される前に配置されていた証明書にロールバックします。

注:

[edit system services extension-service request-response grpc ssl]階層レベルのhot-reloadingステートメントは、証明書更新時に、操作中に認証モードが変更されていない場合にのみ、gRPCセッションを維持します。たとえば、認証モードがサーバーのみから相互認証に切り替わる、またはその逆の場合、クライアントは切断されます。

サポートされているRPC

表1は、JunosデバイスでサポートされるCertificateManagementサービスRPCの概要を示しています。

表1:サポートされているcert.proto RPC
RPC 説明 リリースで導入
CanGenerateCSR()

ターゲットデバイスにクエリして、指定されたキータイプ、キーサイズ、証明書タイプで証明書署名要求(CSR)を生成できるかどうかを判断します。サポートされている値:

  • キータイプ:KT_RSA

  • キーサイズ: 1024, 2048, 4096

  • 証明書の種類:CT_X509

gNOIサーバーが特定のキータイプ、キーサイズ、および証明書タイプをサポートしているかどうか True を返します。

Junos OS Evolved 23.1R1

GenerateCSR()

証明書署名要求(CSR)を生成して返します。

Junos OS Evolved 22.2R1

GetCertificates()

ターゲットデバイスにロードされているローカル証明書を返します。

Junos OS Evolved 22.2R1

Install()

CSRリクエストを作成し、CSRに基づいて証明書を生成し、新しい証明書IDを使用して証明書をロードすることで、ターゲットデバイスに新しい証明書をロードします。

Junos OS Evolved 22.2R1

LoadCertificate()

認証機関(CA)によって署名された証明書をターゲットデバイスにロードします。

Junos OS Evolved 22.2R1

LoadCertificateAuthorityBundle()

ターゲットデバイスにCA証明書バンドルをロードします。

Junos OS Evolved 22.2R1

RevokeCertificates()

ターゲットデバイスで指定された証明書IDを持つ証明書を取り消します。

Junos OS Evolved 23.1R1

Rotate()

CSRリクエストを作成し、CSRに基づいて証明書を生成し、既存の証明書IDを使用して証明書を読み込むことで、ターゲットデバイス上の既存の証明書を置き換えます。

Junos OS Evolved 22.2R1

ネットワークデバイスの設定

始める前に:

[edit system services http servers]階層レベルで設定されたgNOIサーバーの場合、追加の設定は必要ありません。

[edit system services extension-service request-response grpc ssl]階層レベルで設定されたgNOIサーバーの場合、同じ階層レベルでuse-pkiおよびhot-reloadingステートメントを設定する必要があります。hot-reloadingステートメントは、セッションに影響を与える証明書を更新する際にgRPCセッションを維持するために必要です。ステートメントを設定するには:

  1. ローカル証明書にPKIデータベースを使用するようにデバイスを設定します。
  2. デバイスがgRPCセッションを終了せずに証明書をリロードできるようにします。
  3. 設定をコミットします。

証明書をインストールする

RPCInstall()CertificateManagementサービスを使用して、ターゲットデバイスに新しい証明書をロードできます。Install()操作を使用して新しい証明書をインストールする場合、ターゲットデバイスにまだ存在しない新しい証明書IDを指定する必要があります。オプションで、Install()操作の一部としてCA証明書バンドルを読み込むこともできます。

Install()操作の一環として、デバイスは新しい証明書を検証します。そのため、Junos PKIには、新しい証明書を検証するルートCA証明書が必要です。必要なCA証明書は、Install()操作の一部として読み込むことができます。PKI にまだない場合は、操作の前に個別に読み込むこともできます。

gRPCセッション認証に使用する新しいローカル証明書をインストールする場合は、新しい証明書IDを使用するように、デバイス上のgRPCサーバー設定も更新する必要があります。

例:証明書をインストールする

この例では、gNOIサーバーは最初はローカル証明書のみで構成されており、相互認証を使用するようには構成されていません。gNOIクライアントは、 Install() RPCを使用して、新しいローカル証明書とCA証明書バンドルをデバイスにロードします。CAバンドルがgNOIサーバーにロードされると、サーバーはデフォルトで相互認証を使用します。CAバンドルには、クライアント証明書のルートCA証明書と、新しいサーバー証明書のルートCA証明書が含まれています。

クライアントは、以下の操作を実行する gnoi_cert_install_certificate_csr.py Pythonアプリケーションを実行します。

  • ターゲットにCSRを生成するようリクエストします。
  • CSRに基づいて署名された証明書を取得します。
  • 新しいサーバー証明書、サーバーの新しいルート CA 証明書、およびクライアントのルート CA 証明書をターゲットネットワークデバイスにロードします。

アプリケーションは、適切なパラメータとともに InstallCertificateRequest メッセージを使用して、CSRの生成と証明書の読み込みのためのリクエストを定義します。各要求に対して、アプリケーションは Install() RPCを使用して要求をネットワークデバイスに送信します。

gnoi_cert_install_certificate_csr.pyアプリケーションは、チャネルを確立するためのgrpc_channelモジュールをインポートします。grpc_channelモジュールについては、「gNOIサービスを設定する」で説明しています。アプリケーションの引数はargs_cert_install_csr.txtファイルに格納されます。アプリケーションファイルと引数ファイルがここに示されています。

gnoi_cert_install_certificate_csr.py

args_cert_install_csr.txt

アプリケーションの実行

クライアントがアプリケーションを実行すると、アプリケーションはCSRを要求し、署名された証明書を取得して、新しいサーバー証明書とCA証明書をターゲットネットワークデバイスにロードします。

新しいサーバー証明書をインストールした後、gRPCセッション認証にその証明書IDを使用するようにサーバーを設定する必要があります。特定のサーバー設定用に local-certificate ステートメントを更新します。この設定は、以下のいずれかの階層レベルで設定できます。

  • [システムサービス拡張サービスリクエスト応答gRPC SSLの編集]

  • [TLS name システムサービスHTTPサーバーサーバーの編集]

次に例を示します。

さらに、 Install() 操作は新しいCA証明書を読み込むため、デバイスは暗黙的に相互認証を使用します。その結果、チャネルを確立する際に、後続のすべてのgRPCセッションにクライアントの証明書とキーを含める必要があります。

アプリケーションを実行し、サーバー上に既に存在する証明書IDを指定すると、Install()操作には新しい証明書IDが必要になるため、アプリケーションはALREADY_EXISTSエラーを返します。

証明書のローテーション

RPCRotate()CertificateManagementサービスを使用して、ターゲットデバイス上の既存の証明書を置き換えることができます。Rotate()操作を使用して既存の証明書を置き換える場合は、ターゲットデバイスにすでに存在する証明書IDを使用して証明書を読み込む必要があります。オプションで、Rotate()操作の一環として既存のgNOI CA証明書バンドルを置き換えることもできます。

Rotate()操作はInstall()操作と似ていますが、Rotate()操作は新しい証明書をインストールするのではなく、既存の証明書を置き換える点が異なります。さらに、クライアントは、更新された証明書が機能することを検証し、証明書検証の成功または失敗に基づいてRotate()要求を確定またはキャンセルする必要があります。

Rotate()操作の一環として、デバイスは新しい証明書を検証します。そのため、Junos PKIには、新しい証明書を検証するルートCA証明書が必要です。必要なCA証明書は、Rotate()操作の一部として読み込むことができます。PKI にまだない場合は、操作の前に個別に読み込むこともできます。

例:証明書のローテーション

この例では、クライアントは gnoi_cert_rotate_certificate_csr.py Pythonアプリケーションを実行し、以下の操作を実行します。

  • ターゲットにCSRを生成するようリクエストします。
  • CSRに基づいて署名された証明書を取得します。
  • ターゲットネットワークデバイス上のノード証明書とgNOI CAバンドルを置き換えます。
  • 新しい証明書を検証します。
  • Rotate操作を終了します。

アプリケーションは、 RotateCertificateRequest メッセージを適切なパラメータとともに使用して、CSRの生成、証明書およびCAバンドルのロードのためのリクエストを定義します。各要求に対して、アプリケーションは Rotate() RPCを使用して要求をネットワークデバイスに送信します。ターゲットデバイスが新しいノード証明書を検証できるように、アプリケーションは既存のCAバンドルを新しいCAバンドルに置き換えます。バンドルには、クライアントCA証明書と、ノード証明書の検証に必要なCA証明書の両方が含まれています。

アプリケーションは、ネットワークデバイスとの新しいgRPCセッションを作成し、単純な Time() RPCを実行することで、新しい証明書が動作することを検証しますが、任意のRPCでセッション認証テストできます。セッションが正常に確立されると、アプリケーションはローテーション要求を確定し、セッション認証に失敗するとローテーション要求を取り消します。

gnoi_cert_rotate_certificate_csr.pyアプリケーションは、チャネルを確立するためのgrpc_channelモジュールをインポートします。grpc_channelモジュールについては、gNOIサービスを設定するで説明しています。アプリケーションの引数はargs_cert_rotate_csr.txtファイルに格納されます。アプリケーションファイルと引数ファイルがここに示されています。

gnoi_cert_rotate_certificate_csr.py

args_cert_rotate_csr.txt

root_ca_cert引数は、初期チャネル資格情報に必要なサーバーのルートCA証明書であることに注意することが重要です。server_root_ca1引数は、サーバーの新しい証明書に対応するルートCA証明書です。Rotate()操作中に新しいローカル証明書を検証するには、Junos PKIに新しいルートCA証明書が必要です。さらに、新しい証明書を検証するgRPCセッションのチャネル資格情報は、このルートCA証明書を使用します。この例では、新しいサーバー証明書と古いサーバー証明書に同じルート CA 証明書を使用していますが、別のケースでは異なる場合があります。

アプリケーションの実行

クライアントがアプリケーションを実行すると、アプリケーションはCSRを要求し、署名された証明書を取得して、交換証明書とCAバンドルをターゲットネットワークデバイスにロードします。その後、アプリケーションは、単純な Time() RPCを実行する新しいgRPCセッションで交換証明書を検証します。検証に成功すると、クライアントはローテーション要求を確定します。

証明書の失効

gNOIクライアントは、 RevokeCertificates() RPCを使用して、ターゲットデバイスから1つ以上の証明書を削除できます。クライアントには、取り消す証明書IDのリストが記載された RevokeCertificatesRequest メッセージが含まれます。

gNOIサーバーは、 RevokeCertificates() リクエストを受信すると、リスト内の各証明書IDを次のように処理します。

  • 証明書が存在し、失効が成功した場合、デバイスはファイル システムと Junos PKI から証明書を削除し、正常に失効した証明書のリストに証明書 ID を追加します。

  • 証明書が存在する場合、失効に失敗した場合、デバイスは証明書IDと失敗の理由を証明書失効エラーリストに含めます。

  • 証明書が存在しない場合、デバイスは失効操作が成功したとみなし、正常に失効した証明書のリストに証明書IDを追加します。

注:

リクエストによって現在のセッションに使用されている証明書が取り消された場合、セッションは影響を受けません。

リクエストを処理した後、gNOIサーバーは以下を含む RevokeCertificatesResponse メッセージを返します。

  • 正常に取り消された証明書IDのリスト。

  • 証明書IDと失敗の理由を含む失効エラーのリスト。

例:証明書の失効

この例では、クライアントが gnoi_cert_revoke_certificates.py Pythonアプリケーションを実行し、サーバー上の2つの証明書を取り消します。最初の証明書IDは、デバイス上の有効な識別子です。2 番目の証明書 ID は、デバイスに存在しない識別子です。

アプリケーションは、 RevokeCertificatesRequest メッセージを適切なパラメーターとともに使用して要求を定義します。アプリケーションは、 RevokeCertificates() RPCをネットワークデバイスに送信して操作を実行します。

gnoi_cert_revoke_certificates.pyアプリケーションは、チャネルを確立するためのgrpc_channelモジュールをインポートします。grpc_channelモジュールについては、gNOIサービスを設定するで説明しています。アプリケーションの引数はargs_cert_revoke_certificates.txtファイルに格納されます。アプリケーションファイルと引数ファイルがここに示されています。

gnoi_cert_revoke_certificates.py

args_cert_revoke_certificates.txt

アプリケーションの実行

クライアントがアプリケーションを実行すると、指定された証明書を取り消すようにターゲットデバイスに指示します。デバイスは、正常に取り消された証明書とエラーのリストを返します。デバイスは、有効な証明書IDと、デバイスに現在存在しない証明書IDの両方について、操作が成功したとみなします。

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
23.1R1-EVO
Junos OS Evolved リリース 23.1R1 以降、 Install()Rotate()、および LoadCertificate() の操作は、操作の一環として新しい証明書を検証します。