「サーバとセキュリティ保護された接続を確立できなかったため、ページを開けません。」の原因と対処法｜Mac・iPhone・社内プロキシ別【2025年調査・暗号化対策27.4%】

社内のMacやiPhoneで「サーバとセキュリティ保護された接続を確立できなかったため、ページを開けません。」と表示された、という問い合わせを受けていませんか。

ユーザーはページを開きたいだけなので、原因の説明よりも「どうすれば開けるのか」を求めてきます。ところが、この文言だけでは原因がひとつに絞れません。

• 何が原因で出ているのか分からない
• 「このまま進んでいいですか」と聞かれても判断できない
• 同じ問い合わせが繰り返し来て、対応が終わらない

この記事では、原因の切り分けから対処手順、そして再発防止までを情シスの立場で整理します。

このメッセージはSafariがサーバとの暗号化通信を確立できなかったときに表示される

このメッセージは、SafariがWebサーバとの間で暗号化された通信路を作れなかったときに出る警告です。ページの中身を取りに行く前の段階で、通信が止まっている状態を指します。

HTTPSで始まるサイトを開くとき、ブラウザとサーバは最初に「この相手は本物か」「どの暗号方式で話すか」を取り決めます。この取り決めが成立しないと、Safariは中身を一切表示せずに接続を打ち切ります。

そのため、「ページが見つからない」「サーバが落ちている」といった障害とは性質が違います。サーバ自体は動いていて、通信の入り口だけが閉じている状態で発生します。

つまり、この表示が出た時点で分かるのは「暗号化通信の確立に失敗した」という一点だけです。原因を特定するには、ここから順番に切り分けていく必要があります。

エラーの正体はサーバ証明書の検証、またはTLSハンドシェイクの失敗

失敗しているのは、サーバ証明書の検証か、暗号方式・TLSバージョンの取り決めのどちらかです。どちらも、接続開始時にやり取りするTLSハンドシェイクの中で行われます。ブラウザはこの2つを通過して初めて、ページの取得を始めます。

サーバ証明書とは、そのサイトの運営者が本人であることを証明する電子的な文書です。Safariは受け取った証明書について、次の3点を確認しています。

• 信頼できる認証局（CA）から発行されているか
• 有効期限内か
• アクセスしようとしているドメイン名と一致しているか

これに加えて、ブラウザとサーバが共通で使える暗号方式とTLSバージョンがあるかどうかも確認します。どれか1つでも満たされなければ、Safariは接続を中断します。

このように、確認項目が複数あることが、原因を絞りにくくしている理由です。逆に言えば、この4項目のどれが崩れているかを見れば、原因にたどり着けます。

ChromeやEdgeでは同じ原因でも別のエラーコードが表示される

原因を早く絞り込みたいときは、同じURLをChromeやEdgeで開いてみてください。この日本語の文言はSafari（macOS・iOS・iPadOS）固有で、他のブラウザは同じ原因でも別の表示をします。

ChromeやEdgeはエラーコードを画面に出すため、どの検証に失敗したのかが読み取れます。Firefoxも同様に、証明書の問題か通信方式の問題かを区別して表示します。

代表的なエラーコードと、そこから推定できる原因は次のとおりです。

ブラウザの表示	推定される原因
ERR_CERT_DATE_INVALID	証明書の有効期限切れ、または端末の日付と時刻のずれ
ERR_CERT_AUTHORITY_INVALID	信頼されない認証局が発行した証明書（自己署名証明書、社内CA証明書の未配布など）
ERR_CERT_COMMON_NAME_INVALID	証明書のドメイン名とアクセス先が一致していない
ERR_SSL_PROTOCOL_ERROR	TLSハンドシェイクの失敗（TLSバージョンや暗号方式の不一致）
ERR_SSL_VERSION_OR_CIPHER_MISMATCH	サーバ側が古いTLSバージョンにしか対応していない

別ブラウザで開く操作は数十秒で終わります。切り分けの第一手として、問い合わせを受けた時点で試しておくと以降が早くなります。

原因は端末側・社内ネットワーク側・サーバ側の3層に切り分けられる

このエラーの原因は、おおむね端末側・社内ネットワーク側・サーバ側の3層のどこかに収まります。どの層かを先に決めてしまえば、試すべき対処は一気に減ります。

切り分けの判断軸は2つだけです。「誰に起きているか（自分だけか、社内の全員か）」と「どのサイトで起きるか（特定の1サイトか、多くのサイトか）」です。

たとえば自分の端末だけで多くのサイトが開けないなら、端末側を疑います。社内の全員が特定の1サイトだけ開けないなら、サーバ側か社内の通信制御を疑います。

この記事の以降の見出しも、この3層の順に並べています。まずは次のフローで、どの層の話なのかを決めてください。

別の端末と別の回線で同じサイトを開いて発生範囲を確かめる

最初にやることは、別の端末と別の回線で同じURLを開いてみることです。これだけで、端末固有の問題か、社内ネットワーク全体の問題かが分かれます。

隣の席のMacで開けるなら、原因はその人の端末にあります。社内の複数台で同じように開けないなら、端末ではなく共通の経路かサーバ側を疑います。

特に効くのが、スマートフォンのWi-Fiを切ってモバイル回線で開く方法です。社内Wi-Fiでは失敗し、モバイル回線では開ける場合、原因は社内ネットワーク側にあると判断できます。

逆にモバイル回線でも同じエラーが出るなら、社内の設備は関係ありません。サーバ側か、その端末自体の設定に絞って調べていきます。

他のHTTPSサイトが開けるかどうかで端末側とサーバ側を分ける

次に、同じ端末で他のHTTPSサイトが開けるかを確認します。ここで「1サイトだけの問題」か「その端末全体の問題」かが分かれます。

特定の1サイトだけ開けないなら、そのサイトのサーバ設定か、社内のフィルタリング設定が原因の候補になります。この場合はサーバ側の見出しを先に読んでください。

多くのサイトで同じエラーが出るなら、端末の日付と時刻のずれ、OSの古さ、セキュリティソフトの動作など、端末側の要因が濃厚です。端末側の対処から順に試します。

どちらに転んだかで読む場所が変わります。1サイトのみならサーバ側、広範囲なら端末側、と覚えておいてください。

発生範囲ごとに疑うべき原因は変わる

ここまでの2つの確認結果を組み合わせると、疑うべき原因はかなり絞れます。発生範囲と対象サイトの組み合わせで整理すると、次のようになります。

発生範囲	対象	疑う原因	参照する見出し
自分の端末だけ	多くのサイト	日付と時刻のずれ、OSやSafariが古い、セキュリティソフトやVPN	端末側の対処（Mac編）・iPhoneとiPad
自分の端末だけ	特定の1サイト	キャッシュやcookieの残存、証明書の信頼設定	端末側の対処（Mac編）
社内の全員	多くのサイト	社内CA証明書の配布漏れ、プロキシやUTMの設定変更	社内ネットワーク
社内の全員	特定の1サイト	サーバ証明書の期限切れ、中間CA証明書の不足、フィルタリングによるブロック	サーバ側・社内ネットワーク
社外の回線でも発生	特定の1サイト	サーバ証明書やTLS設定の問題（相手側の問題）	サーバ側

この表を問い合わせ受付時のヒアリング項目にしておくと、一次切り分けの精度が上がります。ユーザーに聞くのは「他の人はどうか」「他のサイトは開けるか」の2点だけで済みます。

端末側の対処はOSの日付と時刻の確認から始める（Mac編）

Macで発生している場合、上から順に試すのが基本です。ここでは自分の権限だけで実行できる対処を、効果と手軽さの順に並べます。

順番に意味があります。日付と時刻の確認は数十秒で終わり、しかも確認漏れが起きやすい項目でもあるため、必ず最初に置いてください。

逆に、ネットワーク設定の初期化のような影響の大きい操作は最後です。手軽なものから試して、再現するかどうかを1つずつ確認していきます。

日付と時刻のずれは証明書の有効期間の判定を失敗させる

最初に確認するのは、Macの日付と時刻です。端末の時計がずれていると、有効な証明書でも「期限外」と判定されてエラーになります。

証明書の有効期限は、端末が持っている現在時刻と照らして判定されます。時計が数日ずれているだけで、まだ有効な証明書が「まだ有効になっていない」または「期限切れ」と扱われます。

確認は「システム設定」から「一般」→「日付と時刻」と進み、「日付と時刻を自動的に設定」がオンになっているかを見ます。タイムゾーンが実際の勤務地と合っているかも合わせて確認してください。

長期間電源を切っていた端末、内蔵電池が消耗した古い端末、初期化した直後の端末で起きやすい症状です。心当たりがあるなら、ここだけで解決する可能性が高いです。

Safariのキャッシュとcookieを削除して再現するか確認する

日付に問題がなければ、次はキャッシュとcookieを疑います。古いセッション情報が残っていて、現在のサーバの状態と食い違うケースがあります。

判定は簡単で、プライベートウインドウで同じURLを開いてみてください。プライベートウインドウなら開けるという場合、キャッシュやcookieが原因だと切り分けられます。

削除は「設定」→「プライバシー」から、対象サイトのデータを消す方法が影響を抑えられます。全サイトの履歴を消すと各種サービスのログイン状態が切れるため、ユーザーに事前に伝えておきましょう。

VPN・セキュリティソフト・コンテンツブロッカーを一時的に停止して確認する

キャッシュでも解決しない場合は、通信に介在するソフトを疑います。ウイルス対策ソフトのWeb保護機能のように、TLS通信をいったん復号して検査する仕組みが動いていると、ブラウザが受け取る証明書はその製品が発行したものに置き換わります。

VPNクライアント自体は通信の中身を復号するわけではありませんが、経路と名前解決の向き先が変わるため、接続先や受け取る証明書が変わることがあります。VPNの接続を切る、Web保護機能を一時的に停止する、コンテンツブロッカーを無効にする、といった手順で再現の有無を確認してください。

再現しなくなれば原因はそのソフトです。設定の見直しや例外登録で対応し、停止したままの状態で業務を続けさせないようにします。

OSとSafariのバージョンが古いとルート証明書とTLSバージョンが合わない

ここまでで解決しない場合は、OSとSafariのバージョンを確認します。サポートが終了したOSは新しいルート証明書を持たず、サーバ側が求めるTLSバージョンにも対応できないことがあります。

ルート証明書は認証局の入れ替わりに合わせて更新されます。OSが古いままだと、新しい認証局が発行した証明書を「信頼できない」と判定してしまいます。

「システム設定」→「一般」→「ソフトウェアアップデート」から更新できるなら、まずアップデートを試してください。最新OSに更新できない世代のMacであれば、これは設定では解決せず、端末更改の検討対象になります。

iPhoneとiPadではプライベートリレーと構成プロファイルも確認する

iPhoneやiPadで発生している場合は、モバイル端末特有の要因を先に確認します。日付と時刻、キャッシュの削除はMacと考え方が同じなので、前の見出しの手順をそのまま当てはめてください。

モバイル端末に固有なのは、通信経路を変える機能と、会社から配布された構成プロファイルです。どちらもユーザー自身では気づきにくいため、情シス側から確認箇所を指定するのが早道です。

iCloudプライベートリレーとVPNアプリが接続経路を変えている

まず確認したいのが、iCloudプライベートリレーの設定です。この機能をオンにしていると、SafariでのWebブラウジングに加えてDNSの名前解決もAppleの中継経路を通るため、社内で想定している経路と変わります。

社内サイトや検証環境のように、社内ネットワーク内でのみ名前解決できるサイトでは、これが原因で開けなくなることがあります（このときの表示は今回のエラー文言とは限りません）。「設定」からApple IDを開き、iCloudの項目でプライベートリレーの状態を確認してください。

VPNアプリも同様です。個人で入れたVPNアプリが動いていると、業務用の経路と別のルートで接続され、証明書の検証結果が変わります。

一時的にオフにして再現するかどうかを確かめ、原因が特定できたら社内での利用方針を決めておきましょう。なお、恒久的な対応は端末ごとのオン・オフではなく、社内方針として決めておくものです。Appleは、ネットワーク側でプライベートリレー用ドメインの名前解決を返さないようにする方法を案内しており、この場合はユーザーに通知が表示されます。会社支給端末ではMDMの制限で無効化する運用も取れます。

構成プロファイルとMDMで配布した証明書の状態を確認する

会社支給端末では、構成プロファイルと証明書の状態を必ず確認します。確認場所は「設定」→「一般」→「VPNとデバイス管理」です。

ここでは、MDMから配布されたプロファイルが入っているか、含まれている証明書の有効期限が切れていないかを見ます。社内CA証明書が入っていない端末や、期限切れのまま放置された端末は、社内サイトを開いた瞬間にこのエラーになります。

ユーザーには画面の項目名を伝えて、プロファイル名と証明書の有効期限を読み上げてもらうと確認が早く済みます。該当があればMDM側から再配布して解消します。

この症状は端末の問題というより、社内の証明書配布運用の問題です。次の見出しで、その仕組みを詳しく見ていきます。

ネットワーク設定のリセットは最後の手段として位置づける

ネットワーク設定のリセットは効果がある反面、影響も大きい操作です。実施すると、保存済みのWi-Fiパスワードや手動で入れたネットワーク構成がすべて消えます。

そのため、他の手順をひととおり試したあとの最終手段として位置づけてください。実施前には、社内Wi-FiのSSIDと認証情報、プロキシ設定、VPN構成の内容を控えておきます。

リモートで作業している端末では、リセット後に社内ネットワークへ戻れなくなる恐れもあります。出社時に実施する、手順書を先に渡す、といった段取りをセットにしておくと安全です。

社内ネットワークではプロキシのTLS検査と社内CA証明書の配布漏れが典型的な原因

社内の複数人で同じエラーが起きているなら、疑うべきは社内ネットワークの通信制御です。代表的なのが、プロキシやUTMによるTLS検査（SSLインスペクション）に関連する設定漏れです。

この構成では、社内機器がいったん通信を復号して検査し、あらためて暗号化し直します。そのとき端末に届く証明書は、本来のサイトのものではなく社内CAが発行したものに置き換わります。

そのため、端末に社内のルートCA証明書が入っていなければ、ブラウザは「知らない発行元だ」と判断してエラーを出します。仕組みを知らないと原因にたどり着けない、典型的なパターンです。

なお、こうした構成を採っているかどうかは会社ごとに違います。総務省の2025年調査では、インターネット利用企業（n=2,480）のうち、セキュリティ対策として「プロキシ（代理サーバ）等の利用」を挙げた企業は20.5%でした。同じ複数回答設問で「データやネットワークの暗号化」を挙げた企業は27.4%です。

ただし、これはTLS検査の実施率を示す数値ではありません。自社がどの構成なのかは、ネットワーク図と機器の設定で確認してください。

SSLインスペクション環境では社内CA証明書が端末に入っていないとエラーになる

SSLインスペクション環境では、社内CA証明書の配布漏れがそのままこのエラーになります。端末が社内CAを信頼していない限り、検査後に付け替えられた証明書は検証を通りません。

流れを追うと分かりやすくなります。端末からの通信をプロキシが受け取って復号し、内容を検査したうえで、社内CAが発行した証明書を付けて端末に返します。

Macでの確認は「キーチェーンアクセス」を開き、「システム」または「ログイン」キーチェーンの証明書一覧を見ます。社内CAの証明書が存在するか、信頼設定が「常に信頼」になっているか、有効期限が切れていないかの3点をチェックしてください。

証明書が無ければ配布して解決します。入っているのに信頼設定が外れている場合も同じ症状になるため、有無だけで判断しないのがコツです。

なお、TLS検査はプロキシ側に証明書の発行権限を持たせる構成です。検査は社内で1回に限ること、検査機器と社内CAの管理・監査の役割を分けることが望ましいとされています。エラーを消す目的で端末ごとに例外を積み増す運用にはしないでください。

新規キッティング端末とBYOD端末で発生が集中する

社内CA証明書の配布漏れは、発生するタイミングに偏りがあります。入社直後に渡した端末、初期化した端末、修理から戻った端末で起きやすくなります。

理由は単純で、これらの端末は証明書が入っていない状態からスタートするためです。私物端末を業務利用しているBYODの環境も、会社側の配布対象から漏れやすく、同じ状態になります。

対策は、キッティングの手順書に「社内ルートCA証明書のインストールと信頼設定の確認」を項目として組み込むことです。チェックリストに1行入れておくだけで、同じ原因による問い合わせを減らせます。

BYODについては、参加条件として証明書のインストールを明記しておくと運用が安定します。誰がいつ配布するのかを決めておきましょう。

DNS・ファイアウォール・公衆Wi-Fiのログイン画面でも同じ表示になる

社内ネットワークが原因でも、証明書とは無関係なケースがあります。Safariの表示は同じでも、実際には別の要因で通信が遮られていることがあるためです。

社内DNSが古いIPアドレスを返していると、意図しないサーバに接続してしまい、証明書のドメイン名が一致せずにエラーになります。フィルタリング機器がブロック応答を返す構成でも、同じような表示になります。

出張先のホテルや空港の公衆Wi-Fiも要注意です。認証ページへ強制的に転送される仕組みのため、HTTPSのサイトを先に開こうとするとこのエラーになります。この場合はブラウザで認証ページを開き、ログインを済ませれば解消します。

原因が証明書とは限らない、と知っておくだけで切り分けの精度が上がります。エラー文言に引きずられないようにしましょう。

通信経路を守る対策の実施率は2割台にとどまっている（2025年調査）

社内の通信経路まで手が回っている企業は、実は多くありません。総務省の2025年の調査では、インターネットを利用している企業のうち、何らかのセキュリティ対策を実施している企業は98.3%に達しています。

一方で、対策の内訳には差があります。同じ2025年の調査で、端末へのウイルス対策プログラム導入は82.0%でした。ID・パスワードによるアクセス制御は60.4%、ファイアウォールの設置・導入は51.9%です。

これに対して、データやネットワークの暗号化は27.4%、回線監視は21.7%、プロキシ等の利用は20.5%です。

この数値から読み取れるのは、本記事の整理でいう端末を守る対策と通信経路を守る対策の間に、はっきりとした差があることです。SSL/TLSは後者に属する領域です。社内で証明書やTLS設定を確認できる体制が整っていない組織も少なくない、という前提で対応を組み立ててください。

出典: 総務省「令和7年通信利用動向調査」

サーバ側の原因は証明書の期限切れ・中間CA証明書の不足・TLSバージョンの3つが中心

切り分けの結果「相手側の問題だ」と分かったら、次はサーバ側の設定を確認します。自社が管理するサイトや社内システムであれば、情シスがそのまま対応する範囲です。

サーバ側の原因は、おおむね3つに集約されます。証明書の有効期限切れ、中間CA証明書の設定漏れ、そしてTLSバージョンの非対応です。

症状の出方がそれぞれ違うため、ユーザーからの申告内容で当たりを付けられます。「全員が同時に」なのか「一部の人だけ」なのかが、大きな手がかりになります。

証明書の有効期限切れは特定の日を境に全ユーザーで一斉に発生する

「昨日まで見えていたのに、今朝から全員見えない」という症状なら、まず証明書の有効期限切れを疑ってください。期限は日時で切り替わるため、影響が一斉に出るのが特徴です。

確認は、ブラウザでそのサイトを開き、アドレスバーの鍵マークから証明書の詳細を表示します。有効期間の終了日が過去になっていれば、原因は確定です。

証明書の自動更新を設定していても、更新処理が途中で止まっていることがあります。更新用のポート開放が変わった、更新スクリプトを動かすサーバの認証情報が切れた、といった理由で静かに止まるケースが典型です。

対応は証明書の再発行と入れ替えになります。入れ替え後は必ずブラウザで開き直し、有効期間が更新されているかを確認してください。

中間CA証明書の設定漏れは環境によって「見える人と見えない人」が分かれる

「一部の人だけ開ける」という問い合わせなら、中間CA証明書の設定漏れが候補になります。この症状は、サーバが証明書チェーンを完全に配信していないときに起こります。

サーバ証明書は、ルート認証局から中間認証局を経て発行されます。サーバが中間CA証明書を一緒に送っていないと、ブラウザは信頼の連鎖をたどれません。

ここで差が出ます。過去に別サイトで同じ中間CA証明書を受け取ってキャッシュしている端末は開けてしまい、キャッシュしていない端末では開けません。同じ社内でも、端末ごとに結果が分かれるのはこのためです。

確認には、証明書チェーンを検証できるオンラインのSSLチェックツールを使うと早いです。ただし社内向けのサーバでは、ホスト名やURLを外部サービスに送ることになるため、社内ポリシー上の可否を確認するか、コマンドラインのTLS確認ツールで手元で確認する方法も検討してください。チェーンの不足を指摘されたら、サーバに中間CA証明書を追加設定して解消します。

古いTLSバージョンしか有効でないサーバはブラウザ側から接続を拒否される

3つ目は、サーバが古いTLSバージョンにしか対応していないケースです。TLS 1.0や1.1しか有効でないサーバは、ブラウザ側の対応終了によって接続できなくなります。

この場合、証明書には何の問題もありません。それでもブラウザは安全な通信方式で合意できないと判断し、接続を打ち切ります。

社内で起きやすいのは、長く使っている複合機、NAS、ネットワーク機器の管理画面です。ファームウェアの更新でTLS 1.2以上に対応できるかを確認し、対応できない機器は接続方法や更改を検討します。

TLS 1.0と1.1は、国際的な標準化団体によってすでに非推奨とされています。国内のガイドラインでも、これらの継続利用はリスクを受け入れざるを得ない場合に限る例外的な扱いとされ、その例外設定自体も終了させていく方針が示されています。社内の古い機器を更改する際は、この位置づけを説明材料にしてください。

証明書に記載されたドメイン名と、実際のアクセス先が違う場合も同じエラーになります。IPアドレスを直接入力してアクセスしている、旧ドメインのURLがブックマークに残っている、といった原因も合わせて確認してください。

警告を無視して接続を続ける操作は、最後の検知点を自分で外す行為にあたる

ここまでの手順を試しても開けないとき、ユーザーから「詳細を表示から進んでもいいですか」と聞かれることがあります。原則として、この操作をユーザーに案内してはいけません。

理由は、その警告が偽サイトへの接続を止める最後の仕組みとして働いている場合があるからです。JPCERT/CCへのフィッシングサイトに関するインシデント報告件数は、2023年10〜12月期が4,473件、2024年の各四半期は4,781件・5,025件・4,233件・4,780件と推移し、2025年1〜3月期は5,267件でした。

出典: JPCERT/CC「インシデント報告対応レポート」（2023年10〜12月期〜2025年1〜3月期の各号）

この数値から読み取れるのは、偽サイトへ誘導する手口が特定の時期に限らず続いている状況です。サイバー攻撃対策を多層で組んでいない組織では、ブラウザの警告が接続先の異常を知らせる数少ない手段になります。

企業の48.1%が何らかのセキュリティ被害を経験している（2025年調査）

被害は特別な出来事ではありません。総務省の2025年の調査によると、インターネット利用企業のうち、過去1年間に何らかのセキュリティ被害を受けた企業は48.1%でした。

同じ調査の同じ指標をさかのぼると、2017年50.9%、2018年55.6%、2021年52.4%、2022年62.4%、2023年53.9%、2024年46.2%と推移しています。

出典: 総務省「令和7年通信利用動向調査」

この推移から読み取れるのは、2022年をピークに下がったとはいえ、企業の半数近くが被害を経験する状態が続いていることです。減ってきたから安心ではなく、警告表示を「またか」と閉じる習慣が危ういと読むべき水準です。

被害に気づけているかどうかは監視体制の有無で変わる

同じ「被害」でも、調査の設計によって数字は大きく変わります。総務省の2025年の調査では、従業者規模2,000人以上の企業で被害を受けたと回答した割合は64.9%で、全体の48.1%を上回っています。一方、IPAが中小企業等を対象に行った調査では、2023年度に不正アクセス被害を受けたと回答した割合は10.0%でした。

なお、この2つは並べて比較できる数値ではありません。総務省の調査はウイルス感染や標的型メールの受信を含む包括的な設問で、IPAの調査は不正アクセスに限定した中小企業向けのWebアンケートです。調査主体・母集団が異なるうえ、総務省調査の2,000人以上の区分は回答企業数がn=104と少なく、誤差も大きい点に注意してください。

ここから読み取れるのは、同じ現象を測っても定義と母集団で数字が大きく変わるという事実です。監視の仕組みを持たない組織ほど被害を数えられていない可能性があり、そうした組織にとってブラウザの警告は数少ない自動検知の手段です。

出典: 総務省「令和7年通信利用動向調査」／総務省「令和7年通信利用動向調査報告書」／IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査 報告書」／JPCERT/CC「インシデント報告対応レポート」

進んでよい場面と絶対に進んではいけない場面を分ける

進んでよい場面もあります。分かれ目は、原因が特定できているかどうかと、誰が判断しているかです。

たとえば、自己署名証明書を使った社内の検証環境に、管理者自身が証明書の内容を確認したうえで接続するのは、原因が分かったうえでの判断です。一方、外部サイトでユーザーが原因も分からずに進むのは、まったく別の行為になります。

ID・パスワードや決済情報を入力する画面では、原因が分かっていても進まないでください。認証情報が漏れた場合の影響は、ページが開けない不便さと釣り合いません。実際、保存したパスワードの漏えいを知らせるブラウザの警告と同じく、この警告も無視して進む前提で扱うものではありません。

なお、有効な証明書を取得している偽サイトも存在するため、鍵マークが出ていれば安全とは言い切れません。警告が出ていないことは、接続先が正しいことの証明にはならないと考えておきましょう。

解決しない場合は発生条件を整理してサイト運営者・ベンダーへエスカレーションする

ひととおり試しても解決しない場合は、自分で抱え込まずにエスカレーションします。このとき大事なのは、伝える情報をあらかじめ整理しておくことです。

「開けません」だけの連絡では、相手も切り分けをゼロから始めることになります。発生条件が揃っていれば、相手側は原因の候補をすぐに絞れます。

ここでは、連絡先の判断と、伝えるべき情報の型をまとめます。そのままコピーして問い合わせフォームに貼れる粒度にしています。

相手先に伝える情報を6項目に整理しておく

問い合わせ時に伝える情報は、次の6項目に固定してください。これだけあれば、相手側は再現条件を把握できます。

項目	記載する内容の例
発生日時	2026年8月20日 9時30分ごろ／断続的に発生
対象URL	https://で始まる完全なURL（トップページか特定ページかも記載）
端末とOS	機種名とOSのバージョン（例: MacBook Air／macOS、iPhone／iOS）
ブラウザと表示内容	Safariでは接続エラー、ChromeではERR_CERT_DATE_INVALID
回線	社内Wi-Fi（プロキシ経由）／モバイル回線では再現しない
再現範囲	特定の1名のみ／同一部署の5名／社内全員

この6項目は、社内のヘルプデスク受付フォームにもそのまま流用できます。受付時に埋めてもらう運用にすると、一次切り分けの時間が短くなります。

社内システムが対象なら情シス、外部サイトなら運営者に切り分けて連絡する

連絡先は、対象システムを誰が管理しているかで決まります。社内システムや社内ネットワーク経由の問題であれば情シス、外部の一般サイトであればそのサイトの運営者です。

外部サイトの証明書やTLS設定の問題は、利用者側では解決できません。運営者の対応を待つか、代替の手段で業務を進めるかの判断になります。

SaaSを利用している場合は、まずサービスのステータスページや障害情報を確認してください。すでに障害として公表されていれば、問い合わせをせずに復旧見込みが分かります。

社内の機器が原因の場合は、保守ベンダーへの連絡が必要になることもあります。機器の型番と保守契約の有無を先に確認しておくと、話が早く進みます。

一時的な回避策は業務影響と引き換えである点を共有する

急ぎの業務では、一時的な回避策を取ることもあります。別のブラウザで開く、社外の回線から一時的に利用する、といった方法です。

ただし、いずれも根本解決ではありません。回避策で業務を続けると、原因が残ったまま忘れ去られ、別の場面で同じ問題が再発します。

回避策を使ったときは、いつ・誰が・どの方法で回避したかを記録に残してください。恒久対応の起票までをセットにしておくと、対応が中途半端に終わりません。

証明書の警告を回避するために設定を変更する方法は、案内しないでください。その端末だけ検証を弱めることになり、本来止まるべき通信も通ってしまいます。

再発防止は証明書の期限管理を担当者と手順に落とし込むことから始まる

同じ問い合わせを繰り返さないために効くのは、証明書の期限管理を仕組みにすることです。担当者と手順を決めるところから始めます。

というのも、こうした定期タスクは体制が薄い組織ほど抜けやすいからです。IPAが中小企業等を対象に行った2024年度の調査を見てみます。情報セキュリティ対策の体制について、「専門部署（担当者）がある」と回答したのは9.3%でした。

兼務だが担当者が任命されていると回答した企業も21.0%にとどまります。

同じ調査では、従業員に対する情報セキュリティ教育を特に実施していないと回答した企業が63.6%にのぼります。

ここから読み取れるのは、日常的にセキュリティ運用を回す前提が組織側に用意されていないケースが多い、という構造です。証明書の更新のように「年に1回、期限までに必ず実施する」種類のタスクは、担当が固定されていない組織ほど抜け落ちます。

出典: IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査 報告書」／IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査 概要版」／総務省「令和7年通信利用動向調査」

社内で使っている証明書を棚卸しして期限を一覧化する

最初にやるべきは、社内で使っている証明書の棚卸しです。どこに何枚あるかが分からないままでは、期限管理のしようがありません。

対象は公開サイトだけではありません。社内Webシステム、VPN機器、複合機、NAS、ネットワーク機器の管理画面、そして社内CAそのものも対象に入れてください。

一覧に持たせる項目は、次のとおりです。

項目	記載する内容
対象システム	サーバ名・機器名・URL
証明書の種類	公的な認証局の証明書／社内CA発行／自己署名
有効期限	年月日（更新の起点にする）
発行元	認証局名または社内CA
更新担当	部署名と担当者名（兼務でも明記する）
更新手順	手順書の保管場所へのリンク

この一覧は、作った時点で半分は目的を達しています。期限の近い証明書が一目で分かるだけで、突然の全社停止を避けられます。

期限の通知と更新手順を担当者の異動に耐える形で残す

一覧を作ったら、次は通知と手順です。人が覚えている状態のままにせず、仕組みとして動くようにします。

やることは3つです。期限の一定期間前に、カレンダーやチケットで自動的に通知されるようにします。次に、自動更新が使える環境では更新自体を自動化します。

そして、更新手順を手順書として残します。

通知は期限の60日前と30日前など、複数回に分けておくと安全です。担当者が異動しても、次の担当者が手順書だけで作業できる状態を目指します。

あわせて、キッティング手順に社内ルートCA証明書のインストールと信頼設定の確認を組み込んでおきましょう。新しい端末が増えるたびに同じ問い合わせが発生する状態を、ここで止められます。

TLSと証明書の運用実態は公的統計では把握されていない

最後に、この領域の特徴に触れておきます。証明書やTLSの運用実態は、公的統計ではほとんど把握されていません。

総務省の2025年の調査を見ると、セキュリティ対策の選択肢はかなり細かく用意されています。Webアプリケーションファイアウォールの設置・導入は19.5%、不正侵入検知システム（IDS）の設置・導入は20.7%でした。外部接続の際のウイルスウォール構築も29.1%と、製品カテゴリ単位まで数値が取れます。

その一方で、暗号化については「データやネットワークの暗号化」の27.4%という一項目に集約されています。証明書の管理方法、期限切れの発生頻度、TLSバージョンの更新状況を測る項目はありません。

ここから読み取れるのは、よく起きるトラブルであるにもかかわらず、組織的な実態が可視化されていない領域だということです。参照できる業界水準が無い以上、各社が自前で棚卸しと手順を持つしかありません。

出典: 総務省「令和7年通信利用動向調査」

まとめ

「サーバとセキュリティ保護された接続を確立できなかったため、ページを開けません。」は、Safariが暗号化通信を確立できなかったときの表示です。原因は端末側・社内ネットワーク側・サーバ側の3層に分かれます。

対応の要点を4つにまとめます。

• 最初に確認するのは、端末の日付と時刻、別ブラウザでのエラーコード、別回線での再現有無の3点
• 社内の複数人で発生しているなら、社内CA証明書の配布漏れとプロキシのTLS検査を疑う
• 「一部の人だけ開ける」なら中間CA証明書の設定漏れ、「全員が同時に」なら証明書の期限切れを疑う
• 認証情報や決済情報を入力する画面では、警告を無視して進まない

再発防止は、証明書の棚卸しと期限通知、キッティング手順への組み込みで進めます。問い合わせを受けるたびに調べ直す状態から抜け出しましょう。

情シスの学習は「情シスカレッジ」で

証明書やTLSのようなインフラ運用は、担当者個人の知識に依存しがちです。手順書を作っても、前提となる知識が共有されていないと、結局は分かる人にだけ問い合わせが集まります。

情シスカレッジは、新人・ひとり情シスのためのマイクロラーニングLMSです。日々の業務に必要な知識を、短い動画で少しずつ積み上げられます。

導入は5名から可能で、請求書払いにも対応しています。初期設定は約10分で完了します。

情シスカレッジの詳細を見る

※出典
– 総務省「令和7年通信利用動向調査（報道発表資料）」
– 総務省「令和7年通信利用動向調査報告書（企業編）」
– 総務省「令和5年通信利用動向調査の結果」
– 総務省「令和4年通信利用動向調査の結果」
– 総務省「令和3年通信利用動向調査の結果」
– 総務省「平成30年通信利用動向調査の結果」
– 総務省「平成29年通信利用動向調査の結果」
– JPCERT/CC「インシデント報告対応レポート［2023年10月1日～2023年12月31日］」
– JPCERT/CC「インシデント報告対応レポート［2024年1月1日～2024年3月31日］」
– JPCERT/CC「インシデント報告対応レポート［2024年4月1日～2024年6月30日］」
– JPCERT/CC「インシデント報告対応レポート［2024年7月1日～2024年9月30日］」
– JPCERT/CC「インシデント報告対応レポート［2024年10月1日～2024年12月31日］」
– JPCERT/CC「インシデント報告対応レポート［2025年1月1日～2025年3月31日］」
– IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査 報告書」
– IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査 概要版」