2025 年 3 月のアップデートでデジサートは、認証局認証（CAA）チェックを実装することによって、公的に信頼されるセキュア E メール（S/MIME）証明書の発行に関するセキュリティ対策を強化できるようになります。このアップデートは、E メールのセキュリティ強化を目的とする業界の新しいベースライン要件に準拠したものです。

これまで、公的に信頼される S/MIME 証明書は、発行認証局（CA）がドメイン所有者によって明示的に認証されているかどうかを検証しなくても発行できました。つまり、あるドメイン下の E メールアドレスに対する S/MIME 証明書はどの CA でも発行できたため、不正な発行やセキュリティリスクにつながっていたのです。

現在デジサートは、E メールドメインに対する S/MIME 証明書を発行する前に、そのドメインの DNS CAA リソースレコードをチェックする必要があります。この追加ステップによって、デジサートは証明書発行の権限を明示的に付与されます。そのため、ドメイン所有者はメールセキュリティに関する制御が強化され、誤発行のリスクが軽減されます。

認証局認証の概要

CAA チェックは、不正な証明書発行に対する追加の保護層を管理者に提供します。CAA レコードを実装することで、組織は証明書ポリシーを技術レベルで適用できます。そのため、誤発行のリスクを緩和し、承認された認証局のみがドメインに対する証明書を発行できるよう限定できます。

CAA の仕組み

DNS CAA リソースレコードを構成すると、ウェブサイトまたは E メールドメインに対して証明書を発行できる認証機関を制御できます。このメカニズムは、TLS 証明書に 2017 年から適用されており、現在は公的に信頼される S/MIME 証明書にも適用されています。

なぜ重要か

Web PKI システムで大きな懸念のひとつは、どんな認証局でも、任意のウェブサイトや E メールドメインに対して証明書を発行できる可能性があるということです。そのため、CA が危殆化した場合にセキュリティリスクが発生します。CAA チェックは、ドメイン所有者が特定の CA をホワイトリストに登録できるようにすることで、この懸念に対処するので、そのドメインに対しては信頼できるプロバイダーのみが証明書を発行できるようになります。

CAA を使用しない場合はどうなるか

CAA を実装していないドメインの場合、制限はありません。そのドメインに対しては、どの認証局も証明書を発行できます。発行を制限したくない場合は CAA レコードを作成しないでください。ドメインは通常どおりに機能します。

CAA によるポリシーの適用

CAA は単なるセキュリティ機能ではありません。証明書発行を管理する組織にとって強力なポリシー適用ツールでもあります。ドメインに対して証明書を発行できる認証局を制限することでセキュリティリスクを軽減するほか、証明書の調達や導入に関連する内部ポリシーも適用できます。

多くの組織にとって、特に複数のオフィスや準自律的な部門を持つ組織にとって、内部の証明書ポリシーに確実に準拠することは困難かもしれません。CAA は、不正な証明書要求を防ぐ技術的な保護措置になります。

たとえば、エンジニアリング部門のあるチームが新しいサービスを立ち上げ、証明書を要求しようとしたとします。承認リストにない CA を使おうとした場合、その要求は、組織の証明書ポリシーに準拠するために自動的にブロックされます。

CAA レポートを構成するオプションもあり、承認されていない要求を受信した場合に CA は、指定の E メールアドレスまたは URL に通知を送信できます。このオプションがあるため、管理者はポリシーガイドラインに準拠しない証明書要求の試行をリアルタイムで可視化できます。

CAA の導入方法

幸い、CAA の実装は比較的容易で、HSTS（HTTP Strict Transport Security）や HPKP（Key Pinning）といった厳格なセキュリティメカニズムに比べて設定エラーによるリスクも大幅に低くて済みます。

ただし、技術的な要件がひとつあります。マネージド DNS プロバイダーを使用する場合、CAA レコードをサポートしている必要があります。新しい DNS リソースレコードタイプだからです。

当社のDNS CAA レコードドキュメントでは、CAA を導入するための技術的な手順を詳しく説明していますが、ここでは主な手順の概要をご紹介します。

1. CAA レコードを組織の証明書ポリシーに整合させる

• 最初に、既存の証明書ポリシーを参照します。組織が特定の認証局を承認している場合は、そのリストを使用して、CAA レコードに含める CA を決定します。
• 正式なポリシーがない場合は、組織が通常使用している CA を特定します。
• CAA レコードは必要に応じて更新または削除でき、その変更は DNS の TTL（生存時間）設定に従って有効になります。

2. CAA DNS レコードを作成する

• CAA ポリシーは、必要に応じて厳格にも柔軟にも設定できます。1 つの認証局のみ許可することも、複数のプロバイダーを承認することも可能です。
• 10 の認証局を許可するさらに柔軟なポリシーでも、多くのプラットフォームで信頼される 100 以上の CA よりリスクは大幅に低くなります。

CAA レコードのタグを理解する

E メールドメイン用の S/MIME 証明書を発行することをデジサートに許可する CAA レコードの例を次に示します。

yourdomain CAA  0  issuemail  "digicert.com"

このレコードは、ドメインに属するサブドメインすべてに適用されます。

• S/MIME 証明書は issuemail タグを使用します。
• TLS 証明書は issue タグと issuewild タグを使用します。

複数の CA を承認したい場合は、認証局ごとに新しい CAA レコードを追加します。

CAA レコードと DNS 階層

• CAA レコードは、DNS ツリーの階層構造で最上位ドメインから順にチェックされます。
  • sub.domain.com に対して証明書を要求した場合、CA はまずサブドメインレベルで CAA レコードをチェックします。
  • サブドメインにレコードが存在しない場合、ルートドメインの CAA レコードがチェックされます。
• CNAME レコードを使用しているドメインの場合、親ドメインは最後にチェックされます。

CAA のセキュリティ上の利点

特定の DNS CAA リソースレコードを設定すると、今後の証明書要求はすべて、このレコードを基準にチェックされます。リストにない CA は、そのドメインに対する証明書の発行を拒否しなければならないため、誤発行が発生する可能性が大幅に減少します。

CAA チェックは、人為的なミスを防ぐ優れた保護手段になるだけでなく、敵対者から組織を守る機能もあります。不正な証明書の取得を試みるハッカーは、明示的に承認した認証局に制限されます。CA が強力なアカウント制御を実施している場合、攻撃者は、たとえウェブサーバーに侵入しても、OV/EV 検証を完了することはできません。また、特定の認証局の検証または発行手続きに脆弱性がある場合、信頼できる 1 つの CA に発行を制限すると、特定のドメインが影響を受ける可能性を低減できます。

考慮すべき CAA の制限事項

CAA は実効的なセキュリティ対策ですが、制限もあります。

• 悪意のある、または危殆化した認証局: CA が不正行為に走ったり侵害されたりした場合、CAA レコードを無視して証明書を発行する可能性があります。
• DNS のセキュリティリスク: DNS レコードのなりすましは稀ですが、潜在的なリスクであることは変わりません。攻撃者が DNS にアクセスする場合、CAA レコードを削除または変更できるため、任意の CA がドメインに証明書を発行できるようになります。
• ローカルな信頼の例外: CAA が適用されるのは、公的に信頼されている CA のみです。組織のネットワーク（企業イントラネットなど）内で信頼されているローカルルート証明書による証明書発行は防止できません。

以上の制限はあるものの、CAA は攻撃対象領域を縮小し、信頼できる認証局のみがドメインの証明書を発行できるよう保証する重要なツールです。

デジタルトラストに関する最新情報

S/MIME、DNS、認証局などのトピックについて詳しくお知りになりたい場合、記事を見逃さないようにデジサートのブログを参照してください。