EdgeADC - Version 5.00.1986
User Guide
×
Menu

SSL設定マネージャー

バージョン 196X 以降では、SSL 証明書と証明書要求の設定と管理をより簡単に行えるようになりました。
SSL Configuration Managerには3つの主要なセクションがあります。
証明書リスト・エリア
Managerの上側には、使用可能なSSL証明書、または信頼できる機関から有効化待ちのSSL証明書が表示されます。
証明書は、証明書名、有効期限、Expires In(有効期限までの日数)、および証明書の Status/Type の 4 つのカラムで表示される。
カラーコード
ご覧のように、各行は証明書と色分けされたブロックを示している。以下は、色分けされたブロックとその意味を示した表である。
カラーコード
意味
 
証明書が最新であり、有効期限まで60日以上ある。
 
証明書の有効期限は30日以内です。
 
証明書の有効期限は30日から60日
 
証明書の有効期限が残り1日となりました。
 
証明書の有効期限が切れている
証明書/CSR情報表示
証明書またはCSRをクリックすると、その情報が下部のパネルに表示されます。下の画像を参照してください。
アクションボタンと設定エリア
リスティングで証明書が選択されると、多くのアクションボタンが利用可能になり、実行されます。
概要
Overview」ボタンは、証明書の全体的な状況を下部に表示する。他のアクションとは異なり、「概要」ボタンは独立しており、証明書を選択する必要はない。
リクエストの作成
自己署名証明書またはCSRを作成する場合は、Create Requestボタンをクリックする必要があります。これにより、必要なすべての詳細を入力できる共通入力パネルが表示されます。
AD証明書名(CN
これは、ADC に証明書の名前を表示するために使用される説明フィールドである。フィールドの入力は、スペースを含まない英数字で指定する。
組織(O
このフィールドは、証明書を使用する組織の名前を指定するために使用する。
組織単位(OU
通常、部門または組織単位を指定するために使用されます。
市町村
その名が示すように、一般的にユーザーは組織の所在地を指定する傾向がある。
都道府県
このフィールドに州、郡、または県を指定してください。
国名
これは必須項目であり、証明書を使用する国を選択して記入する必要があります。ここに記入された情報が正確であることを確認してください。
コモンネーム(FQDN
これは重要なフィールドで、証明書を使用して保護するサーバの完全修飾ドメイン名(FQDN)を指定するために使用します。これは www.edgenexus.io edgenexus.io、あるいはワイルドカード *.edgenexus.io のようなものです。証明書をIPアドレスにバインドしたい場合は、IPアドレスを使うこともできます。
キーの長さ
SSL 証明書の暗号化キーの長さを指定するために使用します。
期間(日)
証明書の有効期間を日数で示す。この期間が経過すると、証明書は使用できなくなる。
電子メール
これは、証明書に使用される管理用電子メール ID である。
サブジェクトの別名(SAN
Subject Alternative Name (SAN) は、SSL 証明書の拡張機能で、複数のドメイン名を単一の証明書で保護することができます。この機能は、複数のサブドメインや異なるドメイン名を持つウェブサイトを保護するために特に有用であり、SSL管理のより合理的で費用対効果の高いアプローチを可能にします。SANを含めることで、1つのSSL証明書でさまざまなドメイン名やサブドメインをカバーすることができ、各ウェブアドレスに個別の証明書を発行する必要がなくなるため、ウェブ通信の保護プロセスが簡素化され、多様なドメイン間でデータの暗号化が保証されます。
このフィールドは、SANのタイプを選択できるドロップダウンと、値を指定するテキストフィールドの2つの要素で構成されています。
EdgeADCでは、以下のSANが使用可能です:DNS、IP アドレス、電子メール・アドレス、URI。証明書または CSR に対して、複数の SAN を選択および指定することができる。
指定されたSANは、各SANの値にある赤い×をクリックすることで削除できます。
     DNS - DNS Subject Alternate Name (SAN)では、証明書が有効なドメイン名を追加指定することができる。1つのドメインしか指定できないCommon Name(CN)フィールドとは異なり、SANフィールドには複数のドメイン名を含めることができるため、証明書管理に柔軟性と拡張性を提供することができる。これは、異なるドメインやサブドメインにまたがる複数のサービスをホストしている組織にとって特に有用である。単一のSSL/TLS証明書でこれらすべてのエンティティの通信を保護できるため、管理が簡素化され、セキュリティが向上する。
     IPアドレス - IPサブジェクト代替名(SAN)は、証明書によって保護されるエンティティとして、ドメイン名とともにIPアドレスを含めることを可能にする。この機能は、IPアドレスを介したサービスへの直接アクセスを保護するために非常に重要であり、ドメイン名ではなくIPアドレスを介して直接サーバにアクセスする場合にも暗号化された接続を確立できることを保証する。IP SANを組み込むことで、組織は 、ドメインベースとIPベースの両方の通信でSSL/TLS暗号化を可能にし、内部リソースや特定のサービスへのアクセスにドメイン名が使用されなかったり、好まれなかったりする環境でも多目的に使用できるようにすることで、ネットワークセキュリティを強化することができる。
     電子メールアドレス - 電子メールアドレスのサブジェクト代替名(SAN)は、証明書が発行されたプライマリドメインまたはエンティティの他に、証明書に関連付けられ る追加の電子メールアドレスを指定することを許可する。これにより、証明書は、単一のドメインまたはコモン・ネーム(CN)だけでなく、複数の電子メール・アドレスについて発行者の身元を検証することができる。特に、同じ組織やエンティティの下でさまざまな電子メールアドレスに対して安全な電子メール通信が必要とされるシナリオで有用であり、暗号化された電子メールの交換が認証され、証明書によって検証された発行者の身元に結びつけられることを保証します。これにより、Email Address SANは、暗号化されたフレームワーク内での電子メール通信のセキュリティと信頼性を強化するための重要な機能となります。
     URI - URI(Uniform Resource Identifier)SANは、証明書によって保護される単一のエンティティのURIで表される追加のIDを指定するために使用される。通常、ドメイン名(DNS 名)または IP アドレスを含む従来の SAN エントリとは異なり、URI SAN は、証明書がエンティティを特定の URI(特定のリソースまたはサービス・エンドポイントへの URL など)に関連付けることを可能にする。これにより、より柔軟かつ正確な識別が可能になり、ドメイン自体の安全性を確保するだけでなく、ドメイン内の特定のリソースやサービスと安全な接続を確立できるようになり、SSL/TLS証明書の粒度とスコープが強化される。
正しく記入されたら、証明書署名要求(CSR)を作成し、認証局による署名のために送信するか、すぐに使用するために自己署名証明書を作成するかを選択できます。
キャンセルボタンはリクエスト全体をキャンセルし、リセットボタンはすべてのフィールドをリセットします。
名前変更
名前の変更 ] ボタンを使うと、仮想サービスで使用されていない証明 書の名前を変更できます。
この機能を使うには
     名前を変更したい証明書をクリックし、[Rename]ボタンをクリックします。
     証明書の行が変わり、名前を変更できるようになります。
     完了したら、更新ボタンをクリックします。
     証明書をダブルクリックして、証明書の名前を変更することもできます。
削除
削除ボタンは、証明書が選択されているときのみ有効です。クリックすると、以下の内容が表示されます
下のペインには、削除要求と、削除が要求された証明書の名前が表示される。
ペインの右下にある「削除」ボタンをクリックして削除を進めます。
インストール/サイン
CSRを作成し、認証局(CA)による署名を希望する場合、CSRをCAに送付する。その見返りとして、CAは署名された証明書と秘密鍵ファイル、および証明書を正しく機能させるために必要な仲介物を送付します。
必要な要素がすべて入ったZIPファイルが送られてくるかもしれないので、右ペインの上部を使ってアップロードすることができる。
または、テキストエディタで証明書セットを作成し、その内容をペイン下部の「Certificate Text」フィールドに貼り付けることもできる。
いずれかの方法を使用したら、[署名]ボタンをクリックし、[適用]ボタンをクリックします。署名された証明書が左ペインに表示されます。
リニューアル
証明書の有効期限を過ぎた場合、「Renew」ボタンをクリックすると、証明書の有効期限を延長し、更新することができます。更新には2種類あります。
自己署名証明書
自己署名証明書は、信頼された証明書とは異なり、CSRを使用して更新することはできない。その代わり、自己署名証明書は、既存のデータを使用して新しいコンフィギュレーションを提示することで更新される。ユーザは、証明書の新しい名前と証明書の新しい有効期限を指定することができる。
これが完了すると、新しい自己署名証明書が作成され、証明書ストアに保存される。その後、証明書を使用する仮想サービスが時間内に再設定されるようにするのは、管理者の責任である。
信頼できる署名付き証明書
信頼され、認証局によって署名された証明書に関しては、CSRの使用が採用される。
トップパネルで期限切れの証明書をクリックし、「更新」をクリックすると、現在の証明書の詳細を使用した新しいCSRが表示されます。このCSRをダウンロードして認証局に提示し、署名を受けると、署名された証明書をインストールできます。
更新を依頼した証明書は、新しいステータス「更新中」になります。署名された証明書がインストールされると、証明書に新しい名前を割り当てるよう求められます。この名前は「信頼済み」と表示されます。元の証明書は保持され、それを使用しているサービスは、できるだけ早く新しい証明書を使用するように設定する必要があります。
証明書の検証
SSL証明書を構成する部品はいくつかあり、これらの部品が存在するだけでなく、正しい順序で配置されていることが不可欠です。第三者機関から取得したSSL証明書を検証する理由を以下に示します。
     認証:認証は、証明書が信頼できる機関から発行されたものであることを保証し、ウェブサイトまたはサーバーの身元を確認します。これは、攻撃者がクライアントとサーバー間の通信を傍受できる中間者攻撃を防ぐのに役立ちます。
     完全性:SSL証明書を検証することで、証明書が改ざんされていないことを確認できます。これは、安全な接続の完全性を維持するために非常に重要です。
     トラスト・チェーンの検証SSL証明書は認証局(CA)によって発行される。証明書の検証には、その証明書が信頼できるルート認証局にチェーンバックしているかどうかの検証も含まれます。このプロセスにより、証明書が正当なものであり、信頼できるものであることが保証されます。
     失効ステータス:検証中に、SSL 証明書が発行 CA によって失効されていないかどうかを確認することも重要です。誤って発行された場合、ウェブサイトの秘密鍵が漏洩した場合、サイトが証明書を必要としなくなった場合などに、証明書が失効することがあります。取り消された証明書をインポートすると、セキュリティの脆弱性につながる可能性があります。
     有効期限の確認:SSL証明書には有効期限があります。インポート時に証明書を検証するには、その証明書の有効期限をチェックし、まだ有効であることを確認します。有効期限切れの証明書を使用すると、脆弱性につながり、ブラウザやクライアントが安全な接続を拒否する可能性があります。
     コンフィグレーションと互換性:検証は、証明書のコンフィグレーションがクライアントのセキュリティ・ポリシーおよびサーバまたはアプリケーションの技術要件に適合していることを保証する。これには、使用されるアルゴリズム、証明書の目的、その他の技術的な詳細の確認が含まれる。
     コンプライアンス特定の業界では、機密情報の安全な取り扱いを保証するために、SSL証明書の検証を規制で義務付けている場合があります。これは、金融、医療、電子商取引などの分野で特に重要です。
 
ADCSSL管理システムは、インポートされたSSL証明書の検証を可能にする。
     インポートしたSSL証明書を選択します。
     Validateボタンをクリックする。
     その結果は、下の画像で表されるように、下のパネルで見ることができる。
インターミディエイトを加える
先に述べたように、SSL証明書はいくつかの部分から構成されており、そのうちのひとつが、完全なチェーンを構成するための中間証明書である。
ADCSSL Managerで、不足している中間証明書を追加できる。
     中間証明書を追加したいSSLをクリックします。
     中級者ボタンをクリックする。
     下の画像のようなパネルが表示される。
     中間証明書の内容を貼り付ける。
     Apply をクリックする。
SSL証明書が正しく検証されるように、中間証明書の順序を変更する必要がある場合があります。これは Reorder ボタンを使って行います。
再注文
SSL証明書が正しく動作するためには、正しい順序で配置されていなければならない。
黄金律は、送信者の証明書が最初に来て、最終的なルート証明書がチェーンの最後に来ることである。一般的には、以下のような形になる:
オリジナル発行者>中間1>最終ルート。
最終ルートは、認証局が提供する信頼できるルート証明書である。
場合によっては、複数の中間証明書が存在し、これらも正しい位置に配置されなければならない。基本的に、次の各証明書はその前の証明書を証明しなければならない。つまり、以下のようになります。
オリジナル発行者 > 中間1 > 最終ルート
例えば、中間体2をインポートする場合、これはチェーンの最後に置かれる可能性があり、認証が有効でないことを意味する。したがって、順序を変えて、中間2を正しい位置(赤で示した位置)に置く必要がある。
だから、最終的にはこうなる:
オリジナル発行者 > 中間1 > 中間2最終ルート
 
-----証明書の書き出し
MIIFKTCCBBGgAwIBAgISA/UUyBjJ71fucZuvpiLsdfsfsdfsdfd
...
hoFWWJt3/SeBKn+ci03RRvZsdfdsfsdfw=
-----終了証明書
----証明書の書き出し
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinsdfsdfsdfdsfsdfsd
....
nLRbwHqsdqD7hHwg==
-----終了証明書
-----証明書の書き出し
MIIFYDCCBsdfSDFSDFVSDVzfsdffvqdsfgsT664ScbvsfGDGSDV
...
Dfvp7OOGAN6dEOM4+SDFSDZET+DFGDFQSD45Bddfghqsqf6Bsff
-----終了証明書
-----証明書の書き出し
MIIFYDCCBsdfSDFSDFVSDVzfsdffvqdsfgsT664ScbvsfGDGSDV
...
Dfvp7OOGAN6dEOM4+SDFSDZET+DFGDFQSD45Bddfghqsqf6Bsff
-----終了証明書
証明書を選択し、「Reorder」ボタンを押すと、「Reorder」セクションは下図のようになります。
証明書セクションの順序を変更するには、ボックス内のテキストをコピーし、テキストエディタで内容を編集して順序を変更し、それを貼り付けて既存の内容を置き換えることができます。完了したら、「Apply」ボタンをクリックします。
インポート/エクスポート
SSL証明書プロバイダーから証明書を受け取る際、証明書はZIPファイルまたは一連のファイルとして提供されます。これらのファイルには、SSL証明書、キーファイル、ルートCA、および中間ファイルが含まれています
ADCにインポートする必要があるため、インポート方法を用意した。
SSL証明書には、CER、DER、PEM、PFXなど多くのフォーマットがあります。フォーマットによっては、インポート手順にKEYファイルを追加する必要があります。PFXファイルは、PFX証明書をインポートするためにパスワードが必要です。
必要であれば、ADCから証明書をエクスポートする手段も提供している。エクスポートする場合、ファイルはPFX形式となるため、エクスポートを作成するためのパスワードが必要となります。