最近のニュース：SSL証明書の有効期限が短くなる？

2025年4月に、CA/Browser Forum（証明書のルールを決める国際団体）が「SSL/TLS証明書の有効期限を段階的に短くしていく」という決定をしました。
これまではおよそ 398日（約13か月）の証明書が一般的でしたが、今後は次のようにどんどん短くなっていきます。

2026年3月以降 → 約200日

2027年3月以降 → 約100日

2029年3月以降 → なんと47日

なぜこんな変更をするのか？

理由はシンプルで、セキュリティを高めるためです。
もし証明書や秘密鍵が漏れてしまっても、有効期限が短ければリスクは限定的になります。
さらに、自動更新の仕組み（Let’s Encryptなど）を使うのが標準化されつつあり、昔のように「1年ごとに手動更新」するやり方は時代に合わなくなってきています。

SSL証明書とは？

SSL証明書は、ウェブサイトとユーザーの通信を暗号化するための「デジタル証明書」です。
具体的には以下の役割があります：

通信の暗号化（盗聴や改ざん防止）

ユーザーが https://example.com にアクセス

サーバーは自分の公開鍵を含んだ証明書をブラウザに送る

ブラウザは証明書を確認し、「OK」となれば公開鍵で秘密情報（セッション鍵＝共通鍵）を暗号化してサーバーに送る

サーバーは自分の秘密鍵で復号し、セッション鍵を共有

以降の通信はそのセッション鍵（共通鍵暗号）で暗号化される

👉 ポイント：

「公開鍵暗号方式」で共通鍵を安全に渡す

「共通鍵暗号方式」で高速にやり取りする

サイトの真正性（そのサイトが正しい管理者のものである証明）

証明書には「このドメインは本当にこの組織が管理しています」という情報が入っています。

その証明書は認証局（CA: Certificate Authority）が発行

ブラウザは「CAの公開鍵リスト（ルート証明書）」をもとに、その証明書が信頼できるかチェック

正しく署名されていれば「🔒」が出る

👉 ポイント：

認証局（CA）は「このドメインの持ち主を確認済み」というお墨付きを与える

ブラウザは「自分が信頼するCAが署名した証明書」だけを信用する

ブラウザに「鍵マーク🔒」を表示させる

ブラウザが接続要求

ユーザーが https://example.com にアクセスすると、ブラウザはサーバーに「安全に通信したい」とリクエストを送ります。

サーバーが証明書を提示

サーバーは「SSL証明書」をブラウザに送ります。

この証明書には以下が含まれています：

サイトの公開鍵

サイトのドメイン名情報

発行した認証局（CA）の署名

ブラウザが証明書を確認

証明書の有効期限、ドメイン名、認証局（CA）の署名が正しいかをチェック。

ブラウザに組み込まれた「信頼できるCAリスト」と照合。

問題なければ「この証明書はOK」と判断。

暗号化の鍵を安全に共有

ブラウザはサーバーの公開鍵を使って「共通鍵（セッション鍵）」を暗号化して送ります。

サーバーは自分の秘密鍵で復号し、共通鍵を手に入れます。

これで両者が同じ共通鍵を持つことになります。

共通鍵で通信開始

以降の通信は、効率の良い「共通鍵暗号方式」で暗号化されます。

内容を盗聴しても解読はほぼ不可能。

ブラウザに🔒マーク表示

「証明書が有効で信頼できる」＋「安全な暗号化通信が成立」

この2つがそろった時にブラウザが🔒を表示します。

ニュースを受けて実際に更新してみた

前任者がいなくなって「とりあえず証明書だけ渡されたけど、WEBサーバーの管理者がいない」状況でしたので、まずは環境を理解することからはじめました。

ステップ 1: サーバー環境を特定する

ps aux | grep -E 'httpd|apache2|nginx'

httpd や apache2 があれば → Apache
nginx があれば → Nginx

出力をみた感じNginxとApacheが両方動いていた。
Nginxをフロントのリバースプロキシとして使って、その裏にApacheを置いている構成の可能性が高い。
（よくある「Nginx ＝入口／SSL終端、Apache ＝アプリ処理」のパターン）

どちらがSSLを担当しているか調べる。

sudo grep -R "ssl_certificate" /etc/nginx/
sudo grep -R "SSLCertificateFile" /etc/httpd/

結果から分かったこと

Nginx が /etc/nginx/conf.d/users/... の設定で多数のドメインに対して ssl_certificate を指定している → つまり SSL終端（TLSハンドシェイクを処理する部分）は Nginx 側でやっている。

その裏で Apache (httpd) が動いているけど、Apache 側には SSLCertificateFile の記述がなく、通常の :80（HTTP）でアプリ処理をしている可能性が高い。

このパターンは cPanel/WHM が管理しているホスティング環境でよくある「Nginxがフロント → Apacheが裏でPHPやアプリ処理」構成です。

cPanelで管理されているサーバーなので、CLIではなく、cPanel(WHM)の管理画面から更新することにした。

―次回 cPanel(WHM)を使ってSSL証明書の更新方法をまとめます。-