外部認証の設定
[ローカル認証を使用（Use Local Authentication）] オプション
アウトバウンド HTTP 接続
Lightweight Directory Access Protocol の設定
- LDAP の問題のトラブルシューティング
LDAP 認証の設定（AD 認証）
- LDAP 認証の問題のトラブルシューティング
シングルサインオンの設定
- ID プロバイダー（IdP）と共有する情報
- SSO の問題のトラブルシューティング
SSL 証明書およびキー

外部認証の設定

この外部認証を有効にすると、認証を外部システムに委ねることができます。認証の現在のオプションは、Lightweight Directory Access Protocol（LDAP）とシングルサインオン（SSO）です。このオプションを有効にすると、サインインするすべてのユーザーが、選択したメカニズムを使用して認証を行うようになります。特に [ローカル認証を使用（Use Local Authentication）] オプションが有効なユーザーがいない場合は、LDAP 接続が正しく設定されていることを確認することが重要です。推奨されるアプローチは、[ローカル認証を使用（Use Local Authentication）] オプションをオンにして、サイト管理者のログイン情報を持つローカル認証されたユーザーを少なくとも 1 人指定する方法です。このユーザーは、LDAP が正しく設定されていることを確認できます。接続が正常にセットアップされたら、ユーザー編集フローで [ローカル認証を使用（Use Local Authentication）] オプションをオフにして、このユーザーを外部認証に移行させることもできます。

サイト管理者は、外部接続の問題やユーザーサインインの失敗などのデバッグに役立つ追加のデバッグメッセージを有効にできます。これは、[外部認証デバッグ（External Auth Debug）] オプションをオンにすることで有効にできます。このオプションをオンにすると、追加の説明ログメッセージが「external_auth_debug.log」という名前の別のログファイルに書き込まれます。デバッグが完了したら、[外部認証デバッグ（External Auth Debug）] をオフにして、余分なログがログファイルに書き込まれないようにすることを推奨します。

Note

「ローカル認証を使用」オプションで示されているように、ユーザーごとに有効化すると、ユーザーは外部認証をバイパスできます。このオプションは、外部認証が有効になっている場合の警告メッセージを介して、リンクからユーザー編集フローに移動することでも有効にできます。

連携が有効になっている場合は、SSO を使用した外部認証が推奨される認証アプローチです。ナビゲーションバーで、[プラットフォーム（Platform）] > [外部認証（External Authentication）] を選択します。

Note

Secure Workload リリース 3.7.1.5 以降、外部認証セッションの削除時間が 6 時間から 9 時間に延長されました。この設定は、外部認証またはオンプレミスのみに適用されます。

サイト管理者およびカスタマーサポートの両方は、外部認証を構成できます。リカバリコードを生成できるのはサイト管理者だけであり、外部認証が有効になっている場合は、リカバリコードの生成がサポートされないことに注意してください。

Note

各管理者ユーザーには、ダウンロード用の 6 つのリカバリコードが提供されます。これらのリカバリコードは、管理者ユーザーがログイン後にダウンロードする必要があります。
リカバリコードは、ログイン時にユーザー名と組み合わせて使用する必要があります。[パスワード（Password）] フィールドにリカバリコードを入力します。
ユーザー名とリカバリコードをパスワードとして使用してログインすると、ユーザーはパスワードリセット画面にリダイレクトされ、新しいパスワードを設定できます。使用されたリカバリコードは、以降のログインでは無効になることに注意してください。
利用可能なすべてのコードを使い果たす前に、リカバリコードを再生成することを推奨します。

[ローカル認証を使用（Use Local Authentication）] オプション

構成がセットアップされると、サイト管理者はユーザーが外部認証を使用しないようにできます。ユーザー編集セクションの「ローカル認証を使用」フラグを有効にすると、ユーザーごとに設定できます。ユーザーに対してこのフィールドを選択すると、そのユーザーはすべてのセッションからログアウトされます。

Warning

少なくとも 1 人のユーザーがローカル認証アクセスを持っていることを確認してください。

ユーザーの「Use Local Authentication」オプションが削除されており（つまりチェックされていない）、たまたまこのユーザーがオプションを使用した最後のユーザーだった場合、Secure Workload にサインインするためのローカル認証アクセスを持つユーザーがいなくなります。つまり、設定や接続の問題など、外部認証システムで中断が発生した場合、ユーザーはサインインできなくなります。ローカルで認証された最後のユーザーを削除しようとすると、警告が表示されます。

外部認証を介してログインするユーザーのセッションは短くなり、セッションの有効期限が切れると再ログインを求められます。外部認証を介してログインするユーザーは、サイトでパスワードをリセットできません（会社の Web サイトでリセットする必要があります）。ただし、ユーザーに「ローカル認証を使用」フラグが設定されている場合は、パスワードのリセットが可能です。

アウトバウンド HTTP 接続

Cisco Cloud から最新の脅威インテリジェンスデータセットが取得されるようにするには、アウトバウンド HTTP 接続をセットアップすることを強く推奨します。

Warning

エンタープライズアウトバウンド HTTP リクエストでは、HTTP プロキシの設定に加えて、エンタープライズファイアウォールアウトバウンドルールから periscope.tetrationcloud.com および uas.tetrationcloud.com へのトラフィックを許可する必要がある場合があります。以下を参照してください。

periscope.tetrationcloud.com への TLS 接続は、既知の脆弱性を識別するために脅威インテリジェンスデータを転送するために使用されます。したがって、Cisco Secure Workload では、ドメインの X.509 証明書の署名 CA 証明書を、Secure Workload に付属の信頼できるルート CA 証明書と照合して、ドメイン名の信頼性を検証することが不可欠です。X.509 信頼チェーンを改ざんすると、機能が正常に動作しなくなります。

サイト管理者とカスタマーサポートのユーザーは、アウトバウンド HTTP 設定にアクセスできます。左側のナビゲーションバーで、[プラットフォーム（Platform）] > [アウトバウンドHTTP（Outbound HTTP）]をクリックします。


フィールド	説明
ステータス（Status）	Secure Workload アプライアンスが Secure Workload Cloud にアクセスして脅威インテリジェンスデータセットの更新を取得できるかどうかを示します。ステータスチェックは、更新ボタンをクリックして再トリガーできます。次の HTTP プロキシ設定を使用して、Secure Workload 展開に基づいて HTTP プロキシ設定を構成できます。
[HTTP プロキシを有効化（Enable HTTP Proxy）]	このオプションが有効になっている場合、すべての外部 HTTP 接続で HTTP プロキシが使用されます。
[ホスト（Host）]	HTTP プロキシホストアドレス
ポート（Port）	HTTP プロキシポート番号
[ユーザー名（Username）]	HTTP プロキシサーバーが Basic 認証を使用する場合にのみ必要です。
[パスワード（password）]	HTTP プロキシサーバーが Basic 認証を使用する場合にのみ必要です。

Lightweight Directory Access Protocol の設定

ユーザーを認証するために、Lightweight Directory Access Protocol（LDAP）オプションを選択します。つまり、これを有効にすると、すべてのユーザーがログアウトされ、その後のサインインでは LDAP の電子メールとパスワードを使用して認証されます。

「フェデレーション」が有効になっている場合、現在 LDAP は認証メカニズムとして推奨されていません。

LDAP が有効になっている場合、新しいユーザーを作成するための推奨ワークフローは次のとおりです。

サイト管理者は、新しいユーザーが LDAP を使用して初めてログインする前に、まず電子メールで新しいユーザーを作成し、LDAP 承認（AD 承認）を構成して適切な役割を割り当てるようにお勧めします。新しいユーザーが適切なロールなしで LDAP を使用してログインした場合、デフォルトのロールはユーザーに割り当てられません。

Figure 7. Lightweight Directory Access Protocol の設定

フィールド

説明

ユーザーの自動作成（Auto Create Users）

[ユーザーの自動作成（Auto Create Users）] をオンにすると、初回のログイン時に該当ユーザーが存在しない場合にユーザーが作成されます。これにより、サイト管理者は、ユーザーのログインを許可する前にユーザーを事前にプロビジョニングする必要がなくなります。Secure Workload アクセスを [ユーザー（Users）] ページで手動で作成したユーザーに制限する必要がある場合は、このオプションをオフにする必要があります。

ホスト（Host）

認証に使用される LDAP ホスト。

ポート（Port）

認証に使用される LDAP ポート。

メール属性

LDAP の外部認証設定の [属性（Attribute）] フィールドは、カンマ区切りの値をサポートしています。これにより、認証中に複数の LDAP 属性をフィルタとして使用できます。

Note

LDAP データベース内のユーザのユーザー名が samAccountName の場合、適切なユーザー認証のために、 samAccountName を[属性（Attribute）] フィールドに含める必要があります。

ベース（Base）

ユーザーが検索される LDAP ベース DN。

SSL

暗号化を有効にして、「ldaps://」を使用します。

SSL 検証（SSL Verify）

サーバーの証明書に基づいて、完全修飾ドメイン名（FQDN）などのサーバーの SSL 属性を確認します。

SSL認証局証明書（SSL Certificate Authority Cert）

LDAP サーバーの SSL 証明書の署名証明書。サーバーの証明書チェーンを公的に検証できない場合に必要です。

管理者ユーザ（Admin User）

LDAP サーバーに対してバインドするために使用される LDAP 管理者ユーザー名（Secure Workload ユーザーではない）。例：[ユーザー]@[ドメイン] または [ドメイン]\\[ユーザー]

管理者パスワード（Admin Password）

LDAP サーバーに対してバインドするために使用される LDAP 管理者パスワード。

LDAP認証（Ldap Authorization）

LDAP 認証は、「LDAP 認証の設定（AD 認証）」で説明されているように、有効にして構成することができます。

Note

SMTP サーバーを構成しないと、サイト管理者は電子メールを使用してユーザーを認証できません。SMTP サーバーを構成しないと、電子メールベースの認証の影響を受けるためです。

LDAP 構成が有効になると、[ローカル認証を使用（Use Local Authentication）] オプションが有効になっているユーザーを除くすべてのユーザーがセッションからログアウトされます。

[保存（保存）] ボタンをクリックすると、LDAP 構成を保存できます。LDAP 構成が正常に保存された後、LDAP 接続をテストする前に 1 分間待つことをお勧めします。

[接続のテスト（Test Connection）] ボタンを使用して LDAP 構成を保存した後、LDAP 接続をテストできます。これにより、入力された管理者ログイン情報を使用して LDAP サーバーに対するバインドが試行されます。

LDAP の問題のトラブルシューティング

LDAP 接続のテスト時にエラーが発生した場合は、次の点を確認してください。

LDAP 管理者の資格情報が正しいかどうかを確認します。
ホスト、ポート、SSL などの接続パラメータを確認します。
Secure Workload UI VIP から LDAP サーバーに到達できるかどうかを確認します。
AD サーバーが稼働しているかどうかを確認します。
[ldapsearch] などのコマンドラインツールを接続の詳細とともに使用して、バインドできるかどうかを確認します。

ユーザーのログイン中にエラーが発生した場合は、以下を確認してください。

ユーザーが LDAP 認証を使用する他社の Web サイトに LDAP ログイン情報でログインできるかどうかを確認します。
企業の LDAP 設定で指定されている「基本の」DN が正しいかどうかを確認します。[ldapsearch] などのコマンドラインツールを使用して、基本 DN に対してユーザーを検索することで実行できます。

電子メールでユーザーを検索する [ldapsearch] クエリの例：

ldapsearch -H "ldap://<host>:<port>" -b "<base-dn>" -D "<ldap-admin-user>" -w <ldap->admin-password> "(mail=<users-email-address>)"

LDAP 認証の設定（AD 認証）

Active Directory 認証は、外部認証 LDAP 設定の [管理者資格情報（Admin Credentials）] セクションで [LDAP 認証（LDAP Authorization）] チェックボックスを有効にすることで設定できます。この設定を有効にすると、サイト管理者は、LDAP の「MemberOf」グループのマッピングを以下のセクションの Secure Workload ロールに設定する必要があります。デフォルトではこの設定がないため、Active Directory ユーザーはログインを試行する前に、1 つ以上の Secure Workload ロールを事前に設定する必要があります。

LDAP 外部認証が有効になっている場合、LDAP MemberOf グループの Secure Workload ロールへのマッピングを設定する必要があります。[マッピングの作成（Create Mapping）] を使用すると、LDAP MemberOf グループ値を Secure Workload ロールにマッピングするように設定できます。ロールドロップダウンのロールは、範囲セレクタで選択された範囲に基づいて事前に入力されています。マッピングが保存されると、すべてのユーザーは、その後のログイン時にこれらの値に基づいて承認されます。

マッピングは、並べ替え、編集、または削除ができます。マッピングへの変更は、その後のログイン時にユーザーに割り当てられたロールに反映されます。最大 50 の LDAP MemberOf グループから Secure Workload ロールへのマッピングを作成できます。

LDAP MemberOf グループ名の重複は許可されません。ただし、複数の LDAP MemberOf グループを同じロールにマッピングできます。複数のグループが同じロールにマッピングされている場合、最後のマッピングは、Secure Workload ロールに一致する LDAP MemberOf としてユーザーで保存されます。

Cisco Secure Workload ロールのセットアップへの LDAP グループ — Figure 9. Secure Workload ロールのセットアップへの LDAP グループ

Cisco Secure Workload ロールのマッピングへの LDAP グループ — Figure 10. Secure Workload ロールのマッピングへの LDAP グループ

サイト管理者ユーザーは、ユーザーが最後に成功したログインから取得した外部ユーザーの情報を利用して、上記のロールマッピングに基づいてロールの割り当てを調整できます。

Note

「ローカル認証を使用」オプションで示されているように、ユーザーごとに有効化すると、ユーザーは外部認証をバイパスできます。これらのユーザーは、AD 認証用に設定された認証プロセスもバイパスします。

認証が有効化されると、ユーザー作成フロー（ユーザーの追加）およびユーザー編集フロー（「ユーザーアカウントの編集」）では、手動での Secure Workload ロール選択は許可されません。

[ユーザー（Users）] ページ — Figure 12. [ユーザ（Users）] ページ

Secure Workload ロールにマッピングされた LDAP MemberOf グループは、[ユーザープロファイル（User Profile）] ページに表示されます。

Figure 13. [ユーザープロファイル（User Profile）]ページ

LDAP 承認が有効な場合、ユーザーセッションが終了すると LDAP MemberOf グループから派生した Secure Workload ロールが再評価されるため、API キーを介した OpenAPI へのアクセスはシームレスに機能しなくなります。したがって、中断のない OpenAPI アクセスを保証するために、API キーを持つすべてのユーザーが [ローカル認証を使用（Use Local Authentication）] オプションを有効にすることを推奨します。

LDAP 認証の問題のトラブルシューティング

[外部認証（External Authentication）]、[LDAPグループからロールへのマッピング（LDAP Group to Role Mappings）] セクションで定義されたマッピングに基づいてロールがユーザーに割り当てられない場合は、ロールマッピングの設定と形式をもう一度確認してください。

グループ文字列は文字列形式である必要があります。例：CN=group.jacpang,OU=Organizational,OU=Cisco Groups,DC=stage,DC=cisco,DC=com
グループ名は、スペースや余分な文字が含まれず、AD に存在するものと正確に一致する必要があります。
グループのロールマッピングは、ロールセレクタから選択する必要があります。

ユーザーロールマッピングのデバッグ手順

2 人のユーザーが必要です。1 人はサイト管理者で、このユーザーの電子メールは AD ユーザーとは異なる必要があります。
以下の手順では、このユーザーを「SA ユーザー」と呼びます。
- SA ユーザーには、前述のように、会社ページの [外部認証設定（External Authentication Config）] でロールマッピング設定が事前に設定されています。「SA ユーザー」が [site-admin]@[ドメイン] でログインするとします。
- 「AD ユーザー」は [ad-user]@[Domain] であると仮定します。LDAP のセットアップが完了し、AD ユーザーはログインできますが、ロールが割り当てられていないと仮定します。
AD ユーザーとして、シークレットブラウザセッションを使用してログインします。これにより、ブラウザの状態が SA ユーザーセッションから分離されます。
SA ユーザーとしてログインし、[ユーザー（Users）] ページに移動します。
ロールマッピングを設定する必要がある AD ユーザーの [編集（Edit）] アイコンをクリックします。
[ユーザープロファイル（User Profile）] ページの [外部ユーザープロファイル（External User Profile）] ボタンをクリックします。
「memberof」セクションを含む外部認証プロファイルテーブルが表示されます。
これは、会社ページ、[外部認証設定（External Authentication Config）]、[LDAPグループからロールへのマッピング（LDAP Group to Role Mappings）] セクションでのロールマッピングに使用できる「memberof」値の 1 つです。
「memberof」の行ごとの文字列全体を指定して一致させる必要があります。このロールマッピングを作成すると、同じ属性「memberof」を持つすべてのユーザーに、マップされたロールが割り当てられます。
新しくマップされたロールを AD ユーザーに付与するには、ユーザーはログアウトしてから再度ログインして、このマッピングプロファイルを再評価できる必要があります。
ユーザーがログインし、グループからロールへのマッピングの結果としてロールが正常に割り当てられると、一致するルールがそのユーザーの [設定（Preferences）] ページに表示されます。

シングルサインオンの設定

このオプションを選択すると、シングルサインオン（SSO）を使用してユーザーを認証できます。つまり、これを有効にする場合、すべてのユーザーが認証のために ID プロバイダーのサインインページにリダイレクトされます。[ローカル認証を使用（Use Local Authentication）] オプションが有効になっているユーザーは、サインインページで電子メールとパスワードのサインインフォームを使用して認証できます。

特に [ローカル認証を使用（Use Local Authentication）] オプションが有効なユーザーがいない場合は、SSO が正しく設定されていることを確認することが重要です。推奨されるアプローチは、[ローカル認証を使用（Use Local Authentication）] オプションをオンにして、サイト管理者のログイン情報を持つローカル認証されたユーザーを少なくとも 1 人指定する方法です。このユーザーは、SSO が正しく設定されていることを確認できます。接続が正常にセットアップされたら、ユーザー編集フローで [ローカル認証を使用（Use Local Authentication）] オプションをオフにして、このユーザーを外部認証に移行させることもできます。

SSO を有効にした場合、新しいユーザーを作成するための推奨ワークフローは次のとおりです。

サイト管理者と範囲所有者は、新しいユーザーが SSO で初めてログインする前に、まず自分の電子メールで新しいユーザーを作成し、適切なロールと範囲を割り当てるようにお勧めします。新しいユーザーが適切なロールなしで SSO でログインした場合、デフォルトのロールはユーザーに割り当てられません。

Note

電子メール通信に依存するパスワードリセット指示の送信は、SMTP サーバー設定がない場合は影響を受けます。

次の表では、Secure Workload で SSO を構成するために設定する必要があるフィールドについて説明します。この場合の Secure Workload は、サービスプロバイダーです。


フィールド	説明
[SSOターゲットURL（SSO Target Url）]	ログインのためにユーザーがリダイレクトされる SSO IdP ターゲット URL。
[SSO発行元（SSO Issuer）]	SP の SSO エンティティ ID、SP を一意に識別するための URL。これは通常、SP のメタデータです。このケースの場合： `https://<tetration-cluster-fqdn>/h4_users/saml/metadata`
[SSO証明書（SSO Certificate）]	アイデンティティプロバイダー（IdP）によって提供される SSO 証明書。
[SSO AuthNコンテキスト（SSO AuthN Context）]	SAML 要求で指定された SSO AuthN コンテキストの選択肢。デフォルトのオプションは [パスワードで保護されたトランスポート（Password Protected Transport）] です。他の選択肢は、Windows および PIV ベースの認証用の [統合Windows認証（Integrated Windows Authentication）] および [X.509証明書（X.509 Certificate）] です。

SSO 設定を有効にすると、[ローカル認証を使用（Use Local Authentication）] オプションが有効になっているユーザーを除いて、すべてのユーザーがセッションからログアウトされます。

[保存（Save）] ボタンをクリックすると、SSO 設定が保存されます。

ID プロバイダー（IdP）と共有する情報

IdP は、認証用の SSO を設定するために Secure Workload（SP）の一部の情報を必要とします。次の表に、設定する必要があるフィールドについて説明します。


フィールド	説明
SSO URL（SSO Url）	SAML アサーション（IdP からの応答）を使用する認証エンドポイント（URL）。この例では、次のようになります。 `https://<tetration-cluster-fqdn>/h4_users/saml/auth`
エンティティ ID（Entity Id）	これは SP のメタデータです。このケースの場合、次のようになります。 `https://<tetration-cluster-fqdn>/ h4_users/saml/metadata`
名前 ID の形式（Name ID Format）	名前 ID は電子メールアドレスです。 `'urn:oasis:names:tc:SAML:1. 1:nameid-format:emailAddress'`
属性（Attributes）	ユーザー属性は IdP から取得されます。シスコでは認証の一部としてこれらの属性を取得します。 email firstName lastName 属性名が以前に指定した名前であることを確認します。

SSO の問題のトラブルシューティング

（サービスプロバイダーから）認証が機能することを確認できるのは設定後だけなので、SSO 構成の設定にはダウンタイムを設定します。
生成された IdP メタデータを確認して検証します。
IdP と SP の間で交換されるすべての構成パラメータを確認します。
- IdP での構成：SSO URL、対象者、名前 ID、属性など。
- Secure Workload の会社ページでの構成：SSO ターゲット URL、SSO 発行者、および SSO 証明書。
IdP から返されたサンプル SAML アサーションをサーバーアプリケーションログから取得します。SAML バリデータに対して検証を行い、有効な SAML 応答であることを確認します。
SP SSO セットアップでエラーが発生すると、IdP からエラーが生成される場合があります。ブラウザの Inspect 要素を使用すると、実行されているネットワークリクエストを確認できます。
ユーザーのログインに問題がある場合は、Secure Workload アプリケーションへのアクセス権をそのユーザーが持っているか IdP 管理者に確認してもらいます。

SSL 証明書およびキー

Secure Workload UI への完全に検証可能な HTTPS アクセスを有効にするには、UI のドメイン名に固有の SSL 証明書と、SSL 証明書の公開キーと一致する RSA 秘密キーをクラスタにアップロードします。

SSL 証明書は、Secure Workload UI 仮想 IP（VIP）アドレスを参照するために使用される完全修飾ドメイン名（FQDN）の形式に応じて、2 つの方法で取得できます。Secure Workload FQDN が Tetration.cisco.com などのエンタープライズドメイン名に基づいている場合、ベースドメインを所有するエンタープライズ認証局（CA）が SSL 証明書を発行します。それ以外の場合は、信頼できる SSL 証明書ベンダーを使用して、FQDN の SSL 証明書を発行できます。

Note

Secure Workload UI はサーバー名表示（SNI）をサポートしていますが、証明書で指定されたサブジェクトの代替名（SAN）は一致しないことに注意してください。たとえば、証明書の共通名（CN）が tetration.cisco.com であり、証明書にtetration1.cisco.com の SAN が含まれている場合、ホスト名はその証明書では提供されないため、HTTPS リクエストは SNI 互換ブラウザを使用して tetration1.cisco.com のクラスタに送信されます。CN で指定されたホスト名以外のホスト名でクラスタに対して行われた HTTPS リクエストは、クラスタにインストールされているデフォルトの自己署名証明書を使用して処理されます。それらのリクエストの結果、ブラウザに警告が表示されます。

サイト管理者とカスタマーサポートのユーザーは、SSL 証明書を使用できます。ナビゲーションウィンドウで、[プラットフォーム（Platform）] > [SSL 証明書（SSL Certificate）] の順にクリックします。

メジャーアップグレードリリースとパッチに使用される メンテナンス UI またはセットアップ UI は、HTTPS URL スキーマに移行されました。Cisco Secure Workload リリースにアップグレードした後、管理者は メンテナンス UI用に別の証明書をアップロードする必要があります。

証明書とキーをインポートするには、[新しい証明書とキーのインポート（Import New Certifcate and Key）] ボタンをクリックします。

署名要求を生成するには、 [新しい証明書署名要求の生成（Generate New Certificate Signing Request）] ボタンをクリックします。

Note

SSL 証明書と秘密キーの最初のインポートは、信頼ネットワーク接続を介してクラスタに対して実行し、トランスポート層にアクセスできる悪意のある第三者が秘密キーを傍受できないようにする必要があります。

SSL 証明書とキーについて、次の情報を入力します。

[名前（NAME）] は証明書キーペアの任意の名前にできます。この名前は、インストールされている SSL 証明書を確認するときに役立ちます。

[X509証明書（X509 Certificate）] フィールドには、プライバシー強化メール（PEM）形式の SSL 証明書文字列を入力できます。SSL 証明書に中間 CA バンドルが必要な場合は、証明書の後に CA バンドルを連結して、Secure Workload FQDN の SSL 証明書が証明書ファイルの先頭になるようにします。

次の形式にする必要があります。

-----BEGIN CERTIFICATE-----

< Certificate for Secure Workload FQDN >

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

< Intermediary CA 1 content >

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

< Intermediary CA 2 content >

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

< Root CA content >

-----END CERTIFICATE-----

[RSA秘密キー（RSA Private Key）] フィールドには、前述の証明書で署名された公開キーの RSA 秘密キーを入力する必要があります。次の形式にする必要があります。

-----BEGIN RSA PRIVATE KEY-----

< private key data >

-----END RSA PRIVATE KEY-----

Note

RSA 秘密キーは暗号化されていない必要があります。RSA 秘密キーが暗号化されている場合、「500 内部サーバーエラー（500 Internal Server Error）」が発生します。

インポートすると、検証手順が実行され、証明書に署名された公開キーと秘密キーが実際に RSA キーペアである秘密キーが確認されます。検証に成功すると、証明書バンドルの SHA-1 ダイジェスト（SHA-1 署名と作成時刻）が表示されます。

ブラウザをリロードして、Secure Workload UI への SSL 接続で新しくインポートされた SSL 証明書が使用されていることを確認します。

Cisco Secure Workload ユーザーガイド（オンプレミス）リリース 3.10

偏向のない言語

翻訳について

Book Title