自己署名証明書と認証局署名証明書の違いは何ですか
環境
- ONTAP 9
- SSL および CA 署名証明書
- Active IQ Unified Manager
回答
- 概要と主要定義：
- このドキュメントでは、NetApp ONTAP環境における自己署名SSL/TLS証明書と認証局（CA）署名証明書の、高度に技術的で詳細なアーキテクチャの比較について説明します：
- ONTAPでは、セキュアな管理プロトコル（HTTPS/REST、System Manager、Active IQ Unified Manager、SVMピアリング、およびKMIP/NSE）はTLSハンドシェイクに依存しています。
- 適切な証明書トポロジを選択することは、セキュリティ体制、管理の自動化、監査可能性、およびクラスタの相互運用性に直接影響します。
自己署名証明書：
- 作成者が署名者である証明書。
- 公開鍵構造を生成するために使用された秘密鍵は、その身元確認を発行するためにも使用されます。
- 外部の信頼の拠り所は存在しません。
CA署名証明書：
- 信頼できるサードパーティまたは社内の 企業階層（エンタープライズルートCA）によって発行された証明書であり、その公開検証キーは クライアントまたはアプリケーションのトラストストアに事前インストールされています。
2.技術比較マトリックス：
| 技術的特性 | 自己署名SSL証明書 | CA署名証明書 |
| 信頼モデル | クライアントごとに明示的に手動で信頼を設定する（「初回使用時の信頼」/TOFU）。 | 階層構造：社内エンタープライズPKIまたは公開ルート/中間CAを基盤とする自動化された信頼チェーン。 |
| ブラウザとクライアントの検証 | TLSハンドシェイクの検証に失敗します。ブラウザアラートをトリガーします（ERR_CERT_AUTHORITY_INVALID、SEC_ERROR_UNKNOWN_ISSUER、「安全ではありません」）。（注：HTTP 403などのHTTPステータスコードが発生する前に、TLSレイヤーで失敗します）。 |
エンタープライズブラウザ、CLIツール、バックグラウンドAPI呼び出し元全体で、警告なし（クリーンなロックアイコン）でネイティブ検証を実行します。 |
| 中間者攻撃（MitM）防御 | 高リスク： 習慣的に警告を回避していると（「リスクを受け入れて続行」）、ユーザーやスクリプトが本人確認を無視するようになり、トラフィックが傍受やなりすましに対して脆弱になります。 | 堅牢：クライアントは、証明書の署名、CN/SAN、または証明書チェーンが信頼できるルート証明書と一致しない場合、接続を厳密に切断します。 |
| 自動化互換性 | 安全でないバイパスフラグが挿入されない限り、スクリプトと CI/CD パイプラインが壊れます（例：Ansible validate_certs: false、Python verify=False、curl -k）。 |
Ansible（netapp.ontapコレクション）、ONTAP REST APIクライアント、および完全なTLS検証が有効なPowerShell Toolkitとのネイティブでセキュアな統合。 |
| ライフサイクル管理 | 運用コストが高い。証明書はノード/クラスタ/SVMごとに手動で生成および更新され、集中管理による追跡や自動更新の仕組みがありません。 | 証明書ライフサイクル管理（CLM）の一元化。自動発行／更新ワークフローと、有効期限の一元管理による追跡をサポートします。 |
| 失効サポート | なし： CRL（証明書失効リスト）またはOCSPを介して失効させることはできません。証明書が侵害された場合は、手動で削除し、SVMから関連付けを解除する必要があります。 | サポート対象：クライアントとONTAPは、エンタープライズCRL配布またはOCSPレスポンダに対して、証明書の失効状態をリアルタイムで検証できます。 |
| ONTAP CLIとサービスバインディング | security certificate createを使用したインスタント搭載作成。security ssl modify -vserver <admin_svm> -ca <ca> -serial <serial>を使用してSVM SSLサービスにバインドされます。 |
構造化されたワークフローが必要です： SANを含むCSRを生成し（ |
| AIQUM統合の影響 | 自己署名証明書を更新または再生成すると、新しいサムプリントが生成され、手動で再認証されるまで、AIQUMのバックグラウンド取得スレッドが失敗したり、「ポーリング失敗」/「検出進行中」の状態で停止したりします。 | シームレスな更新：発行元のルート/中間CAがAIQUMホストのトラストストア（Java cacerts）に存在する限り、更新はデータ収集を中断することなく透過的に行われます。 |
3.マイクロアーキテクチャと暗号化の詳細解説：
クライアント（WebブラウザやAIQUMなど）がポート443でONTAPの管理インターフェイス（LIF）へのHTTPS接続を開くと、クラスタはX.509デジタル証明書を提示します。
- 自己署名ハンドシェイクの仕組み：
- プレゼンテーション：ONTAPは、発行者とサブジェクトが同じである、ローカルで作成された証明書を提示します。
- 検証エラー：クライアントは、自身のオペレーティングシステムまたはブラウザのルートトラストストアを確認します。自己署名証明書は、認められた認証局によって署名されていないため、自動的な信頼は失敗します。
- 手動例外：クライアントまたは管理者は、固有の証明書のサムプリントを手動で承認して記録する必要があります（初回使用時の信頼）。
- リスク / 不安定性：証明書の有効期限が切れたり、再生成されたり、ノード/SVM間で証明書の設定が同期されていない状態でフェイルオーバーが発生した場合、ID検証は即座に失敗します。
- CA署名済みトラストチェーンの仕組み：
- プレゼンテーション：ONTAPは、サーバー証明書とすべての中間証明書（証明書チェーン）を提示します。
- 自動チェーン検証：クライアントは、ローカルのトラストストアにインストールされているエンタープライズまたはパブリックルートCAまで、チェーン内の各リンクを暗号的に検証します。
- 実行されるチェック：
- 有効期間：現在の日付/時刻がNotBeforeとNotAfterの間にあります。
- 暗号学的完全性：デジタル署名がCAチェーンと一致します。
- ホスト名の一致：アクセスしたURLまたはIPが、証明書のサブジェクト代替名（SAN）のエントリと一致します。
4.最新のONTAPの要件：サブジェクト代替名（SAN）
最新のWebブラウザ（Chrome、Edge、Safari）とREST APIフレームワークは、従来のコモンネーム（CN）属性を無視し、サブジェクト代替名（SAN）（RFC 2818）を強制します。
- 自己署名デフォルト：ONTAPが自己署名証明書を自動生成する場合、CNにはクラスタ名またはノード管理LIFのみが入力されます。
- 複数のIPアドレスまたは複数のFQDNに対応するSAN属性を生成しないため、証明書を手動で信頼した後でも、ブラウザに警告が表示され続けます。
- CA署名のベストプラクティス： ONTAPで証明書署名要求（CSR）を作成する際、管理者はすべての管理FQDN、ショートネーム、および管理IPアドレスを明示的に -
sanパラメータに含める必要があります：::> security certificate generate-csr -vserver <admin_svm> -common-name cluster01.corp.example.com -san cluster01.corp.example.com,cluster01,10.0.1.10 -size 2048 -hash-function SHA256
5.NetApp管理ツール（Active IQ Unified Manager）への影響
AIQUMは、継続的なバックグラウンド取得スレッドを使用して、パフォーマンス、健全性、容量の指標についてONTAPクラスタをポーリングします。
自己署名証明書の動作：
- 初期設定：検出プロセスにおいて、AIQUMは管理者に信頼できない証明書を受け入れるよう促し、その固有のサムプリントをAIQUMデータベースに保存します。
- 更新時の問題：自己署名証明書の有効期限が切れ、ONTAPクラスタで再生成されると、サムプリントが変更されます。
- 現象：AIQUMはサムプリントの不一致を検出し、潜在的なスプーフィングから保護するためにデータ収集を停止します。
- クラスタのステータスは、管理者がデータソースを手動で再認証するまで、「ポーリング失敗」または「検出中」の状態にロックされます。
CA署名付き証明書の動作：
- 自動検証：ルート/中間CAバンドルは、AIQUMホスト/JVMトラストストア（cacerts）に一度インポートされます。
- スムーズな更新：同じCA階層がクラスタ証明書を更新した場合、AIQUMは新しい証明書を自動的に検証します。
- ポーリングと検出は、中断、設定変更、または管理者による介入なしに継続されます。