SSL証明書更新の方法と手順

    Browse: Home / SSL証明書更新の方法と手順
 

SSL証明書には有効期限があり、定期的な更新が必要です。本記事では、既存のCSR（証明書署名要求）を再利用して証明書を更新する方法を解説します。

目次

  1. CSR再利用と再作成の違い
  2. 更新作業の全体像
  3. 詳細な更新手順
  4. トラブルシューティング
  5. 更新スケジュールの管理

CSR再利用と再作成の違い

SSL証明書を更新する際、CSRの扱いには2つの方法があります。

CSRを再利用する方法

既存の秘密鍵とCSRをそのまま使って新しい証明書を発行します。

メリット

  • 作業が簡単で早い
  • 以前作成した秘密鍵とCSRをそのまま使える
  • サーバー設定の変更が最小限で済む

デメリット

  • 秘密鍵が古いまま（セキュリティリスクがやや高い）
  • もし秘密鍵が過去に漏洩していた場合、リスクが継続
  • ドメイン名や組織情報を変更できない

適した状況

  • 通常の年次更新（情報変更なし）
  • 急いで更新したい時
  • 短期間での更新

CSRを再作成する方法

新しい秘密鍵を生成し、新しいCSRを作成して証明書を発行します。

メリット

  • 新しい秘密鍵を生成するのでセキュリティが向上
  • ドメイン名や組織情報を変更できる
  • 「鍵のローテーション」というセキュリティベストプラクティスに準拠

デメリット

  • 作業が少し増える
  • サーバー設定で秘密鍵のパスを変更する必要がある

適した状況

  • セキュリティを重視する場合
  • ドメイン名や組織情報を変更したい時
  • 秘密鍵の漏洩リスクがあった場合
  • セキュリティポリシーで定期的な鍵の更新が求められる場合

一般的な推奨

セキュリティの観点では、CSRを再作成（新しい秘密鍵を生成）することが推奨されますが、実務では更新のたびに再作成する必要はなく、状況に応じて判断します。

多くの企業では以下のような運用をしています：

  • 通常の年次更新：CSRを再利用
  • 2〜3年に1回：CSRを再作成
  • セキュリティインシデント後：必ずCSRを再作成

更新作業の全体像

CSRを再利用した証明書更新は、以下の10ステップで完了します。

ステップ作業内容所要時間
1既存ファイルの確認5分
2現在の証明書情報を確認5分
3既存CSRの内容を確認5分
4認証局への更新申請10分
5ドメイン所有の再確認5分〜1時間
6新しい証明書のダウンロード5分
7サーバーへの新証明書のインストール10分
8Webサーバーの設定確認と再起動10分
9動作確認10分
10古い証明書の後処理5分

合計所要時間：作業30分〜1時間 + 認証局の審査（数分〜数時間）

詳細な更新手順

ステップ1：既存ファイルの確認

まず、証明書更新に必要なファイルがサーバー上に存在するか確認します。

必要なファイル

private.key  # 秘密鍵
server.csr   # CSR（証明書署名要求）
server.crt   # 現在の証明書（期限切れ間近）

確認コマンド

bash

# ファイルの存在確認
ls -la /path/to/ssl/

注意点

  • ファイルが見つからない場合、初回設置時のバックアップを探す
  • バックアップもない場合は、CSRを再作成する必要がある

SSL証明書ファイルのパスを確認する方法

証明書や秘密鍵のパスがわからない場合、Webサーバーの設定ファイルから確認できます。

Apacheの場合

設定ファイルからパスを確認

bash

# CentOS / RHEL系
sudo grep "SSLCertificate" /etc/httpd/conf.d/ssl.conf

# Ubuntu / Debian系
sudo grep "SSLCertificate" /etc/apache2/sites-available/default-ssl.conf

表示例

apache

SSLCertificateFile /etc/ssl/certs/sample-abc.jp.crt
SSLCertificateKeyFile /etc/ssl/private/sample-abc.jp.key
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

これで以下のパスがわかります：

  • 証明書: /etc/ssl/certs/sample-abc.jp.crt
  • 秘密鍵: /etc/ssl/private/sample-abc.jp.key
  • 中間証明書: /etc/ssl/certs/intermediate.crt

Nginxの場合

設定ファイルからパスを確認

bash

# SSL関連の設定を検索
sudo grep "ssl_certificate" /etc/nginx/sites-available/default

# または、すべての設定ファイルから検索
sudo grep -r "ssl_certificate" /etc/nginx/

表示例

nginx

ssl_certificate /etc/nginx/ssl/sample-abc.jp.crt;
ssl_certificate_key /etc/nginx/ssl/sample-abc.jp.key;

これで以下のパスがわかります：

  • 証明書: /etc/nginx/ssl/sample-abc.jp.crt
  • 秘密鍵: /etc/nginx/ssl/sample-abc.jp.key

注意: Nginxの場合、証明書ファイルにサーバー証明書と中間証明書が連結されていることがあります。

ドメイン名やファイル名で検索

設定ファイルの場所がわからない場合、ドメイン名やファイル拡張子で検索します。

ドメイン名で検索

bash

# ドメイン名を含むファイルを検索
sudo find /etc -name "*sample-abc*" 2>/dev/null

拡張子で検索

bash

# 証明書ファイル (.crt) を検索
sudo find /etc -name "*.crt" 2>/dev/null

# 秘密鍵ファイル (.key) を検索
sudo find /etc -name "*.key" 2>/dev/null

# CSRファイル (.csr) を検索
sudo find /etc -name "*.csr" 2>/dev/null

設定ファイル内を検索

bash

# Apacheの設定から検索
sudo grep -r "SSLCertificate" /etc/httpd/ 2>/dev/null

# Nginxの設定から検索
sudo grep -r "ssl_certificate" /etc/nginx/ 2>/dev/null

CSRファイルが見つからない場合

CSRが見つからなくても、秘密鍵があれば新しいCSRを生成できます。

CSRの再生成

bash

# 既存の秘密鍵から新しいCSRを生成
openssl req -new -key /etc/ssl/private/sample-abc.jp.key -out /tmp/sample-abc.jp.csr

入力が必要な情報

項目入力例
Country NameJP
State or Province NameTokyo
Locality NameShibuya-ku
Organization NameYour Company Name
Common Namesample-abc.jp

重要: Common Name（ドメイン名）は必ず正確に入力してください。その他の項目で Enter を押すと空欄になります。

生成されたCSRを確認

bash

# ファイルの存在確認
ls -l /tmp/sample-abc.jp.csr

# CSRの内容を確認
cat /tmp/sample-abc.jp.csr

ステップ2：現在の証明書情報を確認

更新前に、現在の証明書の有効期限などを確認しておきます。

証明書の詳細を確認

bash

# 証明書の全情報を確認
openssl x509 -in server.crt -text -noout

有効期限だけを確認

bash

# 有効期限のみを表示
openssl x509 -in server.crt -noout -dates

表示例

notBefore=Jan 18 09:15:45 2025 GMT
notAfter=Feb 19 09:15:44 2026 GMT

この例では、2026年2月19日が有効期限です。

推奨タイミング

有効期限の1ヶ月前には更新作業を開始しましょう。上記の例では、2026年1月19日頃に作業を開始するのが理想的です。

ステップ3：既存CSRの内容を確認

念のため、CSRに含まれる情報（ドメイン名など）が正しいか確認します。

CSRの内容を表示

bash

# CSRの詳細を確認
openssl req -in server.csr -text -noout

確認すべき項目

  • Common Name（ドメイン名）：sample-abc.jp
  • Organization Name（組織名）：Your Company Name
  • Country（国コード）：JP
  • State（都道府県）：Tokyo
  • Locality（市区町村）：Shibuya-ku

重要

もしドメイン名や組織情報を変更したい場合は、CSRの再作成が必要です。この場合、本記事の方法ではなく、CSR再作成版の手順を参照してください。

ステップ4：認証局への更新申請

既存のCSRを使って認証局に証明書の更新を申請します。

4-1. 認証局の管理画面にログイン

GlobalSignなどの認証局のWEBサイトにアクセスし、管理画面にログインします。

4-2. 証明書の更新メニューを選択

管理画面で以下のようなメニューを探します：

  • 「証明書を更新する」（Renew Certificate）
  • 「既存の証明書を管理」（Manage Certificates）

期限が近い証明書を選択し、「更新」ボタンをクリックします。

4-3. 既存のCSRをアップロード

更新画面で以下の手順を実行します：

手順1：CSRの提出方法を選択

「既存のCSRを使用」または「CSRをアップロード」を選択します。

手順2：CSRファイルの内容をコピー

サーバーでCSRの内容を表示し、コピーします。

bash

# CSRの内容を表示
cat server.csr

表示例

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCSlAxDjAMBgNVBAgMBVRva3lvMRMwEQYD
VQQHDApTaGlidXlhLWt1MRcwFQYDVQQKDA5Zb3VyIENvbXBhbnkxGjAYBgNVBAMM
...（長い文字列）...
-----END CERTIFICATE REQUEST-----

手順3：認証局の入力欄にペースト

-----BEGIN CERTIFICATE REQUEST----- から -----END CERTIFICATE REQUEST----- までをすべてコピーして、認証局の画面に貼り付けます。

4-4. 更新期間を選択

証明書の有効期間を選択します：

  • 1年（推奨）
  • 2年（認証局によっては選択不可）

重要な制限

2020年9月以降、SSL証明書の最大有効期間は398日（約13ヶ月）に制限されています。これはAppleやGoogleなどのブラウザベンダーが定めたルールです。

4-5. 支払い

クレジットカードや請求書払いで料金を支払います。

料金の目安

  • DV証明書：5,000円〜30,000円/年
  • 認証局によっては更新割引がある場合も
  • 複数年契約で割引になることもある

ステップ5：ドメイン所有の再確認

更新の場合でも、ドメイン所有の確認が必要です（DV証明書の場合）。

以下の3つの方法から1つを選択します。

方法A：メール認証

最も簡単な方法です。

手順1：確認メールの受信

以下のいずれかのメールアドレスに確認メールが届きます：

手順2：確認リンクをクリック

メール内に記載された確認リンクをクリックします。

手順3：完了

数分以内に認証局が確認を完了し、証明書の発行に進みます。

注意点

  • これらのメールアドレスが使用できる状態にしておく必要がある
  • メールが迷惑メールフォルダに入っていないか確認

方法B：DNS認証

DNSレコードを追加して所有を証明する方法です。

手順1：TXTレコードの情報を取得

認証局の画面に表示される情報をメモします：

レコードタイプ: TXT
ホスト名: _validation.sample-abc.jp
値: "ca3-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

手順2：DNSサーバーにレコードを追加

お使いのDNSサービス（お名前.com、さくらインターネット、Route53など）の管理画面にログインし、TXTレコードを追加します。

設定例

タイプ: TXT
名前: _validation.sample-abc.jp
値: ca3-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TTL: 300（5分）

手順3：DNS反映を待つ

通常5分〜1時間程度で反映されます。以下のコマンドで確認できます：

bash

# DNSレコードの確認（nslookup）
nslookup -type=TXT _validation.sample-abc.jp

# DNSレコードの確認（dig）
dig TXT _validation.sample-abc.jp

反映されると、設定した値が表示されます。

手順4：認証局で検証

認証局の画面で「検証する」または「Verify」ボタンをクリックします。

手順5：完了後、TXTレコードを削除

認証が完了したら、追加したTXTレコードは削除してOKです。

メリット

  • メールアドレスが使えなくても対応可能
  • 自動化しやすい（API経由でDNSレコードを操作できる場合）

方法C：ファイル認証

サーバーに確認ファイルを配置して所有を証明する方法です。

手順1：確認ファイルの情報を取得

認証局から以下の情報が提供されます：

ファイル名: validation-xxxxx.txt
内容: ca3-yyyyyyyyyyyyyyyyyyyyy
配置場所: http://sample-abc.jp/.well-known/pki-validation/validation-xxxxx.txt

手順2：サーバーにディレクトリを作成

bash

# ディレクトリを作成
mkdir -p /var/www/html/.well-known/pki-validation/

手順3：確認ファイルを作成

bash

# ファイルを作成（認証局から指定された内容を記述）
echo "ca3-yyyyyyyyyyyyyyyyyyyyy" > /var/www/html/.well-known/pki-validation/validation-xxxxx.txt

手順4：パーミッションを設定

bash

# ファイルを読み取り可能にする
chmod 644 /var/www/html/.well-known/pki-validation/validation-xxxxx.txt

手順5：ブラウザでアクセス確認

以下のURLにブラウザでアクセスし、ファイルの内容が表示されるか確認します：

http://sample-abc.jp/.well-known/pki-validation/validation-xxxxx.txt

ファイルの内容（ca3-yyyyyyyyyyyyyyyyyyyyy）が表示されればOKです。

手順6：認証局で検証

認証局の画面で「検証する」または「Verify」ボタンをクリックします。

手順7：完了後、ファイルを削除

認証が完了したら、確認ファイルは削除してOKです。

bash

# ファイルを削除
rm /var/www/html/.well-known/pki-validation/validation-xxxxx.txt

メリット

  • メールアドレスが使えなくても対応可能
  • DNSの変更権限がなくても対応可能

ステップ6：新しい証明書のダウンロード

ドメイン所有確認が完了すると、認証局が新しい証明書を発行します。

発行までの時間

  • DV証明書：通常、数分〜数時間
  • メール確認の場合：数分以内
  • DNS/ファイル確認の場合：数分〜1時間程度

ダウンロードするファイル

認証局の管理画面から以下のファイルをダウンロードします：

  1. 新しいサーバー証明書（server_new.crt または certificate.crt）
  2. 中間証明書（intermediate.crt または ca-bundle.crt）

注意点

中間証明書は前回と同じ場合もありますが、念のため最新版をダウンロードすることを推奨します。

ダウンロード後の確認

ダウンロードしたファイルをテキストエディタで開き、以下のような内容になっているか確認します：

サーバー証明書の例

-----BEGIN CERTIFICATE-----
MIIFXzCCBEegAwIBAgIQB...（長い文字列）...
-----END CERTIFICATE-----

中間証明書の例

-----BEGIN CERTIFICATE-----
MIIGGTCCBAGgAwIBAgIQE...（長い文字列）...
-----END CERTIFICATE-----

ステップ7：サーバーへの新証明書のインストール

新しい証明書をサーバーに設置します。

7-1. バックアップの作成

最重要：作業前に必ず既存ファイルをバックアップします。

bash

# バックアップディレクトリを作成
mkdir -p /path/to/ssl/backup/

# 現在のファイルをバックアップ
cp /path/to/ssl/server.crt /path/to/ssl/backup/server.crt.backup
cp /path/to/ssl/intermediate.crt /path/to/ssl/backup/intermediate.crt.backup

# バックアップ日時を記録
date > /path/to/ssl/backup/backup_date.txt

万が一、新しい証明書に問題があった場合、このバックアップから即座に復旧できます。

7-2. 新しい証明書をサーバーにアップロード

ローカルPCからサーバーへファイルを転送します。

SCPを使う場合

bash

# ローカルPCから実行
scp server_new.crt user@your-server:/tmp/
scp intermediate.crt user@your-server:/tmp/

FTPクライアントを使う場合

FileZillaなどのFTPクライアントで、/tmp/ ディレクトリにアップロードします。

7-3. ファイルを所定の場所に移動

bash

# サーバー上で実行
sudo mv /tmp/server_new.crt /path/to/ssl/server.crt
sudo mv /tmp/intermediate.crt /path/to/ssl/intermediate.crt

注意：既存の証明書ファイルを上書きします（バックアップ済みなので問題ありません）。

7-4. ファイルのパーミッション設定

bash

# 証明書ファイルのパーミッション（読み取り可能）
sudo chmod 644 /path/to/ssl/server.crt
sudo chmod 644 /path/to/ssl/intermediate.crt

# 秘密鍵のパーミッション（所有者のみ読み取り可能）
sudo chmod 600 /path/to/ssl/private.key

# 所有者をWebサーバーのユーザーに設定
sudo chown root:root /path/to/ssl/server.crt
sudo chown root:root /path/to/ssl/intermediate.crt
sudo chown root:root /path/to/ssl/private.key

7-5. 証明書の内容を確認

インストールした証明書が正しいか確認します。

有効期限の確認

bash

openssl x509 -in /path/to/ssl/server.crt -noout -dates

新しい有効期限が表示されればOKです。

ドメイン名の確認

bash

openssl x509 -in /path/to/ssl/server.crt -noout -subject

CN = sample-abc.jp のように表示されればOKです。

証明書と秘密鍵の整合性確認（重要）

bash

# 証明書のモジュラス（ハッシュ値）を取得
openssl x509 -in /path/to/ssl/server.crt -noout -modulus | openssl md5

# 秘密鍵のモジュラス（ハッシュ値）を取得
openssl rsa -in /path/to/ssl/private.key -noout -modulus | openssl md5

重要：この2つのコマンドの出力が同じMD5ハッシュ値であることを確認してください。

例

# 証明書
(stdin)= 1a2b3c4d5e6f7g8h9i0j

# 秘密鍵
(stdin)= 1a2b3c4d5e6f7g8h9i0j

同じ値なら証明書と秘密鍵が正しくペアになっています。異なる場合、証明書と秘密鍵が一致していないため、再度CSRの提出からやり直す必要があります。

ステップ8：Webサーバーの設定確認と再起動

証明書のパスが正しく設定されているか確認し、Webサーバーを再起動します。

8-1. 設定ファイルの確認

証明書のパスが正しいか確認します。

Apacheの場合

bash

# 設定ファイルを確認
sudo cat /etc/httpd/conf.d/ssl.conf
# または
sudo cat /etc/apache2/sites-available/default-ssl.conf

確認すべき設定

apache

<VirtualHost *:443>
    ServerName sample-abc.jp
    
    SSLEngine on
    SSLCertificateFile /path/to/ssl/server.crt
    SSLCertificateKeyFile /path/to/ssl/private.key
    SSLCertificateChainFile /path/to/ssl/intermediate.crt
    
    # その他の設定...
</VirtualHost>

Nginxの場合

bash

# 設定ファイルを確認
sudo cat /etc/nginx/sites-available/default
# または
sudo cat /etc/nginx/conf.d/ssl.conf

確認すべき設定

nginx

server {
    listen 443 ssl;
    server_name sample-abc.jp;
    
    ssl_certificate /path/to/ssl/server.crt;
    ssl_certificate_key /path/to/ssl/private.key;
    
    # その他の設定...
}

Nginxの注意点

Nginxの場合、証明書ファイルにサーバー証明書と中間証明書を連結する必要がある場合があります：

bash

# 証明書を連結（サーバー証明書→中間証明書の順）
cat /path/to/ssl/server.crt /path/to/ssl/intermediate.crt > /path/to/ssl/server_chain.crt

# 設定ファイルで連結ファイルを指定
ssl_certificate /path/to/ssl/server_chain.crt;

8-2. 設定ファイルの文法チェック

再起動前に、設定ファイルに文法エラーがないか確認します。

Apacheの場合

bash

# 文法チェック
sudo apachectl configtest
# または
sudo apache2ctl configtest

「Syntax OK」と表示されればOKです。エラーが表示された場合は、設定ファイルを修正します。

Nginxの場合

bash

# 文法チェック
sudo nginx -t

「test is successful」と表示されればOKです。

8-3. Webサーバーの再起動

Apacheの場合

bash

# 再起動
sudo systemctl restart httpd
# または
sudo systemctl restart apache2

# 再起動後、ステータスを確認
sudo systemctl status httpd

「active (running)」と表示されればOKです。

Nginxの場合

bash

# 設定の再読み込み（推奨：ダウンタイムなし）
sudo systemctl reload nginx

# または完全に再起動
sudo systemctl restart nginx

# ステータス確認
sudo systemctl status nginx

推奨：本番環境では reload を使用すると、接続中のユーザーに影響を与えずに証明書を更新できます。

再起動でエラーが出た場合

もしWebサーバーの再起動に失敗した場合：

  1. バックアップから証明書を復元
  2. 再度Webサーバーを再起動
  3. エラーログを確認して原因を調査

bash

# Apacheのエラーログ
sudo tail -f /var/log/httpd/error_log
# または
sudo tail -f /var/log/apache2/error.log

# Nginxのエラーログ
sudo tail -f /var/log/nginx/error.log

ステップ9：動作確認

新しい証明書が正しくインストールされたか、複数の方法で確認します。

9-1. ブラウザでのアクセス確認

手順1：サイトにアクセス

ブラウザで https://sample-abc.jp にアクセスします。

手順2：鍵マークをクリック

アドレスバーの鍵マーク（🔒）をクリックして、「接続が保護されています」と表示されることを確認します。

手順3：証明書の詳細を確認

「証明書」または「証明書（有効）」をクリックして、以下を確認：

  • 有効期限：新しい有効期限になっているか
  • 発行先：sample-abc.jp
  • 発行元：GlobalSign など正しい認証局名

9-2. コマンドラインでの確認

サーバーから以下のコマンドで確認できます。

証明書チェーンの確認

bash

# 証明書チェーン全体を表示
openssl s_client -connect sample-abc.jp:443 -showcerts

簡易確認（有効期限のみ）

bash

# 有効期限を表示
echo | openssl s_client -connect sample-abc.jp:443 2>/dev/null | openssl x509 -noout -dates

新しい有効期限が表示されればOKです。

9-3. オンラインツールでの確認

以下のようなツールで総合的にチェックします。

SSL Labs Server Test

https://www.ssllabs.com/ssltest

このツールでは：

  • 証明書の有効性
  • 証明書チェーンの完全性
  • SSL/TLSの設定の安全性
  • 総合評価（A+を目指す）

を確認できます。sample-abc.jp を入力して「Submit」をクリックします。

DigiCert SSL Certificate Checker

https://www.digicert.com/help

証明書のインストール状態を簡易的にチェックできます。

9-4. 複数のブラウザとデバイスで確認

以下の環境で正常に表示されるか確認します：

  • デスクトップブラウザ
    • Chrome
    • Firefox
    • Safari
    • Edge
  • モバイル端末
    • iPhone（Safari）
    • Android（Chrome）

特に古いOSのモバイル端末で問題がないか確認することが重要です。

9-5. 社内からのアクセス確認

社内ネットワークから正常にアクセスできるか確認します。一部の企業ネットワークでは、SSL証明書の検証方法が特殊な場合があります。

ステップ10：古い証明書の後処理

更新作業が完了したら、記録を残しておきます。

10-1. 期限切れ証明書の保管

古い証明書は削除せず、バックアップとして保管しておきます。

bash

# 日付付きでリネームして保管
mv /path/to/ssl/backup/server.crt.backup /path/to/ssl/backup/server.crt.2026-02-19

# 古いファイルは1年後に削除
# (念のため、すぐには削除しない)

10-2. 更新記録の作成

更新作業の記録を残しておきます。トラブル時の調査や次回更新時に役立ちます。

bash

# 更新記録ファイルを作成
cat > /path/to/ssl/renewal_log_2026.txt << EOF
====================================
SSL証明書更新記録
====================================

更新日: 2026-01-15
作業者: 山田太郎

【証明書情報】
ドメイン: sample-abc.jp
認証局: GlobalSign
証明書タイプ: DV証明書（Domain Validation）

【有効期限】
旧証明書: 2025/1/18 〜 2026/2/19
新証明書: 2026/1/15 〜 2027/2/15

【更新方法】
CSR再利用（既存の秘密鍵とCSRを使用）

【確認方法】
ドメイン所有確認: メール認証（admin@sample-abc.jp）

【作業内容】
1. 既存ファイルの確認 - OK
2. CSR内容の確認 - OK
3. 認証局への申請 - OK（GlobalSign）
4. ドメイン確認 - OK（メール認証、所要時間5分）
5. 証明書ダウンロード - OK
6. バックアップ作成 - OK
7. サーバーへのインストール - OK
8. Webサーバー再起動 - OK（Nginx reload）
9. 動作確認 - OK（SSL Labs: A+）

【トラブル】
なし

【次回更新予定日】
2027年1月15日頃（有効期限の1ヶ月前）

【備考】
- 次回更新時はCSRの再作成を検討
- 秘密鍵は2025年1月18日から使用
====================================
EOF

10-3. カレンダーへの次回更新日の登録

次回の更新を忘れないよう、カレンダーに登録します。

登録すべき日付

  • 有効期限の1ヶ月前：2027年1月15日
  • 有効期限の2週間前：2027年2月1日（リマインダー）
  • 有効期限：2027年2月15日

カレンダーのタイトル例

【重要】SSL証明書の更新作業（sample-abc.jp）

トラブルシューティング

更新作業中によくある問題とその解決方法を紹介します。

問題1：「証明書と秘密鍵が一致しません」エラー

症状

Webサーバーの再起動時に以下のようなエラーが出る：

SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

原因

証明書と秘密鍵のペアが間違っている。別のCSRで発行された証明書を使っている可能性があります。

解決方法

証明書、秘密鍵、CSRのモジュラス（ハッシュ値）を確認します。

bash

# 証明書のモジュラスを確認
openssl x509 -in /path/to/ssl/server.crt -noout -modulus | openssl md5

# 秘密鍵のモジュラスを確認
openssl rsa -in /path/to/ssl/private.key -noout -modulus | openssl md5

# CSRのモジュラスを確認
openssl req -in /path/to/ssl/server.csr -noout -modulus | openssl md5

3つのMD5ハッシュ値が一致する必要があります。

一致しない場合の対処

  1. 正しいファイルの組み合わせを探す（バックアップを確認）
  2. 見つからない場合、CSRを再作成して再申請

問題2：「中間証明書が見つかりません」警告

症状

一部のブラウザやSSL Labsで「Chain issues」や「Incomplete chain」と表示される。

原因

中間証明書が正しく設定されていない、または証明書チェーンが不完全。

解決方法

Apacheの場合

設定ファイルに中間証明書の指定があるか確認します。

apache

SSLCertificateChainFile /path/to/ssl/intermediate.crt

この行がない場合は追加して、Apacheを再起動します。

Nginxの場合

サーバー証明書と中間証明書を連結したファイルを使用します。

bash

# サーバー証明書と中間証明書を連結
cat /path/to/ssl/server.crt /path/to/ssl/intermediate.crt > /path/to/ssl/server_chain.crt

# 設定ファイルで連結ファイルを指定
ssl_certificate /path/to/ssl/server_chain.crt;

設定変更後、Nginxをreloadします。

確認方法

bash

# 証明書チェーンを確認
openssl s_client -connect sample-abc.jp:443 -showcerts

サーバー証明書と中間証明書の両方が表示されればOKです。

問題3：一部のブラウザで警告が出る

症状

Chrome、Firefoxでは正常だが、古いIEやAndroidで「信頼できない証明書」と表示される。

原因

証明書チェーンが不完全、または古いブラウザが中間証明書を持っていない。

解決方法

SSL Labs（https://www.ssllabs.com/ssltest/）でテストし、「Chain issues」を確認します。

必要な中間証明書がすべて設定されているか確認し、足りない場合は認証局から取得して追加します。

問題4：「証明書の期限が切れています」エラー

症状

更新作業後も「証明書の期限が切れています」と表示される。

原因

  • 古い証明書がキャッシュされている
  • 新しい証明書が正しくインストールされていない
  • Webサーバーが再起動されていない

解決方法

手順1：サーバー側の確認

bash

# サーバーにインストールされている証明書の有効期限を確認
openssl x509 -in /path/to/ssl/server.crt -noout -dates

新しい有効期限が表示されるか確認。古い日付が表示される場合、インストールが失敗しています。

手順2：Webサーバーの再起動

bash

# Apacheの場合
sudo systemctl restart httpd

# Nginxの場合
sudo systemctl restart nginx

手順3：ブラウザのキャッシュをクリア

ブラウザのキャッシュをクリアしてから再度アクセスします。

問題5：Webサーバーが起動しない

症状

証明書を更新後、Webサーバーが起動しなくなった。

原因

  • 証明書ファイルのパスが間違っている
  • ファイルのパーミッションが不適切
  • 証明書ファイルの形式が間違っている

解決方法

手順1：エラーログを確認

bash

# Apacheの場合
sudo tail -f /var/log/httpd/error_log

# Nginxの場合
sudo tail -f /var/log/nginx/error.log

手順2：バックアップから復元

bash

# バックアップから復元
sudo cp /path/to/ssl/backup/server.crt.backup /path/to/ssl/server.crt
sudo cp /path/to/ssl/backup/intermediate.crt.backup /path/to/ssl/intermediate.crt

# Webサーバーを再起動
sudo systemctl restart httpd
# または
sudo systemctl restart nginx

手順3：原因を調査

Webサーバーが正常に起動したら、エラーログから原因を特定し、新しい証明書を再度インストールします。

更新スケジュールの管理

証明書の有効期限切れを防ぐため、適切な管理が重要です。

カレンダーへの登録

証明書の有効期限の1ヶ月前にリマインダーを設定します。

例

  • 証明書有効期限: 2027年2月15日
  • 更新作業開始: 2027年1月15日（1ヶ月前）
  • リマインダー: 2027年2月1日（2週間前）

自動通知の活用

多くの認証局は、有効期限が近づくとメールで通知してくれます。

確認すべきこと

  1. 登録メールアドレスが正しいか（退職者のアドレスになっていないか）
  2. 通知が迷惑メールに振り分けられていないか
  3. メーリングリストなど複数人に届くようにしているか

証明書管理ツールの活用

複数のドメインを管理している場合、証明書管理ツールの使用を検討します。

無料ツール

  • Certbot（Let’s Encryptと連携、自動更新可能）
  • ssl-cert-check（証明書の有効期限をチェック）

有料ツール

  • DigiCert Certificate Management
  • GlobalSign Certificate Management

更新作業の標準化

更新作業手順書を作成し、担当者が変わっても対応できるようにします。

手順書に含めるべき内容

  • サーバーのログイン情報
  • 証明書ファイルの保存場所
  • 認証局の管理画面URL
  • ドメイン確認方法
  • Webサーバーの再起動コマンド
  • トラブル時の連絡先

まとめ

CSR再利用での証明書更新の流れ

  1. ✅ 既存ファイルの確認（秘密鍵、CSR）
  2. ✅ 現在の証明書情報を確認
  3. ✅ CSRの内容を確認
  4. ✅ 認証局で更新申請（既存CSRをアップロード）
  5. ✅ ドメイン所有の再確認（メール/DNS/ファイル）
  6. ✅ 新しい証明書をダウンロード
  7. ✅ バックアップ作成
  8. ✅ 新しい証明書をサーバーにインストール
  9. ✅ Webサーバーを再起動
  10. ✅ 動作確認（ブラウザ、コマンドライン、オンラインツール）

所要時間

  • 作業時間：30分〜1時間
  • 認証局の審査：数分〜数時間
  • 合計：1時間〜5時間程度

メリットとデメリット

メリット

  • 作業が簡単で早い
  • サーバー設定の変更が最小限
  • 既存の秘密鍵とCSRを再利用できる

デメリット

  • 秘密鍵が古いまま（セキュリティリスクがやや高い）
  • ドメイン名や組織情報を変更できない

セキュリティ上の推奨

通常の年次更新ではCSRの再利用でも問題ありませんが、以下の場合はCSRの再作成を検討してください：

  • 2〜3年に1回程度の頻度で鍵のローテーション
  • セキュリティインシデント（情報漏洩の疑い）後
  • サーバー移転時
  • 組織情報やドメイン名の変更時

重要なポイント

  1. バックアップは必須：作業前に必ず既存ファイルをバックアップ
  2. 整合性確認：証明書と秘密鍵のモジュラスが一致しているか確認
  3. 複数環境で確認：デスクトップ、モバイル、複数ブラウザでテスト
  4. 記録を残す：更新作業の記録を残し、次回作業に活用
  5. 期限管理：カレンダーに登録し、更新を忘れない

SSL証明書の更新は、WEBサイト運営における重要な定期作業です。本記事の手順に従って、安全かつ確実に更新を行いましょう。

WEBプログム、WEBデザインなどの制作については、以下を御覧ください。

WEBプログム、WEBデザインなどの制作
 
«