Internet Infrastructure Review（IIR）Vol.71
2026年9月

現代社会においてインターネットは必要不可欠な存在となっており、その通信の安全性を確保することが極めて重要です。インターネットの初期には、通信内容が暗号化されずに伝送されることが一般的でしたが、2013年、元米国CIA職員だったエドワード・スノーデン氏による米国NSAの世界規模の個人情報収集・監視活動の告発が明るみに出たことで、通信の安全性とプライバシーへの関心が高まりました。

以来、インターネットにおける通信の経路暗号化（以降、「暗号化」）が急速に進み、現代のインターネットはおおむね常時TLSで暗号化されるようになりました^（注1）。この暗号化には、PKI（Public Key Infrastructure）と呼ばれる公開鍵基盤が重要な役割を果たしています。PKIでは認証局（Certificate Authority）^（注2）が、通信相手の認証や暗号化に必要なサーバ証明書の発行をしていますので、認証局とそのサーバ証明書は、現代の暗号化通信においてとても重要な役割を担っていることが分かります。

皆さんが日々利用しているWebブラウザはインターネットへの入り口です。暗号化通信を開始する際、利用者は意識せずともブラウザは通信相手を信じるかを最終的に判断しています。そこで2005年、認証局（CA）とブラウザ（Browser）ベンダーが同じテーブルについてインターネットの安全性を議論・規律する「CA/Bフォーラム^（注3）」という業界団体が設立されました。

CA/Bフォーラムでは、認証局がどのように振る舞うべきかのルールを策定し、認証局が遵守すべき最低限の要件をBR（Baseline Requirements）^（注4）として定めて公開しています。現代では認証局がCA/Bフォーラムのメンバーであるかどうかに関わらず、CA/Bフォーラムでの決定は事実上、強制力を持つものとして扱われています。

そして2024年10月、CA/Bフォーラムにおいて、公開認証局が発行可能なサーバ証明書の有効期限を段階的に47日まで短縮する提案（SC-081）^（注5）がApple社のメンバーにより提出されました。当時、発行可能なサーバ証明書の最大有効期限は398日の約1年間であり、年1回程度のサーバ証明書の更新で運用が可能でしたが、この提案が可決されると、証明書の更新頻度は約1ヵ月に1回となるため、運用体制や業務フロー・仕組みの見直しが求められることになります。

社内外のサーバ運用者視点では、サーバ証明書の更新作業にかかる工数やオペレーションリスクの増大は、事業継続性や運用上のリスクを高める要因となり得ます。特に、サーバ証明書の更新に関連する作業は、事業活動に直接的な利益を生み出さず、サービス利用者にとっても付加価値がありません。こうした作業負担が増加すると、場合によっては事業運営の根幹を揺るがす可能性も否定できない状況です。

この少々過激とも思える提案は様々な賛否と議論が交わされましたが、2025年4月、最終的にはフォーラムメンバーの投票により賛成多数で可決されました^（注6）。表-1は、有効期限短縮のスケジュールを整理したものです。

本稿発行時点で1回目の短縮は既に終わっており、2026年9月時点で発行できるサーバ証明書の最大有効期限は200日間です。認証局による発行の事務手続きや、更新時に設ける安全マージンを考慮すると、実際に利用できる期間はこれよりも短くなることがあります。

なぜCA/Bフォーラムでは、このような決定をしたのでしょうか？こうした背景と目的は次のとおりです。

特に3番目は、サーバ証明書の有効期限に関わらず、運用現場では工数省力化の観点で大きなメリットがあります。

このような状況を踏まえ、証明書更新作業の自動化が求められています。では、どのようにこのプロセスを自動化すれば良いのでしょうか。サーバ証明書の更新を自動化するプロトコルとして、RFC8555で標準化されたACME（Automatic Certificate Management Environment）^（注9）がよく知られています。英語圏では「アクミー」と発音されます。

ACMEに対応した認証局の中でも、Let's Encryptは特に広く認知されています。同認証局は非営利団体ISRG（Internet Security Research Group）によって運営されており、サーバ証明書の発行から利用まですべてのサービスを無償で提供しています。現在、世界中で7億以上のWebサイトがLet's Encryptのサービスを利用しており、その普及率は非常に高いと言えます。

また、Let's Encryptに対応したACMEクライアントは複数の実装がインターネット上で公開されており、次のようなクライアントが有名です。仕組みがシンプルなので、動きを確認する目的で手作業でも証明書を取得することができます。

サーバ証明書を発行するためには、認証局が発行審査を行う必要がありますが、このプロセスも当然自動化されています。なお、サーバ証明書には発行審査の違いとして、表-2の3種類がありますが、どの証明書を利用しても暗号化やTLSの機能面に差はありません。本稿ではDVについて記載します。

サーバ証明書を発行する方法として、主に「HTTP-01 Challenge」と「DNS-01 Challenge」の2つが標準的に利用されています。表-3は、それぞれ特徴や手順をまとめたものです。

ここまで、Webブラウザで暗号化通信を行う際にはサーバ証明書が必要であることを説明しましたが、メールの暗号化通信においても、SMTPの拡張機能であるSTARTTLSを利用する際、メールサーバ側でサーバ証明書が必要です。従って、CA/Bフォーラムでの決定はメールサーバの運用もその例外ではなく、同じ影響を受けることになります。

IIJセキュアMXサービスでは、インターネット経由でメールを受信するサーバだけでなく、お客様のメールクライアントやメールサーバから送信されるメールをリレーする送信サーバ、更にWebメールやAPIのエンドポイントなど、多岐にわたる機能を提供しています。同サービスにおいて、サーバ証明書の更新が必要となる対象を調査したところ合計で13ヵ所あることが分かりました。また、機能ごとに可用性と性能向上のために冗長化・スケールアウトしており、すべてのサーバの証明書が更新対象です。

なお、CA/BフォーラムがSC-081の提案を行う前の2023年3月、Google社がサーバ証明書の有効期限を最大90日に短縮する方針を発表していました^（注11）。その後、CA/Bフォーラムでサーバ証明書の有効期限短縮に関する議論が活発になっていることに着目し、IIJセキュアMXチームでは、先んじた対策が必要と判断、社内で検討を開始していました。

図-1は、構成の概略図です。

IIJセキュアMXサービスはメールサーバのようにWebインタフェースを持たないサービスがあること、ワイルドカードの証明書が利用できること、複数のサーバに証明書を配布する必要があることから、DNS-01 Challengeを利用しています。

幸いにもIIJにはIIJ DNSプラットフォームサービス^（注12）という、API経由でDNSレコードを編集できるサービスがあり、Let's Encrypt対応のACMEクライアント「lego」が、同サービスに標準対応しています^（注13）。従って個別に実装する必要があるのは、取得した証明書を各サーバに配布する部分（8）のみです。また、秘密鍵と証明書は社内のシークレット情報を保管するVault^（注14）に格納し（7）、各サービスホストのエージェントが更新を検知して取得・反映する仕組みとしました。legoは後処理のプロセスも追加可能なので、この拡張も容易です。

チームメンバーによるPoC（概念実証）を経て社内稟議が承認され、2024年9月よりサーバ証明書更新の自動化を開始しました。当初の想定どおり、運用チーム内でサーバ証明書の更新作業をすることが不要となり、作業工数の大幅な削減と人為的ミスなどのリスク低減を同時に実現することができました。図-2は社内の経緯とサーバ証明書の有効期限のタイムラインを示したものです。

なお、社内稟議及び作業前のリスクアセスメントにおいて、認証局の変更によるリスクが重要な検討項目として挙げられました。特に、当時はメールサーバにLet's Encryptを導入している他社事例が存在しない状況だったため、未知の運用リスクやサービス安定性への影響が懸念されました。これらのリスクについては、事前にお客様への十分なご案内を行った上で、サービスとしてリスクを受容する方針を取りました。その結果、運用開始後に大きな問題や反響は発生せず、スムーズな移行が実現しました。新たな技術導入に積極的に取り組み、サービス進化を推進できたことは、現場にとっても大きな成果となったのです。

今回、Let's Encrypt及びACMEの仕組みを活用することでサーバ証明書の更新自動化を実現しました。しかしながら、万が一Let's Encryptのサービスが停止すると、そこがサービス全体の単一障害点となるリスクが残る点は、IIJセキュアMXサービスに限らず、グローバルに共通する課題として認識されています。このリスクは有効期限が短くなればなるほど大きくなります。

このような背景を踏まえ、IIJでは単一障害点のリスクを軽減し、サーバ証明書の発行・更新を自動化する新たなサービスの開発に取り組んでいます。IIJサービスのみならず、サーバ証明書の管理で課題をお持ちのお客様にも、まもなく本ソリューションをご提案できる予定ですので、続報をお待ちください。