更新をサービス継続タスクにする
の HTTPS 証明書を更新する MTA-STS ポリシー ホストは、正しい証明書が必要なエンドポイントで実際に提供され、検証クライアントがポリシーを取得できる場合にのみ完了します。通知の発行が成功しても、展開、トラスト チェーンの完全性、または可用性は確立されません。証明書の順序ではなく、実行中のサービスに関する作業を整理します。
このガイドでは、更新管理と架空の障害レビューを提案します。証明書の発行、秘密キーの検査、ホスティングの変更、顧客ドメインへの接続は行いません。元の証明書と HTTP 観察は引き続き必要です。所有者は、オペレーターがサービスに触れる前に、承認された展開とロールバックの手順に同意する必要があります。
2 つの証明書表面のインベントリを作成する
ポリシー ホスト証明書は、HTTPS 取得中にmta-sts.example.comなどの名前を認証します。受信側SMTPサーバーは、 MXホスト名に対して個別の証明書を提示します。これらのサービスには、所有者、更新システム、有効期限が異なる場合があります。両方が同じホスティングプロバイダーによって管理されている場合でも、一方を更新してももう一方は修正されません。 RFC 8461セクション 3.3 および 4.2
ポリシーのホスト名、責任チーム、展開プラットフォーム、現在の公開証明書のフィンガープリント、有効期間、および意図された更新メカニズムを記録します。エンドポイントに応答できるすべてのアドレスまたはサービス層を含めます。証明書の notBefore と notAfter はその有効期間を区切りますが、パスの検証は他の証明書の制約と信頼にも依存します。明らかに将来の有効期限日だけでは、検証結果は成功とは言えません。 RFC 5280セクション4.1.2.5および 6
導入前に ID とチェーンを検証する
ポリシーホストは、必要なDNS ID と、送信側によって信頼されるルートへのチェーンに対して有効な、有効期限が切れていない証明書を提示する必要があります。 MTA。を介してホスティングを委任する CNAME プロバイダーのホスト名の証明書が十分ではありません。検証テストでは元のポリシーのホスト名を保持し、サーバーが送信すると予想されるパブリック チェーンを文書化します。 RFC 8461セクション 3.3 および 8.2
目的のサービス ID を評価する場合は、証明書のサブジェクトの代替名を使用します。 RFC 9525は現在の一般的なサービス ID 仕様であり、 RFC 8461で引用されているRFC 6125は廃止されます。無関係なアプリケーションの動作を黙って置き換えるのではなく、 MTA-STSのアプリケーション固有の DNS-ID ルールを明示的に保ちます。人間が判読できる共通名は、ホスト名の不一致を免除する理由にはなりません。 RFC 9525セクション 2 および 6
安全に回復するために十分な時間を計画する
発行の失敗、展開エラー、検証のための時間を残せる社内更新期限を選択してください。適切なマージンは、証明書の有効期間と運用上の所有権によって異なります。ここでは普遍的な日数は確立されていません。責任者と予備の連絡先を割り当てます。アラート宛先または所有者のないスケジュールされたジョブは未検証の依存関係であり、完全な更新プロセスではありません。
証明書の処理は、承認された秘密管理システム内で行います。証拠パケットには、秘密キーやアカウント資格情報ではなく、公開証明書の詳細と検証出力が含まれている必要があります。オペレーターがロールバックできる内容、現在の有効性をどのようにチェックするか、およびどの障害にエスカレーションが必要かを定義します。昨日の既知の構成だったために期限切れの証明書を復元することは、有用な回復計画ではありません。
証明書ファイルではなく、デプロイされたエンドポイントをテストします。
承認された展開の後、提案されたチェックでは、正確なホスト名、アドレス、UTC 時間、観察されたチェーン、名前検証の結果、および信頼の結果を特定する必要があります。複数のサービングノードが存在する場合、実際にチェックされたスコープを保持します。オペレータのローカル テストが成功しても、すべての外部送信者が同じルートを信頼していること、または同じノードに到達していることを証明することはできません。 1 つの観察を普遍的な準備に変換するのではなく、それらの制限を記録します。
次に、元の既知の URL が意図したポリシーを持つダイレクト HTTP 200 を生成することを確認します。証明書作業により、仮想ホストの選択、ルーティング、またはアプリケーションのアクセス制御が誤って変更される可能性があります。 MTA-STS取得中に HTTP リダイレクトに従うことが禁止されているため、リダイレクト後のブラウザの成功は不十分です。有効なTLS接続と使用可能な HTTP 応答は、明確な受け入れ条件です。 RFC 8461セクション 3.2 ～ 3.3
架空の部分的な展開を調べる
架空のexample.comについて考えてみましょう。このポリシーのホスト名は 2 つのエッジ ノードによって提供されます。更新システムは新しい証明書を取得しますが、証明書をリロードするのは 1 つのノードだけです。もう 1 つは、期限切れの証明書を提供し続けます。更新されたノードに到達するテストは合格します。 2 番目のノードに到達する送信者はポリシーを認証できません。これらの観察はでっち上げられたものであり、実際のプロバイダーの動作を確立するものではありません。
提案された調査では、サービング ノードで公開フィンガープリントと有効性間隔を比較し、その後、変更されていないホスト名で認証された取得が行われます。証明書のチェックを緩和したり、検出レコードを削除したりすることから始まるわけではありません。修復所有者は、承認された展開を完了し、両方のノードを検証します。 SMTP MX証明書は、ポリシー ホストの修復ではその状態について何も示されないため、依然として独自の検証が必要です。
停止中のキャッシュ境界を理解する
ライブ ポリシーを取得できない場合、有効で期限切れになっていないキャッシュされたポリシーを持つサポート送信者は、そのポリシーを使用し続ける必要があります。このようなポリシーを持たない送信者は、フェッチ失敗後もMTA-STS存在しないかのように続行します。したがって、キャッシュの有効期間は、一部の送信者に限定的な継続性の利点を提供するものであり、HTTPS 証明書を期限切れにする許可を提供するものではありません。異なる送信者は、同じ停止中に正当に異なる状態を占有することができます。 RFC 8461セクション 3.3
検出 ID は、証明書のシリアル番号ではなく、ポリシー インスタンスを識別します。証明書のみが変更され、ポリシー本体が同一のままである場合は、更新を有効にするために新しい ID が必要であると想定しないでください。ポリシーも変更される場合は、ID の前に本体を更新する順序に従い、キャッシュされたポリシーを考慮してください。証明書の展開とポリシーのリビジョンを、個別に確認可能な変更として保持します。 RFC 8461セクション 3.1 および 8.1
次回の更新に備えて証拠を保管しておく
承認された導入記録、公開前後の証明書の詳細、認証されたフェッチ結果、および関連するすべての情報を保存します。 TLS-RPT 観察。ポリシー Web PKI の失敗は、ポリシー エンドポイントの調査に属します。報告されたSMTP証明書の有効期限は受信接続に関するものです。実際にどのカテゴリが報告されたかを確認してください。 RFC 8460セクション 4.3
現在のRFC 8461正誤表には、期限切れの受信 MTA 証明書に関して報告された大文字の修正が含まれています。期限切れの証明書は許可されません。ここでは、元の更新またはホスティングの証拠は提供されません。最終的な運用ゲートは、所有者によってレビューされた、デプロイされたサービスのタイムスタンプ付きのデモンストレーションのままです。 RFC 8461正誤表