SSL証明書が47日になったら、手動更新は詰む

ある案件で、証明書の自動更新を進めようとしたとき、先に片付けないといけない問題が出てきた。自動更新の設定より、そっちのほうが面倒だった、という話です。

有効期間の短縮スケジュール

まず現状から整理します。

SSL証明書（TLS証明書とも言います。サイトやAPIの通信を暗号化する、あの「鍵」です）の最大有効期間は、ここ数年で段階的に短くなっていきます。

年1回だった作業が、最終的には47日ごとになります。ほぼ毎月半、証明書の更新作業が発生する計算です。

手動でこれをやり続けるのは現実的ではない。漏れたら、そのサービスは証明書が期限切れのまま動き続けることになります。APIなら、接続を拒否するようになります。

自動更新が「先に決めておく方針」になる理由

証明書の更新を忘れたことで、本番のAPIが止まったという話はそこそこ聞きます。年1回しか作業が発生しないから忘れやすいし、アラートが飛んでも後回しにしがちです。47日になれば、この問題の頻度が数倍になる。

このある案件では、APIサービスを提供する側として、連携している外部の相手方に「証明書の更新を自動化する方針に切り替えます」という説明資料を作りました。

AIに頼んだ依頼はざっくりこんな内容です。

証明書の有効期間が最終的に47日まで短縮されるスケジュールを表で示して、手動更新の頻度とリスクが上がることを伝えるスライドを作ってほしい。 自動更新に切り替える方針と、それに伴って相手方にお願いがあることを、5枚構成でPPT化して。

AIがPowerPointを直接出力してくれるので、構成を渡せばほぼそのまま使える形になります。

ピンニングが問題になる

ここからが本題です。

証明書の自動更新を設定すると、証明書の中身が定期的に新しいものに差し替わります。これは想定通りの動作です。

ところが、相手のクライアントアプリケーションが「証明書ピンニング」（SSL pinningとも言います。特定の証明書の指紋情報を埋め込んで、それ以外は拒否する仕組みです）を実装していると、証明書が新しくなった瞬間に接続が切れます。正確には、クライアント側が「知らない証明書だ」と判断して拒否するのです。

つまり自動更新を設定しただけでは、連携相手のアプリが壊れます。

この案件でも、連携先の相手方に「証明書ピンニングを廃止して、OSが持っている標準の証明書検証に切り替えてもらえますか」というお願いを盛り込んだ資料を作りました。OS標準の検証を使えば、証明書が更新されても問題ありません。

頼む側・頼まれる側の両方に刺さる話

この問題の面倒なところは、自分側だけで完結しないことです。

自動更新を入れる側は「設定したから大丈夫」と思いがちですが、連携相手がピンニングを入れていたら、相手のアプリが黙って止まります。逆に、相手から「うちのAPIが証明書を自動更新するので、ピンニングを外してください」と言われた側も、「何を言われているのか」がすぐわからないことが多い。

自社のシステムがどこかの外部APIに繋がっているなら、両方の視点で確認しておく必要があります。

• 自分側は証明書の更新を自動化しているか
• 相手側のAPIが自動更新に移行した場合、自分のアプリはピンニングしていないか

特に後者はアプリのコードの中に埋まっているので、担当者が変わっていると「そんな設定あったっけ」という状態になることも少なくないです。

まず確認するポイント

中小企業のITシステムでSSL証明書が絡む場面は、大体こういうものです。

• 自社サイト・ランディングページ
• 問い合わせフォームやAPIの受け口
• 外部サービス（決済、CRM、在庫管理など）との連携部分

このうち「外部サービスとの連携」は、相手方の更新方針次第で自分側が影響を受けます。連携先が証明書を自動更新したとき、自分側のアプリがそれに追従できるかどうかを確認しておくと、後で慌てなくて済みます。

手動更新のままなら、今のうちにカレンダーで管理しながら、2029年に向けて自動化に切り替える計画だけ立てておくことをすすめます。47日になってから動くと、毎回更新に追われることになります。