AI は誤ることがあります。原文をご確認ください 専用ページで開く
ドキュメントに質問
目次

証明書操作マニュアル

8 分で読了
このページの目次

CA 発行済み・disk 配置済み・service 読込済み・client 受信のどれかを区別する。HTTPS 検証には名前・時刻・chain・信頼が必要。

やりたいこと参照先
browser 証明書エラー公開中の証明書を確認
更新後も期限切れ更新から配置
CSR・ローカル証明書作成名前・鍵・信頼

SNI は site 選択、hostname は識別検証

online：handshake と identity を検証する

# 完全な handshake 検証でエラーを隠さず対象へ接続する
openssl s_client -connect example.com:443 \
  -servername example.com -verify_hostname example.com \
  -verify_return_error -showcerts </dev/null

-connect は TCP、-servername は SNI、-verify_hostname は名前検証、-verify_return_error は検証失敗時に中止する。-showcerts は相手の chain を表示。検証結果と stderr を読む。

特定入口なら -connect を実 IP にし、SNI/hostname は実 domain を保つ。私有 CA は管理された CAfile を使い、検証を切らない。

disk：metadata と期限を読む

# ファイル内の最初の証明書の名前・issuer・時刻を読む
openssl x509 -in fullchain.pem -noout -subject -issuer -dates -ext subjectAltName

通常 fullchain は leaf、その後 intermediate。これは最初の一枚の解析で chain 検証ではない。サービスの実ファイルを使う。

# 24 時間以内の期限切れを調べる
openssl x509 -in fullchain.pem -noout -checkend 86400

0 は期間内に期限切れにならないことを示す。非ゼロは結果・エラーを読む。単位は秒で、名前・信頼は別。

完全な handshake 検証でエラーを隠さず、private CA は信頼する -CAfile を指定する。-servername だけでは名前検証しない。checkend 86400 は24時間以内の失効を判定し、現在の失効や名前・chain・notBefore 検査とは別。

検査失敗の根拠修正箇所
SAN / hostname接続名が SAN にない正しい名前で発行・URL 修正
notBefore / notAfter時計誤り・有効前・期限切れ校時・更新して配置
Chain中間証明書不足・chain 不一致正しい fullchain を配置
Trustclient が root CA を信頼しない適切な CA または管理された信頼。検証無効化をしない

更新完了は client 側で確認

証明書配置の連鎖 CA が新証明書発行 service のパスへ配置 service が新内容を読込 client が指紋を確認

設置済みと配信中の証明書を照合する

# サービスが参照する disk 証明書の識別子を読む
openssl x509 -in /etc/ssl/example/fullchain.pem -noout -serial -fingerprint -sha256

serial と SHA-256 fingerprint を記録し、同じ endpoint/SNI と比較する。

# online leaf の fingerprint を比較用に抽出する
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null |
  openssl x509 -noout -serial -fingerprint -sha256

handshake 診断を省く metadata 抽出で、信頼検証ではない。後で完全検証する。不一致なら CDN/LB・別 instance の終端を調べる。

ここでは指紋抽出のみ。信頼検証は前節を使う。disk と配信版が違えば参照 path・権限・reload hook・LB/CDN の TLS 終端を確認し、必要な各 edge を検証する。

証明書の管理元を一つ選ぶ

acme.sh・Certbot・Caddy 自動 HTTPS は選択肢。管理元と保存先権限を確認し、同じ証明書へ重ねて適用しない。

# acme.sh 所有アカウントで発行済み domain・鍵種別を見る
acme.sh --list

次は ECC 発行済みが前提。なければ適切な HTTP/DNS challenge で先に発行する。install-cert は issue ではない。

# 発行済み証明書をサービスの固定参照先へ設置する
acme.sh --install-cert -d example.com --ecc \
  --key-file /etc/ssl/example/key.pem \
  --fullchain-file /etc/ssl/example/fullchain.pem \
  --reloadcmd 'systemctl reload caddy'

手動証明書の Caddy と、書込・reload 権限のあるアカウント向け。RSA は --ecc を外す。権限・fingerprint・reload log・online TLS を確認する。

Certbot：既存確認または初回発行

# Certbot の証明書名・domain・path を列挙する
certbot certificates

Cert Name は domain と同じとは限らない。--cert-name は実名を使い、plugin は別途確認する。

webroot 初回発行は、既存 HTTP server が公開 80 で challenge path を /var/www/acme 配下から配信し、A/AAAA が正しいことが前提。Caddy 自動 HTTPS では不要。

# test CA で HTTP-01 経路を検証する
sudo certbot certonly --webroot -w /var/www/acme -d example.com --dry-run

-w は server の webroot、-d は申請名。アカウント入力に従う。dry-run は本番配備用証明書を作らず、失敗原因を先に直す。

# test 成功後に発行し、サービス参照を別に設定する
sudo certbot certonly --webroot -w /var/www/acme -d example.com

certonly は Web 設定を変更しない。実 path を調べ、設定・検証・reload 後に client から TLS を確認する。

# 既存の更新設定と challenge を試す
sudo certbot renew --dry-run

成功しても配備済みとは限らない。timer・deploy hook を確認し、dry-run 時の hook 実行は --run-deploy-hooks 等の挙動を確かめる。

acme.sh は ECC 発行済み・保存先と権限・有効な reload が前提。RSA は --ecc なし。内部 workdir でなく安定した install-cert 先を参照する。同一証明書の更新主体を一つにし、DNS plugin と権限を確認する。

Caddy 自動 HTTPS は通常発行・更新を担当する。Caddy参照。手動証明書を選ぶ場合に外部更新を使う。challenge 経路・委任・TXT・権限を調べ、試験は staging/dry-run。cloud LB は binding も必要。

SAN を含む要求を作り公開鍵を照合

新 key・CSR：出力保護を先に行う

# この shell の新規秘密鍵ファイル権限を制限する
umask 077

管理された場所と未使用名を使い、既存 server.key を上書きしない。

# private key と SAN 付き CSR を作る
openssl req -new -newkey rsa:3072 -noenc \
  -keyout server.key -out server.csr \
  -subj '/CN=example.com' \
  -addext 'subjectAltName=DNS:example.com,DNS:www.example.com'

OpenSSL 3 の -noenc は未暗号化。権限・配備保護を前提とする。暗号化なら省略し unlock を設計する。SAN に実名を列挙し、CN で代替しない。

# CSR の署名・SAN・公開鍵情報を確認する
openssl req -in server.csr -noout -verify -text

-verify は CSR 自身の検証で、CA 発行・SAN 受理の証明ではない。提出は CSR のみで秘密鍵は保持する。

発行後に公開鍵 hash を比較する

# 秘密鍵から公開鍵を取り出して hash 化する
openssl pkey -in server.key -pubout -outform DER | openssl dgst -sha256

出力は公開鍵の hash だけ。次も同じ DER に揃える。

# 発行された証明書の公開鍵を hash 化する
openssl x509 -in server.crt -pubkey -noout |
  openssl pkey -pubin -outform DER | openssl dgst -sha256

server.crt は CA の leaf。hash 一致は鍵の対応だけで、SAN・期限・chain・信頼は別途確認する。

OpenSSL 3 の例。-noenc は暗号化しない鍵なので保存権限を保護する。CSR に秘密鍵は含まれない。発行後の公開鍵一致は信頼の証明ではない。localhost 自己署名には SAN と明示的信頼が必要。鍵漏洩時は鍵・証明書交換と失効を行う。

OpenSSL s_client · OpenSSL x509 · acme.sh installation · Certbot

実環境：WildWind CLB 証明書更新と binding。

リンクプレビュー

新しいタブで開く