用語辞典13分で読める

Let's Encrypt とは — 無料でHTTPSを自動化する証明書認証局

Let's Encryptは、無料でTLS証明書を発行する認証局です。ACMEで発行と更新を自動化でき、証明書は90日と短命です。仕組み、certbotやCaddyでの導入、更新停止による失効を防ぐ運用を解説します。

本文を読む
公開日
更新日
目次

「HTTPS にしたいけど証明書って高くて面倒そう」。その前提を変えたのが Let's Encrypt です。無料で、しかも発行から更新まで自動化できる仕組みを、防御目線で解説します。

仕組み:ドメイン所有を「自動で」確認する(ACME)

従来の証明書は、申請して、本人確認の書類を出して、発行されるまで待つという手作業でした。Let's Encrypt は ACME(Automatic Certificate Management Environment) というプロトコルで、この一連を機械同士のやり取りに置き換えます。

① チャレンジ:CAが「このドメインの管理者なら、指定の場所にこの値を置けるはず」と課題を出す
② 証明:サーバーが Web パス(HTTP-01)か DNS レコード(DNS-01)に値を設置
③ 発行:CAが確認できたら証明書を発行。期限が近づくと②〜③を自動で繰り返す
ACMEの基本:サーバーが『ドメインの管理者である証明』をその場で提示し、自動で証明書を受け取る。

ポイントは、確認するのが**「ドメインの管理権」だけ**(ドメイン認証=DV)だということ。企業の実在性までは確認しないので、手続きが軽く、完全に自動化できます。暗号化そのものの強度は有料証明書と変わりません。

有効期間が90日なのは、自動更新を前提にしているため

Let's Encrypt の証明書は有効期限が90日です。短いのには理由があります。

1

鍵漏えいの被害を短く区切る

万一サーバーの秘密鍵が漏れても、証明書の有効期間が短ければ悪用できる期間が短くなります。失効処理が間に合わなくても、自然に期限切れになります。

2

自動更新を標準にする

90日では手動更新は現実的でないため、運用者は自動化せざるを得ません。これが業界全体を「証明書は自動で回すもの」へ押し上げました。実際、更新ツールは期限の約30日前から自動で更新を試みます。

3

だから運用で重要なのは監視

自動更新は、cron が壊れた・権限が変わった・ドメインの確認が通らなくなった、といった理由で気づかないうちに止まります。止まったことに気づかないまま90日が過ぎると失効します。更新の成否と残り日数を監視しておくのが基本の対策です。

当サイトの視点:証明書を意識しない運用(自動TLS)

当サイトは Caddy という Web サーバーで動いており、ドメインを向けるだけで Let's Encrypt の証明書を自動発行・自動更新しています(設定ファイルに証明書の話はほぼ書きません)。「証明書を意識しなくていい状態」が理想で、人が手で触る箇所が少ないほど、入れ替え忘れによる失効事故は起きません。

逆に、certbot を cron で回す構成なら、その cron が動いているかまで含めて仕組みで監視するのが安全です。

有効期間はこれから短くなる(2026年10月時点の予定)

90日は今の標準ですが、Let's Encrypt は段階的に短くすると公表しています。ブラウザ各社と認証局でつくる業界団体(CA/Browser Forum)も、ブラウザに信頼される証明書の最大有効期間を2026年3月から順に縮め、2029年3月に47日にすると決めています。

時期変更の内容
2026年10月時点有効期間90日
2026年5月13日〜希望者向けの tlsserver プロファイルで45日の証明書を選べる
2027年2月10日〜標準(classic プロファイル)が64日に。ドメイン確認結果の再利用期間は10日に
2028年2月16日〜標準が45日に。ドメイン確認結果の再利用期間は7時間に

このほか、有効期間が約6日(160時間)の shortlived プロファイルも2026年1月から一般提供されています。IP アドレス向けの証明書は、この短い証明書でだけ発行されます。

運用で気をつけるのは、更新の間隔を「60日ごと」のように決め打ちしないことです。Let's Encrypt は、更新の時期をサーバーから知らせる仕組み(ARI:ACME Renewal Information)に対応したクライアントを使うこと、対応していない場合は有効期間の3分の2が過ぎた時点で更新することを勧めています。cron で日数を固定している構成は、期間が短くなった時点で失効の原因になります。

2025年に終わったこと:OCSP と期限切れ通知メール

Let's Encrypt は2025年に、次の2つをやめています。古い記事や設定を参考にしている場合は注意してください。

  • OCSP(証明書が失効していないかをその都度問い合わせる仕組み):2025年5月7日に証明書から OCSP の URL を外し、8月6日に応答サーバーを停止しました。失効の確認は CRL(失効した証明書の一覧)に一本化されています。理由の1つは、OCSP では認証局が「どの IP アドレスの人がどのサイトを見たか」を知り得てしまうことでした。
  • 期限切れの通知メール:2025年6月4日に送信を終了しました。以前は期限が近づくとメールが届きましたが、今は届きません。期限の監視は自分で用意する必要があります。

一番多い事故:更新が止まって「失効」

HTTPS まわりで最も多いトラブルは、攻撃ではなく証明書の失効です。失効するとブラウザが大きな警告を出し、利用者はほぼ確実に離脱します。原因は「更新の自動化が壊れていたのに気づかなかった」がほとんど。

だからこそ、自分のサイトの証明書の有効期限を定期的に見る仕組みを持つべきです。当サイトのサイト総合セキュリティ診断は、所有を確認したあなたのサイトの TLS 証明書(残り日数・失効・古いプロトコル)を他の項目とまとめて点検します。証明書の更新を自動化したうえで、その自動化が動いているかを外から確かめる。この2つを組み合わせれば、失効事故はほぼ確実に防げます。

ドメインの確認方法(チャレンジ)の違い

ACME でドメインの管理権を示す方法は3種類あります。環境に合うものを選びます。

方式何を置くかワイルドカード証明書向いている場面
HTTP-01Web サーバーの決まったパスにファイル不可80番ポートを外から受けられる、ふつうの Web サーバー
DNS-01DNS に TXT レコード可*.example.com が必要、サーバーを外に公開していない
TLS-ALPN-01443番ポートの TLS 接続で応答不可大規模なホスティングやリバースプロキシ

DNS-01 を自動化するには、DNS を書き換えられる API キーをサーバーに置くことになります。このキーが漏れるとドメインの設定を書き換えられるので、権限を TXT レコードの操作だけに絞れる DNS サービスを選び、キーの置き場所を限定します。

自分のサイトで確認する方法

1

ブラウザで発行元と期限を見る

アドレスバーの鍵アイコンから証明書を開くと、発行者(Issuer)の組織名と有効期限が分かります。組織名が Let's Encrypt なら、この記事の内容が当てはまります。
2

更新が自動で動いているかを見る

certbot を使っているなら、certbot certificates で期限を、certbot renew --dry-run で更新の試運転を確認できます。systemd の環境では systemctl list-timers に certbot のタイマーがあるかも見ます。Caddy は起動ログに証明書の取得・更新の記録が出ます。
3

意図しない証明書が出ていないか見る

ブラウザに信頼される証明書は、Certificate Transparency(CT)という公開ログに記録されます。crt.sh などの CT 検索で自分のドメインを調べると、自分が知らない証明書が発行されていないかを確かめられます。
4

発行できる認証局を DNS で絞る

DNS に CAA レコードを置くと、自分のドメインの証明書を発行できる認証局を指定できます。Let's Encrypt だけを使っているなら、Let's Encrypt だけを許可しておきます。
5

外から残り日数を監視する

通知メールが終わった今は、外から残り日数を定期的に確かめる仕組みが必要です。当サイトの サイト総合セキュリティ診断 でも、証明書の残り日数と古いプロトコルを点検できます。

具体例:2021年のルート証明書の期限切れ

証明書は、信頼の起点となる「ルート証明書」から順につながって検証されます。Let's Encrypt の証明書は当初、別の認証局のルート証明書(DST Root CA X3)に連なる形で信頼されていましたが、このルート証明書が2021年9月30日に期限を迎えました。

Let's Encrypt 自身のルート証明書(ISRG Root X1)を信頼していない古い機器やソフトでは、この日から Let's Encrypt を使うサイトで証明書の警告が出るようになりました(古い Android は特別な対応で引き続き使えました)。サイト側の証明書は正しく更新されていても、利用者側の機器が古いと接続できなくなる、という例です。

古い機器から接続される API やシステムを運用しているなら、Let's Encrypt の告知を購読し、中間証明書やルート証明書の切り替えに備えます。中間証明書を設定ファイルに固定で書き込まず、ACME クライアントが受け取ったものをそのまま使うのが Let's Encrypt の推奨です。

次に読む

出典(一次情報)

  • Let's Encrypt 公式ブログ(2025年12月2日、有効期間を45日へ短縮する計画) — letsencrypt.org(64日・45日への移行日、確認結果の再利用期間、ARI の推奨)
  • Let's Encrypt 公式ブログ(2026年1月15日、6日証明書と IP アドレス証明書の一般提供) — letsencrypt.org
  • Let's Encrypt 公式ブログ(2024年12月5日、OCSP の提供終了) — letsencrypt.org(OCSP URL の削除と応答サーバー停止の日付)
  • Let's Encrypt 公式ブログ(2025年1月22日、期限切れ通知メールの終了) — letsencrypt.org
  • Let's Encrypt「Challenge Types」 — letsencrypt.org
  • Let's Encrypt「Integration Guide」 — letsencrypt.org(更新時期、中間証明書を固定しない)
  • Let's Encrypt「DST Root CA X3 Expiration (September 2021)」 — letsencrypt.org
  • CA/Browser Forum「Ballot SC081v3」(2025年4月11日可決) — cabforum.org(公的な証明書の最大有効期間を2029年3月に47日へ)

よくある質問

QLet's Encrypt の証明書は本当に無料で、有料の証明書と何が違いますか?
A

発行・更新ともに無料です。Let's Encrypt はドメイン認証(DV)のみを行い、『このドメインを管理している人か』だけを自動で確認します。暗号化の強さは有料証明書と同じで、ブラウザの鍵マークも同じように表示されます。違いは、企業の実在性を確認する OV/EV の手続きが無いことと、保証(warranty)が付かないことです。個人サイトや小規模サービスの HTTPS 化には、無料の DV 証明書で十分なケースがほとんどです。

Q証明書の有効期限が90日と短いのはなぜですか?短いと困りませんか?
A

短いのは弱点ではなく設計です。万一秘密鍵が漏れても悪用できる期間を短く区切れること、そして『自動更新が当たり前』の文化を強制できることが狙いです。困らないために、更新は自動化します(多くのツールが期限の30日前から自動で更新します)。手動で年1回入れ替える運用こそ、入れ替えを忘れて失効する事故の原因になりやすいのです。

Q導入にはどんなツールを使いますか?
A

代表的なのは certbot(Apache/Nginx 向けに広く使われる)と Caddy(設定なしで自動的に HTTPS 化・自動更新まで行う Web サーバー)です。ほかに acme.sh や Traefik なども ACME に対応しています。ワイルドカード証明書(*.example.com)が必要なら、DNS-01 という方式で DNS レコードに確認用の値を置いて取得します。

QLet's Encrypt の証明書の有効期限はどう確認しますか?
A

ブラウザのアドレスバーの鍵アイコンから証明書を開くと、有効期限と発行者が表示されます。サーバー上では、certbot なら certbot certificates で一覧と期限を確認できます。2025年6月で期限切れの通知メールは終了しているので、外から残り日数を定期的に確かめる仕組みを用意してください。

Q有効期間が45日になるのはいつからですか?
A

Let's Encrypt の発表では、標準の証明書は2027年2月10日から64日、2028年2月16日から45日になります。2026年5月13日からは、希望すれば tlsserver プロファイルで45日の証明書を先に使えます。更新の時期をサーバーが知らせる ARI に対応した ACME クライアントを使うか、有効期間の3分の2が過ぎた時点で更新する設定にしておけば、短くなっても対応できます。

QOCSP が終わって何か対応は必要ですか?
A

一般的な Web サイトでは、特に作業はいりません。Let's Encrypt は2025年5月に証明書から OCSP の URL を外し、8月に応答サーバーを止め、失効の確認を CRL に移しました。OCSP Must-Staple を指定していた設定や、OCSP の URL があることを前提にした独自のクライアントを使っている場合は、設定の見直しが必要です。