Let's Encryptとは
Let's Encryptは、2015年に運用を開始した非営利の認証局（CA）で、無料でドメイン検証（DV）TLS証明書を発行しています。運営母体はカリフォルニア州の非営利法人ISRG（Internet Security Research Group）で、設立時にはMozilla、EFF（Electronic Frontier Foundation）、Cisco、Akamaiが支援し、その後Chrome（Google）、Facebook、IdenTrustなど多数の企業がスポンサー・技術協力に加わりました。
Let's Encryptが画期的だったのは「無料」という点よりも、証明書の申請・検証・発行・更新のすべてをACME（Automatic Certificate Management Environment）プロトコルでAPI化し、人手を介さずに完結させた点にあります。従来の商用CAでは、CSR（証明書署名要求）の作成、メールでの本人確認、証明書ファイルの手動配置といった作業が数十分〜数日かかっていましたが、ACME対応クライアント（certbot、acme.sh、lego、Caddyの内蔵ACMEなど）を使えば数秒〜数十秒で完結します。この自動化モデルが評価され、Let's Encryptの登場以降、Web全体のHTTPS化率は大きく上昇し、現在では主要ブラウザで読み込まれるページの大半がHTTPS経由になっています。
信頼の起点となるルート証明書は「ISRG Root X1」（RSA 4096ビット、自己署名）です。当初は主要OS・ブラウザの信頼ストアへの浸透が不十分だったため、老舗CAであるIdenTrustの「DST Root CA X3」からクロス署名を受けて互換性を確保していましたが、DST Root CA X3自体は2021年9月に有効期限切れとなり、以降はISRG Root X1が単独で（一部の古いAndroid端末向けにはIdenTrustの別ルートによるクロス署名を残しつつ）主要トラストストアに直接収録される体制に移行しています。またECDSA（P-384）ベースの「ISRG Root X2」も追加され、より軽量な証明書チェーンを組めるようになりました。
Let's Encryptの特徴
- 完全無料：証明書発行・更新に費用は一切かからない（寄付によって運営されている）
- 自動化：ACMEプロトコル（RFC 8555）による自動発行・更新
- 短い有効期間：90日間が標準（自動更新運用が前提）
- ドメイン検証（DV）のみ：HTTP-01、DNS-01、TLS-ALPN-01の3種類のチャレンジ方式に対応
- ワイルドカード対応：*.example.comの証明書もDNS-01チャレンジで発行可能
- 透明性：発行した証明書はすべてCT（Certificate Transparency）ログに記録され、第三者が監査可能
- 大規模実績：公開情報によれば累計発行数は数十億件規模に達しており、世界で最も利用されているCAの一つとされる
ACMEプロトコルの仕組み
ACMEは2019年にIETFでRFC 8555として標準化されたプロトコルで、クライアント（サーバー運用者側）とACMEサーバー（CA側）がHTTPS上のJSON API（JWS署名付きリクエスト）でやり取りし、以下の流れで証明書を発行します。
- アカウント登録：クライアントが鍵ペアを生成し、ACMEサーバーにアカウントを登録
- オーダー作成：発行したいドメイン名（identifier）を指定してオーダーを作成
- チャレンジの提示と応答：CAが「このドメインを本当に管理しているか」を確認するためのチャレンジを提示し、クライアントが応答を用意
- 検証：CA側のサーバーが実際にチャレンジ内容を確認（HTTPアクセス、DNS問い合わせ、TLS接続など）
- CSRの送信と証明書発行：検証に成功したらCSRを送信し、CAが証明書に署名して発行
チャレンジ方式の比較
| 方式 | 検証方法 | 主な用途・制約 |
|---|---|---|
| HTTP-01 | トークンを/.well-known/acme-challenge/に配置し、CAがHTTP（80番ポート）でアクセスして確認 |
最も手軽。ワイルドカード証明書には使用不可。80番ポートへの到達性が必須 |
| DNS-01 | 指定のTXTレコード（_acme-challenge.example.com）をDNSに追加して確認 |
ワイルドカード証明書の取得に必須。DNS APIが使えるプロバイダなら自動化しやすい |
| TLS-ALPN-01（RFC 8737） | 443番ポートへのTLS接続時にALPN拡張と自己署名証明書で確認 | 80番ポートを開けられないロードバランサ配下などで有効。対応クライアントは限定的 |
鍵アルゴリズムと2026年時点の推奨
Let's EncryptはcertbotのデフォルトではRSA 2048ビットの鍵を生成しますが、--key-type ecdsa指定でECDSA P-256（secp256r1）の鍵も選択できます。米国NIST（SP 800-57 Part 1）は、RSAであれば鍵長2048ビット以上、楕円曲線暗号であればP-256相当以上を2030年頃までの推奨強度としており、TLS証明書の鍵としてはこの水準が事実上の業界標準です。ECDSA P-256はRSA 2048ビットと同等以上の強度をより短い鍵長・小さい証明書サイズで実現できるため、TLSハンドシェイクの高速化やモバイル環境での負荷軽減を重視する場合に選ばれる傾向があります。一方でRSAは古い環境との互換性に優れるため、対応クライアントの幅を優先する場合はRSAが選ばれます。なお、SHA-1やRSA 1024ビット以下はNISTがすでに非推奨としており、Let's Encryptを含む主要CAは発行していません。長期的には量子計算機を見据えた耐量子暗号（ML-KEM、ML-DSAなど）への移行がNISTやNSA（CNSA 2.0）で議論されていますが、2026年時点でLet's EncryptがPQC証明書を標準発行するには至っていません。
証明書の有効期間と署名アルゴリズム
発行される証明書はX.509 v3形式（RFC 5280に準拠）で、署名アルゴリズムはSHA-256をベースとしたもの（RSA鍵ならSHA256withRSA、ECDSA鍵ならECDSA-SHA256系）が使われます。有効期間は標準で90日間です。短い有効期間には、(1) 秘密鍵が漏えいした際の被害期間を短縮できる、(2) 失効情報（CRL/OCSP）に依存せず「更新されなければ自動的に無効になる」運用に近づける、(3) 証明書関連の実装バグや旧式アルゴリズムの延命を防ぎやすい、といった意図があります。
実務でのLet's Encrypt活用例
開発環境やステージング環境、社内向けAPIサーバーのHTTPS化では、Let's Encryptとcertbotの組み合わせが定石になっています。代表的なコマンド例は以下の通りです。
# certbotのインストール（Ubuntu/Debian系）
sudo apt update
sudo apt install certbot python3-certbot-nginx
# Nginx用の証明書取得（Nginx設定ファイルも自動更新）
sudo certbot --nginx -d api.example.com -d www.example.com
# スタンドアロンモード（Webサーバーを一時停止して取得）
sudo certbot certonly --standalone -d api.example.com
# DNS-01チャレンジ（ワイルドカード証明書の取得）
sudo certbot certonly --manual --preferred-challenges dns \
-d '*.example.com' -d example.com
# ECDSA鍵で発行したい場合
sudo certbot certonly --key-type ecdsa --nginx -d example.com
# 証明書の更新テスト（実際には更新しないドライラン）
sudo certbot renew --dry-run
# 自動更新のタイマー状態を確認
sudo systemctl list-timers | grep certbot
CDN（Cloudflare、Amazon CloudFrontなど）の背後で運用する場合はDNS-01チャレンジを使い、CDN側のAPIトークンをcertbotのDNSプラグイン（certbot-dns-cloudflareなど）に渡すことで、証明書更新とDNSレコード操作を完全に自動化できます。Kubernetes環境ではcert-managerがACMEクライアントの役割を担い、Ingressリソースに応じて証明書を自動払い出しするのが一般的な構成です。
メリットとデメリット（注意点）
メリット
- 証明書取得・更新のコストがゼロで、複数ドメイン・サブドメインを持つ環境でもスケールしやすい
- ACME対応クライアントが豊富（certbot、acme.sh、lego、Caddy、Traefik、cert-managerなど）で、既存のインフラ自動化ツールに組み込みやすい
- 自動更新を前提とした短命証明書により、鍵漏えい時の被害範囲を限定できる
- ワイルドカード証明書にも対応しており、多数のサブドメインを1枚で運用できる
- 発行実績が豊富で、主要ブラウザ・OSの信頼ストアへの収録状況が安定している
デメリット・注意点
- DV証明書しか発行できない：組織の実在性を証明するOV（組織認証）やEV（拡張認証）証明書は発行できないため、金融機関や決済事業者などが求める組織実在証明が必要な用途には使えない
- 有効期間が短く運用負荷がある：90日ごとの更新が前提のため、自動更新の仕組みが壊れると気づかないままサイトがダウンするリスクがある
- レート制限がある：同一登録ドメインに対する新規証明書発行数などに制限があり、大量のサブドメインを一気に発行しようとすると制限に抵触することがある
- 賠償責任（ワランティ）の提供がない：多くの商用有償証明書には誤発行時の保証（ワランティ）が付帯するが、Let's Encryptは無償ゆえにそうした保証は基本的に提供していない
- 可用性の依存：ACMEサーバー側の障害やネットワーク分断時には更新自体ができなくなるため、更新期限に十分な余裕を持たせた運用が必要
混同されやすい用語・類似技術との違い
Let's Encrypt と 商用CA（DigiCert・GlobalSignなど）
どちらも認証局（CA）として機能する点は同じですが、Let's EncryptはDV証明書のみを無料・自動発行するのに対し、商用CAはDVに加えてOV・EV証明書、コードサイニング証明書、S/MIME証明書など幅広い製品を有償で提供し、専任サポートや誤発行時の賠償責任（ワランティ）を伴うのが一般的です。組織の実在性を示す必要がある場合や、長期の有効期間・手厚いサポートが必要な場合は商用CAが選択肢になります。
Let's Encrypt と 自己署名証明書（Self-Signed Certificate）
自己署名証明書は誰でも自分で発行できますが、ブラウザやOSの信頼ストアに登録されていないため「この接続は安全ではありません」という警告が表示されます。Let's Encryptの証明書はISRGという第三者機関が検証・発行しており、主要ブラウザ・OSに信頼ルートとして収録されているため、警告なしにHTTPS接続が確立できる点が決定的に異なります。社内限定の検証環境などを除き、公開Webサイトで自己署名証明書を使うことは推奨されません。
Let's Encrypt と 他の無料ACME対応CA（ZeroSSL・Buypass Go SSLなど）
ACMEプロトコル自体はオープンな標準（RFC 8555）であり、Let's Encrypt専用の技術ではありません。ZeroSSLやBuypassなど、同様にACMEでDV証明書を無料発行するCAも存在します。certbotなどのクライアントはデフォルトでLet's Encryptを向いていますが、設定変更で他のACME CAに切り替えることも可能です。「ACME＝Let's Encrypt」ではなく、ACMEはプロトコル、Let's Encryptはそれを採用する数あるCAの一つという関係を理解しておくと混同を避けられます。
DV・OV・EV証明書の違い
| 種別 | 検証内容 | Let's Encryptでの発行 |
|---|---|---|
| DV（ドメイン認証） | ドメインの管理権限のみを確認 | 可能（Let's Encryptの標準） |
| OV（組織認証） | 運営組織の法的実在性を書類等で確認 | 不可 |
| EV（拡張認証） | 組織の実在性をより厳格な手続きで確認 | 不可 |
TLS証明書とクライアント証明書（mTLS）の違い
Let's Encryptが発行するのは「サーバーが本物であること」をクライアントに証明するためのサーバー証明書です。これに対し、mTLS（相互TLS認証）で使われるクライアント証明書は「クライアント側が正当な相手であること」をサーバーに証明するためのもので、用途も発行プロセスも異なります。Let's Encryptはサーバー証明書の発行に特化しており、クライアント証明書やコードサイニング証明書の発行は行っていません。
自動更新の設定と運用のポイント
Let's Encryptを本番運用する上で最も重要なのは「自動更新が確実に動いているかを継続的に確認する」ことです。certbotをパッケージ経由でインストールすると、多くのディストリビューションでsystemdタイマーが自動的に設定されます。
# systemdタイマーの確認
sudo systemctl status certbot.timer
# 手動でcronを設定する場合の例（/etc/cron.d/certbot）
0 */12 * * * root certbot renew --quiet --post-hook "systemctl reload nginx"
# ARI（ACME Renewal Information）対応クライアントであれば
# CAが推奨する更新タイミングを自動で問い合わせて調整してくれる
運用上のポイントとして、(1) certbot renew --dry-runを定期的に実行し更新処理自体が壊れていないかを検証する、(2) 証明書の有効期限を外部の証明書監視サービスやNagios/Zabbix等の監視ツールでダブルチェックする、(3) 更新後に自動でWebサーバー・ロードバランサをリロードするフック（--post-hook）を必ず設定する、(4) 複数台構成では証明書とDNS更新の競合が起きないよう排他制御する、という4点を押さえておくと事故を防ぎやすくなります。
最新動向（2026年）
証明書の有効期間短縮の流れ
CA/Browser Forum（CAB Forum）では、AppleやGoogleなどブラウザベンダー主導で証明書の最大有効期間を段階的に短縮する方針が採択されています。現行の最大398日から、数年かけて100日程度、最終的には47日程度まで短縮する多段階のスケジュールが合意されており、2026年以降、商用証明書の世界でも「短命化・自動化」がLet's Encrypt型の運用モデルに近づいていく見通しです。Let's Encrypt自身はこの流れに先行する形で、より短い有効期間の証明書プロファイルを試験的に提供する取り組みも進めています。
ARI（ACME Renewal Information）の普及
ACMEプロトコルの拡張機能であるARIは、CA側が「この証明書はいつ頃更新するのが望ましいか」をクライアントに提示できるようにする仕組みです。証明書の失効（大規模な鍵漏えい対応など）が発生した際に、影響を受けるクライアントだけを前倒しで更新させるといった柔軟な運用が可能になり、対応クライアントの普及が進んでいます。
マルチパースペクティブ検証（Multi-Perspective Issuance Corroboration）
ドメイン検証を単一のネットワーク経路からだけでなく、地理的に離れた複数の観測拠点から実施することで、BGPハイジャックなど経路操作による不正な証明書発行を防ぐ「マルチパースペクティブ検証」がCAB Forumの要件として広がっています。Let's EncryptもこうしたMPIC（Multi-Perspective Issuance Corroboration）の考え方を取り入れた検証体制の強化を進めています。
耐量子暗号（PQC）への関心の高まり
NISTがML-KEM・ML-DSAなどの耐量子暗号アルゴリズムを標準化したことを受け、TLSエコシステム全体でPQC移行の検討が進んでいます。証明書レベルでのPQC対応はまだ実験段階ですが、鍵交換部分でハイブリッド方式（従来のECDHと耐量子アルゴリズムを併用）を採用するTLS実装が増えており、CA各社もロードマップの検討を始めています。Let's Encryptについても、標準運用としてのPQC証明書発行時期は2026年時点で明言されていません。
トラブル事例と対策
自動更新の失敗
症状：certbotのcronやsystemdタイマーが何らかの理由（設定変更・パッケージ更新・権限変更など）で動かなくなり、90日後に証明書が期限切れとなってサイトがダウンする。
対策：certbot renew --dry-runを定期実行して更新処理そのものを検証する、外部の証明書監視サービスで有効期限を独立して監視する、更新失敗時にSlackやメールへ通知する仕組みを組み込む。
レート制限への抵触
症状：CI/CDのミスや検証作業の繰り返しで同一ドメインに対する証明書発行を短時間に何度も試み、レート制限に達して発行が一時的にできなくなる。
対策：検証作業は本番用エンドポイントではなくステージング環境（--stagingオプション）を使う。レート制限の具体的な数値や条件は変更されることがあるため、作業前にLet's Encrypt公式ドキュメントの最新のレート制限ページを確認する。
DNS-01チャレンジの反映遅延
症状：ワイルドカード証明書取得のためTXTレコードを追加したが、DNSの伝播（TTLやセカンダリDNSへの反映）が遅れて検証がタイムアウトする。
対策：DNSプラグイン（certbot-dns-*系）を使い、レコード追加後に伝播確認を自動で待機させる。TTLを短めに設定しておく、あるいはDNS APIが安定して即時反映されるプロバイダを選ぶ。
大量失効イベントへの対応漏れ
症状：CA側で発行プロセスにバグが見つかるなどして、対象となった証明書が予告なく前倒しで失効させられ、対応しないままサイトがダウンする。
対策：Let's Encryptからの通知（メール・APIのARI情報）を監視対象に含め、失効告知が出た場合は速やかに再発行できるよう、証明書発行の自動化パイプラインを事前に整備しておく。
📝 関連ブログ記事
よくある質問（FAQ）
Q. Let's Encryptとは何ですか？
Let's Encryptは、ISRG（Internet Security Research Group）が運営する非営利の認証局（CA）です。ACMEプロトコルを使って無料でDV（ドメイン認証）TLS/SSL証明書を自動発行・更新します。2025年時点で世界中の数億のWebサイトで使用されています。
Q. Let's Encryptの証明書は有効期間が短いのはなぜですか？
Let's Encryptの証明書有効期間は90日です（一般的な商用証明書は1〜2年）。短い有効期間は自動更新を促し、セキュリティインシデント発生時に鍵の置き換えを迅速化するためです。Certbotを使えば60日ごとに自動更新するcronを設定できます。
Q. Let's EncryptとNginxを使った証明書取得方法は？
sudo apt install certbot python3-certbot-nginx; sudo certbot --nginx -d example.com のコマンドで自動的に証明書を取得しNginxの設定も更新できます。自動更新はsudo systemctl enable certbot.timer で有効化できます。また、Cloudflare等のCDNを使う場合はDNS-01チャレンジで取得できます。
Q. 2025年以降のLet's Encryptの動向は？
CA/Browser Forumでは、Apple・Googleなどブラウザベンダー主導で証明書の最大有効期間を段階的に短縮する方針が採択されており、最終的には47日程度まで短縮する多段階スケジュールが合意されています。実現すれば自動更新の仕組みがより重要になります。またARI（ACME Renewal Information）など、更新タイミングを最適化する新機能の普及も進んでいます。
Q. Let's Encryptにはどんなデメリットや制約がありますか？
最大のデメリットはDV（ドメイン認証）証明書しか発行できないことです。組織の実在性を証明するOV証明書やEV証明書が必要な金融機関・決済事業者などの用途には使えません。また有効期間が90日と短いため自動更新の仕組みが前提となり、誤発行時の賠償責任（ワランティ）も基本的に提供されないため、重要システムでは監視体制の整備が欠かせません。
Q. Let's EncryptとZeroSSLなど他の無料ACME CAはどう違いますか？
ACMEはIETFで標準化されたオープンなプロトコル（RFC 8555）であり、Let's Encrypt専用の技術ではありません。ZeroSSLやBuypass Go SSLなど、同様にACMEでDV証明書を無料発行するCAも存在し、certbot等のクライアントは設定変更でこれらに切り替えることも可能です。「ACME＝Let's Encrypt」ではなく、ACMEはプロトコル、Let's Encryptはそれを採用するCAの一つという関係です。