SSL/TLS 証明書を更新する際、新しい CSR(と秘密鍵)を再作成することを強く推奨します。長期間同じ秘密鍵を使い続けることはセキュリティ上のリスクを高めるため、更新の機会に新しいキーペアを生成するのがベストプラクティスです。47 日ルール時代に向けては、ACME 自動更新を導入すれば CSR・秘密鍵の生成も自動化できます。
- 更新時は新しい CSR / 秘密鍵の再作成を推奨
- 同じ秘密鍵の使い回しはセキュリティリスク
- ACME 自動更新なら毎回自動で新規生成
🔐 なぜ新しい CSR/秘密鍵が必要なのか
SSL/TLS 通信の安全性は、秘密鍵が漏洩していないことを前提に成り立っています。長期間同じ秘密鍵を使い続けると、以下のようなリスクが高まります。
| リスク | 内容 |
|---|---|
| 秘密鍵の漏洩リスク | 長期間使用するほど、ログ・バックアップ・退職者のアクセスなど、漏洩経路が増える |
| 暗号アルゴリズムの陳腐化 | 古い鍵長・古いアルゴリズム(SHA-1 等)が業界標準から外れる |
| 過去の脆弱性の影響 | Heartbleed(2014)など、過去に秘密鍵が露出した可能性のある脆弱性に対応 |
| 暗号方式の進化への対応 | RSA → ECC(楕円曲線暗号)など、新しい方式への移行機会 |
NIST(米国国立標準技術研究所)や OWASP のガイドラインでも、定期的な秘密鍵のローテーションが推奨されています。証明書更新のタイミングは、秘密鍵を更新する自然な機会です。
📋 更新時の手順
-
新しい秘密鍵を生成
サーバ上で新しい秘密鍵を生成します。鍵長は RSA 2048 ビット以上または ECC P-256 / P-384を推奨。
# OpenSSL での秘密鍵生成例(RSA 2048) openssl genrsa -out new-private.key 2048 # ECC 秘密鍵生成例 openssl ecparam -genkey -name prime256v1 -out new-private.key -
新しい CSR を作成
新しい秘密鍵をもとに CSR を作成します。コモンネーム・組織情報は既存証明書と同じ内容を指定します。
# OpenSSL での CSR 作成例 openssl req -new -key new-private.key -out new-request.csr \ -subj "/CN=www.example.com/O=Your Company/C=JP" -
SSL ストアで更新申請
マイページから更新申請を行い、新しい CSR を提出します。
-
ドメイン認証・発行
ドメイン認証完了後、新しい証明書が発行されます。
-
サーバへ配置・切替
新しい証明書と新しい秘密鍵をペアでサーバへ配置し、切替を行います。
新しい秘密鍵で CSR を作成した場合、新しい証明書は新しい秘密鍵とのみペアになります。旧秘密鍵では動作しないため、サーバ配置時に両ファイルが正しいセットになっているかご確認ください。
💡 当店ツールでの CSR 生成
OpenSSL コマンドが分からない場合は、当店の CSR 生成ツール をご利用ください。Web フォームから必要事項を入力するだけで、秘密鍵と CSR が生成できます。
| 当店ツール | 用途 |
|---|---|
| CSR 生成ツール | 秘密鍵と CSR を生成 |
| CSR 解析ツール | 申請前に CSR の内容確認 |
| 証明書解析ツール | 発行後の証明書内容確認 |
⚙️ 同じ CSR/秘密鍵を使い続けることは可能?
技術的には、既存の CSR・秘密鍵を使い続けて更新することも可能です。ただし、以下のようなリスクがあります。
| 状況 | 判断 |
|---|---|
| 1〜2 回の更新で同じ鍵を使う | ⚠️ 非推奨だが許容 |
| 3 回以上同じ鍵を使い続ける | ❌ 強く非推奨 |
| 秘密鍵が漏洩した疑いがある | ❌ 即座に新規生成 |
| 古い暗号方式(SHA-1 等)を使用 | ❌ 新規生成必須 |
| 退職者がアクセスできた可能性 | ❌ 即座に新規生成 |
「更新するたびに新しい秘密鍵」が最もシンプルで安全です。手間を考えずに毎回新規生成する方針が、結果的に運用負荷を下げます。
🤖 47 日ルール時代は ACME で完全自動化
2029 年からの 47 日ルール時代では、年に 8 回程度の更新が発生します。毎回手動で CSR・秘密鍵を生成するのは現実的ではありません。
ACME 自動更新の場合
- CSR と秘密鍵は毎回自動で新規生成される
- サーバへの配置も自動
- 人為的なミスがゼロ
- 業界ベストプラクティス(秘密鍵ローテーション)を自然に実現
ACME プロトコルは、もともと「短サイクルでの証明書更新と秘密鍵ローテーションを自動化する」目的で設計されました。47 日ルール時代には、ACME 自動更新が事実上の標準となります。
当グループ運営の FujiSSL なら、DV だけでなく業界稀少の OV 証明書も ACME 自動更新に対応しています。
📊 推奨される鍵の仕様
| 暗号方式 | 鍵長 | 判断 |
|---|---|---|
| RSA | 2048 ビット | ✅ 現在の業界標準 |
| RSA | 3072 ビット / 4096 ビット | ✅ より高セキュリティ |
| ECC(楕円曲線) | P-256(256 ビット) | ✅ 推奨(RSA 3072 相当・軽量高速) |
| ECC | P-384(384 ビット) | ✅ 高セキュリティ |
| RSA | 1024 ビット以下 | ❌ 業界で非推奨 |
| SHA-1 ハッシュアルゴリズム | ― | ❌ 業界で廃止済み |
ECC 証明書については ECC 証明書とは何ですか? をご参照ください。
💡 関連するご質問
| ご質問 | 対応 |
|---|---|
| 同じ CSR で更新したいのですが | 技術的には可能ですが、新規生成を推奨します |
| CSR の作り方が分からない | CSR 生成ツールをご利用ください |
| 秘密鍵を紛失してしまった | 秘密鍵紛失時の対応をご参照ください |
| ECC 証明書って何? | ECC 証明書とはをご参照ください |
| ACME なら CSR は不要? | はい、ACME クライアントが自動生成します |