SSL証明書（サーバー証明書）とは認証局が発行する電子証明書で、Webサイトの通信を暗号化する鍵の受け渡しに使う。SSLは古い名前で今の規格はTLS、鍵マークは安全の印ではなく、2026年3月15日以降に発行する証明書の有効期間は最大200日【2026年10月版】

2026年10月13日・日本時間時点の情報です。 SSL証明書（エスエスエルしょうめいしょ）とは、Webサイトのサーバーについて、認証局という第三者がドメイン名の利用権などを確かめて発行する電子的な証明書で、ブラウザとの通信を暗号化する鍵の情報を正しく渡す役目も持ちます。官公庁や認証局の文書では「サーバー証明書」「サーバ証明書」と書かれ、名前の「SSL」は古い規格で、いま使われている規格はTLS（ティーエルエス）です。サイトを見る側が覚えておくことは、鍵マークは安全なサイトの印ではないことと、期限切れなどの警告が出たら先へ進まないことです（この2点は筆者の整理）。

3行まとめ

1. SSL証明書（サーバー証明書）は、総務省の用語集によると「利用者がアクセスしているサーバが「本物」であることを保証する電子的な証明書」。認証局が発行し、IPAは暗号通信に使う公開鍵情報を正しく伝える役割も挙げる
2. SSLは古い名前。SSL 3.0はRFC 7568（2015年6月）で使用禁止、TLS 1.0・1.1もRFC 8996（2021年3月）で廃止。筆者がこのMacで5サイトに接続すると、4つがTLS 1.3、1つがTLS 1.2だった
3. 鍵マークは安全の印ではない（Googleは2023年5月2日に「nearly all phishing sites use HTTPS」と書いた）。最大有効期間は、2026年3月15日以降の発行で200日、2027年3月15日以降は100日、2029年3月15日以降は47日（CA/Browser Forum）

偽サイトの見分け方はフィッシング詐欺とは、ドメイン名の仕組みはDNSサーバーとはを見てください。

SSL証明書とは何か？総務省・IPA・JPRSの定義を並べる

総務省の用語集は、サーバ証明書を次のように定義します。

「SSL(TLS)を用いて、利用者がアクセスしているサーバが「本物」であることを保証する電子的な証明書のこと。」「サーバ証明書は、認証局と呼ばれる第三者機関によって発行されます。」

筆者が2026年10月13日3時32分に撮影。

IPAの「TLS暗号設定ガイドライン」（Ver. 3.1.1）は、役割を2つ挙げます。「①当該サーバが、意図する相手によって管理されているサーバであることを確認する手段をクライアントに対して提供すること」と、「②SSL/TLSによる暗号通信を行うために必要なサーバの公開鍵情報をクライアントに正しく伝えること」です。JPRSは「通信の暗号化」「Webサイトの運営者・運営組織の実在証明」の2つの役割と書きます（JPRSは証明書の発行サービスも行っています）。

「認証局」は、総務省の用語集で「電子証明書の登録、発行および失効などを行う第三者認証機関」です。「SSL証明書」「サーバー証明書」「サーバ証明書」は、筆者が読んだ資料では同じものを指します（IPAは「TLS サーバ認証用途向けデジタル証明書を「サーバ証明書」と呼んでいる」と書く）。

SSL通信とは？URLが https:// で始まる暗号化通信で、始めに証明書で相手を確かめる

「SSL通信」は、SSL/TLSで暗号化された通信のことです。国家サイバー統括室（NCO）の「インターネットの安全・安心ハンドブック」（Ver 5.10）の第5章は、暗号化していないサイトのURLは http://、SSL/TLSの通信は https:// で始まり、s は「secure」の意味だと説明します。暗号化されていない通信は平文で、盗聴する攻撃者は工夫なしに盗める、とも書きます。

通信を始める前の「ハンドシェイク」を、IPAは3つにまとめます。

1. ブラウザとサーバーが、暗号アルゴリズムとプロトコルのバージョンを決める
2. サーバー証明書によって、サーバーの認証を行う
3. そのセッションで使うセッション鍵を共有する

2では、IPAによると、ブラウザは「ブラウザに登録された認証局の証明書を信頼の起点として、当該サーバ証明書の正当性を確認する」。NCOのハンドブックによると、暗号化されるのはブラウザから目的のサーバーまでの区間です（VPNとの違いはVPNとは）。

SSLとTLSの違いは？SSLは古い名前で、標準化されたTLSが後を継いだ

IPAのガイドラインによると、SSLはNetscape社が開発し、SSL 2.0が1995年、SSL 3.0が1996年に出ました。標準化団体のIETFが、SSL 3.0を土台にTLS 1.0を作りました。RFC 2246（1999年1月）は、両者の違いを「not dramatic」（訳：大きくはない）と書きます。

JPRSは「現在、SSLはすべての主要ブラウザでは利用できなくなっており」と書きつつ、「「SSL」という言葉自体が浸透しているため、使用されることがあります」とも書きます。総務省はTLSを「SSLを元にして標準化されました」と説明します。つまり「SSL証明書」「SSL通信」は、いまのTLSを古い名前で呼ぶ言い方です（筆者の整理）。

このMacで公的機関など5サイトの証明書を読むと、種類・期限・TLSの版はどうだったか

IPAのガイドラインは、証明書の「対象者（subject）」と「証明書ポリシー」のOIDを見ると、EV・OV・DVの別が判別できると書きます。筆者は画面を開かず、この Mac のコマンドで同じ項目を読みました。接続は各サイトへ1回ずつの通常のハンドシェイクです。2026年10月13日3時29分に、IPAのサイトへ次のコマンドを実行しました（OpenSSL 3.6.4、macOS 26.6）。

openssl s_client -connect www.ipa.go.jp:443 -servername www.ipa.go.jp </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates
issuer=C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., OU=http://certs.starfieldtech.com/repository/, CN=Starfield Secure Certificate Authority - G2
subject=jurisdictionC=JP, businessCategory=Private Organization, serialNumber=0100-05-007126, C=JP, ST=東京都, L=文京区, O=独立行政法人情報処理推進機構, CN=www.ipa.go.jp
notBefore=Nov  6 22:16:35 2025 GMT
notAfter=Nov 25 00:04:41 2026 GMT

issuer が発行した認証局、subject が持ち主（O が組織名、CN がドメイン名、serialNumber は持ち主の登録番号で、EVガイドライン7.1.4.2.5の「Registration Number」。このMacの機器番号ではありません）、notBefore・notAfter が有効期間です。サーバーは証明書を3枚（サイト用・中間・ルート）送ってきて、OpenSSLは連鎖を確認でき、接続はTLS 1.3でした。このMacのシステムのルート証明書の入れ物（158件）にも、連鎖の最後の「Starfield Root Certificate Authority - G2」が入っていました（security find-certificate）。

同じ方法で5サイトを読みました。種類は、ポリシーOIDをCA/Browser ForumのBaseline Requirements（7.1.2.7）の対応で読み替え、日数は筆者が notAfter から notBefore を引いて計算しました（1日未満は切り捨て）。

発行者の欄は、5サイトとも別々の認証局でした（特定の認証局を勧める意図はありません）。subject の欄は、EVの3サイトとOVのJPRSでは組織名と所在地が入り、DVのcabforum.orgは CN=cabforum.org（ドメイン名）だけでした。3時31分には、ヘッドレスのChromium 148（Playwright）で協議会を除く4サイトのページを開き、ブラウザが報告した発行者・期限・TLSの版もコマンドと同じでした。

証明書の種類（DV・OV・EV）は何が違うのか？

IPAは、DVでは「運営組織の実在性や、ドメイン名と運営組織の関係については確認されない」と書きます。フィッシング対策協議会のWGの文書が引く同協議会のガイドラインは「フィッシング対策の観点からは DV（Domain Validation）ではなく、OV（Organization Validation）もしくは EV（Extended Validation）であることが望ましい」と書きます。NCOのハンドブックは利用者に、「厳しい認証局の審査を伴う EV-SSL のウェブサイトを利用する方が、より安全である」と判断するよう書きます。一方、CA/Browser Forumは4つの型の説明に次の注を付けています。

「Note: Although each Subscriber Certificate type varies in Subject Information, all Certificates provide the same level of assurance of the device identity (domain name and/or IP address).」

（訳：注：各型の証明書は主体者情報の内容が異なるが、すべての証明書は、機器の身元（ドメイン名またはIPアドレス）について同じ水準の保証を与える。）

IPA・協議会・NCOは運営組織の確認の有無を、CA/Browser Forumはドメイン名の確認の水準を述べていると、筆者は読みました（解釈です）。EVの表示は、Chromium Docsによると Chrome 77から、鍵アイコンを押して開くページ情報へ移り、理由は「the EV UI does not protect users as intended」（訳：EVの表示は意図したようには利用者を守らない）です。NCOのハンドブックは、EVでは「一部のブラウザでは文字が緑になる」と書きます（どのブラウザかは書いていません）。

ブラウザで証明書を確かめるには？Edge・Safariのヘルプと、IPAが書くChromeの手順

フィッシング対策協議会の2022年9月6日の文書は、主要ブラウザーの更新でアドレスバーの表示が鍵マークだけになり、どの組織のサイトかは「一目では識別できなくなり」、確かめるには鍵マークのクリックが必要だと書きます。手順は次のとおりです。筆者はこの画面操作を自分の画面では行っていません。

• Microsoft Edge: Microsoftサポートによると、南京錠のアイコンをクリックすると「サイトのセキュリティ証明書の詳細が表示されます」。「接続がセキュリティで保護されているかどうか、および証明書の発行者が表示されます」。
• Safari（Mac）: Appleサポートによると、「「Safari」＞「接続セキュリティの詳細」と選択します。」。証明書の警告が出たときは、「「証明書を表示」をクリックして、証明書の内容を確認します。」。
• Google Chrome: IPAのガイドラインの付録D.1は、調整アイコン、「この情報は保護されています」、「証明書は有効です」の順にクリックする手順を載せています。開発者向けには、DevToolsのドキュメントが「[セキュリティ] > [概要] で [証明書を表示] をクリック」する手順を書きます。Chromeヘルプ「サイトの接続が安全かどうかを確認する」には、アイコンの意味と、パソコンに入っている証明書を見る「証明書の管理」の手順はありますが、開いているサイトの証明書を表示する手順は、本記事が確認した範囲では見当たりませんでした。

アイコンの見た目はブラウザや版で違います（Chromeの変更は次の節）。見る項目は、発行者、有効期限、サイトの名前（OV・EVでは組織名）です。

鍵マークが出ていれば安全なサイトなのか？公的機関とGoogleの原文

総務省の「フィッシング詐欺とは？」のページは、次のように書いています。

「WebブラウザのURLに鍵マークが表示されているにもかかわらず、フィッシングサイトであるケースが増えています。鍵マークには、Webサイトとの通信が暗号化されているという意味と、Webサイトを運営している組織が実在しているといった全く異なる意味がありますが、いずれも同じように表示されています。」

フィッシング対策協議会の「フィッシングとは」は「フィッシングサイトでも簡単に証明書を取得できるため、鍵マークが表示されてしまうことがあります」と書きます。IPAのガイドラインのコラムは、DV証明書は「ドメインが実在するかどうかしか検証せず」運営組織を確認しないので、フィッシングサイトにも発行でき、「ブラウザはそのサイトがフィッシングサイトであるかどうかの判断はしない」と書きます。

各社のヘルプも同じ趣旨です。Chromeヘルプは「安全なサイトでも、個人情報の扱いには十分注意してください。」、Appleのヘルプは「暗号化によりウェブサイトへの接続は安全になりますが、ウェブサイトの信頼性が保証されるわけではありません。」と書きます。

Googleは、鍵アイコンの扱いを次の順で変えてきました（いずれもChromium Blog）。

2023年5月2日の記事は、理由を次のように書きます。

「we know that the lock icon does not indicate website trustworthiness.」「nearly all phishing sites use HTTPS, and therefore also display the lock icon.」

（訳：鍵アイコンはウェブサイトが信頼できることを示さない、と私たちは知っている。ほぼすべてのフィッシングサイトがHTTPSを使っていて、そのため鍵アイコンも表示される。）

これは予定の発表で、実施についてはIPAのガイドライン（2025年4月公開）の脚注が、Chromeはアドレスバーの印を錠前から「調整アイコン」と呼ばれるものへ「変更を始めている」と書いています。

証明書の有効期間はなぜ短くなっているのか？CA/Browser Forumの決議と日付

最大有効期間は、Baseline Requirementsの6.3.2に表があります（Version 2.3.1、2026年10月4日）。

これを定めたBallot SC081v3は、2025年4月11日に投票が終わり、同年5月16日に施行されました（改訂履歴）。認証局側は30票中25が賛成、反対0、棄権5、ブラウザ側のApple・Google・Microsoft・Mozillaは4票とも賛成でした。以前の段階として、改訂履歴には「825-day Certificate Lifetimes」（2017年3月17日採択、2018年3月1日施行）の行があり、Appleのサポートページは、2020年9月1日以降に発行するTLSサーバー証明書の有効期間は398日を超えてはならないと書きます（AppleのOSのルート認証局が対象）。

理由を、Ballotのページは「Certificates are representations of a point in time state of reality.」（訳：証明書は、ある時点の現実の状態を表したものである）と書き、時間がたつほど書かれた情報が現実とずれるので、有効期間を短くしてそのずれを小さくする、と説明します。フィッシング対策協議会のWGは2025年8月19日の文書で、短縮に対応するには「証明書のライフサイクル全体を自動化することが不可欠です」と書きます。

筆者が読んだ5サイトを、この表に当てます。2026年3月15日より前に発行されたIPA（383日）と協議会（389日）は398日の範囲内、3月15日以降に発行された総務省（194日）・JPRS（174日）・cabforum.org（約90日）は200日の範囲内でした。IPAの証明書の期限は2026年11月25日で、表のとおりなら、これから発行される証明書は最大200日です（IPAの更新予定は確かめていません）。期限切れなどで警告が出るサイトには、NCOのハンドブックは「接続しない」よう書いています。

この記事で確かめていない点：画面の操作・各ブラウザの現在の表示・5サイト以外

• 各ブラウザの手順は各社のヘルプとIPAの文言で、メニュー名が手元の版と一致するかは確かめていません。
• 各ブラウザのアドレスバーが、いまDV・OV・EVをどう表示するかは確かめていません。
• 証明書を読んだのは5サイトだけで、全体の傾向は示せません。「種類」はポリシーOIDの読み替えで、審査内容は確かめていません。
• 最大有効期間は、CA/Browser Forumの現在の文書に基づきます。Google・Mozilla・Microsoftが独自に定める期間は確かめていません。2029年3月15日の47日は、今後変わる可能性があります。
• RFC 9846は冒頭と、RFC 8446・TLS 1.2との関係の部分だけを読みました。クライアント証明書・S/MIME・コード署名の証明書は扱っていません。

本文の出典と開いた時刻（SSL証明書の記事）

本文で名指しした資料は、すべて記事冒頭のsourcesに入れています。取得は2026年10月13日3時19分から3時34分（日本時間）、ルート証明書の数え上げは3時32分です。