名フィールドでは完全修飾名を使用します。名フィールドでは使用しないでください。アドレスは証明書の仕様に違反しています。ワイルドカード証明書を使用しないワイルドカード証明書の使用は控えてください。ワイルドカード証明書は、厄介なユーザープロンプトを回避する便法ですが、最小権限の原則にも反するほか、開発者のマシンやロビーにある秘書のマシン、サインインキオスクを含むすべてのマシンを信頼するようユーザーに要求することになります。プライベート鍵へのアクセスの取得というハードルが攻撃者にはまだ残っていますが、無防備な状態でファイルシステムに保存されていれば、相当に簡単になります。したがって、ワイルドカード証明書の使用は、公衆ネットワークにつながるホストでは標準的ではありません。アドレスを使用しない証明書ではプライベートアドレスを使用しないでください。プライベートネットワークのアドレス割り当てです。証明書ガイドラインに違反します。Security』で次のように述べています。「これは特に厄介である。証明書サイトになりすますことができるからだ。使用するアプリケーションユーザーに対して、この証明書は不明か信頼できない機関によって署名されたという警告が絶対に提示されないようにする必要があります。アプリケーションの全ユーザーが、サーバーの証明書を発行した認証機関の公開証明書にアクセスできることが必要です。証明書を購入することです。一般的なインターネットブラウザーには、このような公認認証機関の公開証明書があらかじめ組み込まれています。ユーザー数が限られた社内用アプリケーションでは社内の認証機関を使用できますが、その公開証明書を全ユーザーに安全に配布することが前提となります。この認証機関が発行するすべての証明書をユーザーが信頼することになるので注意してください。このため、徹底した制御によってプライベート鍵を保護し、許可された人間だけが証明書に署名できることを確保します。自己署名証明書の使用は絶対に認められません。自己署名証明書はエンドポイント認証の利点を打ち消すだけでなく、ユーザーが中間者攻撃を検知する能力を低下させます。証明書によって解決しようとします。ユーザーがサーバーまたはホストの証明書を受け取った時点で、その証明書の正当性を、信頼されたルート証明機関まで遡って検証できることが必要です。これをパス検証といいます。以上の中間証明書が介在する場合があります。両方のエンドポイントの検証に加え、ユーザーはすべての中間証明書も検証する必要があります。ユーザーがすべての中間証明書をローカルに保有していない可能性もあるため、この検証は難しい場合があります。問題と呼ばれています。問題を回避するには、パス検証で使用される必要なすべての証明書をサーバーからユーザーに提供する必要があります。廃止計画に組織として事前に対応しておく必要があります。SHA-1」を参照)。チェーンに移行するのが妥当でしょう。失効するように徹底してください。暗号モジュールを使用している場合は、以下のルールを無視して、特定の暗号モジュールの推奨構成に従ってください。その場合も、以下のルールを利用して構成を監査することをお勧めします。複数のプロトコルの集合です。プロトコルには脆弱性が見つかっています。今後使用しないください。サポートすることです。この構成は、高度なスキルと明確な動機を持つ攻撃者に対し最大の防御を提供し、機密データを扱うアプリケーションや危険な操作を行うアプリケーションに適しています。