証明書が切れる日は買収後にやってくる

引き継ぎ資料の技術構成には、「HTTPS対応済み、SSL証明書設定完了」と一行だけ書かれていることがあります。切り替え当日、ブラウザのアドレスバーには鍵のマークが並び、通信は暗号化され、警告は一つも出ません。売り手も買い手も、ここは片付いた項目として次の議論へ移ります。ところが買い手は、この「設定完了」という一行を、完了報告ではなくカウントダウンの開始として読むべきです。

SSL/TLS証明書(サイトの通信を暗号化し、接続先が本物であることを証明する電子的な身分証)には、必ず有効期限があります。運転免許証に更新期限があるのと同じで、期限を過ぎた証明書は無効になります。無効になった瞬間、ブラウザは「この接続ではプライバシーが保護されません」と全面警告を出し、利用者はサイトへ入れなくなります。問題は、この期限が引き渡しの数字に一切現れないことです。損益計算書にもトラフィックのグラフにも、証明書があと何日で切れるかは書かれていません。

「設定完了」は片付いた項目ではなく、時限装置の起動

引き渡しの時点で鍵マークが緑なのは、当たり前です。証明書はその日、確かに有効だからです。しかし有効であることと、これからも有効であり続けることは、まったく別の話です。証明書には発行日と失効日があり、失効日を一秒でも過ぎれば、それまで何事もなく回っていたサイトが、一斉にエラー画面に変わります。前日まで正常だったという事実は、翌日の安全を何も保証しません。

効率的な運用と、更新の仕組みが欠けた運用は、引き渡しの日には見分けがつきません。どちらも同じ緑の鍵マークを見せるからです。健全な事業では、証明書は人が意識しないところで自動的に更新され続けます。脆い事業では、旧オーナーが数か月に一度、カレンダーの通知を見て手作業で更新していただけ——そしてその通知は、もう買い手のカレンダーには入っていません。誰も嘘をついていないのに、更新の営みだけが引き渡しから抜け落ちるのです。

Let's Encryptの有効期間は90日 ── 買収の高揚が冷めた頃に切れる

無料証明書として広く使われる Let's Encrypt(自動化を前提に無償で証明書を発行する認証局)の有効期間は、90日です。商用の有料証明書でも、かつて主流だった2年・3年は廃止され、いまは長くても約1年(398日)が上限になりました。しかも業界はこの期間をさらに短縮する方向にあり、数年のうちに数十日単位まで縮む見込みです。証明書の寿命は年々短くなっており、手動更新の負担と失効の頻度は、これから増える一方です。

90日という数字は、買収のスケジュール感と最悪の相性です。デューデリジェンスから契約、引き渡し、そして運用の引き継ぎが一段落するまでには、1〜2か月かかる場合があります。仮に引き渡しの40日前に発行された証明書なら、残りは50日。買い手が環境の把握にようやく慣れ、日々の運用に気を取られ始めた頃に、証明書は静かに失効日を迎えます。切れるのは、いつも警戒が緩んだ後です。

厄介なのは、この期限がどの引き継ぎ資料にも数字として現れないことです。売上、原価、トラフィック、これらはすべて表になって共有されますが、「証明書があと何日で切れるか」は、その表のどこにも現れません。見えない数字だからこそ、DDで自分の手で掘り起こす必要があります。

自動更新は「設定されている」ことと「動いている」ことが別物

「自動更新しているので大丈夫です」——引き継ぎで出てくる一言ですが、ここには二つの落とし穴があります。一つ目は、自動更新が設定されていることと、実際に動いていることは別だという点です。certbot(Let's Encrypt の証明書を取得・更新する定番ツール)を入れただけで、更新を定期実行するタイマーが止まっている、あるいは登録すらされていない構成があります。入っている道具と、回っている歯車は違います。

確認は難しくありません。Linux サーバーなら systemctl list-timers に certbot の行が生きているか、あるいは crontab -l と /etc/letsencrypt/renewal/ 配下の設定ファイルを見れば、更新が仕込まれているかが分かります。そして certbot renew --dry-run を一度流せば、本番の証明書に触れずに「次の更新が本当に通るか」を予行演習できます。この一手間を省くと、切り替え後に落ちる原因になります。

二つ目の落とし穴は、更新そのものは成功しているのに、新しい証明書がサーバーに読み込まれていないケースです。証明書ファイルは無事に差し替わっているのに、稼働し続けている nginx や Apache が古い証明書をメモリに抱えたまま配り続ける——更新後にサーバーを再読込するフック(certbot の deploy-hook で reload を呼ぶ設定)が抜けていると、これが起きます。ファイル上は新しいのに利用者には古いまま届き、期限が来れば結局切れるのです。

切れて沈黙するのはブラウザだけではない ── アプリと連携が同時に落ちる

証明書が切れて困るのは、ブラウザで訪れる人間だけではありません。むしろ深刻なのは、機械同士の通信です。スマホアプリが叩く API、外部サービスから届く Webhook(あるイベントが起きたときに自動で送られてくる通知)、決済や配送の連携——これらは証明書が無効になった瞬間、多くが問答無用で接続を拒否します。人間ならエラー画面を見て異変に気づけますが、機械は静かに失敗し、リトライを諦め、データだけが欠け始めます。気づいたときには取りこぼしが積み上がっています。

さらに事態を固くするのが HSTS(一度 HTTPS で来たブラウザに、次からは必ず暗号化接続を使えと命じる仕組み)です。HSTS が有効なサイトでは、証明書が切れたとき、利用者は「危険を承知で進む」というリンクすら押せません。ブラウザが接続そのものを拒み、迂回路を塞ぐからです。セキュリティを固めていた事業ほど、証明書失効の被害は中途半端な不調ではなく全面停止になります。移管を境にサービス全体が一斉に使えなくなる構造という点では、認証基盤の移管で全員がログインできなくなるで扱った事象と根は同じです。

更新の主体・支払い・通知先が、まだ旧オーナーに紐づいている

自動更新がきちんと動いていても、まだ安心はできません。その更新を成立させている「主体」が、誰の手の中にあるかという問題が残るからです。Let's Encrypt の更新は ACME(証明書の発行・更新を機械同士で自動化する取り決め)という仕組みで動きますが、その ACME アカウントや、DNS(ドメイン名と IP アドレスを結ぶ電話帳)の管理権限、証明書を管理する Cloudflare や AWS のアカウントが旧オーナーの個人名義のままなら、買い手は更新を自分で制御できていません。旧オーナーがアカウントを閉じた瞬間、あるいは請求が滞った瞬間に、更新は止まります。

通知先も同じ落とし穴です。証明書の期限が近いという警告は、認証局や監視サービスから、登録されたメールアドレスへ届きます。それが旧オーナーのアドレスなら、第一報は買い手に届きません。加えて Let's Encrypt は2025年に、有効期限の通知メール送信そのものを終了しました。つまり「メールが来なかったから大丈夫」という判断は、もう成り立たないのです。障害の一報が新しい持ち主に届かない構造は、障害の第一報が買い手に届かない構造で詳しく扱いました。

支払いも見落とされがちです。有料証明書やドメイン、関連する各種サービスの自動更新が、旧オーナーのクレジットカードに紐づいたままだと、そのカードが解約・失効した時点で更新は静かに失敗します。宛先や名義が旧オーナーに残ったまま引き渡される問題は、Webhookの宛先は旧オーナーのままだでも同じ構図を指摘しました。更新を担う仕組みは動いていても、その根元が他人の手にあれば、それは他人に握られた停止スイッチと変わりません。

時限は証明書だけではない ── ドメインとサブスクの自動更新

時限装置は証明書だけではありません。同じ「自動更新頼み」の脆さは、事業のあちこちに埋まっています。筆頭がドメインです。ドメインの登録には期限があり、レジストラ(ドメインの登録業者)の自動更新が有効でも、支払いカードが旧オーナーのものなら、ある日更新に失敗します。ドメインが失効すると、猶予期間を経て一時凍結、そして高額な復旧料が必要な期間へ進み、最悪は第三者に取得されます。証明書の失効はサイトを止めますが、ドメインの失効は事業そのものを消しかねません。

確認は whois(ドメインの登録情報を照会する仕組み)で期限を見るところから始まります。中古のドメインを引き継ぐ場合、過去の名義や利用履歴に別の地雷が埋まっていることもあり、これは中古ドメイン購入前に見る負の遺産で別途扱いました。ドメインは事業の住所であり看板でもあるので、証明書と同じ熱量で期限と名義を確かめる価値があります。

証明書とドメインの先には、さらに小さな時限が無数にあります。アプリのプッシュ通知に使う証明書(APNs など)は多くが年単位で失効しますし、事業が依存する外部サービスの月額契約、独自ドメインのメール、監視サービスの契約——これらが旧オーナーの個人アカウントと個人カードに紐づいていれば、それぞれが別々の日に、静かに切れていきます。引き継ぐべきは資産だけでなく、この「更新の責任」の一切だと考えるべきです。

DDでは openssl 一発から始める ── 五つの確認

では、DDで証明書の時限をどう見抜くか。特別な権限がなくても、外から一発で始められます。ターミナルで echo | openssl s_client -connect 対象ドメイン:443 -servername 対象ドメイン 2>/dev/null | openssl x509 -noout -dates -issuer と打てば、証明書の発行日・失効日と発行元(issuer)がその場で分かります。失効日までの残り日数と、発行元が Let's Encrypt のような自動化前提の認証局か、手動運用になりがちな有料認証局かが、これだけで読み取れます。

次に crt.sh のような証明書の発行記録(Certificate Transparency、発行された証明書が公開ログに記録される仕組み)を照会すると、そのドメインで過去にどんな証明書が、どれくらいの間隔で発行されてきたかが見えます。90日ごとにきれいに発行され続けていれば自動更新が回っている可能性が高く、間隔がばらばらで時々空白があるなら、手作業で綱渡りしてきた兆候です。ここまでは相手の協力なしに、外から確認できます。

相手の協力が得られる段階では、五点を具体的に確かめます。第一に発行方法(ACME による自動か、手動取得か、Cloudflare や AWS の managed か)。第二に有効期限と残り日数。第三に自動更新の実在(certbot renew --dry-run が通るか、再読込フックが繋がっているか)。第四に更新権限の所在(ACME アカウント・DNS・レジストラ・関連クラウドのアカウント名義)。第五に通知と支払いの宛先(期限警告のメールアドレスと、更新に使われるカードの名義)。この五点が揃って初めて、緑の鍵マークの裏側が見えてきます。

移管計画に「更新の引き継ぎ」を一項目として書き込む

確認で終わらせず、移管計画に「更新の引き継ぎ」を明確な一項目として書き込むことが肝心です。理想は、引き渡しと同時に証明書を買い手の管理下で発行し直し、ACME アカウント・DNS・レジストラ・支払い方法を、すべて買い手名義へ移し切ることです。旧オーナーのアカウントに一つでも依存が残っていれば、それは将来のある日の停止予約に等しいと考えます。

あわせて、期限そのものを監視の対象にします。証明書の失効日を定期的に確認し、残り日数がしきい値を割ったら買い手へ通知する仕組み——監視サービスの SSL チェックでも、openssl を回す簡単な定期処理でも構いません——を、引き渡し直後に必ず組み込みます。人間の記憶やカレンダーに頼る運用は、担当者が変わった瞬間に破綻するからです。移管で最初に失われるのは、まさにその「誰かの頭の中にあった更新の段取り」です。

証明書やドメインの失効は、引き渡しの当日には決して姿を現しません。すべてが正常に見える日に取引は完了し、問題は数十日後、警戒が緩んだ頃にやってきます。引き渡し後にこそ本当の問題が始まるという構造は、サイト売買の失敗は引き渡し後に始まるで繰り返し述べてきたとおりです。緑の鍵マークを完了の証としてではなく、いつ切れるかを問う入口として見ること。それが、買収後に訪れる「証明書が切れる日」を防ぐ、ほとんど唯一の準備です。

証明書やドメインの更新が本当に自動で回っているのか、その主体と通知先が誰に紐づいているのかを、買収前に外から確かめておきたいときは、AI技術デューデリジェンスで技術面の兆候を確認できます(登録不要)。