この記事の結論サーバ証明書を発行するには、まずドメインを取得し、DNSのAレコードでサーバーのグローバルIPへ向けます。そのうえで認証局がHTTP-01やDNS-01などのチャレンジでドメイン管理権限を確認し、確認できたら証明書を発行します。秘密鍵はサーバー側に置き、証明書と中間証明書をWebサーバーへ設定します。

サーバ証明書は何を証明するのか

サーバ証明書は、ドメイン名と公開鍵を結び付けるX.509証明書です。ブラウザはHTTPS接続時にサーバーから証明書を受け取り、証明書の署名、期限、対象ドメイン、信頼できる認証局へつながる証明書チェーンを検証します。

ここで重要なのは、証明書が「通信内容を暗号化する鍵そのもの」ではないことです。証明書には公開鍵が入っており、秘密鍵はサーバー側に保管されます。TLSハンドシェイクでは、サーバーが秘密鍵を持っていることを示しながら、この接続だけの共通鍵を合意します。

証明書に入る代表的な情報

現在のWebサーバ証明書では、接続先ホスト名は主にSAN（Subject Alternative Name）で確認されます。ブラウザはアクセス先のドメインがSANに含まれているかを見ます。

項目意味
Subject / SAN証明書の対象。example.com や www.example.com などのドメイン名
Issuer証明書を発行した認証局または中間認証局
Validity証明書の有効期間。期限切れの証明書は拒否される
Public Keyサーバーの秘密鍵に対応する公開鍵
Signature認証局が証明書内容に付けた署名
Key Usage証明書の用途。TLSサーバー認証など

証明書チェーンと信頼の流れ

ブラウザは、サーバー証明書だけを単独で信じるわけではありません。サーバー証明書、中間証明書、ルート証明書という信頼の連鎖をたどります。ルート証明書はOSやブラウザの信頼ストアに入っているため、そこまで署名のつながりを確認できると信頼できます。

サーバ証明書
  ↓ 中間CAが署名
中間証明書
  ↓ ルートCAが署名
ルート証明書（ブラウザやOSが信頼済み）

Webサーバーには、サーバ証明書だけでなく中間証明書も正しく配信する設定が必要です。中間証明書が不足すると、自分の環境では開けても別の端末や古い環境で証明書エラーになることがあります。

Aレコード設定から発行までの全体像

ドメインに対して証明書を発行するには、認証局が「申請者はそのドメインを管理している」と確認できる必要があります。HTTP-01を使う典型的な流れでは、まずDNSのAレコードでドメインをサーバーのグローバルIPへ向けます。

sequenceDiagram
  autonumber
  participant Admin as 管理者
  participant DNS as DNS
  participant Server as Webサーバー
  participant CA as 認証局 / ACME

  Admin->>DNS: example.comのAレコードにサーバーIPを設定
  CA->>DNS: example.comの名前解決を確認
  Admin->>Server: ACMEクライアントで証明書を申請
  CA-->>Server: HTTP-01チャレンジ用トークンを指定
  Server->>Server: /.well-known/acme-challenge/ にトークンを配置
  CA->>Server: http://example.com/.well-known/acme-challenge/... を取得
  Server-->>CA: 指定されたトークンを返す
  CA-->>Server: ドメイン管理を確認し、証明書を発行
  Server->>Server: 証明書と秘密鍵をWebサーバーへ設定

実務での手順

たとえば example.com を新しいVPSやクラウドVMへ向け、そこで証明書を発行する場合は、次のような順序になります。

  1. ドメインを取得し、DNS管理画面を開く
  2. サーバーのグローバルIPアドレスを確認する
  3. example.com のAレコードにそのIPv4アドレスを設定する
  4. IPv6も使うならAAAAレコードにIPv6アドレスを設定する
  5. DNSの反映後、example.com がサーバーIPへ解決されることを確認する
  6. サーバー側で80番ポートと443番ポートを開ける
  7. CertbotなどのACMEクライアントで証明書を申請する
  8. HTTP-01またはDNS-01のチャレンジを完了する
  9. 発行された証明書をNginxやApacheへ設定する
  10. 自動更新と更新後のWebサーバー再読み込みを設定する
# 名前解決の確認例
dig example.com A

# サーバーに向いているか確認
curl -I http://example.com

HTTP-01では、認証局が外部から http://example.com/.well-known/acme-challenge/... にアクセスできる必要があります。CDN、WAF、リバースプロキシ、ファイアウォールでブロックされていると検証に失敗します。

HTTP-01とDNS-01の違い

ACMEでは、ドメイン管理権限を確認するためにチャレンジを使います。代表的なのがHTTP-01とDNS-01です。

方式特徴
HTTP-01対象ドメインのHTTP URLへ指定トークンを置く。Webサーバーを公開している単一ドメインで扱いやすい
DNS-01対象ドメインのDNS TXTレコードへ指定値を置く。ワイルドカード証明書や外部公開前のサーバーで使いやすい
TLS-ALPN-01443番ポート上のTLS応答で検証する方式。環境により利用可否が分かれる

ワイルドカード証明書、たとえば *.example.com を発行したい場合はDNS-01が必要です。一方、通常の example.com や www.example.com だけならHTTP-01でも十分なことが多いです。

秘密鍵とCSRの扱い

証明書発行では、秘密鍵と公開鍵のペアが中心になります。昔ながらの手順では、サーバー側で秘密鍵を作り、公開鍵やドメイン名を含むCSR（Certificate Signing Request）を作成し、認証局へ提出します。ACMEクライアントを使う場合も、内部では同じ考え方で鍵や申請情報を扱います。

秘密鍵は外へ出さない秘密鍵が漏れると、攻撃者がその証明書に対応するサーバーとして振る舞える可能性があります。秘密鍵はサーバー上で生成し、権限を絞って保存し、リポジトリやチャット、チケットに貼り付けないようにします。

証明書を更新するときに秘密鍵を再利用するか、新しい鍵を作るかは運用方針によります。漏えいが疑われる場合は、証明書の失効と鍵の作り直しが必要です。

インストール後に確認すること

証明書を発行しただけではHTTPSは有効になりません。Webサーバーが443番ポートでTLSを終端し、正しい証明書チェーンと秘密鍵を使うように設定します。

確認項目見るポイント
ホスト名アクセスするドメインが証明書のSANに含まれているか
期限有効期限切れになっていないか、自動更新が動くか
チェーン中間証明書を含めてクライアントが信頼できるか
秘密鍵証明書に対応する秘密鍵をWebサーバーが読めるか
リダイレクトHTTPからHTTPSへ誘導するか。ACME更新用のパスを壊していないか
# 証明書の概要確認
openssl s_client -connect example.com:443 -servername example.com

# HTTPS応答の確認
curl -I https://example.com

よくある失敗

証明書まわりの失敗は、DNS、ネットワーク、Webサーバー設定、証明書チェーンのどこで止まっているかを分けると見つけやすくなります。

症状原因の例
認証局の検証が失敗するAレコードが別IPを向いている、80番ポートが閉じている、チャレンジURLがリダイレクトやWAFで壊れている
ブラウザで名前不一致www ありなしなど、アクセス先ドメインがSANに入っていない
一部端末だけエラー中間証明書の配信不足、古いルート証明書、時刻ずれ
更新に失敗する初回発行後に80番ポートを閉じた、DNS API権限が失効した、更新後のreloadが動いていない

まとめ

サーバ証明書は、ドメイン名と公開鍵を認証局の署名で結び付ける仕組みです。発行の実務では、ドメインのAレコードをサーバーIPへ向け、認証局がHTTP-01やDNS-01で管理権限を確認し、証明書を発行します。発行後は証明書チェーン、秘密鍵、Webサーバー設定、自動更新まで含めて運用することが大切です。

詳細は RFC 5280（X.509 PKI）、RFC 8555（ACME）、Let’s Encrypt Challenge Types を参照してください。