Ubuntu 26.04 講座 / HTTPS 証明書の発行・自動更新・期限確認
HTTPSは、自分が管理する実際のドメインとドメイン検証用のパスを準備した後、証明書を発行してウェブサーバーに適用します。発行成功、外部から提供される証明書、自動更新作業および有効期限の検出はそれぞれ検証する必要があります。
ドメインと公開HTTP条件の確認
Nginx講座の127.0.0.1:8080 .test 実習サイトは証明書発行対象ではありません。実際のDNSがサーバーを指しており、Nginxのserver_name・ドキュメントルート・ポート80への応答が正しいサイトをまず準備します。IPv6 AAAAレコードがある場合は、その経路も実際に機能する必要があります。
次の問い合わせは、実際のドメインを入力して実行します。digがない場合は、Ubuntuのdnsutilsパッケージを準備します。別のネットワークのクライアントからもDNSとHTTP応答を確認し、ファイアウォール・ルーター・クラウドのルールも合わせて確認します。
read -r -p "Domain you control: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl -I "http://$domain/"
実際のドメインのHTTPサイトをまず完成させる
この章は、ユーザー所有のドメインが公開アドレスに接続される別の Ubuntu ウェブサーバーを対象としています。固定IP実習に使用するホスト専用VMはインターネットから直接アクセスされないため、そのまま発行を試みません。公開サーバー・DNS を準備できない場合、発行の実習は保留するか、公式 DNS プラグインと資格情報保管を備えた DNS-01 経路を別途選びます。
Nginx と curl を準備し、ドメインの A レコードをサーバーの公開 IPv4 に設定します。AAAA がある場合は IPv6 経路も動作する必要があります。以下の全コードを ~/prepare-public-http.sh に保存し、bash ~/prepare-public-http.sh 実際のドメインで実行します。一般 ASCII ホスト名用の例であり、国際化ドメインは検証済みの Punycode 名を使用します。既存の実習経路がある場合は上書きせず中断します。
set -eu
if [ "$#" -ne 1 ]; then
printf 'Usage: bash prepare-public-http.sh YOUR_DOMAIN\n' >&2; exit 2
fi
domain=$(printf '%s' "$1" | tr '[:upper:]' '[:lower:]')
if [[ ! "$domain" =~ ^([a-z0-9]([a-z0-9-]*[a-z0-9])?\.)+[a-z]([a-z0-9-]*[a-z0-9])?$ ]]; then
printf 'Use a valid ASCII hostname you control.\n' >&2; exit 2
fi
case "$domain" in
*.test|*.invalid|*.localhost|*.example|example.com|*.example.com)
printf 'Use your real domain, not an example name.\n' >&2; exit 2 ;;
esac
site=/etc/nginx/sites-available/ubuntu-course-public
enabled=/etc/nginx/sites-enabled/ubuntu-course-public
root_dir=/srv/ubuntu-course-public
for path in "$site" "$enabled" "$root_dir"; do
if sudo test -e "$path" || sudo test -L "$path"; then
printf 'Existing lab path: %s; stop and inspect.\n' "$path" >&2; exit 1
fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-public.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo install -d -m 0755 "$root_dir"
printf 'public-http-lab\n' | sudo sh -c 'set -C; cat > "$1/index.html"' sh "$root_dir"
sudo chmod 0644 "$root_dir/index.html"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<EOF
server {
listen 80;
listen [::]:80;
server_name $domain;
root /srv/ubuntu-course-public;
index index.html;
location / {
try_files \$uri \$uri/ =404;
}
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
printf 'HTTP site prepared; backup: %s\n' "$backup_dir"
IPv6 リスナーを使用できないサーバーは、実際のポリシーを確認して該当する listen 行を調整し、使用できない AAAA を提供しません。ファイル・リンク作成、確認および reload がすべて成功した後、次のステップに進みます。失敗した場合は今回のファイル・リンクのみバックアップと照合し、他のサイトを上書きしません。
UFWで既に管理されている新しい公開ウェブサーバーでHTTP・HTTPSを公開する方針であれば、次のルールを追加します。SSHルールは保持し、プロバイダのファイアウォール・セキュリティグループにも80/443の経路を準備します。UFWを新たに有効化するコマンドではありません。HTTP-01外部検証は、実習クライアント .10のみを許可したルールでは完了しません。
sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw status verbose
上記別スクリプトのdomain変数は親シェルには残りません。現在のBashセッションで実際の名前を再入力し、別のインターネット接続のクライアントからもHTTP本文のpublic-http-labを確認します。名前・本文・A/AAAA経路が正しいか照合した後、Certbotで進めます。
read -r -p "Domain you control: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl --fail --show-error "http://$domain/"
Certbotのインストール経路を一つに決める
既存のCertbotがある場合は、インストール元と更新作業を先に確認し、APT・Snap・pipのインストールを混在させません。この例では、新しい専用サーバーで公式Snap経路を選びます。classic権限が必要なパッケージである点を読み、インストールし、コマンドは絶対パスで実行して、別の方法でインストールしたCertbotと混同しません。
sudo snap install --classic certbot
/snap/bin/certbot --version
Certbot公式Nginx·Snapガイドでインストール・発行・更新テスト手順を確認できます。
バックアップと構文チェック後に発行する
(
set -eu
backup=$(sudo mktemp -d /root/nginx-before-tls.XXXXXX)
sudo cp -a /etc/nginx "$backup/"
sudo nginx -t
sudo /snap/bin/certbot --nginx -d "$domain"
)
同じBashセッションのdomain変数に実際のドメインが入っているかを再確認し、構文チェックが成功した場合にのみCertbotを実行します。メールアドレス・利用規約・リダイレクトの選択は案内を読んで決定します。自動設定はNginxファイルを修正するため、何が変更されたかをバックアップと比較します。
HTTP-01は外部の検証者がアクセスするパスを必要とします。アクセスできない環境では公式DNSプラグインなどのサポートされている方法を別途選択し、DNS APIの資格情報は最小権限で保管します。発行失敗を繰り返しリクエストで解決しようとせず、まずDNS・ポート・検証ログを調査します。
外部HTTPSと実際の証明書を確認する
curl --fail --show-error "https://$domain/"
openssl s_client -connect "$domain:443" -servername "$domain" -verify_return_error -verify_hostname "$domain" </dev/null
名称・証明書チェーンの検証と予想されるWebレスポンスを確認します。検証を無効にするcurl -kで成功表示を作成しません。ローカル発行ファイルが最新でも、プロキシ・ロードバランサー・他のIPv6サーバーが古い証明書を提供することがあるため、ユーザーが接続する実際の経路をテストする必要があります。
更新テストと期限検知
sudo /snap/bin/certbot certificates
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all | grep certbot
dry-runは現在の検証・更新経路のテストであり、将来の作業が必ず成功する保証はありません。実際のタイマー・実行ログ・失敗通知と外部証明書の有効期限検知も併せて準備してください。証明書の有効期間を固定の日数で仮定せず、現在のnotAfterを確認してください。
復元する際は、今回のCertbot変更とNginx設定のみを確認し、他のドメインの証明書・更新設定を削除しないでください。証明書更新後は、実際の提供経路で新しい証明書とサービス応答を確認することで、HTTPS運用チェックが完了します。




