Microsoft Edge を 122.0.2365.66 に更新後、特定の銀行サイトで「このサイトは安全ではありません（DLG_FLAGS_INVALID_CA）」が出て先へ進めない――そんな相談が増えています。Chrome や Firefox では閲覧できるのに Edge だけ弾かれる。この現象は多くのケースで Bitdefender の「Encrypted Web Scan（HTTPS スキャン）」が関与しており、設定を見直すことで安定して解消できます。本記事では原因の仕組みから安全な回避策、検証・運用までを実務レベルで詳説します。
発生している症状と再現環境
まずは実際に報告されている状況を整理します。
- Edge を 122.0.2365.66 に更新後、特定の銀行サイトで DLG_FLAGS_INVALID_CA（「このサイトは安全ではありません」）と表示されてアクセス不可。
- 同一 PC でも Chrome／Firefox は正常表示。問題は Edge に限定。
- キャッシュ削除／拡張機能オフ／証明書の手動インポート（Chrome からエクスポートして
certmgr.mscで Trusted Root に登録）／thisisunsafe によるバイパス、いずれも効果なし。 - Bitdefender の Encrypted Web Scan をオフにするとエラーが消えることを確認。
症状のポイントを表で把握
| 項目 | 状況 | 補足 |
|---|---|---|
| 影響ブラウザ | Microsoft Edge 122 以降 | Chromium ベースだが検証仕様の差異が要因 |
| 対象サイト | 一部の銀行ドメイン | 例：connect.bankname.co.nz（仮名） |
| エラー内容 | DLG_FLAGS_INVALID_CA | 「発行元 CA が無効」と判断された場合に表示 |
| 切り分け結果 | Bitdefender HTTPS スキャンが関与 | Encrypted Web Scan をオフで解消 |
なぜ起きるのか：技術的背景（わかりやすく）
銀行サイトは TLS で暗号化され、ブラウザは サーバ証明書の連鎖（ルート→中間→エンドエンティティ） を検証して「信頼できる第三者が署名しているか」を確かめます。ところがウイルス対策ソフトの一部機能（Encrypted Web Scan など）は、悪性コンテンツを見つけるために HTTPS 通信をいったん復号し再暗号化します（いわゆる MITM 型スキャン）。このときローカルで生成した「代理証明書」でブラウザと通信するため、ブラウザ側は「銀行の本来の証明書」ではなく「ローカルで差し替えられた証明書」を受け取ります。
Edge 122 以降では、この 代理証明書の提示やチェーンの作り方が厳密に検証され、以下のような条件に引っかかると DLG_FLAGS_INVALID_CA でブロックします。
- ローカルに挿入された独自ルート証明書の属性やチェーン提示が要件を満たさない。
- 中間 CA の提示順や Key Usage/EKU の整合性が適切でない。
- CT（Certificate Transparency）や HSTS 要件とローカル検査の兼ね合いで安全性が担保できないと判断。
結果として、Bitdefender の Encrypted Web Scan が銀行サイトとの TLS を「置き換え」→ Edge が CA 無効と判断→ DLG_FLAGS_INVALID_CA が発生、という流れになります。Chrome／Firefox で発生しないのは、それぞれの証明書検証実装や許容条件が Edge と異なるためです。
5分でできる原因切り分け手順
- Edge で問題サイトにアクセスし、エラーを再現する（スクリーンを控える）。
- Bitdefender を開き、Protection > Online Threat Prevention > Encrypted Web Scan を一時的にオフにする。
- Edge を再起動し、同じ URL にアクセスする。
- エラーが消えれば、HTTPS スキャンが原因であることが確定。
- Chrome／Firefox で同じ URL を開き、証明書の発行者名が 銀行の実 CA（DigiCert/GlobalSign 等） になっていることを確認する。Edge で発行者が Bitdefender 等に変わっていれば差し替えが起きている証拠です。
解決の全体像と推奨フロー
回避策は大きく 3 つ。まずは 例外登録（推奨）を試し、だめなら一時的に機能をオフ、パッチ配布後に元へ戻します。
回避策比較表
| 方法 | 概要 | メリット | デメリット |
|---|---|---|---|
| A. Encrypted Web Scan を無効化 | Bitdefender → Protection → Online Threat Prevention → Encrypted Web Scan をオフ | 即効性があり設定が簡単 | 全 HTTPS サイトでスキャンが停止。セキュリティ低下 |
| B. 例外登録（推奨） | 同画面の Manage Exceptions に銀行ドメイン connect.bankname.co.nz を追加 | 他サイトのスキャンは維持、影響範囲を極小化 | ドメインが増えると管理負荷。記入ミスに注意 |
| C. アップデート待ち | Bitdefender が Edge の新しい検証仕様へ対応するパッチを待つ | セキュアなまま恒久対応が期待できる | 時期未定。A/B の暫定対応が必要 |
各方法の具体的手順
A. Encrypted Web Scan を無効化（短期の応急処置）
- Bitdefender を起動 → Protection を開く。
- Online Threat Prevention を選択。
- Encrypted Web Scan のトグルをオフ。
- Edge を再起動 → 銀行サイトへアクセスし動作確認。
- 作業後は必要に応じてオンへ戻す（銀行利用時のみオフ → 利用後オンが安全）。
B. 例外登録（推奨の恒久回避）
- Bitdefender → Protection → Online Threat Prevention → Encrypted Web Scan。
- Manage Exceptions を開き、正確なホスト名を追加（例：
connect.bankname.co.nz）。 - ワイルドカードを使う場合は最小限に（
*.bankname.co.nzなど）。不要に広げない。 - Edge を再起動し、証明書の発行者が銀行の正規 CA に戻っていることを確認。
C. アップデート待ち（恒久対応）
- Bitdefender の定義・本体アップデートを定期適用。
- 更新後に Encrypted Web Scan をオンへ戻し、例外設定をいったん削除して再検証。問題なければ例外保守から解放されます。
補足：thisisunsafe バイパスは非推奨
Edge の隠しバイパス（thisisunsafe）は検証を強制突破するデバッグ手段に過ぎません。恒常運用や業務端末では 絶対に使わないでください。
「銀行側や Windows の問題ではない」理由
- エラーは ローカルで挿入された代理証明書に起因。銀行サーバや Windows ルートストアが壊れているわけではありません。
- 企業・学校などのプロキシ／フィルタリング（Zscaler、SWG、DLP など）でも同種の差し替えが行われ、同様のブロックが発生します。
- Edge の検証が厳格化したことで「以前は通っていたグレーなチェーン」が落ちるようになっただけ、という理解が実務的です。
安全性と運用の考え方（セキュリティ低下を最小に）
HTTPS スキャンを全面停止すると、マルウェアやフィッシング検出の一部が効かなくなります。以下の方針を組み合わせてリスクを抑えましょう。
- 例外は最小範囲（ホスト単位、必要なサブドメインのみ）。
- 銀行利用が終わったら、Encrypted Web Scan をオンへ戻す運用ルール。
- ブラウザ側の保護機能（スマートスクリーン、閲覧保護、サンドボックス）を有効化。
- Windows のリアルタイム保護や OS 更新を最新維持。
運用判断のヒント
| 選択肢 | 利便性 | 安全性 | 推奨度 |
|---|---|---|---|
| 例外登録（銀行ドメイン限定） | 高 | 中〜高（範囲が限定される） | ◎ |
| Encrypted Web Scan 全面オフ | 高 | 中（全サイトでスキャン停止） | ○（短期のみ） |
| ベンダーパッチ待ち | 中 | 高 | ◎（恒久） |
企業・学校など管理環境での注意点
エンドポイントの HTTPS インターセプトが「ファイアウォール／SWG 側」で行われる場合、個人端末と手順が異なります。次を確認しましょう。
- 端末が「組織配布のルート証明書」を Local Machine/Root に保持しているか。
- Edge の ユーザープロファイルとマシンストアのどちらを参照しているか（環境により挙動差）。
- 銀行ドメインを検査対象外にする SWG 側の例外ポリシーの有無。
組織管理下では、端末側のセキュリティ機能を勝手にオフにしないこと。ネットワーク側の例外ルールでピンポイントに回避するのが基本方針です。
検証チェックリスト（導入前・後に確認）
| 確認項目 | 見る場所 | 期待値 |
|---|---|---|
| 証明書の発行者 | Edge のサイト情報 → 証明書 | 銀行の正規 CA（例：DigiCert、GlobalSign 等） |
| チェーンの最上位 | 証明書の「証明のパス」 | OS 信頼済みルート（ローカル代理ではない） |
| 例外が効いているか | Bitdefender の Manage Exceptions | 対象ホストのみ例外。過剰なワイルドカードなし |
| 再発有無 | OS/AV/Edge アップデート後に再テスト | エラー再現なし |
よくあるつまずきと対処
| 現象 | 考えられる原因 | 対処 |
|---|---|---|
| 例外登録したのに直らない | ホスト名の誤り、サブドメイン抜け、HTTP→HTTPS リダイレクトで別ホストに移動 | 正確な FQDN を再確認。必要なサブドメインを最小限で追加 |
| Chrome/Firefox は OK、Edge だけ NG | Edge の検証仕様差、MITM との相性 | 本記事の手順で HTTPS スキャンを例外化／無効化して確認 |
| thisisunsafe で通る | 検証を強制突破しているだけ | 恒久利用は厳禁。例外登録またはベンダー修正を待つ |
| 証明書を Trusted Root に入れたがダメ | Edge の厳格化によりローカル代理の提示が拒否 | ルート追加の力業は避け、HTTPS スキャン側の設定で解消 |
コマンドでの確認（上級者向け）
PowerShell でローカルルートに Bitdefender 系の証明書があるかを確認できます。
PowerShell（管理者）:
Get-ChildItem -Path Cert:\LocalMachine\Root |
Where-Object { $_.Subject -match "Bitdefender" } |
Select-Object Subject, Thumbprint, NotAfter
ユーザーストアを含めて検索する場合：
Get-ChildItem -Path Cert:\CurrentUser\Root |
Where-Object { $_.Subject -match "Bitdefender" } |
Select-Object Subject, Thumbprint, NotAfter
certutil での簡易検索：
certutil -store -user Root | findstr /I Bitdefender
OpenSSL が使える環境なら、実サーバ証明書のチェーンを見ることも可能です（差し替えがない参照系環境で実施）。
openssl s_client -connect connect.bankname.co.nz:443 \
-servername connect.bankname.co.nz -showcerts
Edge 固有のポイントと誤解しやすい点
- 「Windows のルートストアへ入れれば何でも通る」という時代ではありません。提示チェーンの作法や拡張属性、ブラウザの追加検証が関与します。
- 古い Edge へロールバックするのは非推奨。Chromium 系ブラウザは自動更新前提で設計され、旧版には脆弱性が残ります。
- 「銀行側の証明書が悪い」と決めつけない。Chrome／Firefox が通る時点で、銀行側が広範囲に壊れている可能性は低いです。
例外登録の書き方（実務の勘所）
| 用途 | 記入例 | 注意 |
|---|---|---|
| 単一ホスト | connect.bankname.co.nz | 最も安全。まずはこれから。 |
| サブドメイン全域 | *.bankname.co.nz | 範囲が広がる。必要なときのみ。 |
| 別ブランド・別環境 | online.bankname.co.nz / secure.bankname.com | 実際の遷移先を FQDN で確認して最小化。 |
再発防止と運用チェックポイント
- Bitdefender／Edge／Windows の更新後に 回帰テストをルーチン化（対象 URL リストを用意）。
- 例外リストは台帳化して棚卸（担当者／追加理由／追加日／対象 URL／見直し日）。
- 銀行側のドメイン変更や新サービス追加に備え、最小限のワイルドカードを運用ポリシーに明記。
- 利用者向けの簡易手順書（例外のオンオフ、確認方法、問い合わせ窓口）を作成。
FAQ（よくある質問）
Q. 銀行に問い合わせるべき？
A. ほとんどのケースで不要です。ローカルの HTTPS スキャン差し替えが原因であり、銀行側では再現できません。まずは本記事の手順で切り分けを。
Q. 例外登録だけで本当に大丈夫？
A. 例外を 対象ドメインに限定し、他の保護機能を有効化していれば実務上のリスクは小さく運用できます。広範囲のワイルドカードや恒久的な全面オフは避けてください。
Q. 証明書を「信頼されたルート」に輸入すれば解決？
A. うまくいかないことが多い上、将来の互換性を損ねやすい対応です。ウイルス対策側の設定で回避するのが筋です。
Q. 他のセキュリティ製品でも起きる？
A. HTTPS スキャン（MITM）方式を採る製品やプロキシなら原理的に同じ事象が起き得ます。発生時は「その製品の HTTPS 検査の例外設定」を確認してください。
Q. Edge だけ NG なのはなぜ？
A. 同じ Chromium 系でも各ブラウザで証明書検証の細部が異なり、Edge 122 以降ではより厳密な条件が導入されています。その差が表面化しています。
実務現場向け「ワークフロー」テンプレート
1) 事象受付：
- 端末情報（OS/Edge/Bitdefender のバージョン）を収集
- エラー画面のスクリーンショットを取得（URL/時刻を含む）
2. 切り分け（ローカル）：
* Bitdefender Encrypted Web Scan を一時オフ → 再現確認
* Edge、Chrome、Firefox の比較
3. 暫定対応：
* Manage Exceptions に銀行ドメインを登録（最小範囲）
* 利用後は機能をオンへ戻す
4. 恒久対応：
* ベンダーパッチ適用後に例外解除の再検証
* 台帳更新・周知・ナレッジ化
5. 終了判定：
* 連続 2 回の回帰テストで再現なし
* 例外は必要最小限のみ残すまとめ（要点のおさらい）
結論：Edge のアップデートで TLS 検証が強化され、Bitdefender の HTTPS スキャン用プロキシ証明書が認識されなくなったことが直接の原因。現時点では「銀行ドメインを Bitdefender の例外に登録」するか「Encrypted Web Scan を一時停止」すれば解消できます。ベンダーから修正が出たら設定を元に戻し、例外を削減するのが最善策です。
すぐ使えるチェックリスト（配布用ミニ版）
- Edge 122 以降 ＋ 銀行サイトで DLG_FLAGS_INVALID_CA？ → はい。
- Bitdefender → Protection → Online Threat Prevention → Encrypted Web Scan をオフ → 正常表示？ → はい＝原因確定。
- Manage Exceptions に
connect.bankname.co.nzを追加 → 再テスト。 - 成功したら機能をオンへ戻す。パッチ後に例外の棚卸。
- thisisunsafe は使わない。ロールバックもしない。
コメント