LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

Let’s Encryptで取った証明書が、気づかないうちに期限切れになっていた。有料の証明書から切り替えたいものの、商用のサイトで使ってよいのか判断がつかない——。Webサービスを運用する現場では、こうした迷いが起こりがちです。Let’s Encryptは、非営利団体のISRG（Internet Security Research Group）が運営する認証局で、Webサイトの通信を暗号化するSSL/TLSのサーバー証明書を無料で発行しています。

申請から更新までを自動化しやすい一方、万能ではなく、組織の実在を示す証明書は発行されず、問い合わせ窓口もありません。OCSP（証明書が失効していないかを認証局に問い合わせる仕組み）の終了など、運用に響く変更も続いています。本記事では、Webサービスを運用するエンジニアや情報システム部門の方に向けて、発行の仕組み、有料の証明書との違い、仕様の変更と日付、つまずきやすい点、そして外部に頼むときに確認したい点を整理します。

Let’s Encryptとは

Let’s Encryptが発行するのは、DV（ドメイン認証）証明書だけです。申請者がドメインを管理していることだけを確かめる種類で、OV（組織認証）やEV（拡張認証）は、発行を自動化できないため扱っていません。料金はかからず、運営は寄付やスポンサーの支援でまかなわれています。

証明書の有効期間は標準で90日で、6日前後で切れる短い証明書も選べますが、期間を個別に延ばすことはできません。更新は、90日の証明書なら60日ごと、6日の証明書なら3日ごとが目安です。^*1 秘密鍵は利用者のサーバーで作り、Let’s Encryptが預かることはありません。

メールサーバーなどWeb以外のサーバーにも使えますが、電子メールの暗号化やコード署名（プログラムの作成者を示す署名）の証明書は対象外です。発行には、IETF（インターネットの技術を標準化する団体）がRFC 8555として定めたACME（証明書の発行と更新を自動で行う通信の決まり）を使います。

証明書が発行される仕組み

ACMEによる発行は、おおまかに3つの段階で進みます。ACMEクライアント（Certbotなど、認証局とやり取りするソフトウェア）がドメイン名を伝えて注文を作り、認証局が出す課題（チャレンジ）に答えてドメインの管理を示し、最後に署名要求を送って証明書を受け取ります。

チャレンジの方式は3つです。HTTP-01は80番ポートでしか検証できず、ワイルドカード証明書（*.example.comのようにサブドメインをまとめて守る証明書）は、_acme-challengeという名前のTXTレコードを登録するDNS-01でしか取れません。^*2 TLS-ALPN-01は443番ポートのTLSで検証する方式ですが、対応するクライアントが限られます。

一度検証に通ると、その結果はしばらく使い回されます。標準のclassicプロファイル（発行の条件と証明書の中身をまとめた設定）では30日です。^*3 そのため、DNSやファイアウォールを変えた直後は、次の検証で初めて失敗に気づくことがあります。

手順を試すときは、発行数の上限に当たりにくいステージング環境（試験用の発行環境）を使います。Certbotであれば、–test-cert や –dry-run を付けます。

# ステージング環境で発行を試す（ブラウザには信頼されない証明書が出る）
sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com --test-cert

# 更新の処理だけを試す（証明書は保存されない）
sudo certbot renew --dry-run

有料の証明書との違い

有料の証明書との違いは、価格よりも証明できる範囲に表れます。Let’s Encryptはドメインの管理しか証明しないため、証明書に会社名を載せて組織の実在を示せません。取引先の調達基準や社内の規程でOV・EVを求められているサイトでは、条件を満たせません。

支援の受け方も違います。Let’s Encryptは少人数の体制のため、利用者への直接の支援は行っていません。頼り先は公開の文書と利用者どうしのフォーラムで、夜間に更新が止まっても問い合わせる先はありません。

仕様の変更と日付

2025年以降に効いてくる主な変更は、次の図のとおりです。

1つ目は、有効期限の通知メールの終了です。Let’s Encryptは2025年6月4日で、期限の近づいた利用者への通知メールをやめました。^*4 多くの利用者が自動更新を整えたことや、数百万件のメールアドレスを持ち続けなければならないことが理由です。このメールに頼っていた運用は、監視サービスや自前の監視に置き換えます。

2つ目は、OCSPの終了です。2025年5月7日に証明書からOCSPのURLが外れ、同年8月6日には応答サーバーが止まりました。^*5 失効の情報はCRLで配られます。ブラウザでWebサイトを見る人には影響しないとされる一方、VPNなどブラウザ以外のソフトウェアは、OCSPのURLが無い証明書でも正しく動くかを確かめるよう求めています。

3つ目は、クライアント認証の用途の廃止です。証明書の使いみちを示すEKU（拡張鍵用途）から、標準のclassicプロファイルでは2026年2月11日にクライアント認証が外れ、移行用のtlsclientプロファイルも同年7月8日に提供を終えています。^*6 Google Chromeが、サーバー認証とクライアント認証を別々の認証局の体系に分けるよう求めたためです。

4つ目が、有効期間の短縮です。CA/Browser Forum（認証局とブラウザの開発元でつくる業界団体）の規則では、公開のサーバー証明書の有効期間の上限が、2026年3月15日以降の発行分で200日、2027年3月15日以降で100日、2029年3月15日以降で47日と段階的に縮みます。^*7 Let’s Encryptは、標準のclassicプロファイルを2027年2月10日に64日、2028年2月16日に45日へ切り替えると発表しています。先に試せるtlsserverプロファイルは、2026年5月13日から45日の証明書になりました。^*8

有効期間が縮むと、決め打ちの間隔で更新する設定は通用しません。Let’s Encryptは、60日ごとの更新では45日の証明書に間に合わないとして、ARI（認証局が更新の時期を知らせる仕組み）か、有効期間の3分の2ほどが過ぎた時点での更新を勧めています。^*8 自動化の組み立て方は「SSL証明書の短命化、更新自動化を外注で対応」で扱っています。

向いている場面・向いていない場面

向いているのは、ドメイン名で公開するWebサイトやAPIのうち、更新の自動化と監視を自分たちで回せるものです。サブドメインの多いサービスや、検証環境をいくつも立ち上げる開発の現場では、手作業の申請が要らない点が生きます。1枚に載せられる名前は、classicプロファイルで100までです。^*3

インターネットに公開していないサーバーでも、DNS-01ならDNSの記録だけで検証できるため、証明書を取れます。ただし、次の節のとおり、ドメイン名は誰でも見られる記録に載ります。

向いていないのは、OV・EVを条件にしている取引や、社員の端末や機器を証明書で認証する仕組みです。社内向けの認証には、プライベート認証局（自社で運営する認証局）が合います。証明書の台帳管理は「証明書管理(PKI)システム」で扱っています。

つまずきやすい点

1つ目は、発行数の上限（レート制限）です。主なものは次のとおりです。^*9

• 登録ドメイン（example.comのように、事業者から買ったドメイン）ごとに、7日間に50枚まで
• まったく同じ名前の組み合わせの証明書は、7日間に5枚まで
• 1つのアカウントで、同じ名前の検証に失敗できるのは1時間に5回まで
• 1つのアカウントで作れる注文は、3時間に300件まで

同じ名前の組み合わせの上限は、原因が分からないままクライアントを入れ直したり、デプロイのたびに設定を消したりすると当たりがちです。上限は一時的に解除してもらえず、証明書を失効させても枠は戻りません。なお、ARIで調整された更新は、すべての上限の対象外です。

2つ目は、ドメイン名の公開です。発行した証明書はCTログ（誰でも見られる証明書の発行記録）に登録され、間もなくログを巡回するプログラムがそのドメインへアクセスしてくることがあります。社内向けのホスト名や公開前のサービス名を載せると、名前が外部から見えます。

3つ目は、DNS-01で使うAPIの認証情報です。DNS全体を書き換えられる認証情報をWebサーバーに置くと、乗っ取られたときの被害が広がります。Let’s Encryptは、権限を絞るか、検証を別のサーバーで行って証明書を配る形を勧めています。

4つ目は、CAAレコード（証明書を発行してよい認証局を指定するDNSの記録）です。設定が無ければ、公開の認証局はどこでも検証に通れば発行できます。Let’s Encryptに限るなら1行目、自社のACMEアカウントからの申請だけに絞るならaccounturiを付けた2行目のように書きます。^*10

; Let's Encryptだけに発行を許す
example.com.  IN  CAA  0 issue "letsencrypt.org"

; さらに、特定のACMEアカウントからの申請だけに絞る（末尾の数字はアカウントID）
example.com.  IN  CAA  0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"

別の認証局だけを許すCAAレコードが残っていると、発行は失敗します。また、中間証明書は複数を入れ替えながら使われるため、特定の中間証明書を決め打ちで組み込む設定は避けます。チェーンの組み立ては「証明書チェーンの仕組み」で扱っています。

発行された証明書は、次のコマンドで発行元、有効期間、CRLの配布先、EKUを確かめられます。

# サーバーが実際に返している証明書を取り出して中身を表示する（OpenSSL 1.1.1以降）
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates -ext crlDistributionPoints,extendedKeyUsage

この確認を定期的に回し、期限までの日数が減ったら通知するようにしておくと、通知メールの代わりになります。

外部に委託するときに確認しておきたい点

Let’s Encryptの導入を外部に頼むときは、3つの点を確かめておくと比べやすくなります。第一に、チャレンジの方式の選び方です。HTTP-01とDNS-01のどちらを使うか、ロードバランサーやCDNの手前でどう検証を通すか、DNSの認証情報をどこに置くかを説明できるかを見ます。

第二に、更新が止まったときの手当てです。有効期限の監視、失敗の通知、誰がどの手順で切り分けるかまで、運用の設計に入っているかを確かめます。問い合わせ先の無い認証局なので、切り分けの手順が委託先の手元にあることが前提です。

第三に、変更の追いかけ方です。日付の決まった変更はこれからも続くため、Let’s Encryptの告知を誰が読み、いつ設定に反映するのかを保守の範囲に含めます。社内の機器やVPNでクライアント認証やOCSPに頼っている箇所の棚卸しも依頼に入れておくと、切り替えた後に思わぬところで止まる事態を防げます。

依頼の前には、ドメインと証明書の一覧、発行元と更新の方法、証明書を置いている機器、DNSの管理者を社内でまとめておくと、見積もりの前提がそろいます。

まとめ：Let’s Encryptで確かめておきたい3つの点

Let’s Encryptを商用で使ううえで、確かめておきたい点は3つです。第一に、DVの証明書だけで取引や社内の規程の条件を満たせるかを確かめること。第二に、通知メールもOCSPも無い前提で、更新の自動化と有効期限の監視を用意すること。第三に、日付の決まった変更を保守の中で追いかけることです。この3点を踏まえておけば、「無料だから入れたのに、ある朝サイトに警告が出ていた」という事態を避けやすくなります。チャレンジの方式の選び方や更新の仕組みづくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Let’s Encrypt「FAQ」（https://letsencrypt.org/docs/faq/）。出典：Let’s Encrypt「FAQ」（最終更新2025年4月28日）。DV証明書のみの発行とOV・EVを発行しない理由、直接の支援を行わないこと、有効期間（標準90日・6日の短期証明書）と推奨の更新間隔、秘密鍵を預からないこと、CTログへの登録、更新の実行時刻を分散させる勧めを参照（2026年10月確認）
2. *2　参考：Let’s Encrypt「Challenge Types」（https://letsencrypt.org/docs/challenge-types/）。出典：Let’s Encrypt「Challenge Types」（最終更新2026年2月12日）。HTTP-01（80番ポートのみ・ワイルドカード不可）、DNS-01（ワイルドカード可・非公開サーバーの検証可・IPアドレス不可・API認証情報の扱い）、TLS-ALPN-01（RFC 8737・443番ポート）の説明を参照（2026年10月確認）
3. *3　参考：Let’s Encrypt「Profiles」（https://letsencrypt.org/docs/profiles/）。出典：Let’s Encrypt「Profiles」（最終更新2026年9月8日）。classic（検証結果の再利用30日・有効期間90日・名前の上限100）、tlsserver（有効期間45日）、shortlived（有効期間160時間・IPアドレス可）、tlsclientの提供終了（2026年7月8日）を参照（2026年10月確認）
4. *4　参考：Let’s Encrypt「Ending Support for Expiration Notification Emails」（2025年1月22日）（https://letsencrypt.org/2025/01/22/ending-expiration-emails/）。出典：Let’s Encrypt公式ブログ。有効期限の通知メールを2025年6月4日で終了すること、その理由を参照（2026年10月確認）
5. *5　参考：Let’s Encrypt「Ending OCSP Support in 2025」（2024年12月5日）（https://letsencrypt.org/2024/12/05/ending-ocsp/）。出典：Let’s Encrypt公式ブログ。2025年5月7日のOCSP URLの削除、2025年8月6日のOCSP応答サーバーの停止、ブラウザ以外のソフトウェアへの影響の注意を参照（2026年10月確認）
6. *6　参考：Let’s Encrypt「Ending TLS Client Authentication Certificate Support in 2026」（2025年5月14日、2026年3月16日更新）（https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/）。出典：Let’s Encrypt公式ブログ。classicプロファイルからのクライアント認証EKUの削除（2026年2月11日）、tlsclientプロファイルの終了（2026年7月8日）、Google Chromeのルートプログラムの要件、プライベート認証局の勧めを参照（2026年10月確認）
7. *7　参考：CA/Browser Forum「Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates」6.3.2（https://github.com/cabforum/servercert/blob/main/docs/BR.md）。出典：CA/Browser Forum TLS Baseline Requirements（Version 2.3.0）6.3.2。2026年3月15日以降200日、2027年3月15日以降100日、2029年3月15日以降47日の有効期間の上限を参照。2025年4月11日に可決したBallot SC-081v3（https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/）で定められた（2026年10月確認）
8. *8　参考：Let’s Encrypt「Decreasing Certificate Lifetimes to 45 Days」（2025年12月2日）（https://letsencrypt.org/2025/12/02/from-90-to-45/）。出典：Let’s Encrypt公式ブログ。tlsserverプロファイルの45日化（2026年5月13日）、classicプロファイルの64日化（2027年2月10日）と45日化（2028年2月16日）、60日の決め打ち更新では足りないこと、ARIと有効期間の3分の2での更新の勧めを参照（2026年10月確認）
9. *9　参考：Let’s Encrypt「Rate Limits」（https://letsencrypt.org/docs/rate-limits/）。出典：Let’s Encrypt「Rate Limits」（最終更新2026年8月5日）。登録ドメインごとの発行数、同一の名前の組み合わせの発行数、検証の失敗、アカウントごとの注文数の上限、失効させても枠が戻らないこと、ARIによる更新の適用除外を参照（2026年10月確認）
10. *10　参考：Let’s Encrypt「Certificate Authority Authorization (CAA)」（https://letsencrypt.org/docs/caa/）。出典：Let’s Encrypt「Certificate Authority Authorization (CAA)」。CAAレコードの書式、Let’s Encryptの識別名 letsencrypt.org、accounturiパラメータとアカウントURIの形を参照。CAAの規格はRFC 8659（2026年10月確認）
11. *11　参考：Let’s Encrypt「Policy and Legal Repository」（https://letsencrypt.org/repository/）。出典：Let’s Encrypt「Policy and Legal Repository」。Let’s Encrypt Subscriber Agreement v1.8（2026年7月6日）を参照（2026年10月確認）
12. *12　参考：Let’s Encrypt「Staging Environment」（https://letsencrypt.org/docs/staging-environment/）。出典：Let’s Encrypt「Staging Environment」（最終更新2026年4月10日）。Certbotの –test-cert と –dry-run、アカウントが環境ごとに別であること、ステージング環境の上限値を参照（2026年10月確認）

Tweet