【Edge】社内サイト証明書が社外回線だけ失敗する時の条件付きアクセス確認

社内のWebサイトにアクセスする際、社内ネットワークでは問題なく接続できるのに、自宅や出先のテレワーク環境など社外回線経由で接続しようとすると「このサイトは安全に接続できません」などの証明書エラーが表示された経験はないでしょうか。単なる証明書の失効や構成ミスだけでなく、最近では条件付きアクセス(Conditional Access)のポリシーによってアクセスがブロックされ、結果として証明書エラーのように見えるケースが増えています。本記事では、Edgeブラウザで社内サイト証明書が社外回線だけ失敗する原因を、条件付きアクセスの観点から切り分ける方法を解説します。特に、ネットワークの場所に基づくアクセス制御がどのように影響するのかを具体的に確認していきます。

1. 社内サイト証明書エラーの原因:条件付きアクセスが疑われるパターン

社内サイトへのアクセスが社外回線でだけ失敗する場合、原因は大きく分けて二つあります。一つは証明書自体の問題(失効、CRL配布点への到達不能、中間CA証明書の不足など)、もう一つは条件付きアクセスによるアクセス制御です。特に後者は、Azure ADに参加している端末やハイブリッド参加端末でよく発生します。条件付きアクセスのポリシーで「すべての場所」または「信頼できない場所」からのアクセスをブロックする設定になっていると、社外回線からアクセスした際に認証は通るものの、リソースへのアクセスが拒否され、ブラウザに証明書エラーと似た画面が表示されることがあります。

この現象が起こる背景には、証明書ベースの認証(クライアント証明書)を要求するサイトで、条件付きアクセスがクライアント証明書の提示を妨げるケースがあります。例えば、条件付きアクセスが「デバイス準拠」を要求し、準拠していないデバイスからのアクセスをブロックすると、サーバー側でクライアント証明書のネゴシエーションが行われず、結果として「このサイトは安全に接続できません」というエラーが表示されるのです。したがって、エラーメッセージだけでは原因を特定できず、WindowsのイベントログやAzure ADのサインインログを確認する必要があります。

2. エラーメッセージとダイアログから原因を絞る

Edgeで証明書エラーが表示されたとき、まずはエラーページの詳細を確認しましょう。以下の表に、典型的なエラー表示とその意味をまとめました。

エラーメッセージ	主な原因	社外回線での発生頻度
「このサイトは安全に接続できません」	証明書の検証エラー(失効、ホスト名不一致、CA不明)	高い
「アクセスが拒否されました」または「このサイトにはアクセスできません」	条件付きアクセスやプロキシによるブロック	中程度
「証明書失効情報を確認できません」	CRL/OCSPサーバーに社外から到達できない	高い
「クライアント証明書が必要です」	サーバーがクライアント証明書を要求しているが提示できない	低い(条件付きアクセスが原因の場合あり)

また、Edgeのアドレスバーに鍵マークが表示され、クリックすると「この接続は完全には保護されていません」と出る場合は、証明書の一部の検証に失敗しています。一方、アドレスバーに「ブロックされました」や「403 Forbidden」が表示される場合は、条件付きアクセスがブロックしている可能性が高いです。

2.1 証明書の失効確認が原因の場合

社外回線から証明書の失効情報を取得するために、CRL配布点(CDP)やOCSPレスポンダにアクセスできない場合、ブラウザは証明書を失効とみなしてエラーを表示します。これは、社内ネットワークではプロキシ経由でアクセスできるが、社外では直接アクセスできない、またはファイアウォールでブロックされていることが原因です。この場合、証明書自体は有効でも社外からは正常に検証できません。

2.2 条件付きアクセスが原因の場合

条件付きアクセスポリシーが「場所」条件で社外からのアクセスをブロックしている場合、認証は成功するがリソースアクセスが拒否されます。このとき、ブラウザには「このサイトにアクセスできません」や「403 Forbidden」が表示され、証明書エラーと見分けがつきにくいことがあります。さらに、条件付きアクセスがクライアント証明書の提示を要求する設定になっていると、証明書のネゴシエーションフェーズで失敗し、結果的に証明書エラーメッセージが表示されることもあります。

3. 社外回線だけで発生する場合の確認手順

以下の手順で、原因が証明書の問題か条件付きアクセスの問題かを切り分けてください。ここでは一般ユーザーが自分でできる範囲と、管理者に依頼すべき内容を分けて説明します。

1. エラーページのURLとエラーメッセージを記録する。 画面全体のスクリーンショットを撮っておくと、後で管理者に伝える際に役立ちます。特にアドレスバーのURLと鍵マークの状態、エラーページの文字列を正確に控えてください。
2. 社内ネットワークに接続して同じサイトにアクセスする。 社内回線でアクセスできる場合は、証明書の基本的な構成は正しい可能性が高いです。社内でも同じエラーが出るなら、証明書そのものが失効しているか、デバイス全体の問題です。
3. Edgeのセキュリティレポートを確認する。 アドレスバー左の鍵マークをクリックし、「接続はセキュリティ保護されています」などの表示を確認。さらに「証明書」をクリックして証明書パスと失効情報を確認します。社外回線で「証明書失効情報を確認できません」と表示されている場合、CRL/OCSPの問題です。
4. Windowsイベントビューアーを確認する。 「Windowsログ」→「システム」または「アプリケーション」で、ソースが「Schannel」や「Edge」のエラーを検索します。特にSchannelイベントID 36888や36874は証明書エラーに関係します。条件付きアクセスのブロックはイベントログに直接記録されないため、後述のAzure ADサインインログが必要です。
5. 管理者にAzure ADサインインログの確認を依頼する。 条件付きアクセスが原因かどうかを特定するには、Azure ADのサインインログを見る必要があります。自分では見られないので、管理者に以下の情報を伝えて依頼します。日時、ユーザー名、アクセス先URL、エラーメッセージ、デバイス情報(OS、Edgeバージョンなど)。
6. テスト用の別ネットワークで試す。 モバイル回線(テザリングなど)や別の社外Wi-Fiからアクセスして、現象がネットワーク依存かどうかを確認します。特定のネットワークだけで起こる場合、そのネットワークのファイアウォールやプロキシが原因かもしれません。
7. Edgeの設定を初期状態に戻して試す。 「設定」→「プライバシー、検索、サービス」→「セキュリティ」→「セキュリティチェック」を実行し、問題がないか確認します。また、「設定」→「システムとパフォーマンス」→「起動時の動作」で拡張機能を無効にして再起動し、拡張機能が原因でないか切り分けます。

3.1 失敗パターン:CRL配布点への到達不能

あるユーザーが自宅のWi-Fiから社内のポータルサイトにアクセスしたところ、「このサイトは安全に接続できません」と表示されました。社内では問題なくアクセスできていました。エラーページの詳細を開くと「証明書失効情報を確認できませんでした。サーバーの応答がありません。」と表示されていました。このケースでは、証明書のCRL配布点が社内ネットワークからしか到達できない場所にあり、社外のDNS解決やファイアウォールでブロックされていました。解決策として、管理者がCRL配布点をインターネットからアクセス可能にするか、OCSPステープリングを有効にすることで改善しました。

4. 条件付きアクセスの設定による影響の検証

条件付きアクセスが原因である場合、以下のようなポリシー設定が疑われます。

ポリシー条件	社外回線での影響	確認方法
場所条件:「信頼できる場所」からのアクセスを許可	社外IPは信頼できる場所と見なされずブロック	Azure ADサインインログで「場所」の情報を確認
デバイス条件:「準拠済みデバイス」が必要	社外ではデバイス準拠状態が評価されずブロック	Intune/ConfigMgrのデバイスコンプライアンス状況確認
クライアントアプリ条件:「ブラウザー」に制限	Edgeはブラウザーとして扱われるが、追加条件でブロック	サインインログの「クライアントアプリ」列
リスク条件:「サインインリスク」が中以上	社外からのサインインでリスクが高く評価されブロック	Azure AD Identity Protectionのレポート

条件付きアクセスによるブロックの場合、通常は「アクセスが拒否されました」というページが表示されますが、サーバー側の設定によっては証明書エラー画面にリダイレクトされることもあります。また、クライアント証明書を要求するWebサイトでは、条件付きアクセスがデバイス準拠をチェックする過程でクライアント証明書の提示がスキップされ、結果として証明書エラーとなるパターンもあります。

4.1 管理者に伝えるべき情報

原因を特定するために、管理者には以下の情報を伝えてください。

• 発生した日時とタイムゾーン: 正確な時刻はログ検索に不可欠です。
• ユーザー名とデバイス名: 影響を受けるアカウントと端末を特定します。
• アクセス先のURLとエラーメッセージのスクリーンショット: 特にエラーページのURLバーと本文を撮影します。
• ネットワーク情報: 使用したWi-FiのSSID、VPNの有無、IPアドレス(可能なら)。
• ブラウザのバージョンと証明書の詳細: Edgeのメニュー→「ヘルプとフィードバック」→「Microsoft Edge について」からバージョン確認。エラーページで「証明書」をクリックして、発行先、発行者、有効期限をメモ。
• 社内回線でのアクセス可否: 社内ネットワークでは成功したかどうかを明記。

4.2 条件付きアクセスポリシーの一時的な回避

ユーザー側でできることは限られていますが、管理者がテスト用に「すべてのユーザー」から「すべての場所」へのポリシーを一時的に緩和して確認してもらうことが可能です。ただし、セキュリティに影響するため、通常は行わないでください。また、VPNを使用して社内ネットワークに接続することで、場所条件を回避できる場合もあります。社内VPNが利用可能なら、VPN接続後にアクセスを試してください。VPN接続後は社内IPアドレスとみなされるため、条件付きアクセスの場所条件をパスできる可能性があります。

5. よくある質問

Q1. 証明書を再インストールすれば直りますか?

いいえ、証明書の再インストールが有効なのは、証明書が破損している場合や期限切れの場合だけです。社外回線だけで失敗するケースの多くは、証明書の失効情報取得不可や条件付きアクセスが原因なので、再インストールでは解決しません。

Q2. 自宅のWi-Fiを変えれば直りますか?

可能性は低いです。ただし、自宅のプロバイダが特定のOCSPやCRLへのアクセスをブロックしている場合、別のネットワークで試す価値はあります。モバイル回線で成功すれば、自宅のネットワーク設定が原因です。

Q3. 管理者に連絡する前に自分で確認できることはありますか?

上記の手順1～4(エラーメッセージ記録、社内比較、セキュリティレポート、イベントビューアー)は自分で可能です。イベントビューアーの確認には管理者権限が必要な場合もありますが、多くの会社PCではユーザーでもシステムログの参照が可能です(特にSchannelイベントは閲覧できることが多い)。

Q4. 条件付きアクセスが原因の場合、ユーザー側で何か設定変更できますか?

通常、ユーザー側で条件付きアクセスポリシーを変更することはできません。管理者にポリシーの見直しを依頼するか、VPN接続などの回避策を試すことになります。

6. まとめ

社内サイト証明書が社外回線だけ失敗する場合、原因は証明書の失効情報取得問題か条件付きアクセスによるブロックが大半です。エラーメッセージの種類を確認し、社内ネットワークと社外ネットワークでの動作を比較することで、原因を絞り込めます。自分でイベントログを確認するなど一次切り分けを行った上で、管理者にAzure ADサインインログの調査を依頼するのが効率的です。条件付きアクセスが原因の場合、VPN接続による回避が有効なこともありますが、根本的な解決には管理者によるポリシー設定の見直しが必要です。証明書エラーと一言で言っても、その背後には複数の要因が潜んでいるため、落ち着いて手順を踏むことが重要です。

🧭

Microsoft Edgeトラブル完全解決データベース ページが開かない・パスワードが消えた・動作が重いなど、Edgeの困りごとを設定・仕組みから即解消。逆引きリファレンスとして活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。