TLSAレコードの生成方法と3 1 1の不一致の修正方法

TLSAレコードの生成方法と3 1 1の不一致の修正方法 TLSAレコードは、メールサーバーのTLS証明書をDNSにピン留めするため、送信サーバーはSMTP経由で正しいキーに到達するか、配信を拒否します。その最も一般的な形式である3 1 1は、DANE（DNS-Based Authentication of Named Entities、RFC 6698、メールの場合はRFC 7672）の中心です。このガイドでは、OpenSSLを使用してTLSAレコードを生成し、公開し、解決と検証を行い、ほとんどのデプロイメントを壊す3 1 1の不一致を修正する方法を示します。理論ではなく、コマンドのみです。 対象者：PostfixおよびEximオペレーター、Microsoft 365管理者でインバウンドDANEを追加するユーザー、またはdane tlsa 3 1 1 mismatchの検索でここにたどり着いたすべての人。TLSAレコードとは何か、そしてDANEがより広い全体像の中でどのように位置づけられるかについては、DANEプロトコルガイドを参照してください。この記事は運用に焦点を当てます。 主な発見：スキャンされた5.5Mドメインのうち30（0.0%）がDANE TLSAレコードを公開しています（出典：DMARCguard、State of Email Authentication 2026（2026年2月））。 DANEは稀です。しかし、SMTPにとっては最も強力なトランスポート認証オプションです。TLSAレコードを公開するドメインが非常に少ない理由は、レコード自体ではなくDNSSECの前提条件です。ゾーンがすでに署名されている場合、以下の作業は約3つのコマンドと1つのDNSレコードで完了します。 3 1 1の意味：証明書使用量3（DANE-EE）、セレクター1（SubjectPublicKeyInfo — 証明書全体ではなく公開鍵）、マッチングタイプ1（SHA-256ハッシュ） TLSAレコードの3 1 1は3つの数値フィールドです。証明書使用量3（DANE-EE）、セレクター1（SubjectPublicKeyInfo — 証明書全体ではなく公開鍵）、マッチングタイプ1（SHA-256ハッシュ）。これらを組み合わせることで、送信サーバーに1つのことを伝えます。この正確な公開鍵がSHA-256でハッシュされたものが、私のメールサーバーが提示する唯一の鍵であるということです（RFC 6698 §2.1.1–2.1.3）。各フィールドはワイヤー上では1オクテットです。 証明書使用量（RFC 6698 §2.1.1）：0 PKIX-TA、1 PKIX-EE、2 DANE-TA、3 DANE-EE。SMTPでは2と3のみが使用可能です。Postfixは使用量0と1を無効とみなし、RFC 7672 §3.1.3ではSMTP TLSAレコードはPKIX-TA(0)またはPKIX-EE(1)を使用してはいけない（SHOULD NOT）とされています。これは、MTA間で合意されたCAリストがなく、警告を通過する人間がいないためです。 セレクター（RFC 6698 §2.1.2）：0は完全な証明書、1はSubjectPublicKeyInfo（SPKI）、公開鍵のみです。セレクター1は、キーペアを再利用する限り、証明書更新後も有効です。 マッチングタイプ（RFC 6698 §2.1.3）：0は選択されたデータの完全一致、1はSHA-256ハッシュ、2はSHA-512です。 したがって、3 1 1は「DANE-EE、SPKI、SHA-256」と読み取れます。RFC 7672 §3.1は、この組み合わせ（DANE-EE(3) SPKI(1) SHA2-256(1)）をSMTPの主要な推奨事項として挙げています。これはリーフ公開鍵をピン留めし、CAを必要とせず、証明書の有効期限とホスト名チェックを明示的に無視するためです（§3.1.1、§3.1.3）。知っておくべき唯一の代替手段は2 1 1（DANE-TA）で、これはリーフではなく発行CAをピン留めします。これは以下の例でカバーされています。 OpenSSLでTLSAレコードを生成する方法 3 1 1 TLSAレコードを生成するには、証明書から公開鍵を抽出し、DERに変換し、SHA-256でハッシュします。64文字の16進数ダイジェストがレコードの3番目の値になります。 3 1 1 TLSA値を生成する（DANE-EE (3) / SPKI (1) / SHA-256 (1)）。セレクター1は公開鍵（SubjectPublicKeyInfo）をハッシュするため、キーペアを再利用する限り、値は更新後も同じままです。 ```bash openssl x509 -in cert.pem -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256 -binary \ | hexdump -ve '/1 "%02x"'; echo ``` 出力は64文字の16進数ダイジェストです — レコードの3番目のフィールドです： `3 1 1 4e7098b757d837a9d782a1fe31057708ee4d2a71166e185f66009c488ed3632c` バイナリパイプの実行を避けたい場合：`openssl dgst -sha256`は、`= `の後に同じ16進数を出力します（プレフィックスはOpenSSLのバージョンによって異なります）： `SHA2-256(stdin)= 4e7098b757d837...ed3632c` 最初のパイプ（openssl x509 -noout -pubkey）は証明書からSubjectPublicKeyInfoを抽出します。openssl pkey -pubin -outform DERはそれをマッチングタイプがハッシュするDERバイトとして再エンコードします。openssl dgst -sha256はダイジェストを生成します。これがセレクター1です — 公開鍵をハッシュしているため、キーを再利用する限り、値は更新後も一定です。セレクター0が落とし穴です。証明書全体をハッシュする（openssl x509 -outform DER | openssl dgst -sha256、3 0 1レコードを生成）と、キーが変わらなくても更新ごとに値が変わるダイジェストが生成されます — これがセレクター1が運用上のデフォルトである理由です。同様に一般的な2番目の間違いは、セレクター1を公開するが、証明書全体に対してダイジェストを計算することです。レコードは構文的に有効ですが、決して一致せず、DANE SMTP Validatorの「よくある間違い」リストで文書化されているトップエラーです。 OpenSSLを実行したくない場合？証明書またはホスト名をTLSA/DANEレコードジェネレーターに貼り付けると、公開準備のできた3 1 1値が計算されます。 TLSAレコードの例：3 1 1 vs 2 1 1 vs 3 0 1 ほとんどすべてのSMTPメールには3 1 1を使用してください。リーフ公開鍵をピン留めし、キーを再利用すれば証明書更新後も有効です。2 1 1は、リーフローテーション全体で発行CAをピン留めする必要がある場合にのみ使用してください。3 0 1は、完全証明書のハッシュは更新ごとに変更されるため避けてください。 これら3つすべてをライブレコードとして示します。 _25._tcp.mail.example.com のTLSAレコード例 オーナー名の形式：_<ポート>._<プロトコル>.<MXホスト名> MTA間メールの場合、これは常にポート25のTCPです（RFC 7672 §2.1）： `_25._tcp.<各MXホスト名>` 3 1 1 — DANE-EE / SPKI / SHA-256。推奨されるSMTPレコード（RFC 7672 §3.1）。リーフ公開鍵をピン留めし、キーを再利用すれば更新後も有効です。 `_25._tcp.mail.example.com. IN TLSA 3 1 1 ( 4e7098b757d837a9d782a1fe31057708ee4d2a71166e185f66009c488ed3632c )` 2 1 1 — DANE-TA / SPKI / SHA-256。発行CAの公開鍵をピン留めするため、同じCAが署名している限り、リーフローテーション全体で検証を維持します。（RFC 7672 §3.1ではDANE-TA(2)を発行CAの公開鍵のSHA-256ハッシュとして2番目の選択肢として挙げており、その例では2 0 1の完全証明書形式を使用しています。）発行CA証明書は、提供されるチェーンに含まれている必要があります。 `_25._tcp.mail.example.com. IN TLSA 2 1 1 ( 1f2e3d4c5b6a79880192a3b4c5d6e7f80a1b2c3d4e5f60718293a4b5c6d7e8f90 )` 3 0 1 — DANE-EE / 完全証明書 / SHA-256。証明書全体をハッシュするため、更新ごとに破損します。メールにはほとんど適していません。 `_25._tcp.mail.example.com. IN TLSA 3 0 1 ( af53b991cf4bceed4987aa6d7084b144ac8c84ba3d9c45128d652a97739bd74c0 )` | レコード | 更新時に使用 | ピン留め対象 | |---|---|---| | 3 1 1 | リーフ公開鍵（SPKI）、SHA-256 | SMTPのデフォルト。キーが再利用されれば安定 | | 2 1 1 | 発行CA公開鍵、SHA-256 | ローテーション全体でCAをピン留め。同じCAであれば安定 | | 3 0 1 | 完全リーフ証明書、SHA-256 | 更新ごとに破損。稀な選択肢 | SMTPにおける各TLSAレコードフレーバーの使用時期 オーナー名は常に同じ形式に従います：`_25._tcp.<MXホスト名>` — ポート25、TCP、そして実際にメールを受け付けるMXホスト（RFC 7672 §2.1）。DANEは各MXホストに個別にバインドされ、組織ドメインにはバインドされないため、2つのMXホストを持つドメインは各ホストの下にTLSAレコードが必要です。（RFC 7672 §3.1では、DANE-TA(2) Cert(0) SHA2-256(1) — 2 0 1完全CA形式 — を文書化された2番目の選択肢として挙げていますが、オペレーターは発行CAのキーのみをピン留めする2 1 1 SPKIバリアントを公開することが多いです。） DNSプロバイダーでのTLSAレコードの公開方法 レコードをオーナー名 `_25._tcp.<あなたのMXホスト名>` に、レコードタイプTLSA（またはプロバイダーにTLSAフィールドがない場合は汎用タイプTYPE52）として、3つのフィールドとハッシュ値を値として公開します。ゾーンはDNSSEC署名されている必要があり、DSレコードがレジストラに公開されている必要があります — そうでない場合、検証する送信者はレコードを完全に無視します。 メールサービス用のTLSAレコードを公開する MXホストごとにオーナー名を選択します。`mail.example.com` の場合、`_25._tcp.mail.example.com` です。実行しているすべてのMXホスト名に対して繰り返します。レコードタイプを選択します。Sel