2026年5月24日

SSL/TLS 証明書を発行・更新する手順（CSR作成から設置・確認まで）

ネットワーク・接続

SSL/TLS 証明書の発行と更新は、「秘密鍵とCSRを作る」「認証局（CA）でドメインの認証を受ける」「証明書と中間証明書をサーバーに設置する」「外部から確認する」という同じ流れを、有効期限が来るたびに繰り返す作業です。この記事では、有料証明書を手作業で扱う場合を中心に、OpenSSL でのCSR作成、Nginx・Apache への設置、更新時の注意点、確認コマンドまでをまとめます。

Let's Encrypt のように自動で発行・更新できる証明書を使う場合は、手順の多くを certbot などのツールが代わりに行います。その場合でも、ここで説明する「何が起きているか」を知っておくと、更新に失敗したときの切り分けが速くなります。

証明書の有効期間は短くなっている

証明書の最大有効期間は、ブラウザベンダーと認証局でつくる業界団体（CA/Browser Forum）のルールで決まっています。2025年に、最大有効期間を段階的に短縮する決定がされ、2026年3月以降に発行される証明書は最大200日程度、その後さらに100日、最終的には47日程度まで短くなる予定とされています（2026年10月現在。日程や日数は各CAの案内で確認してください）。

これは「1年に1回、手で入れ替える」運用が成り立たなくなることを意味します。手作業の手順を理解したうえで、可能なら ACME（自動発行のための仕組み）に対応した自動更新へ移行することを検討してください。多くのレンタルサーバーやクラウドのロードバランサーには、無料の証明書を自動で更新する機能も用意されています。

ステップ1：証明書の種類と取得先を決める

証明書には、ドメインの管理権限だけを確認するDV、組織の実在も確認するOV、さらに厳格な審査を行うEVがあります。ブラウザのアドレスバーでの見え方はどれもほぼ同じになっており、通信の暗号化の強さにも違いはありません。一般的なWebサイトならDVで足りることが多く、組織情報の証明が必要な場合にOV・EVを選びます。

あわせて、1枚の証明書でカバーするドメイン名を決めます。example.com と www.example.com の両方で接続されるなら、両方を証明書の SAN（サブジェクト代替名）に入れる必要があります。サブドメインが多い場合はワイルドカード証明書（*.example.com）も選択肢ですが、*.example.com は example.com 自体や2階層下のサブドメインを含まない点に注意してください。

ステップ2：秘密鍵とCSRを作る

CSR（証明書署名要求）は、公開鍵とドメイン名などの情報をまとめて認証局に提出するファイルです。秘密鍵とセットで作ります。

# 作業用ディレクトリ（権限を絞っておく）
sudo mkdir -p /etc/ssl/example.com
cd /etc/ssl/example.com

# RSA 2048bit の秘密鍵とCSRを同時に作成（SAN付き）
sudo openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

sudo chmod 600 example.com.key

# CSRの内容を確認
openssl req -in example.com.csr -noout -text

-addext は OpenSSL 1.1.1 以降で使えるオプションです。確認の出力で「Subject Alternative Name」の欄に必要なドメインがすべて入っているかを見てください。現在の認証局やブラウザはCN（コモンネーム）ではなくSANの値で照合するため、ここが抜けていると証明書エラーになります。

鍵の種類は RSA 2048bit が広く使われていますが、より短い鍵で同等の強度がある ECDSA（P-256）を選べる認証局も増えています。どちらを使うかは、認証局の対応と、古い端末からの接続を受ける必要があるかで決めます。

秘密鍵は認証局を含め、誰にも送りません。認証局に提出するのはCSRだけです。秘密鍵のファイルはバックアップを取りつつ、権限を root だけが読める状態にしておきます。

ステップ3：ドメインの認証を受ける

CSRを認証局（または販売代理店）の申し込み画面に貼り付けると、ドメインの管理権限を確認する手続き（DCV）が始まります。方法は主に次の3つです。

HTTPファイル認証：指定されたファイルを http://example.com/.well-known/pki-validation/ などのパスに置く
DNS認証：指定された値をTXTレコードやCNAMEレコードとしてDNSに登録する
メール認証：admin@example.com などの決められたアドレスに届くメールで承認する

HTTP認証では、ファイルを置いたパスがリダイレクトやBasic認証、WAFで止められていないかを確認してください。DNS認証では、レコード登録後に反映されるまで時間がかかることがあります。ドメインに CAA レコードを設定している場合は、利用する認証局が許可されているかも確認が必要です。

ステップ4：証明書を設置する

認証が通ると、サーバー証明書と中間証明書が発行されます。設置でもっとも多い失敗は、中間証明書の入れ忘れです。パソコンのブラウザでは問題なく見えても、一部のスマートフォンや curl、外部サービスからの接続でエラーになります。

Nginx の場合

Nginx では、サーバー証明書の後ろに中間証明書をつなげた1つのファイル（いわゆる fullchain）を指定します。

# サーバー証明書 → 中間証明書 の順で連結
cat example.com.crt intermediate.crt | sudo tee fullchain.pem > /dev/null

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/example.com.key;
}

Apache の場合

Apache 2.4.8 以降では、SSLCertificateFile に中間証明書を連結したファイルを指定できます。古い解説で見かける SSLCertificateChainFile は非推奨になっています。

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/example.com/example.com.key
</VirtualHost>

鍵と証明書の組み合わせを確かめる

設定を反映する前に、証明書と秘密鍵が対になっているかを確認します。2つのハッシュ値が一致すれば正しい組み合わせです。

openssl x509 -in fullchain.pem -noout -pubkey | openssl sha256
openssl pkey -in example.com.key -pubout | openssl sha256

# 設定ファイルの文法チェックをしてから再読み込み
sudo nginx -t && sudo systemctl reload nginx
# Apache の場合
sudo apachectl configtest && sudo systemctl reload apache2

Apache のサービス名は、Debian / Ubuntu では apache2、RHEL系では httpd です。

ステップ5：外部から確認する

設置後は、サーバーの外から実際に配信されている証明書を確認します。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

見るべき点は、発行者（issuer）が想定した認証局になっているか、有効期限（notAfter）が新しい日付になっているか、SANに必要なドメインがすべて含まれているかの3つです。中間証明書が送られているかは、openssl s_client -showcerts の出力で証明書が2枚以上返ってくるかで確認できます。

更新するときの注意点

更新は、基本的に新しい秘密鍵とCSRを作り直して申し込みます。古い鍵を使い回すこともできますが、鍵を定期的に新しくするほうが、万一の漏えい時の影響を小さくできます。更新時に残り日数を新しい証明書に引き継げるかどうかは販売元ごとに扱いが異なるため、申し込み前に確認してください。

更新作業で見落としやすいのは、証明書を持っている場所が1か所とは限らないことです。CDNやロードバランサーで暗号化を終端している構成では、そちらにも証明書が設定されています。複数台のWebサーバーがある場合は全台に配る必要があります。メールサーバーなど、Web以外のサービスが同じ証明書を使っていることもあります。どこに証明書があるかを一覧にしておくと、更新漏れを防げます。

また、期限切れの直前に作業すると、認証や反映に時間がかかったときに間に合いません。期限の数週間前には更新を始め、期限を監視する仕組みも用意しておくのが安全です。

まとめ

証明書の発行・更新は「鍵とCSRの作成」「ドメイン認証」「設置」「外部からの確認」の繰り返しです
証明書の最大有効期間は段階的に短くなっており、自動更新への移行も検討が必要です
CSRにはSANで必要なドメインをすべて入れ、秘密鍵は誰にも送らずに権限を絞って保管します
設置では中間証明書を含めたファイルを指定し、鍵との組み合わせと文法チェックをしてから反映します
更新時はCDN・ロードバランサー・複数サーバーなど、証明書を置いているすべての場所を確認します