VPSにドメインを向けてHTTPSにする — 自動更新は未確認だった

サーバーの初期設定を終えました。SSHは鍵だけで入れるようになり、rootのログインも止めました。

それでも、サイトはまだIPアドレスを直接打たないと見えません。ブラウザのアドレス欄には数字が並び、その横に「保護されていない通信」と出ています。

この記事は、そこから 自分のドメインで、鍵マークが付いた状態にするまでの話です。

そして、この記事の本題は手順そのものではありません。手順は検索すれば出てきます。出てこないのは、設定したあとに、それが本当に動いているかをどう確かめるかのほうです。

私は自分のサイトのHTTPSを2か月放置していて、その間ずっと「自動更新設定済み」と記録に書いていました。 2026年8月23日に本番のサーバーを見に行って、一度も更新されていないことが分かりました。

全体は5つです

1. 80番と443番を開ける
2. ドメインのAレコードを、サーバーのIPアドレスに向ける
3. 証明書を取る          ← ここで「鶏と卵」に当たります
4. nginx に証明書を読ませる
5. 自動更新が動くことを確かめる  ← ここが、いちばん書かれていない

1から4は、うまくいけば1時間ほどで終わります。5だけが性質の違う話です。

理由は2つあります。

• 自動更新は、設定した日には正しさを確認できません。 実際に更新が走るのは、期限まで残り30日を切ってからです
• 期限切れが近づいても、メールはもう来ません。 Let's Encrypt の通知メールは 2025年6月4日で終わっています

つまり、設定した日から最初の更新日までのあいだ、正しいかどうかを教えてくれるものが何もありません。 そこを埋める方法まで書きます。

1. 80番と443番を開ける

前の記事（VPSを契約したらやる初期設定4つ）では、SSHの22番しか扱っていません。Webの穴はまだ開いていません。

ファイアウォールが VPS事業者側とOS側の2つある話も、そちらに書きました。片方だけ開けてもつながりません。 つながらないときは両方見てください。

OS側（ufw）で開けるのは2つです。

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

nginxを入れた方法によっては、名前でまとめて指定できることがあります。あるかどうかは環境によって違うので、先に一覧を見てください。

sudo ufw app list

ufw は /etc/ufw/applications.d に置かれたプロファイルを読んで、この一覧を作ります。そこに何が置かれるかはインストール方法しだいなので、「この名前で通る」と決め打ちしないほうが安全です。一覧に出なければ、上の 80/tcp / 443/tcp で指定します。

2. ドメインをサーバーに向ける

ドメインを買ったら、そのドメインを引いたときにサーバーのIPアドレスが返るようにします。置くのは1本だけです。

この記事は Aレコード（IPv4）だけの話です。IPv6（AAAAレコード）は扱いません。

ドメインそのものには、CNAME を置けません

www.example.com のような名前には CNAME（別名）を置けますが、example.com そのものには置けません。ここは仕様の理解が要ります。

RFC 2181 は、DNSのどの名前についても、次の4つのうちちょうど1つだけが成り立つと書いています。

• one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
• one or more records exist, none being CNAME records,
• the name exists, but has no associated RRs of any type,
• the name does not exist at all.

そして example.com そのものには、SOA と NS が必ず存在します（そのドメインを誰が管理しているかを示すレコードです）。CNAMEが単独で存在する1番目の状態には、どうやってもなりません。

「RFCがドメインの頂点でのCNAMEを禁止している」と書いてあるわけではありません。そう書けない構造になっている、という説明のほうが正確です。

DNS事業者によっては、この制約を内部で吸収する機能を持っています。Cloudflare の場合は CNAME flattening という名前です。

CNAME flattening speeds up CNAME resolution and allows you to use a CNAME record at your zone apex (example.com).

使うかどうかは事業者しだいなので、この記事では Aレコードを1本置く形で進めます。

www を作るかどうかは、最初に決めてください

私は2つのサイトで、逆の判断をしています。

どちらが正解かという話ではありません。 問題は、後から足すと手戻りがあることです。

証明書はドメイン名の組み合わせに対して発行されます。example.com だけで取ったあとに www.example.com を足すと、それは別の組み合わせなので、証明書を取り直すことになります。

そしてLet's Encryptには回数の制限があります。

Up to 5 certificates can be issued per exact same set of identifiers every 7 days.

「同じ組み合わせで7日に5回まで」です。取り直しはこの回数を消費します。最初に決めておけば、消費せずに済みます。

変える前にTTLを下げる（これは2回目以降の話です）

DNSの各レコードには TTL という秒数が付いています。

サーバーを引っ越すとき、つまりすでに置いてあるAレコードのIPアドレスを書き換えるときには、順番があります。RFC 1912 は1996年の時点でこう書いています。

If you plan to make major changes, it's a good idea to turn this value down temporarily beforehand. Then wait the previous minimum value, make your changes, verify their correctness, and turn this value back up.

変えてから待つのではなく、変える前にTTLを下げる。 下げる → 前のTTLぶん待つ → 変更する → 確認する → 戻す、という順序まで原文に書かれています。

「DNS浸透」を待っている、という言い方について

レコードを置いた直後は、まだ古い状態が返ってくることがあります。これを「浸透待ち」と呼ぶ説明をよく見かけます。

この言い方は、起きていることを逆に説明しています。

株式会社日本レジストリサービス（JPRS）が2011年のInternet Weekで出した資料に、こう書かれています。

• キャッシュDNSサーバーは古いデータがキャッシュから消えない限り、新しいデータを能動的に取りに行くことは決してない • つまり、浸透問題とは「新しいデータが反映されない問題」なのではなく、何らかの理由により「消えるはずの古いデータが残り続けてしまう問題」である

同じ資料は、正しい手順で作業して待っている状態についても、こう書いています。

– 「新しいデータの浸透（伝播）待ち」ではなく、「古いデータの消滅待ち」と言うのが正しい

つまり、新しい情報が世界中に広がっていくのを待っているのではありません。 古い情報が捨てられるのを待っています。 そして捨てられるまでの長さを決めているのは、自分が設定したTTLです。

これが分かると、待ち時間が自分の設定で決まることが分かります。「1〜2週間かかる」という類の説明が出てくる余地は、初回設定にはありません。

実務的な数字を1つ挙げると、Cloudflare の TTL の既定値（Auto）は 300秒（5分）です。そして Cloudflare 自身が、こう書いています。

It may take longer than 5 minutes for you to actually experience record changes, as your local DNS cache may take longer to update.

手元のパソコンや家のルーターにも、別のキャッシュがあります。 事業者側の設定を5分にしても、自分のブラウザで確認できるまでは、それより長くかかることがあります。 これも「広がるのを待っている」のではなく、手元の古い答えが消えるのを待っているという同じ話です。

3. 証明書を取る

ドメインが自分のサーバーを指したら、証明書を取りに行きます。

DNSのTXTレコードで証明する DNS-01 という方式もあります。DNSプロバイダにAPIがあって、それを自動化できるときの選択肢です。ワイルドカード証明書を取るならこちらになりますが、この記事では扱いません。

⚠️ 本番で叩く前に、--dry-run を通してください

ここがいちばん実害を防げる項目です。

証明書の発行には回数制限があります。さきほど引いた「同じ組み合わせで7日に5回まで」がそれです。Let's Encrypt は、その制限に引っかかる典型的な原因まで書いています。

Reinstalling your client multiple times to troubleshoot an unknown error, or deleting your ACME client's configuration data each time you deploy your application, are common ways to hit this limit.

設定をいじっては叩き直すという、初めての人がいちばんやる動きです。そして、

If you've hit a rate limit, we don't have a way to temporarily reset it.

一時的にリセットする方法はありません。 証明書を失効させても戻りません（発行に使った資源はもう消費されているため、と原文に書かれています）。

そのための逃げ道が --dry-run です。

--dry-run Perform a test run against the Let's Encrypt staging server, obtaining test (invalid) certificates but not saving them to disk. This can only be used with the 'certonly' and 'renew' subcommands.

テスト用のサーバーに対して実行するので、本番の回数を消費しません。 ディスクにも保存されません。

そして、最後の一文が大事です。 使えるのは certonly と renew の2つだけ。いまはまだ証明書を1枚も持っていないので、使うのは certonly のほうになります。

# ① まず、本番の回数を使わずに試す
sudo certbot certonly --webroot -w /var/www/certbot -d example.com --dry-run

# ② 成功したら --dry-run を外して、本番を1回だけ叩く
sudo certbot certonly --webroot -w /var/www/certbot -d example.com

certbot には、nginxの設定ファイルを自動で書き換えてくれるモード（certbot --nginx）もあります。私は使っていないので、この記事では手順を書きません。 自分で設定を書いている場合や、コンテナで動かしている場合は、次に書く形になります。

⚠️ 鶏と卵 — 証明書が無いと、nginx が起動しません

ここが、公式ドキュメントを順に読んでいるだけでは出てこない場所です。

• 証明書を取るには、80番でnginxが応答している必要があります
• しかし、443番の設定に書いた証明書ファイルが存在しないと、nginxは起動しません

起動しないから証明書が取れず、証明書が無いから起動しない、という循環に入ります。

私のリポジトリには、この循環を抜けるためだけの設定ファイルが1本残っています。その先頭のコメントが、そのまま説明になっています。

# Used only before the first Let's Encrypt certificate exists: nginx fails
# to start if default.prod.conf's 443 server block references
# ssl_certificate files that aren't there yet. Swap this in as
# default.conf, `docker compose ... restart nginx`, run the one-off
# `certbot certonly` (see deploy notes), then switch back to
# default.prod.conf and restart again. Identical to default.prod.conf's
# HTTP server except it serves the site directly instead of redirecting to
# HTTPS (which would otherwise have nowhere to go yet).

やることは2段階です。

① HTTPSを含まない設定（80番だけ）でnginxを起動する
     ↓
② certbot で証明書を1回だけ取る
     ↓
③ 本来の設定に差し替えて、もう一度起動する

①の設定では、HTTPSへの転送を書きません。 まだ飛ばす先が無いからです。80番でそのままサイトを出します。

私がこれを踏んだのは、nginxの設定を手で書いているからです。certbot --nginx（設定を自動で書き換えるモード）を使ったときにこの循環がどう扱われるのかは、使っていないので分かりません。

4. nginx に証明書を読ませる

証明書が取れたら、nginx に場所を教えます。

現在のnginx公式ドキュメントによれば、必要なのは 443番で ssl を有効にすることと、証明書と秘密鍵のファイルを指定することです。

To configure an HTTPS server, the ssl parameter must be enabled on listening sockets in the server block, and the locations of the server certificate and private key files should be specified:

どのファイルを指すか

certbot が作るファイルは複数あります。nginx が要るのは fullchain.pem です。

This is what Apache >= 2.4.8 needs for SSLCertificateFile, and what Nginx needs for ssl_certificate.

cert.pem という似た名前のファイルもありますが、そちらではありません。certbot のドキュメントは、間違えたときの症状まで書いています。

If you provide one of these files to your web server, you must provide both of them, or some browsers will show "This Connection is Untrusted" errors for your site, some of the time.

「一部のブラウザで、ときどき」です。自分のブラウザでは出ないことがあります。動いて見えるので、いちばん気づきにくい間違いです。

★ コピーしないでください

これは後の5番に直結します。

Rather than copying, please point your (web) server configuration directly to those files (or create symlinks). During the renewal, /etc/letsencrypt/live is updated with the latest necessary files.

証明書ファイルをどこかにコピーして、そこを指すという書き方をすると、更新されても古いファイルを配り続けます。 /etc/letsencrypt/live/ を直接指してください。

私の設定（80番側）

server {
  listen 80 default_server;
  server_name mypowerstone.com www.mypowerstone.com;

  location /.well-known/acme-challenge/ {
    root /var/www/certbot;
  }

  location / {
    return 301 https://$host$request_uri;
  }
}

80番に来たものは全部HTTPSへ転送しますが、/.well-known/acme-challenge/ だけは例外にしています。ここを転送してしまうと、更新のときの確認ファイルが取りに来られません。

443番側は listen 443 ssl default_server; に http2 on; を添え、ssl_certificate に /etc/letsencrypt/live/<ドメイン>/fullchain.pem、ssl_certificate_key に同じ場所の privkey.pem を指定しています。

ネットで拾った設定に listen 443 ssl http2; と書いてあったら、それは古い形式です nginx公式は listen の http2 パラメータについて 「The parameter is deprecated, the http2 directive should be used instead.」 と書いています。 http2 を独立したディレクティブとして書く形は バージョン 1.25.1 からです。 動かないわけではありませんが、コピー元が古い可能性の目印にはなります。

リダイレクトを入れると、証明書の更新が壊れるのか

壊れません。 ここは直感に反します。

Let's Encrypt は、確認のときにリダイレクトを追います。

Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to "http:" or "https:", and only to ports 80 or 443. When redirected to an HTTPS URL, it does not validate certificates

転送先の証明書を検証しません。 つまり期限切れの証明書が刺さっている状態でも、更新のための確認は通ります。 そのように作られています。

ただし、80番を塞ぐのは致命的です。 リダイレクトの有無ではなく、80番に到達できるかどうかが条件です。

5. ★自動更新は、設定した日には確認できません

ここからが本題です。

期限切れのメールは、もう来ません

以前は、期限が近づくとLet's Encryptからメールが届きました。その仕組みは終了しています。

Since its inception, Let's Encrypt has been sending expiration notification emails to subscribers that have provided an email address to us via the ACME API. This service ended on June 4, 2025.

2025年6月4日で終了しています。「期限が近づくとメールが来ます」と書いてある解説記事は、現在は誤りです。

Let's Encrypt自身は、代わりに第三者の監視サービスを使うことを案内しています（同じ告知の中で、Red Sift Certificates Lite というサービスを名前で挙げています）。私は使っていないので、良し悪しは書けません。 公式が第三者のサービスを案内している、という事実だけ書いておきます。

つまり、自動更新が止まったとき、それを知らせてくれるものは既定では何もありません。 気づくのは、読者のブラウザに証明書エラーが出てからです。

更新が走るのは、残り30日を切ってから

certbot renew を実行しても、たいてい何も起きません。それが正常です。

This command attempts to renew any previously-obtained certificates which are ready for renewal. As of Certbot 4.0.0, a certificate is considered ready for renewal when less than 1/3rd of its lifetime remains. For certificates with a lifetime of 10 days or less, that threshold is 1/2 of the lifetime. Prior to Certbot 4.0.0 the threshold was a fixed 30 days.

90日の証明書なら、90日 ÷ 3 = 30日です。そして4.0.0より前は固定で30日でした。

certbot 4.0.0 以降   90日 × 1/3 = 30日
certbot 4.0.0 より前  固定 30日

既定の90日の証明書を使っているかぎり、どちらのルールでも同じ「残り30日」になります。 certbotのバージョンを気にする必要はありません。

Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action.

何度実行しても構いません。ふつうは何もしません。 だから「更新されない」と思ったとき、最初に疑うのは設定ではなく、まだ更新の時期ではないことです。

私の証明書は、2か月間 一度も更新されていませんでした

2026年8月23日に、自分の本番サーバーで確かめた結果です。

/etc/letsencrypt/archive/<ドメイン>/ には、発行のたびに番号が1つ増えたセットが積まれます。 1回目が cert1.pem / chain1.pem / fullchain1.pem / privkey1.pem の4つ、2回目が ～2.pem の4つ、という具合です。

私の環境には 1 のセットしかありませんでした。 つまり発行は1回、最初に取ったきりです。2 が現れていれば、それが更新の起きた証拠になります。

そして、私の記録には「自動更新設定済み」と書いてありました。

書いてあったことは嘘ではありません。 仕組みは設置してあり、コンテナは8週間動き続けています。ただ、設定してあることと、動いた実績があることは別でした。2か月のあいだ、この仕組みは一度も本番で試されていません。

残り30日を切るのは8月26日ごろです。 最初の更新はそこで初めて走ります。

設定した日に確かめる方法は、あります

--dry-run です。 さきほど「本番で叩く前に」と書いたものと同じコマンドを、設置後の点検にも使えます。

sudo certbot renew --dry-run

私の環境では Congratulations, all simulated renewals succeeded が返りました。これが読者にとっていちばん役に立つ点だと思っています。

• 本番の証明書に触りません（ディスクに保存しない、と公式が明記しています）
• 回数制限を消費しません（テスト用のサーバーを使うため）
• 更新の時期を待つ必要がありません

つまり、設置したその日に、更新の経路が通っているかだけを確かめられます。 更新が実際に成功するのは先の話でも、「80番に届くか」「ファイルを置ける場所が合っているか」は今日わかります。

⚠️ ログが空なのは、正常だからか、動いていないからか

私の構成には欠陥があります。正直に書きます。

certbot の実行に --quiet を付けています。成功しても何も出力しません。 その結果、8週間ぶんのログが1行しかありません。

Another instance of Certbot is already running.

これが8週間で出力された全部です。 しかも内容は「別のcertbotが動いているので今回はやめた」という、更新とは関係のない一時的な衝突でした。

皮肉なことに、このエラー1行が「ループが実際に動いている」ことを示す唯一の証拠になっています。正常に動いた回はすべて無言なので、記録に残っていません。

ログが空   ← 正常に「何もしなかった」のか
ログが空   ← そもそも実行されていないのか

この2つが区別できません。

これは、私がヘルスチェックが5日間 unhealthy だった記事で書いたのと同じ形の落とし穴です。あのときは赤い表示が鳴りっぱなしで意味を失っていました。今回は逆に、何も鳴らないことに意味が無くなっています。

表示が出ないことを、正常の証拠に使えません。 --quiet を付けるなら、別に確認の手段を持ってください。 私はまだ直していません。

自分で期限を見る

通知が来ない以上、自分で見に行く必要があります。

certbot 側には、証明書の一覧を出すサブコマンドがあります。

sudo certbot certificates

発行の回数は、さきほどのフォルダで数えられます。私はここで「1回だけ」だと分かりました。

sudo ls -l /etc/letsencrypt/archive/<ドメイン>/

証明書ファイルから直接期限を読む方法もあります。OpenSSLの公式ドキュメントによれば、-enddate は 「Prints out the expiry date of the certificate, that is the notAfter date.」、-checkend は 「checks if the certificate expires within the next arg seconds and exits nonzero if it will expire or zero if not」 です。

-checkend は終了コードで答えます。 つまり監視の仕組みに組み込めます。

自分の環境で測りました。期限まで33日の証明書に対して、30日の窓と60日の窓で聞いています。

$ openssl x509 -checkend 2592000 -noout -in cert.pem   # 30日
Certificate will not expire
exit=0

$ openssl x509 -checkend 5184000 -noout -in cert.pem   # 60日
Certificate will expire
exit=1

$ openssl x509 -enddate -noout -in cert.pem
notAfter=Sep 25 14:03:39 2026 GMT

同じ証明書が、窓の取り方で逆の答えを返しています。 33日後に切れるので、30日以内には切れず、60日以内には切れる。当然ですが、実際に両方を試さないと、秒数をいくつにすべきか決められません。

更新されても、nginx は読み直さないと使いません

証明書のファイルが新しくなることと、nginxが新しいほうを配ることは、別です。

私の構成では、nginxのコンテナが6時間ごとに設定を再読み込みしています。理由も設定ファイルにコメントとして書いてあります。リロードは軽く、接続も切れないので、ファイルを監視する仕組みを組むより単純だからです。

certbot には、更新が成功したときだけ実行される仕組み（--deploy-hook と /etc/letsencrypt/renewal-hooks/deploy）が公式に用意されています。私はそれを使わず、定期リロードで代用しています。 コンテナをまたいで実行するものを書くより、決まった時間に読み直すほうが単純だと判断しました。

私の構成は、公式のとおりではありません

certbot の公式ドキュメントは、自動更新についてこう書いています。

Most Certbot installations come with automatic renewals preconfigured. This is done by means of a scheduled task which runs certbot renew periodically.

そして確認場所として、crontab か systemd のタイマーを挙げています（/etc/crontab・/etc/cron.*/*・systemctl list-timers）。

私の構成は、そのどちらでもありません。

  certbot:
    image: certbot/certbot:latest
    volumes:
      - certbot_conf:/etc/letsencrypt
      - certbot_www:/var/www/certbot
    entrypoint: >
      sh -c 'trap exit TERM; while :; do certbot renew --webroot -w /var/www/certbot --quiet; sleep 12h & wait $$!; done'
    restart: unless-stopped

コンテナの中で12時間ごとに実行し続けているだけです。理由は単純で、コンテナには cron も systemd も入っていないからです。

この4行だけ補足します。3番と4番でやったことが、ここで繋がります。

nginxの設定で /.well-known/acme-challenge/ の root に /var/www/certbot を指定していたのは、ここに繋げるためでした。certbotが置いたファイルを、nginxが80番で配るという分担です。

素のUbuntuに certbot を入れたなら、公式の言うとおり、すでに何かが入っている可能性が高いです。 その場合、自分で何かを設置する前に、まず入っているものを確認してください。

systemctl list-timers
ls /etc/cron.d/

なお、実行の間隔について、Let's Encrypt は推奨は90日の証明書なら60日ごととしています。手動で設定する場合の例として公式が示しているのは 1日2回（0時と12時）＋最大3600秒のランダムな待ち時間という形です。ランダムにする理由も書かれています。

We ask that ACME clients perform routine renewals at random times to avoid spikes in traffic at set times of the day

私の12時間ごとは回数としては同じですが、ランダム化はしていません。

この作業をどこでやったか

ここまでの作業は、ConoHa VPS の2GBプランの上でやっています。サーバーの選び方や、2GBで足りるかどうかは別の記事に書きました。

→ VPSは2GBで足りるか — 個人開発のアプリを46日動かして実測

ドメインとHTTPSの手順そのものは、どのVPSでも変わりません。 違うのは、事業者側のファイアウォールの画面くらいです。

90日は、これからも90日とは限りません

証明書の有効期間について、Let's Encrypt の現在のFAQはこう書いています。

Our default certificates are valid for 90 days.

2026年8月時点の既定は90日です。ただし、これは恒久的な数字ではありません。

Our default certificate lifetimes will be going from 90 days down to 45 days over the next few years, as previously announced.

45日への短縮が予告されています。 また、希望すれば6日間（160時間）の証明書を選ぶこともできるようになっています。

「90日で切れる」と覚えるのではなく、「短くなっていく方向にある」と覚えるほうが安全です。短くなるほど、手で更新するという選択肢は現実的でなくなります。 自動更新が動いていることを確かめる話は、これから重くなります。

この手順が前提にしていること

私の環境ではそうだったけれど、あなたの環境ではそうとは限らないものを並べます。

まだ確かめていないこと

正直に書いておきます。以下はすべて2026年8月23日時点の状態です。

• 更新が本番で成功したところを、まだ一度も見ていません。 私の証明書の期限は2026年9月25日で、certbot が動き出すのは残り30日を切ってからなので、最初の更新は2026年8月26日ごろになります
• 更新後にnginxが新しい証明書を配るところも、当然まだ見ていません
• --quiet を外していません。 欠陥だと分かっていて、まだ直していません

この記事は、その結果が出る前に公開しています。 更新が実際に走ったかどうかは、/etc/letsencrypt/archive/ に 2 のセットが増えたかと、 期限が11月台に動いたかで分かります。確かめたら、この節に追記します。

まとめ

1. 80番と443番を開ける        80が無いと証明書が取れない
2. Aレコードを1本置く          待つのは「古いデータが消えるまで」
3. 証明書を取る                本番の前に必ず --dry-run
4. nginx に読ませる            fullchain.pem。コピーせず live/ を直接指す
5. 自動更新を確かめる          設定した日に確かめられるのは「経路が通ること」まで

鍵マークが付いた日は、まだ何も確認できていません。

自動更新が正しいかどうかが分かるのは、最初の更新が来る日です。 そして、その日が来たことを教えてくれるものは、もうありません。

私は自分のサイトで、それを2か月確かめていませんでした。確かめる方法は、最初の日からありました。

次にやること

HTTPSにしたあと、同じリダイレクトが別のものを壊すことがあります。私はそれで5日間、赤い表示を眺めていました。

→ docker ps が unhealthy なのにサイトは正常に動いていた

本番と開発で設定を書き分けている場合、書き分けたつもりが効いていないことがあります。

→ docker-compose.prod.yml が効かない — 本番が開発モード