eMudhraのCA鍵危殆化：企業がいま確認し、直すべきこと

2026年10月17日（土）、あるセキュリティ研究者が、インドの認証局eMudhraが運営する8つの中間認証局について、その秘密鍵が公開されている証明書から誰でも割り出せる状態にあると報告しました。鍵はどれも256より小さい数でした。そのうちの1つは、数字の4でした。8つのうち6つはApple、Google、Microsoft、Mozillaが信頼するTLS証明書を発行でき、残る2つはWindowsのソフトウェアに署名できました。

Chromeは報告の1時間40分後に6つのTLS用の鍵をブロックし、Firefoxも同じ日の夜にブロックしました。ウェブを閲覧する人にとっては、危険は土曜の夜までに去っていました。

それ以外のすべてにとっては、終わっていませんでした。サーバー、コンテナ、Javaアプリケーション、Pythonスクリプト、決済連携、コネクテッドデバイスは、信頼する認証局の一覧を自前で持ち、それと照らして証明書を検証します。その一覧の多くは、誰かが更新をインストールしたときにしか変わりません。それまでは、これらの鍵のいずれかで署名された証明書は、どのドメインのものであっても本物として通ってしまいます。しかも鍵は10月20日から公開されています。

同じ週、GoDaddyは404,607件の証明書の失効を始めました。証明書に含まれるポリシー情報が、同社自身が公開している文書と一致していなかったためです。顧客は、差し替え用の証明書を自分でダウンロードしてインストールしなければなりませんでした。

このガイドは、「自社は影響を受けるのか」に答えなければならない人のためのものです。ITと運用の責任者、CTO、そしてウェブサイトやAPI、コネクテッド製品で事業を営む創業者です。Mozilla、Google、eMudhra、GoDaddy、各ソフトウェアベンダーが公開したインシデント記録をもとに何が起きたのかを整理し、今日確認すべきこと、今週更新すべきこと、そして次に同種のインシデントが起きても通常業務として対処できるよう整えておくべきことを説明します。内容はすべて2026年10月22日時点のもので、インシデントはまだ収束していません。

何が起きたのか

eMudhraは2025年4月30日のキーセレモニーで、この8つの中間認証局を作成しました。10月19日にMozillaのインシデント用バグに投稿された同社の説明は次のとおりです。通常の手順からの逸脱として承認された、鍵のラップとアンラップの工程のテストに欠陥があり、ハードウェアセキュリティモジュール（HSM）の中に、本来の鍵と並んで弱い鍵がもう1組作られました。ラベルが似ていたため、証明書署名要求の作成に誤って弱い鍵が使われ、eMudhraのルート証明書がそれに署名しました。同じ要求はSectigoにも送られ、Sectigoは2025年5月14日に、同社のルート証明書AAA Certificate Servicesで8つすべてにクロス署名しました。eMudhraは「正確な根本原因はまだ確認できていない」と述べています。

Mozillaはその結果を「P384の秘密鍵は、1から群の位数までの範囲で無作為に選ばれる整数である。影響を受けた8つの鍵は、いずれも256未満の整数を使っていた」と説明しています。Mozillaは20:06 UTCに報告を受け、21:48には「最初の報告者が使った手法を一切知らないまま」自力で鍵を復元しました。研究者は、Googleのオープンソースのライブラリparanoid_cryptoを「標準設定のまま」使って鍵を見つけたと述べています。弱い鍵は、18か月近くにわたって公的に信頼された証明書チェーンの一部になっていました。

対象の8つの証明書：

それぞれの鍵は2つの証明書に含まれています。1つはeMudhraのemSign Root TLS CA - G3またはemSign Root CS CA - G3が発行したもので、これらはemSign ECC Root CA - G3へとつながります。もう1つは、AAA Certificate Servicesから発行されたSectigoのクロス証明書です。2つ目の経路が重要なのは、eMudhraのルート証明書を一度も収録したことのないトラストストアでも、Sectigoのこの古いルート証明書はいまも信頼している場合があるからです。

攻撃はあったのか

悪用の報告はありません。ブラウザについては、悪用がなかったと考えるだけの十分な理由もあります。Chromeは、Certificate Transparency（CT：証明書の発行を公開ログに記録させる仕組み）を強制するほかのクライアントと同様に、公開されたCTログに記録されている証明書しか受け入れません。Googleによれば、ブロックより前に、この6つの中間認証局につながるTLS証明書は1件もログに記録されていませんでした。そのため同社は「これらのCAが発行した不正な証明書が、CTを強制するクライアントに対して使われた可能性はない」としています。

ブラウザの外では、状況が違います。Mozillaのインシデントページは「ブラウザのエコシステムの外にある多くのクライアントは、Certificate Transparencyを強制していない。攻撃者が欠陥のある鍵生成を悪用してこれらのクライアントを狙ったかどうかは、わかっていない」と書いています。この隙は2025年春に開き、クライアントごとに、更新されたときにだけ閉じます。eMudhraは、公表前に鍵が復元されていたことを示す証拠は把握していないとしており、Cloudflareも、調査の結果、同社のサービスで実際の悪用は見つからなかったとしています。

鍵が公開されたいま、証明書の偽造に技術は要りません。Mozillaのインシデントページには、危殆化した鍵で発行された証明書を提示するテストサーバーが掲載されており、誰でも自分のクライアントをそれで確かめられます（コマンドは後述します）。

偽造された証明書があれば、次のことが可能になります。自社のソフトウェアと、それが呼び出すサービスとの間の通信を傍受できる者（共有ネットワーク上で、乗っ取られたルーター経由で、あるいは改ざんされたDNS応答によって）は、そのサービスになりすまし、ソフトウェアが送る内容をAPIキーや個人データも含めて読み取り、受け取る内容を書き換えられます。2つのコード署名用の鍵のいずれかで署名されたソフトウェアは、Microsoftのブロックがそのマシンに届くまで、Windowsの署名チェックを通過していたはずです。

影響を受けるのは誰か

問題は3つあり、それぞれ別物です。1つの企業が3つすべてを抱えていることもあります。

1. 危殆化した鍵をまだ信頼しているソフトウェア

ほぼすべての企業がこの問題を抱えています。HTTPSで通信するプログラムのうち、トラストストアにまだemSign ECC Root CA - G3またはAAA Certificate Servicesが含まれ、8つの鍵に対するブロックを受け取っていないものはすべて該当します。典型的な場所は次のとおりです。

• 10月20日または21日より前に構築されたLinuxサーバーとコンテナイメージ。たとえば、パッチを当てていないDebian 12は両方のチェーンを信頼します。
• 独自の一覧を同梱する言語ランタイム：Node.js、Pythonのcertifi、Javaのcacerts、PHPのComposerのバンドル、Rustのwebpki-roots。
• macOSのコマンドラインツール。Mozillaのインシデントページによれば、標準搭載のcurl、git、python3、perl、ruby、opensslは、失効を確認せずに/etc/ssl/cert.pemと照らして証明書を検証しており、Appleはこのファイルを更新していません。
• Microsoftによる許可されていない証明書の一覧の自動更新を受け取らないWindowsマシン。たいていは、グループポリシーで自動更新が無効になっているか、ネットワークがオフラインであることが原因です。
• ロードバランサー、VPNゲートウェイ、SDK、組み込みコントローラーなど、独自のCAファイルを同梱するアプライアンス、デバイス、サードパーティ製ソフトウェア。

ランタイムは1つずつ確認する必要があります。当社が10月22日に行ったテストでは、パッチを当てていないDebian 12のマシン上で、Node.js 24.18はeMudhraのルート証明書で終わるチェーンを受け入れ、Sectigoのルート証明書で終わるチェーンは拒否しましたが、同じマシンのPythonは両方を受け入れました。

2. 自社の証明書が、削除されたルート証明書につながっている企業

Mozillaと各LinuxディストリビューションはemSign ECC Root CA - G3を削除しており、Chromeも10月27日にこれに続きます。このルート証明書の配下にある有効な証明書は、各クライアントが更新されるたびに、そのクライアントで使えなくなります。Googleの指示では、そうした証明書を使うウェブサイトの運営者は「Chrome Root Storeに含まれる別のPKI階層から新しいTLS証明書を直ちに取得し、インストールしなければならない」とされています。

Chromeは10月21日時点で、このルート証明書の配下にある有効期限内の証明書をCT上で約30,800件数えました。そのうち30,791件は、Internet2が米国の大学や研究機関向けに運営する証明書サービスInCommonの、2つの中間認証局から発行されたものです。InCommonは、eMudhraのプラットフォームであるCERTInextを通じてECC証明書を発行しています。18件はeMudhra自身の中間認証局からのものでした。eMudhraによれば、移行が必要な証明書は約30,000件で、その約97%はACMEで発行されたものです。同社は、別の階層から差し替え用の証明書を発行しているとしています。

サイトがCloudflareのFull (strict)モードの背後にあり、オリジンがこのルート証明書の配下にある証明書を提示している場合、Cloudflareは信頼の取り消しが「障害を引き起こす」としており、顧客に「カスタムのオリジン証明書とサーバーの設定を見直す」よう求めています。

eMudhraのもう1つのルート証明書emSign Root CA - G1から発行されたRSA証明書は、今のところ影響を受けていません。Mozillaはこのルート証明書を「現時点では」削除しないとしています。Chromeは「eMudhraの残りのCA証明書を今後も収録し続けるかどうかを詳しく調査している」としています。種類を問わずeMudhraやCERTInextの証明書に依存しているなら、いますぐ2つ目の認証局を確保してください。

3. GoDaddyの顧客

GoDaddyの件はeMudhraとは無関係ですが、同じ週に起き、はるかに多くのサイトに影響しました。10月15日、GoDaddyは、同社のGoDaddyとStarfieldの階層から発行された証明書に、同社自身のCP/CPS（認証局が何を発行するかを定めた文書）のプロファイルと一致しない証明書ポリシー情報（ポリシーOIDとCPSへのリンク）が含まれていたとMozillaに報告しました。これは証明書のセキュリティ上の欠陥ではありません。それでも、すべての公的認証局が従うルールであるBaseline Requirementsのもとでは、5日以内に失効させる理由になります。

対象は404,607件で、そのうち396,055件はドメイン認証（DV）証明書でした。GoDaddyは期限である10月18日23:45 UTCまでに170,566件を失効させ、翌朝までに227,422件を失効させました。同社の顧客向けのお知らせによれば、残りは10月21日に失効しました。GoDaddyは証明書を再発行しますが、インストールするのは顧客です。同社は「新しい証明書がインストールされるまで、ウェブサイトの訪問者にセキュリティ警告が表示されることがあり、サイトにアクセスできなくなるおそれもある」としています。

今日確認すべきこと

1. 自社のサーバーは何を送っているか？ 公開している各ホスト名について、提示している証明書チェーンの発行者を一覧にします。

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

eMudhra、emSign、EM ... G3BまたはG3Cの認証局のいずれか、あるいはInCommon Intermediate CA - DVG3C、OVG3C、EVG3Cの名前が出てくる行があれば、その証明書は10月27日より前に差し替える必要があります。AAA Certificate Servicesだけなら正常です。ごく普通のSectigoのチェーンの多くに、いまも含まれているからです。メールやディレクトリのサービスでは、-starttls smtp（またはimap、ldap）と適切なポートを指定します。社内のホスト、ロードバランサー、CDNの背後にあるオリジンも含めてください。

2. 自社のドメインに何が発行されているか？ CTには、公的認証局が自社のドメイン名に対して発行したすべての証明書が載っています。社内の誰も注文した覚えのないものも含まれます。

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

この出力からは、自社が実際にどの認証局を使っているかもわかります。これが、後述する棚卸しの出発点になります。

3. 自社のクライアントは危殆化した鍵を信頼しているか？ Mozillaのテストサーバーは危殆化した鍵で発行された証明書を提示するので、証明書エラーになるのが望ましい結果です。両方の系統をテストしてください。1つ目のホストはeMudhraのルート証明書に、2つ目はSectigoのルート証明書につながっており、トラストストアによっては一方を拒否し、もう一方を受け入れることがあります。

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curlでわかるのは、curlの結果だけです。同じリクエストを、各アプリケーション自身のTLSスタックを通じて、そのアプリケーションが動く環境で実行してください。

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Pythonの2行は重複ではありません。urllibはOSのトラストストアを使い、requestsはcertifiを使います。それぞれの行をdv-g3b-aaa-emudhraのホストでも実行してください。Javaの場合は、対象のJVMからテストサーバーに何らかのHTTPS通信を行い、そのトラストストアにどちらかのルート証明書が含まれているかを一覧で確認します（Java 9以降。Java 8では-keystore $JAVA_HOME/jre/lib/security/cacertsを使います）。

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

トラストストアにルート証明書があるだけでは、影響を受けるとは言い切れません。Go、Node.js、Deno、Rustのrustls-webpkiは、トラストストアの内容にかかわらず、いまでは8つの鍵をブロックしているからです。決め手になるのはテストサーバーです。

4. 社内のWindows端末。 Microsoftはこのインシデントについて何も公表していませんが、Windowsが自動でダウンロードする許可されていない証明書の一覧は、10月20日から8つの鍵すべてをブロックしています。例外は、グループポリシーでルート証明書の自動更新が無効になっているマシンと、Windows Updateへの経路がないネットワークです。そうした環境には、別の方法で一覧を届ける必要があります。certutil -verifyCTL Disallowedで、マシンがキャッシュしている一覧を確認できます。Mozillaのインシデントページは個々のマシン向けのスクリプトを提供していますが、「企業が管理するデバイスには推奨されない」としています。

5. GoDaddyの証明書。 各サーバーが実際にどの証明書を提示しているかを確認します。

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

発行者がGoDaddyまたはStarfieldなら、シリアル番号をGoDaddyアカウント内の証明書と照合してください。GoDaddyに「Install your new certificate」（新しい証明書をインストール）と表示されている場合、そのサーバーにはまだ失効した証明書が入っています。

どの段階でも守るべきルール：証明書の検証を無効にしてエラーを消さないでください。Cloudflareも「これらのエラーを、検証を無効にすることで解決しないことが重要だ」と述べています。検証しないクライアントは、今回の証明書に限らず、あらゆる偽造証明書を信頼してしまいます。

今週更新すべきこと

修正には2種類あります。2つのルート証明書を削除すれば、そのトラストストアを使うクライアントにとってはすべての経路がふさがりますが、配下の有効な証明書も使えなくなります。Go、Node.js、Deno、Electron、rustls-webpki、Composer、Windowsのように8つの鍵を公開鍵のハッシュでブロックすれば、穴をふさいだうえで、ほかには何も壊しません。プラットフォームが後者を提供しているなら、そちらを選んでください。

「まだなし」は、10月22日の時点で何も公開されていなかったことを意味します。それを前提に計画を立てる前に、もう一度確認してください。

チームがつまずきやすい点が4つあります。

• コンテナイメージは古い一覧のままです。 10月20日または21日より前にビルドされたイメージは、更新されたベースイメージで再ビルドされるまで、これらの鍵を信頼し続けます。同じタグをpullし直しても、効果があるのはベースイメージが再ビルドされた後だけです。再ビルドして再デプロイし、自社で動かしているイメージのベンダーにも問い合わせてください。
• プロセスは読み込んだ内容を保持します。 プログラムは起動時にトラストストアを読み込むので、更新後は常駐しているサービスを再起動してください。Node.jsは、アップグレード前のセッションから再開されたTLSセッションは改めて検証されないとも補足しています。
• アプリケーションは独自のCAファイルを持っています。 SDKやアプリケーションは、独自のcacert.pemやca-bundle.crtを同梱していることがよくあります。たとえばfind / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/nullでリポジトリやイメージを検索し、複数見つかるものと考えてください。pipも、certifiのコピーを独自に持っています。
• デバイスはベンダー待ちです。 製品がどのトラストストアを使っているか、更新がいつ出るかを、各ベンダーに書面で問い合わせてください。更新が届くまで、そのデバイスは呼び出すすべてのサービスについて偽造証明書を信頼してしまうので、接続できる先を制限してください。

Debian、Ubuntu ESM、Fedora、Red Hatの回避策のようにAAA Certificate Servicesを手動で削除する場合は、その後でSectigoの証明書を使うサービスへの接続をテストしてください。古いサーバーの中には、いまもこのルート証明書で終わるチェーンを送ってくるものがあります。

次に備えて整えておくべきこと

認証局がここまで弱い鍵を放置するのはまれです。大量失効は、まれではありません。Mozillaのバグトラッカーに記録された2026年の大規模なものは次のとおりです。

この5件は、いずれもセキュリティ上の失敗ではありません。どれも、証明書が認証局自身の文書と食い違っていたというもので、それでもBaseline Requirements（4.9.1.1節）は5日以内の失効を求めています。鍵が危殆化した場合や、ドメイン認証が信頼できない場合、期限は24時間です。この期限を延ばしてくれる人はいません。2024年にDigiCertが83,267件の証明書を失効させた際、Chrome Root Programは「例外を認める権限を持たない」と書いています。ある顧客は自社の証明書の失効を止める裁判所命令を得ましたが、その命令は4日後に取り消されました。

差し替えがどう進んだかは、多くを物語ります。7月、HARICAはACME Renewal Information（ARI）を使って顧客のACMEクライアントに早期の更新を指示し、それ以外の証明書は自ら再発行しました。2回の失効のうち規模の大きい方では、期限の時点で対象のドメイン名の87%が差し替え済みでした。顧客が差し替え用の証明書を1枚ずつ自分でダウンロードしてインストールするGoDaddyでは、期限までに失効させられたのは対象の証明書の42%でした。

いずれにしても、更新の周期は短くなっていきます。

• CA/Browser ForumのバロットSC-081により、公的なTLS証明書の有効期間は2026年3月15日から200日に制限されています。上限は2027年3月15日に100日、2029年3月15日に47日まで短くなり、その時点でドメイン認証の結果を再利用できるのは10日間だけになります。
• Let's Encryptは2027年2月10日に既定の有効期間を64日に、その1年後に45日に変更します。
• 公的なTLS証明書からは、クライアント認証の用途がなくなりつつあります。Let's Encryptは2026年7月8日にクライアント認証用の発行をやめ、Chrome Root Programは2027年3月15日以降に発行される証明書をサーバー認証専用とするよう求めています。B2BのAPI連携でよくあるように、公的な証明書を相互TLSのクライアント証明書として使っているなら、それらの接続にはプライベート認証局が必要になります。

有効期間が100日、さらに47日になれば、証明書を手作業でインストールするのは現実的な選択肢ではなくなります。このスケジュールに合わせて自動化した企業は、次の大量失効にも備えられています。必要なのは次のことです。

1. 持っているものを、両方向で把握する。 1つ目は、自社が提示しているすべての証明書の一覧で、ホスト名、発行者、有効期限、更新方法、担当者を記録します。2つ目は、自社のソフトウェアが依存しているすべてのトラストストアの一覧です。OSのパッケージ、各言語のバンドル、アプリケーションやデバイスに含まれる個々のCAファイルが入ります。1つ目の一覧は前述のCT検索から、2つ目はソフトウェア部品表（SBOM）や依存関係の棚卸しから始められます。
2. 発行とインストールを自動化する。 ACMEが動く場所ではどこでもACMEを使い、ARI（RFC 9773）を組み合わせて、認証局が自社のクライアントに早期の更新を指示できるようにします。ACMEを動かせないデバイスでは、ベンダーの自動化の仕組みを使うか、ACMEを動かせる機器をその手前に置いてTLSを終端させます。
3. 2つ目の認証局を用意しておく。 2つ目の認証局でテスト済みの、実際に使えるACMEアカウントを持ち、DNSのCAAレコードで両方を許可しておきます。一方の認証局が信頼を取り消されたり大量失効を行ったりしたとき、切り替えは設定変更だけで済みます。
4. 自社ドメインのCTを監視する。 自社のドメイン名に新しい証明書が発行されるたびに通知を受け取ります。想定外の発行を、その日のうちに知ることができます。
5. トラストストアを依存関係として扱う。 通常のパッチ適用の中で更新し、イメージはコードが変わったときだけでなく、定期的に再ビルドします。
6. 2つの期限を前提に手順書（ランブック）を書く。 24時間と5日です。誰が判断するのか、誰がどのシステムにアクセスできるのか、どのシステムに手作業が必要か、各ベンダーにどう連絡するか。失敗しても困らないサービスで証明書を差し替えて、年に1回演習してください。公的認証局は2025年から、自らの大量失効計画を維持し、テストすることを義務付けられています。顧客の側に必要なのは、その残り半分です。

他社が運用する製品を作っている場合

自社の製品（デバイス、インストール型のアプリケーション、SDK）がトラストストアを含んでいるなら、顧客が守られるのは自社の更新が顧客に届いてからです。更新を出荷し、どのバージョンで修正されたかを顧客に伝えてください。Mozillaはトラストストアの運営者に対し、ソフトウェアが対応できるなら8つの中間認証局をブロックし、できない場合は「これらの中間認証局に署名したルート証明書への信頼を取り除くことが適切かどうかを検討する」よう助言しています。

サイバーレジリエンス法は、ここで2つの形で関わってきます。2026年9月11日から適用されている通報義務は実際に悪用されている脆弱性を対象としており、今回の件では悪用は報告されていません。2027年12月11日から適用される必須要件には、脆弱性にセキュリティ更新で対処できることが含まれており、信頼する認証局の一覧を更新できない製品はこれを満たさないことになります。NIS2の対象となる顧客は、この件にどれだけ早く対処したかをサプライヤーに尋ねるはずです。答えを文書にしておくと役に立ちます。

まだ決着していないこと

• eMudhraの残るルート証明書：Chromeは10月21日にeMudhraに12の質問を送りましたが、emSign Root CA - G1についての決定は発表していません。Mozillaは「現時点では」削除しないとしています。
• eMudhraの移行先：同社はMozillaに対し、顧客をG1（RSA）の階層に移すと伝えましたが、同社のステータスページは「独立して運営され、公に信頼されている別のCA階層」に触れています。Chromeは、それがどちらなのかを尋ねています。
• MicrosoftとApple：どちらも声明を出しておらず、どちらのルート証明書もストアから削除していません。
• 未提供の修正：Red Hat、Amazon Linux、Temurin、Correttoは10月22日の時点で何も出荷しておらず、Bunの修正はマージされたもののリリースされていません。
• 根本原因：eMudhraは根本原因を確認しておらず、これまでに行ったすべてのキーセレモニーを検証し直すとしています。
• Sectigo：9月5日から続いている別の件で、Sectigoは、拡張鍵用途（EKU）がCPSの一文と一致しない証明書の失効を、その一文はあいまいだったと主張して拒んでいます。10月18日の時点で、同社はそうした証明書のうち約7,200万件がまだ有効だと数えています。公開の議論の参加者の中には信頼の取り消しを求める声もありますが、決定を発表したルートプログラムはありません。Sectigoの証明書を使っている企業は、この件の行方を追ってください。

ご相談先

証明書の問題が、証明書の問題として姿を現すことはめったにありません。読み込まれなくなったチェックアウト、同期しなくなった連携、報告を送らなくなったデバイスとして現れ、たいていは週末に起きます。当社は、今週のような週を企業が障害なく乗り切れるよう支援し、次に同じことが起きても通常業務として対処できるよう仕組みを整えます。

• 影響範囲の調査：御社のシステムがどこでTLS接続を行い、どこで受け付けているか、それぞれがどのトラストストアを使っているか、どの証明書を提示しているかを洗い出します。コンテナ、Javaのサービス、銀行や決済・物流事業者との連携、デバイスも含みます。
• 修正：更新の適用、イメージの再ビルド、鍵のブロック、証明書の差し替えを、御社の変更管理プロセスに沿って行い、Mozillaのテストサーバーで確認します。
• 2027年に向けた自動化：サーバー、ロードバランサー、アプライアンス全体でのARI対応のACME、2つ目の認証局、CAAレコード、CTの監視、手順書を整え、2027年3月15日から始まる有効期間100日の証明書に備えます。
• 誰も触りたがらないシステム：古いJavaアプリケーション、アプライアンス、独自のトラストストアを持つ組み込みクライアントこそ、当社のレガシーシステムとコードの保守サービスが対象とするものです。

影響を受けているかどうかわからない場合は、運用しているドメインとプラットフォームを添えてoffice@c9group.devまでご連絡いただくか、お打ち合わせをご予約ください。まず何を確認すべきかをお伝えします。