HTTPS と証明書の基本：守られること・守られないことと、有効期間 200 日（2026年3月から）

「鍵マークが付いていれば安全」とは言えません。総務省は、ブラウザーのアドレスに鍵マークが出ているのに、フィッシングサイト（本物のふりをして、パスワードなどを盗むサイト）だった、というケースが増えていると書いています。HTTPS（通信を暗号化した Web の通信）で守られるのは、ブラウザーとサーバーのあいだを運ばれている中身です。サイトが良いサイトかどうかまでは、鍵マークは示しません。

もう一つの「証明書の期限が短くなる」は、これから先の話ではなく、すでに始まっています。公に信頼される TLS サーバー証明書の最大の有効期間は、2026年3月15日以降に発行する証明書から 200 日までになりました（それより前に発行する分は 398 日まで）。100 日・47 日への短縮はこの先に決まっている予定で、この記事では本文の中で扱います。

この記事は、Web サイトやアプリを作り始めた初心者〜若手の人に向けて、HTTPS と証明書の基本（何が守られて、何が守られないか）と、有効期間の話、手元で証明書を見る方法を説明します。版や日付が動く話には「2026年10月20日時点」と、出どころを添えています。

この記事でわかること

HTTPS・TLS・証明書・認証局の関係（それぞれ一言で）
HTTPS で守られること（途中で読まれない・書き換えられない・相手を確かめられる）と、守られないこと（鍵マークだけで安心できない理由、届いたあとのデータ）
証明書の有効期間の上限が、2026年3月15日から 200 日になったこと。短くする公式の理由と、決まっている予定（業界の決まりの 100 日・47 日と、Let's Encrypt の 64 日・45 日。この二つは別もの）
自動更新（ACME）と、更新の設定を点検するときに見る所
openssl と curl で、有効期間や発行者を手元で見る方法。HSTS とは何か

HTTPS とは？ TLS・証明書・認証局の関係
1. TLS の版：いまは 1.3 が中心
HTTPS で守られることは？守られないことは？
証明書の有効期間は、いま何日まで？
有効期間が短くなると、何を点検すればいい？自動更新（ACME）の話
1. ACME：証明書の発行を自動にする決まり
2. 更新の設定を点検する：「何日前」と決め打ちしていないか
  1. FAQ の「60 日ごと」と、新しい告知の違い
手元で証明書を見るには？ openssl と curl（Mac）
HSTS とは？ HTTPS だけで開かせる設定
1. HSTS が無いと何が困る？弱点は「最初の1回」
2. 例：いくつかのサイトの HSTS（2026年10月20日に見たとき）
よくある質問
まとめ
参考資料

HTTPS とは？ TLS・証明書・認証局の関係

まず言葉を整理します。

HTTPS。 MDN（Mozilla が運営する Web 技術の資料）によると、HTTP を暗号化したものです。TLS を使って、ブラウザー（クライアント）とサーバーのあいだのやり取りを全部暗号化します
TLS。 総務省の用語集では、インターネットでデータを暗号化したり、なりすましを防いだりするためのプロトコル（通信の決まり）のことです。SSL を元に標準化されました
サーバー証明書。 総務省の用語集では、アクセスしているサーバーが「本物」であることを保証する電子的な証明書のことです。暗号化通信にも使います。この記事では単に「証明書」と書きます
認証局。 証明書の登録・発行・失効などを行う第三者機関のことです（総務省の用語集）。英語では CA（Certificate Authority）といい、この記事では「認証局」と書きます

MDN は、TLS がつながりを3つの形で守ると説明しています。

守り	意味
暗号化（Encryption）	運ばれているあいだのデータを、攻撃者が読めない
完全性（Integrity）	運ばれているあいだに、攻撃者が気づかれずにデータを書き換えることはできない
認証（Authentication）	相手が名乗ったとおりの相手だと示せる。Web では、ふつうサーバーが自分を示し、クライアントは示さない

3つ目の「認証」を支えるのが証明書です。MDN によると、証明書には、サイトの秘密鍵と対になる公開鍵が、署名つきで入っています。これでサイトの鍵とドメイン名が結び付き、ブラウザーは、たとえば本当に https://example.com につないでいると分かります。（鍵のペアのうち、公開鍵は誰に見せてもよい鍵、秘密鍵はサイトだけが持つ鍵、と覚えると読みやすくなります。）

出典: MDN: HTTPS・MDN: Transport Layer Security・総務省の用語集のTLS・SSL・サーバ証明書・認証局

TLS の版：いまは 1.3 が中心

TLS には版があります。MDN と OWASP の言い方を並べます（2026年10月20日時点）。

MDN（2026年2月28日更新のページ）: いまの TLS の版は 1.3 で、いちばん広く使われています。1.2 はまだ一部のサイトで使われていて、1.1 と 1.0 はもう使うべきではありません
OWASP（Web アプリのセキュリティの資料を出している団体）の TLS のチートシート: Web アプリは既定で TLS 1.3 にしなければならず、互換性のために 1.2 を使ってもよい、という趣旨です

MDN と OWASP が 1.3 を中心にしているので、この記事も 1.3 を中心に書きます。手元で試した example.com も、TLS 1.3 でつながりました（あとの「手元で証明書を見る」の節）。

名前が似ていますが、GitHub につなぐ方法の「HTTPS と SSH」の話は別です。SSH の鍵の設定はGitHub の SSH 設定入門にまとめています。

出典: MDN: Transport Layer Security・OWASP: Transport Layer Security Cheat Sheet

HTTPS で守られることは？守られないことは？

HTTPS の守りは、広い所と狭い所があります。先に結論を表にします。

	守られる	守られない
通信の途中	読まれる・気づかれずに書き換えられる、ことが防がれる	送ったデータの長さは隠れない（RFC 8446）
相手	証明書に書かれたドメインのサーバーとつながっていると確かめられる	そのサイトの運営者・評判・安全さは分からない（DV 証明書の場合）
届いたあと	—	要求した側（ブラウザーのキャッシュなど）に届いたあとのデータは、TLS では守られない（OWASP）
ページの中	HTTPS で読み込んだ部分	HTTP で読み込んだ画像やスクリプト（混在コンテンツ）

以下、順に説明します。

守られること：途中で読まれない・書き換えられない

MDN は、HTTPS は「あいだに割り込む攻撃（MITM。manipulator in the middle）」への守りだと書いています。MITM は、攻撃者がユーザーのブラウザーとサーバーのあいだに入り込んで、やり取りを読んだり書き換えたりする攻撃です。

TLS の規格（RFC 8446。TLS 1.3）は、守る性質を3つ挙げています。

サーバー側はいつも認証される（クライアント側は、任意で認証される）
つながりができたあとに送ったデータは、両端（endpoints）にだけ見える。ただし、送るデータの長さは隠さない
つながりができたあとに送ったデータは、攻撃者に気づかれずに書き換えることはできない

規格は、これらの性質は、ネットワークを丸ごと握っている攻撃者がいても成り立つべきだ、とも書いています。

例：公衆 Wi-Fi

総務省の公衆 Wi-Fi 利用者向けの簡易マニュアル（令和7年2月版）には、守られる範囲の違いが書いてあります。

Wi-Fi の暗号化で守られるのは、無線の区間（機器と Wi-Fi ルーターのあいだ）だけです。ルーターから先は守られません
HTTPS は、ブラウザーから目的の Web サーバーまでを暗号化します。そのため、Wi-Fi が暗号化されていなくても、悪意のある第三者から通信の中身を守れます
逆に、アドレスが http:// で始まる、ブラウザーに「保護されていない通信」「安全ではありません」と出る、といったときは、通信が適切に暗号化されていません。そこでパスワードや個人情報を入力するのは危険です

出典: MDN: Transport Layer Security・RFC 8446（TLS 1.3）・総務省: 公衆 Wi-Fi 利用者向けの案内ページ（簡易マニュアル令和7年2月版）

守られないこと1：鍵マークがあっても、フィッシングサイトのことがある

総務省の「フィッシング詐欺とは？」のページは、鍵マークがあってもフィッシングサイトのケースが増えている、と書いています。理由として、鍵マークには次の「まったく違う意味」があるのに、同じように表示されることを挙げています。

Web サイトとの通信が暗号化されているという意味
Web サイトを運営している組織が実在しているといった意味

そのうえで、鍵マークだけで安心せず、もっと詳しく、もしくはほかの方法と組み合わせて確認しましょう、と呼びかけています。総務省の対策は次のとおりです。

金融機関から通知を受けた URL を直接入力するか、ふだん使うブラウザーのブックマークに正しい URL を記録して、毎回そこからアクセスする（常に本物のページにアクセスするように心がける）
正規のドメイン名が分かっているときは、サイトの URL のドメイン名が一致しているかを確かめる。ドメイン名は「https://（ドメイン名）/」、もしくは「（鍵マーク）（ドメイン名）」のように表示される

公衆 Wi-Fi のマニュアルにも、HTTPS で通信していても本物の URL に似せた偽の URL の場合があるので、URL の全体を確認するように、とあります。スマートフォンは、既定では URL の全体が表示されないことがあるので注意が必要です。

出典: 総務省: フィッシング詐欺とは？（国民のためのサイバーセキュリティサイト。更新日の表示なし）・総務省: 公衆 Wi-Fi 利用者向けの案内ページ

守られないこと2：DV 証明書が言うのは「このドメインの鍵」だけ

証明書には、認証局がどこまで確かめたかで種類があります。基本の確認が DV（Domain Validation） です。OWASP の資料によると、公に発行されるすべての証明書は、ドメインの確認が済んでいなければなりません。この確認は、証明書に書く名前（ドメイン）や接続先を、申し込んだ人が握っていることの証明を求めるものです。DNS や公式のメールアドレス、証明書を受け取る接続先での「問いと答え」で確かめるのがふつうです。

Let's Encrypt（無料の認証局）は、DV 証明書が言うのは「この公開鍵はこのドメインのもの」ということだけだと説明しています。サイトの中身や、運営している人については何も言いません。評判・現実の身元・安全さの情報も入っていません（2015年10月の記事）。Let's Encrypt が出すのは DV 証明書だけで、OV（Organization Validation）と EV（Extended Validation）は出しません。主に、自動で発行できないからです（FAQ。2025年4月28日更新）。

これが、総務省の説明と合わさって、「鍵マーク＝安全なサイト」にならない理由です。鍵マークで言えるのは、少なくとも通信が暗号化されていることです。相手のサイトが良いサイトかどうかは、別に確かめます。

Cloudflare が自動で出す無料の証明書（Universal SSL）も DV です。くわしくはCloudflare の無料プランの記事にあります。

出典: OWASP: Transport Layer Security Cheat Sheet・Let's Encrypt: フィッシングとマルウェアへの対策での認証局の役割（The CA's Role in Fighting Phishing and Malware）（2015年10月29日の記事）・Let's Encrypt の FAQ

守られないこと3：届いたあとのデータと、受け入れてしまった相手

TLS が守るのは、両端のあいだを運ばれているデータです。RFC 8446 の言い方では、送ったデータが見えるのは両端だけです。両端には、サーバーも入っています。 OWASP の資料は、TLS は運んでいるあいだのデータを守るが、要求した側のシステム（届いた先）ではデータを何も守らない、と書いています。例として、利用者のブラウザーのキャッシュ（一時的な保存）や、TLS を解く設定にした仲介のプロキシに残ることを挙げています。

ここから一歩進めて言えば、サーバーに届いたあとでデータをどう保存し、誰に見せるかは、HTTPS の外の話です。（この一文は、RFC 8446 と OWASP の文を踏まえたこの記事の説明で、「HTTPS はサーバーの中のデータを守らない」と書いた公的な資料を見つけたわけではありません。）サーバー側の守りの全体は、Web 開発のセキュリティの基本の記事で点検表にしています。

OWASP は、相手の証明書を受け入れてしまった場合のことも書いています。TLS は両端のあいだの秘密を守りますが、クライアントが攻撃者の証明書を受け入れると、攻撃者はそこに送ったデータを読めます。

出典: RFC 8446・OWASP: Transport Layer Security Cheat Sheet

守られないこと4：HTTP で読み込む部分（混在コンテンツ）

ページ本体を HTTPS で出しても、画像やスクリプトなどの部品を HTTP で読み込むと、混在コンテンツ（mixed content） になります。MDN によると、その部品は HTTPS の守りを受けないので、攻撃者が読めるだけでなく、書き換えられるおそれもあります。そのため、ブラウザーは、安全なページが安全でない部品を読み込むことを許しません。部品の種類に応じて、HTTPS に上げて読み込むか、読み込みを止めます。

出典: MDN: Transport Layer Security（Mixed content）

なお、ブラウザーが、別のオリジンからの応答を JavaScript に読ませないようにする「CORS エラー」は、HTTPS の話とは別のものです。くわしくはCORS エラーの記事にあります。

証明書の有効期間は、いま何日まで？

証明書には期限があります。有効期間（Validity Period） は、証明書に書かれた notBefore（ここから有効）から notAfter（ここまで有効）までの期間のことです。この期間の最大が、いま短くなっていっています。

決めているのは CA/Browser Forum：いまは 200 日まで（2026年10月20日時点）

公に信頼される TLS サーバー証明書の決まりは、CA/Browser Forum（証明書を出す認証局と、ブラウザーなどを作る側が集まって決める団体）の Baseline Requirements（BR） にあります。2026年10月20日に公式のページを開いたところ、いまの版は 2.3.1（Ballot SC104 で採択）で、GitHub の BR.md の日付は 2026年10月4日でした。

最大の有効期間は、BR の 6.3.2 に、証明書を発行した日で分けて書いてあります。

発行した日	最大の有効期間	いまの状況
2026年3月15日より前	398 日	過去の決まり
2026年3月15日〜2027年3月15日より前	200 日	いま効いている
2027年3月15日〜2029年3月15日より前	100 日	決まっている予定
2029年3月15日以降	47 日	決まっている予定

BR の原文は、200 日の行で「199 日を超えるべきではない（SHOULD NOT）」と「200 日を超えてはならない（MUST NOT）」の2つを並べています。100 日と 47 日の行にも、同じように 99 日・46 日の SHOULD NOT が付いています。数え方は、1日を 86,400 秒とし、それを少しでも超えたら1日足す、とされています。そのため BR は、既定で上限いっぱいの期間で発行すべきではない、と書いています。

つまり、200 日は「上限」です。みんなが 200 日の証明書を使っているわけではありません。手元で見た example.com と letsencrypt.org の証明書は、どちらも約 90 日でした（あとの「手元で証明書を見る」の節）。

この予定を決めた投票

この短縮の予定は、Ballot SC-081v3 で決まりました。投票は 2025年4月4日から11日（UTC）で、提案には「398 日から 47 日へ。2026年3月に始まり、2029年3月に終わる」と書いてあります。ドメインの確認の使い回しの期間も、398 日から 10 日に短くする、という内容です。投票の結果は、証明書を出す側が 30 票のうち賛成 25・反対 0・棄権 5、ブラウザーなど証明書を使う側は 4 票すべて賛成でした。

投票のページは「提案（proposed）」と書いていますが、採択後の BR 2.3.1 には、日付つきの決まりとして入っています。

出典: CA/B Forum: Baseline Requirements の版の一覧・BR.md（6.3.2）・Ballot SC-081v3（2025年4月11日）

なぜ短くするの？公式の説明

CA/Browser Forum の SC-081v3 のページ（Benefits の項）には、主に次の3つが書いてあります。

証明書は「発行した時点」の事実の写しだから。 時間がたつほど、証明書の中身が現実とずれる可能性が上がります。研究では、ドメインの期限切れや、第三者が鍵を握ってしまうことなどが挙げられています。有効期間を短くすると、中身が正しくなくなったあとも有効なままの証明書が残りにくくなります
失効を知らせる仕組みに頼らず守れるから。 CRL や OCSP（証明書をもう使えないと知らせる仕組み）は、いまのインターネットの規模では、利用者を十分に守れないと書かれています。有効期間を短くすると、それらに頼らず、利用者を確実に守れます
暗号のやり方に弱点が見つかったとき、早く移れるから。 有効期間が短ければ、動いている暗号を、スムーズに・必要なら素早く切り替えられます

自動化が進むことは、このページでは「主な狙いではない」が、副次的に期待される効き目として書かれています。

Let's Encrypt も、同じ趣旨で説明しています。2025年12月2日の記事では、これは業界全体の変更で、BR が求めているものだと書いたうえで、有効期間を短くすると、漏れたときの範囲を狭め、失効の仕組みも効きやすくなる、と説明しています。2026年10月7日の記事では、鍵が漏れる・誤って証明書が発行される、といったときの危険を減らすためだと書いています。

出典: Ballot SC-081v3（Benefits）・Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days（2025年12月2日）・Let's Encrypt: 64 日の証明書（2026年10月7日）

決まっている予定：業界の上限と、Let's Encrypt の日程は別もの

ここからは、まだ来ていない日付の話です（2026年10月20日時点）。BR の上限と、Let's Encrypt が出す日数は別ものなので、分けて書きます。

BR（業界の決まりの上限）。 上の表のとおり、2027年3月15日以降に発行する分は 100 日まで、2029年3月15日以降は 47 日までです。

Let's Encrypt。 上限の内側で、先に進めています。

日付	Let's Encrypt の動き
いま	既定（classic プロファイル）は 90 日。選ぶ人だけの tlsserver プロファイルは 45 日（2026年5月13日から。公式の告知）、shortlived プロファイルは 160 時間（約 6 日）
2027年2月10日	既定の classic が 64 日になる（ドメインの確認の使い回しは 10 日）。この日以降に発行・更新する証明書が対象。最後の 90 日の証明書は、2027年5月11日に切れる見込み。有効な証明書を失効させはしない
2028年2月16日	classic が 45 日になる（確認の使い回しは 7 時間）

Let's Encrypt によると、これらの日付は新しく発行する証明書に効きます。利用者が変化に気づくのは、その日付のあとの次の更新のときです。試験用の環境（staging）は、2026年10月14日に 64 日への切り替えが済んでいます。

「プロファイル」は、どの種類の証明書を出してほしいかを、申し込むときに選ぶ設定です。何も選ばなければ classic になります。つまり、いまの 90 日は 200 日の上限の内側で、Let's Encrypt の 64 日・45 日は、BR の 100 日・47 日より早く・短く進める計画です。「2029年に 47 日」は BR の話で、「2028年に 45 日」は Let's Encrypt の話です。

出典: Let's Encrypt: プロファイル（2026年10月4日更新）・Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days（2025年12月2日）・Let's Encrypt: 64 日の証明書（2026年10月7日）・staging の切り替えのお知らせ（2026年10月14日）

有効期間が短くなると、何を点検すればいい？自動更新（ACME）の話

期限が短くなると、更新の回数が増えます。Let's Encrypt は、手作業で証明書を更新することは勧めない、と書いています。短い有効期間では、手作業の更新をもっと頻繁にしなければならなくなるからです。そこで使われるのが、自動更新の仕組みです。

ACME：証明書の発行を自動にする決まり

ACME（RFC 8555） は、認証局と申し込む人が、ドメインの確認と証明書の発行を自動で行うための規格です。失効などの管理の機能も含みます。Let's Encrypt の説明では、この仕組みの狙いは、人の手を使わずに、HTTPS のサーバーが、ブラウザーに信頼される証明書を自分で取れるようにすることです。Web サーバーで ACME クライアント（申し込む側のプログラム）を動かします。

流れは2段階です。

ACME クライアントが、そのドメインを握っていることを認証局に示す。DNS（example.com の下）にレコードを置くか、http://example.com/ の決まった場所にファイルを置く。認証局は、その確認が満たされているかを、複数のネットワークの地点から調べる
そのあとで、クライアントはそのドメインの証明書を頼んだり、失効させたりできる

ホスティングのサービス（サイトを置く場所を貸すサービス）を使っているなら、MDN によると、HTTPS は既定で、または設定で対応していて、サービス側が証明書を管理し、サーバーの設定もしてくれる可能性が高いです。Cloudflare を使う場合は、Cloudflare の無料プランの記事に、無料の証明書が自動で出る話があります。Cloudflare にサイトを置く場所を選ぶ話は、Pages と Workers の記事です。

出典: RFC 8555（ACME）・Let's Encrypt: How It Works（2025年8月2日更新）・MDN: Transport Layer Security

更新の設定を点検する：「何日前」と決め打ちしていないか

自分で ACME クライアントを動かしているなら、Let's Encrypt の告知に、点検することが書いてあります。

更新を「期限の何日前」と決め打ちしているなら、有効期間の 約 2/3 で更新するように直します。cron（決まった時刻にコマンドを動かす仕組み）、スクリプト、手順書の中で、83・80・60 などの数を探します
更新が自動で、ARI（ACME Renewal Info）に対応したクライアントなら、更新の時期を Let's Encrypt が教えてくれるので、そのままで構いません
証明書が予定どおりに更新されなかったら知らせる監視を置きます

2025年12月2日の告知には、60 日の決め打ちは、45 日の証明書ではもう足りなくなる、という例も挙がっています。

FAQ の「60 日ごと」と、新しい告知の違い

Let's Encrypt の FAQ（2025年4月28日更新）は、90 日の証明書は 60 日ごとに更新するのを勧めています。いっぽう、2026年10月7日の告知は、有効期間の約 2/3 で更新するように、と書いています。90 日の 2/3 は 60 日なので、いまの 90 日の証明書にとっては同じ割合です（これは計算です）。64 日・45 日に向けては、FAQ の「60 日」ではなく、約 2/3 か ARI で考えます。FAQ にはまだ 64 日・45 日の予定が書かれていません（2026年10月20日時点）。

出典: Let's Encrypt: 64 日の証明書（2026年10月7日）・Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days（Action Required。2025年12月2日）・Let's Encrypt の FAQ（2025年4月28日更新）

手元で証明書を見るには？ openssl と curl（Mac）

ここまでの話は、手元のコマンドで確かめられます。この節の出力は、2026年10月20日に macOS 14.4.1 で流したものです。Windows と Linux では流していません。証明書は更新されるので、読むときの値は変わっているはずです。見るのは、書き方と読み方です。

先に `openssl version` で、どの openssl か見る

Mac には、openssl が2つあることがあります。この Mac では、次のようになっていました。

openssl version
# OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025)   ← Homebrew のもの。PATH の先頭
/usr/bin/openssl version
# LibreSSL 3.3.6                                                  ← macOS に入っているもの

値は同じでも、出力の書き方が少し違います。以下は、特に断らなければ Homebrew の OpenSSL 3.6.0 の出力です。

有効期間・発行者・名前を見る

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer -subject

s_client でサイトにつないで証明書を取り、x509 で中身を読む組み合わせです。先頭の echo | は、s_client が入力待ちで止まらないようにするためのもの、2>/dev/null は途中の表示を捨てるためのものです。-servername は接続先の名前を伝える指定で、この説明は手元の出力から読んだもので、openssl の文書では確かめていません。

2026年10月20日の example.com の出力は次のとおりでした。

notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT
issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
subject=CN=example.com

notBefore と notAfter が有効期間です（時刻は GMT）。この差を数えると 90 日と 7 分ほどです
issuer が発行者（証明書を出した認証局）、subject が証明書に書かれた名前です

同じ日の letsencrypt.org は、次のとおりです。

notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
issuer=C=US, O=Let's Encrypt, CN=YE2
subject=CN=letsencrypt.org

差は 89 日 23 時間 59 分 59 秒です。BR の有効期間の定義は「notBefore から notAfter まで、両端を含む」なので、数えると 90 日になり、Let's Encrypt の既定の 90 日と合います。どちらも 200 日の上限の内側です。

macOS の /usr/bin/openssl（LibreSSL 3.3.6）で同じコマンドを流すと、日付は同じで、issuer と subject の書き方だけが違いました（issuer= /C=US/O=SSL Corporation/CN=Cloudflare TLS Issuing ECC CA 3 のように、スラッシュ区切りです）。

curl で、つないだ TLS の版と検証を見る

curl -sv -o /dev/null https://example.com/ 2>&1 | grep '^\*'

macOS の /usr/bin/curl（8.4.0）で流すと、要所は次のようになりました（途中を省いています）。

* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* Server certificate:
*  subject: CN=example.com
*  start date: Sep 26 22:49:11 2026 GMT
*  expire date: Dec 25 22:56:35 2026 GMT
*  subjectAltName: host "example.com" matched cert's "example.com"
*  issuer: C=US; O=SSL Corporation; CN=Cloudflare TLS Issuing ECC CA 3
*  SSL certificate verify ok.

TLSv1.3 が、つながった TLS の版です。SSL certificate verify ok. は、証明書の検証が通ったことを示します。LibreSSL の s_client は、同じ接続で New, TLSv1/SSLv3, … という行も出しますが、同じ出力の Protocol : TLSv1.3 の行が版を表していました（手元の出力からの読みで、文書では確かめていません）。

期限が切れた証明書は、どう見える？

expired.badssl.com は、期限が切れた証明書を見せるテスト用の公開サイトです。

curl -sS -o /dev/null https://expired.badssl.com/
# curl: (60) SSL certificate problem: certificate has expired    ← 終了コードは 60
echo | /usr/bin/openssl s_client -connect expired.badssl.com:443 -servername expired.badssl.com 2>&1 | grep -E 'Verify return code|verify error'
# verify error:num=10:certificate has expired
#     Verify return code: 10 (certificate has expired)

curl は検証に失敗して止まります。openssl も Verify return code: 10 (certificate has expired) と出します。この証明書の有効期間は、2015年4月9日〜12日でした。openssl の出力は /usr/bin/openssl（LibreSSL 3.3.6）のものです。Homebrew の OpenSSL 3.6.0 でも、この2行は同じでした。

あと何日で切れるか：`-checkend`

openssl x509 -checkend <秒> は、「その秒数のうちに切れるか」を終了コードで返します（0 は切れない、1 は切れる）。手元では次のとおりでした。ex.pem は、s_client の出力をそのまま保存したファイルです。

# 2592000 秒 = 30 日。example.com の notAfter は Dec 25 2026 なので、30 日のうちには切れない
openssl x509 -in ex.pem -noout -checkend 2592000
# Certificate will not expire     ← OpenSSL 3.6.0 は表示する。終了コードは 0
/usr/bin/openssl x509 -in ex.pem -noout -checkend 2592000
# （何も表示されない）            ← LibreSSL 3.3.6 は表示なし。終了コードは 0

LibreSSL で 90 日（7776000 秒）を指定すると、この日の example.com の証明書は終了コード 1 でした（表示なし）。更新が止まっていないかを見張るスクリプトの材料になりますが、この記事では書き方の例までです。-checkend の終了コードの意味は、手元の出力から読んだもので、openssl の文書では確かめていません。

出典: 手元で流した出力（上記の日付・環境）。有効期間の定義はBR.md

HSTS とは？ HTTPS だけで開かせる設定

HSTS（HTTP Strict Transport Security） は、サーバーが返す応答のヘッダー（付け足しの情報）Strict-Transport-Security で、ブラウザーに伝える設定です。MDN によると、「このホストは HTTPS だけで開くこと。この先 HTTP で開こうとしたら、自動で HTTPS に上げること」と知らせます。さらに、以後そのホストにつなぐときは、証明書が無効などの安全なつながりのエラーを、利用者が無視して進むことを、ブラウザーが許さなくなります。

書き方は次のとおりです（MDN）。

Strict-Transport-Security: max-age=<秒>
Strict-Transport-Security: max-age=<秒>; includeSubDomains
Strict-Transport-Security: max-age=<秒>; includeSubDomains; preload

max-age: ブラウザーが「このホストは HTTPS だけで開く」と覚えておく秒数
includeSubDomains: サブドメインにも同じ決まりを適用する
preload: 後述のリストに載せたいときに付ける

HSTS は、HTTPS の応答で送ったときだけ効きます。 HTTP で送っても、ブラウザーは無視します。途中の攻撃者がヘッダーを書き換えて、期限を早く切らせたり、HTTPS に対応していないホストに付けたりするのを防ぐためです。

HSTS が無いと何が困る？弱点は「最初の1回」

利用者が http:// で打ち込んだとき、HSTS が無いと、最初のやり取りを攻撃者に横取りされて、HTTPS へ上がるのを止められるおそれがあります。これを SSL ストリッピングといいます（SSL は TLS の前身の名前です）。HSTS があれば、2回目からは、ブラウザーが最初から HTTPS でつなぎます。

HSTS で SSL ストリッピングを防げないのは、次の2つの場合です（MDN）。

ブラウザーが、そのホストに一度も安全につないでおらず、ヘッダーを受け取っていない最初の1回
HSTS の期限（max-age）が切れたあとの最初の1回

この「最初の1回」を埋めるのが、preload のリスト（あらかじめブラウザーに入れておくリスト）です。リストに載せるには、1年（31536000 秒）以上の max-age と includeSubDomains が要ります。リストは Google が運営し、主なブラウザーが使っていますが、HSTS の規格の一部ではありません。載せる手順と取り消し方は、この記事では扱いません（一次の資料を開いて確かめていないため）。

MDN の例では、空港の偽の Wi-Fi が出てきます。以前 HSTS を受け取っているブラウザーなら、http://login.example.com/ を開いても HTTPS でつなぎます。攻撃者は正しい証明書を持たないので、ブラウザーに無効な証明書のエラーが出て、利用者は進めず、パスワードを渡さずに済みます。

HSTS を付けると証明書のエラーを無視して進めなくなる、ということは、証明書の更新が止まって期限が切れると、読者もそのサイトを開けなくなる、ということでもあります（MDN の説明から導いたこの記事の整理です）。有効期間が短くなる時代に、更新の見張りが大事なのは、このためでもあります。

例：いくつかのサイトの HSTS（2026年10月20日に見たとき）

curl -sI https://letsencrypt.org/ | grep -i -E '^HTTP|strict-transport'
# HTTP/2 200
# strict-transport-security: max-age=31536000

letsencrypt.org は max-age=31536000、developer.mozilla.org（/en-US/ に転送されたあと）は max-age=63072000 で、example.com には付いていませんでした。サイトの運営者がいつでも変えられる値なので、読むときは違うかもしれません。

出典: MDN: Strict-Transport-Security（2026年9月11日更新）・MDN: Transport Layer Security（Upgrading HTTP connections）

よくある質問

鍵マークが付いていれば安全？

安全とは言えません。総務省は、鍵マークがあるのにフィッシングサイトだったケースが増えていると書いています。鍵マークには「通信が暗号化されている」という意味と「運営している組織が実在している」といった意味があって、同じように表示されます。また、Let's Encrypt が出す DV 証明書が言うのは、「この公開鍵はこのドメインのもの」までです。通知で受け取った URL を自分で入力するか、ブックマークから開く・ドメイン名が正しいか URL の全体で確かめる、といった確認と組み合わせます。くわしくは、上の「守られないこと1・2」です。

HTTPS にすれば、サーバーに保存したデータも守られる？

HTTPS（TLS）が守るのは、両端のあいだを運ばれているデータです。OWASP が書いているのは、要求した側に届いたあとのデータ（例: 利用者のブラウザーのキャッシュ。TLS を解く仲介のプロキシにも残りうる）は TLS では守られない、ということです。サーバーに保存したデータも同じく HTTPS の外の話だ、というのはこの記事の整理です（一文で書いた公的な資料は、確かめた範囲では見つかっていません）。

証明書の期限が切れると、どうなる？

手元の確認では、期限が切れた証明書を持つ expired.badssl.com に curl でつなぐと certificate has expired で止まり（終了コード 60）、openssl も Verify return code: 10 (certificate has expired) と出しました。ブラウザーの画面の文言は、この記事では確かめていません。HSTS が付いているサイトでは、MDN によると、利用者がエラーを無視して進むことをブラウザーが許しません。

Let's Encrypt の証明書は、90 日のまま？

2026年10月20日時点では、既定（classic プロファイル）は 90 日です。2027年2月10日に既定が 64 日になり、2028年2月16日に 45 日になる予定が、Let's Encrypt から告知されています。これは Let's Encrypt の日程で、業界の決まりの上限（2027年3月15日から 100 日、2029年3月15日から 47 日）とは別ものです。更新を「何日前」と決め打ちしている設定は、有効期間の約 2/3 に直すか、ARI に対応したクライアントを使います。

200 日になったのは、いつ？

2026年3月15日以降に発行する証明書からです。CA/Browser Forum の Baseline Requirements（版 2.3.1。2026年10月20日に開いた公式の資料）の 6.3.2 で、発行した日が 2026年3月15日より前なら 398 日まで、2026年3月15日から 2027年3月15日より前なら 200 日までです。

自分のアプリで確かめること（チェックリスト）

ページ本体を HTTPS で出していても、画像やスクリプトなどの部品を HTTP で読み込んでいないか（→「守られないこと4：HTTP で読み込む部分（混在コンテンツ）」）
HTTPS にしたことと、サーバーに届いたあとのデータの保存のしかた・見せる相手を、分けて点検しているか（→「守られないこと3：届いたあとのデータと、受け入れてしまった相手」）
自分のサイトの証明書の有効期間と期限を、openssl や curl で見たか。2026年3月15日から 2027年3月15日より前に発行する証明書の最大は 200 日（2026年10月20日時点）（→「有効期間・発行者・名前を見る」）
業界の決まりの上限（2027年3月15日から 100 日、2029年3月15日から 47 日）と、Let's Encrypt の日程（2027年2月10日から既定 64 日、2028年2月16日から 45 日）を、混ぜずに読んでいるか（→「決まっている予定：業界の上限と、Let's Encrypt の日程は別もの」）
自分で ACME クライアントを動かしているなら、更新を「期限の何日前」と決め打ちしていないか。cron・スクリプト・手順書の中で 83・80・60 などの数を探し、有効期間の約 2/3 か ARI にしているか（→「更新の設定を点検する：「何日前」と決め打ちしていないか」）
証明書が予定どおりに更新されなかったら知らせる監視を置いているか（→「更新の設定を点検する：「何日前」と決め打ちしていないか」）
HSTS（Strict-Transport-Security）を付けるなら、HTTPS の応答で送っているか。HTTP で送っても、ブラウザーは無視する（→「HSTS とは？ HTTPS だけで開かせる設定」）
HSTS を付けているサイトは、証明書の更新が止まって期限が切れると、読者も開けなくなる（この記事の整理）。更新の見張りを置いているか（→「HSTS が無いと何が困る？弱点は「最初の1回」」）

まとめ

HTTPS は、HTTP を TLS で暗号化したもの。守られるのは、ブラウザーとサーバーのあいだを運ばれているデータで、読まれない・気づかれずに書き換えられない・相手のドメインを確かめられる、の3つ
鍵マークがあってもフィッシングサイトのことがある（総務省）。DV 証明書は、公開鍵がそのドメインのものだと言うだけで、運営者や安全さは示さない。URL の全体を確かめる
要求した側（ブラウザーのキャッシュなど）に届いたあとのデータは TLS では守られない（OWASP）。サーバーに保存したデータも HTTPS の外の話（この記事の整理）。HTTP で読み込む部品（混在コンテンツ）も守られない
公に信頼される証明書の最大の有効期間は、2026年3月15日以降の発行で 200 日（それまでは 398 日）。短くする理由は、証明書の中身が現実とずれにくくする・失効の仕組みに頼らない・暗号を早く移せる、など
決まっている予定は、BR が 2027年3月15日から 100 日・2029年3月15日から 47 日。Let's Encrypt は別の日程で、2027年2月10日から既定 64 日・2028年2月16日から 45 日。混ぜずに読む
自分で ACME クライアントを動かしているなら、更新を「何日前」と決め打ちしていないか点検し、有効期間の約 2/3 か ARI にして、更新されなかったら知らせる監視を置く
手元では、openssl s_client と openssl x509、curl -v で、有効期間・発行者・TLS の版を見られる。先に openssl version で、どの openssl かを確かめる
HSTS は、HTTPS だけで開かせる設定。証明書のエラーを無視して進めなくなるので、更新が止まると読者も開けなくなる