STARTTLSとは

STARTTLSを読むときの前提

STARTTLSは、平文で接続を開始したあと、プロトコル上のコマンドでTLSへ切り替える仕組みです。SMTP、IMAP、LDAPなどで使われ、接続開始時からTLSで待ち受ける方式とは確認観点が違います。

実務では、相手がSTARTTLSを広告しているか、TLSが必須か任意か、証明書のCN/SAN、期限、信頼チェーン、TLSバージョン、暗号スイート、ダウングレード時の挙動を分けて確認します。

証跡には、対象ホスト、ポート、EHLOなどの応答、STARTTLS広告、証明書情報、TLSバージョン、検証コマンド、確認時刻を残します。

任意暗号化と必須暗号化を分ける

SMTPのサーバー間配送では、STARTTLSは任意暗号化として扱われることが多く、相手が対応していない場合に平文配送へ落ちる構成があります。一方、submissionや社内連携ではTLS必須にする設計もあります。

障害時は、TLS必須設定が配送を止めているのか、相手がSTARTTLSを広告していないのか、証明書検証で失敗しているのかを分けます。ポート番号だけでは暗号化の有無は判断できません。

• STARTTLSが広告されているか確認する。
• TLS必須か任意かを設定で確認する。
• 平文フォールバックの有無と許容条件を記録する。

証明書と名前の整合を見る

STARTTLSでもTLS証明書の検証が関係します。証明書の期限、信頼チェーン、SAN、接続先名、SNIの扱いが合わないと、クライアントや中継サーバーによっては接続に失敗します。

メール配送ではMX名、接続先ホスト名、証明書名、ログ上の相手名が一致しないことがあります。どの名前で接続し、どの証明書を受け取ったかを保存します。

• 証明書の期限、発行者、SANを確認する。
• 接続先名と証明書名を突合する。
• SNIの有無で証明書が変わらないか確認する。

ダウングレードとログを確認する

STARTTLSは平文接続から始まるため、経路上の機器や相手側の不具合でSTARTTLS広告が見えない、TLSハンドシェイクが失敗する、平文へ落ちるといった事象があります。

切り分けでは、openssl s_client -starttls smtp のような確認、メール基盤のTLSログ、配送ログ、相手先の応答を同じ時刻で見ます。暗号化できていないことと、メール認証に失敗していることは別問題です。

• STARTTLS広告とTLSハンドシェイク結果を保存する。
• メール基盤のTLSログと配送ログを突合する。
• 平文配送へ落ちた条件を確認する。

変更証跡と引き継ぎ

STARTTLS変更では、対象サービス、ポート、TLS必須設定、証明書、信頼チェーン、テストコマンド、相手先影響、戻し条件を残します。証明書更新やメール基盤移行では、TLS設定とMX/SMTP設定を同じ変更として確認します。

引き継ぎでは、メール基盤管理者、証明書管理者、DNS管理者、関連語としてSMTP、TLS、MX、MTA-STS、TLS-RPTを残すと追いやすくなります。

• TLS必須設定と例外条件を記録する。
• 証明書更新時の確認コマンドを残す。
• 配送ログとTLSログの見方を引き継ぐ。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能