CA/BフォーラムによるS/MIMEベースライン要件（BR）は、長年分断されてきたエコシステムに秩序をもたらすことを目的として策定されました。ついに認証局（CA）が共通の基準に従い、メールクライアントは一貫した挙動を示し、組織は署名や暗号化を安心して導入できる――それが理想でした。

しかし実際には、状況は異なります。電子メールは今なお、企業内外や金融・医療などの規制産業でのコミュニケーションの基盤です。弱い、あるいは非準拠の証明書を使用すれば、コンプライアンス違反、監査失敗、ブランドへの損害といった重大なリスクを招きかねません。

ところが2年が経過した今でも、現実は理想からほど遠いのです。準拠状況は広がっておらず、相互運用性にも課題が残り、多くの組織――管理体制の整ったPKIプログラムを持つ企業でさえ――が、BRの基本的な検証にすら通らない証明書を使用しています。

多くの組織は「信頼された証明書を使っている」「メールセキュリティは標準準拠だ」「相手には正しい信頼マークが表示されている」と信じています。しかし現実には、要件を満たしていない環境が数多く存在し、クライアント側の検証が厳格化する中で、その“認識と実態のギャップ”がリスクとなりつつあります。

BRが解決を目指した課題

BR策定以前のS/MIMEは、まさに「つぎはぎ」状態でした。認証局（CA）ごとに発行方針が異なり、メールクライアントによって挙動もばらばら。ID検証、証明書構造、暗号強度に共通ルールがなかったため、S/MIMEは展開しづらく、信頼しにくく、誤用されやすい技術となっていました。

そこでBRは、S/MIME証明書の発行・検証・解釈に明確で実行可能な標準を導入し、電子メールの暗号化と署名を最新のPKI基準に合わせることを目的としました。

企業にとってのメリットは明快です。相互運用性の向上、ID保証の強化、そして運用の単純化。すべてのCAとクライアントが同じルールで動作すれば、暗号化の失敗、警告エラー、なりすましメッセージといったリスクを減らせるはずでした。

現実に起きていること

2023年にBRが施行された際、多くのセキュリティチームは「S/MIMEの強化が始まった」と考えました。既存の証明書は整備され、新規発行は自動的に安全で、クライアントも新基準を強制する――そう信じていたのです。

しかし、現実は異なりました。

2025年9月、研究者チームが世界中のLDAPディレクトリから収集した3800万枚以上の証明書を分析した初の包括的調査を発表しました（USENIX研究）。結果は衝撃的なものでした。

• 大多数の証明書がいまだにベースライン要件を満たしていない
• 直近発行された証明書の90％以上が、BR準拠を示すポリシー識別子を欠如
• 多数が基本的な検証（lintチェック）に不合格。欠落・誤構成フィールド、弱い暗号、壊れた信頼チェーンなどが発覚
• さらに問題なのは、これらの証明書が依然として主要メールクライアントで受け入れられ、実環境で使用されている点です

ベースライン要件が浸透しない理由

BR自体は明確で、範囲も妥当で、主要プレイヤーも支持している――では、なぜ採用が進まないのでしょうか。問題は標準そのものではなく、エコシステム構造にあります。

TLSのように、ブラウザ、HSTSポリシー、証明書透明性ログによって準拠が推進される仕組みは、S/MIMEには存在しません。中央の強制機構も、公開ログシステムも、自動失効・更新の仕組みもありません。圧力がないため、変化のスピードは遅いのです。

多くのCAが発行プロセスを完全には移行しておらず、旧プロファイルをデフォルトで提供するケースもあります。ID検証やフィールド設定を更新していないCAも存在します。一方で、メールクライアントの多くはようやく警告やブロックを始めたばかりで、明確に違反する証明書でも受け入れてしまう場合があります。

組織内部でも同様です。S/MIMEは一度導入されると、そのまま放置されがちです。どの証明書がどこで使われているのか、BR準拠かどうかを監査できるチームは少なく、問題があっても気づかないことが多いのです。失効URIの欠如や信頼チェーンの欠落など、見えないトラブルが発生しても、実際に障害が起きるまで放置されてしまいます。

非準拠のまま放置するリスク

一見、非準拠のS/MIME証明書でも「動いている」ように見えるかもしれません。メッセージ署名も暗号化もできている――しかし、それは危うい正常性です。

クライアントの検証が厳格化すれば、昨日まで問題なく使えていた証明書が突然機能しなくなり、暗号化が失敗し、署名が無効化され、重要な通信の信頼性が損なわれる可能性があります。

さらに深刻なのは、組織の多くがそのリスクに気づいていないことです。どの証明書が古いのか、設定が誤っているのか、脆弱なのかが把握できず、監査も困難。メッセージが届かない、署名が認証されない――その理由を説明できないのです。

金融・医療などの規制業界では、これらの失敗は単なる技術的な問題にとどまりません。運用面・ブランド面の損失に直結するリスクです。しかも、適切なツールなしでは検知すら困難です。

最初のステップは「置き換え」ではなく「可視化」

多くの組織は、自社インフラでどのS/MIME証明書が使われているか把握できていません。可視化がなければ、準拠状況や信頼性を判断することは不可能です。

そこで重要なのが証明書リンティング（linting）です。デジサートが開発したpkilintのようなオープンソースの証明書リンターは、まさにこの課題を解決するためのツールです。pkilintは証明書のBR違反、暗号の弱点、構造エラーなどを検出し、通常では見逃される問題を可視化します。

実際、USENIXの研究ではpkilintを使って約1000万枚の証明書を解析しました。その結果、数百万枚が基本的なチェックに不合格であり、ポリシー識別子の欠如、キー使用法の誤設定、AIAフィールドの無効化などが多数確認されました。これは例外ではなく、広範な問題なのです。

証明書発行、ディレクトリアudit、パートナー検証などのプロセスにlintingを組み込むことで、推測に頼らず実行可能なインサイトを得て、強制的な準拠化が始まる前にS/MIME体制を整えることができます。

デジサートと共に、将来に備えたS/MIME戦略を構築する

メール署名と暗号化は、企業の重要な通信、ブランド、そして法的な信頼を守る要です。標準に準拠しない証明書に依存すること、または準拠状況を把握していないことは、大きなリスクです。

そこでデジサートが支援します。

pkilintなどのツールを使えば、まず証明書の在庫を可視化し、問題を事前に検出できます。さらに、デジサートのソリューションは、BR準拠の発行、ライフサイクル全体の管理、大規模環境への統合を支援します。

社内PKIのモダナイゼーション、規制業界の通信セキュリティ、レガシー環境の整理――どのケースでも、デジサートは可視化と統制の両立を支援し、コンプライアンスギャップを埋めることができます。

電子メールの信頼は「運」に任せるべきではありません。それは「基準」によって守るべきものであり――その基準を支えるのが、デジサートのツールです。