NET::ERR_CERT_AUTHORITY_INVALID: この接続ではプライバシーが保護されません — 修正方法

NET::ERR_CERT_AUTHORITY_INVALIDとは？

NET::ERR_CERT_AUTHORITY_INVALIDは、Chrome、Edge、またはその他のChromiumベースのブラウザが、WebサイトのSSL証明書に署名した認証局（CA）を信頼していない場合に表示されるブラウザのセキュリティエラーです。ブラウザは接続をブロックし、「この接続ではプライバシーが保護されません」という警告を表示して、潜在的に不正なWebサイトからユーザーを保護します。

ERR_SSL_PROTOCOL_ERROR（TLSハンドシェイク自体が失敗したことを意味する）とは異なり、ERR_CERT_AUTHORITY_INVALIDはハンドシェイクが完了したが証明書の検証ステップが失敗したことを意味します。ブラウザは証明書を受け取り、検査し、信頼できないと判断しました。

Chromiumの内部エラーコードはnet::ERR_CERT_AUTHORITY_INVALID（エラーコード-202）です。これは証明書エラーファミリーに属し、ERR_CERT_DATE_INVALIDやERR_SSL_VERSION_OR_CIPHER_MISMATCHなどの関連エラーが含まれます。

各ブラウザでのERR_CERT_AUTHORITY_INVALIDの表示

異なるブラウザは同じ問題に対して異なるエラーメッセージを表示します。何を探すべきかを知ることで、認証局の問題なのか別のSSLエラーなのかを診断できます。

SSL証明書の信頼の仕組み（信頼チェーン）

このエラーが発生する理由を理解するには、ブラウザがSSL証明書を検証する方法を知る必要があります。すべての証明書は、ルート認証局（CA）に遡る信頼チェーンの一部です。

ブラウザがHTTPS経由でWebサイトに接続すると、サーバーはSSL証明書と中間証明書を送信します。ブラウザはチェーンをたどります：リーフ証明書（Webサイトの証明書）が中間CAによって署名されていること、そして中間CAがブラウザが既に信頼しているルートCAによって署名されていることを確認します。最新のブラウザとオペレーティングシステムには、DigiCert、Let's Encrypt（ISRG Root）、Sectigo、GlobalSignなどの組織から約150のプリインストールされたルートCA証明書が付属しています。

このチェーンのいずれかのリンクが壊れている場合（ルートCAが欠けている、中間証明書が含まれていない、署名CAが認識されない）、ブラウザはERR_CERT_AUTHORITY_INVALIDをスローします。詳しい説明については、SSL証明書チェーンとはのガイドを参照してください。

• ルートCA — 自己署名、OS/ブラウザのトラストストアにプリインストール（約150の信頼されたルート）

• 中間CA — ルートCAによって署名、TLSハンドシェイク中にサーバーから送信される必要あり

• リーフ証明書 — Webサイトの証明書、中間CAによって署名

• 検証 — ブラウザはリーフからルートまでチェーンをたどり、すべての署名が検証される必要あり

NET::ERR_CERT_AUTHORITY_INVALIDの原因

このエラーには、サーバー側の原因（Webサイトの問題）とクライアント側の原因（デバイスの問題）の両方があります。エラーが1つのWebサイトのみに表示される場合、問題はほぼ確実にサーバー側です。複数またはすべてのHTTPS Webサイトに表示される場合、問題はあなた側にあります。

訪問者向けの修正（クライアント側）

自分が管理していないWebサイトの閲覧中にNET::ERR_CERT_AUTHORITY_INVALIDが表示される場合、以下の修正を順番に試してください。最も簡単な確認から始めましょう — 問題は思ったより簡単であることが多いです。

修正1: システムの日付と時刻を確認

不正確なシステム時計は、証明書エラーの最も見落とされる原因の1つです。SSL証明書には有効期間（開始日と終了日）があります。デバイスが2026年なのに2020年だと認識している場合、2025年に発行された証明書は「まだ有効ではない」と判断され、ブラウザは拒否します。

この修正には10秒しかかからず、人々が思うよりも頻繁に問題を解決します — 特にBIOSバッテリーの故障、仮想マシンのスナップショット復元、デュアルブートの時刻ずれの後に起こります。

# Windows — システム時刻の確認と同期
w32tm /query /status
w32tm /resync

# macOS — 自動時刻同期を有効化
sudo sntp -sS time.apple.com

# Linux — NTPと同期
sudo timedatectl set-ntp true
timedatectl status

修正2: シークレット/プライベートブラウジングモードを試す

シークレットウィンドウでWebサイトを開くと、ブラウザキャッシュ、Cookie、拡張機能の干渉をすべて一度に除外できます。シークレットモードでサイトが正常に読み込まれる場合、問題はキャッシュされた証明書の状態または不正な拡張機能であり、Webサイト自体ではありません。

シークレットモードを開くには：ChromeまたはEdgeでCtrl+Shift+N、FirefoxでCtrl+Shift+Pを押します。

修正3: ブラウザキャッシュとCookieをクリア

ブラウザは後続の接続を高速化するためにSSL証明書情報をキャッシュします。Webサイトが最近証明書を更新または置き換えた場合、ブラウザがまだ古い（無効な）証明書をキャッシュに保持している可能性があり、サーバーが有効な証明書を持っているにもかかわらずERR_CERT_AUTHORITY_INVALIDエラーが発生します。

# Chrome: キーボードショートカットでキャッシュをクリア
# Windows/Linux: Ctrl+Shift+Delete
# macOS: Cmd+Shift+Delete
# 「キャッシュされた画像とファイル」と「Cookie」を選択 → データを消去

# Firefox: キャッシュをクリア
# Ctrl+Shift+Delete → 「キャッシュ」と「Cookie」を選択 → 今すぐ消去

修正4: SSL状態をクリア（Windows）

WindowsはブラウザキャッシュとIS独立した、OS レベルでの別個のSSL証明書キャッシュを維持しています。このキャッシュをクリアすると、Windowsは証明書をゼロから再取得して再検証します。

# 方法1: インターネットオプション経由
# インターネットオプション（inetcpl.cpl）を開く → コンテンツタブ → 「SSL状態のクリア」ボタン

# 方法2: コマンドライン経由
# 管理者としてコマンドプロンプトを開く:
certutil -URLcache * delete

修正5: ブラウザ拡張機能を無効化

セキュリティ拡張機能、VPN拡張機能、広告ブロッカー、プライバシーツールはSSL接続に干渉する可能性があります。一部の拡張機能はローカルプロキシとして機能し、HTTPSトラフィックを傍受して証明書を置き換えます — これがERR_CERT_AUTHORITY_INVALIDを引き起こします。

テストするにはすべての拡張機能を一時的に無効にします：chrome://extensions/にアクセスして各拡張機能をオフに切り替え、Webサイトを再読み込みします。エラーが消えたら、拡張機能を1つずつ再有効化して原因を特定します。

修正6: OSとブラウザを更新

ルートCA証明書はOSとブラウザの更新を通じて配布されます。オペレーティングシステムが古い場合、トラストストアに新しいルートCAが含まれていない可能性があります。たとえば、ISRG Root X1証明書（Let's Encryptで使用）は、更新を通じてのみ古いAndroidおよびWindowsバージョンに追加されました。Android 7.0以前のデバイスにはこのルートがまったくない場合があります。

ChromeとEdgeはWindowsとmacOSではOSのトラストストアに依存しますが、Firefoxは独自のストアを持っています。OSとブラウザの両方を最新に保つことで、最新の信頼されたルート証明書を確保できます。

修正7: ウイルス対策のSSL/HTTPSスキャンを無効化

Kaspersky、Avast、ESET、Bitdefenderなどのウイルス対策ソフトウェアには、「HTTPSスキャン」または「SSLインターセプト」機能が含まれていることがよくあります。この機能は中間者として動作し、HTTPSトラフィックを独自の証明書で復号化し、スキャンしてから再暗号化します。ウイルス対策のCA証明書がブラウザのトラストストアにインストールされていない場合、すべてのHTTPSサイトでERR_CERT_AUTHORITY_INVALIDが表示されます。

テストするには：ウイルス対策の設定でHTTPSスキャン機能を一時的に無効にします（ウイルス対策全体ではなく、SSL/Webスキャンコンポーネントのみ）。エラーが消えたら、スキャンを無効のままにするか、ウイルス対策のルート証明書をブラウザに再インストールできます。

修正8: DNSキャッシュをフラッシュ

まれに、古いDNSキャッシュがブラウザを間違ったIPアドレスに向ける可能性があります — 異なる（無効な）SSL証明書を提供するアドレスです。DNSをフラッシュすると、デバイスがドメインを正しいサーバーに解決することが保証されます。完全なガイドについては、DNSキャッシュのフラッシュ方法を参照してください。

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches

# Chromeの内部DNSキャッシュ
# chrome://net-internals/#dns に移動 → 「Clear host cache」

修正9: 別のネットワークを試す

企業ネットワーク、学校のWi-Fi、一部の公共ホットスポットは、HTTPS接続を傍受する透過プロキシを使用しています。これらのプロキシはWebサイトのSSL証明書を独自のものに置き換え、ERR_CERT_AUTHORITY_INVALIDを引き起こします。モバイルデータまたは別のWi-Fiネットワークに切り替えることで、ネットワークが問題であるかどうかを確認できます。

職場や学校のネットワークでのみエラーが表示される場合は、ネットワーク管理者に連絡してください — プロキシのルート証明書をデバイスにインストールするか、ドメインをSSLインスペクションからホワイトリストに登録する必要がある場合があります。

Webサイト所有者向けの修正（サーバー側）

訪問者がWebサイトでERR_CERT_AUTHORITY_INVALIDを報告している場合、問題はSSL証明書の設定にあります。以下はサーバー側の修正で、最も一般的なものから順に並べています。

修正1: 信頼されたCAの証明書をインストール

自己署名証明書は、Webサイト所有者にとってERR_CERT_AUTHORITY_INVALIDの#1の原因です。OpenSSLまたは同様のツールで独自の証明書を生成した場合、ブラウザは決して信頼しません — 署名権限（あなた）がどのブラウザのトラストストアにも存在しないためです。

修正は、公的に信頼された認証局からの証明書をインストールすることです。Let's Encryptは、すべての主要ブラウザが信頼する無料の自動化された証明書を提供しています。商用サイトの場合、DigiCert、Sectigo、GlobalSignの有料証明書がEV（拡張検証）とより長い有効期間を提供します。

# Let's Encrypt証明書をCertbotでインストール（Nginx）
sudo certbot --nginx -d example.com -d www.example.com

# Let's Encrypt証明書をCertbotでインストール（Apache）
sudo certbot --apache -d example.com -d www.example.com

# インストール済み証明書を確認
sudo certbot certificates

修正2: 完全な証明書チェーンをインストール

中間証明書の欠落は、サーバー側で2番目に一般的な原因です。SSL証明書は完全に有効かもしれませんが、サーバーが中間CA証明書を一緒に送信しない場合、ブラウザは信頼チェーンを検証できずERR_CERT_AUTHORITY_INVALIDをスローします。

DNS RobotのSSL Checkerを使用して証明書チェーンを確認してください。健全なチェーンは3つの証明書を表示します：ルートCA > 中間CA > あなたの証明書。中間証明書が欠けている場合、完全なチェーンを送信するようにサーバーを設定する必要があります。

# OpenSSLで証明書チェーンを確認
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E 's:|i:'

# Nginx — 完全なチェーンを設定
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache — 完全なチェーンを設定
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

修正3: 期限切れの証明書を更新

期限切れの証明書はすべてのブラウザによって即座に拒否されます。Chromeは、期限切れの証明書の中間CAもローテーションされた場合に、ERR_CERT_DATE_INVALIDではなくERR_CERT_AUTHORITY_INVALIDを特に表示することがあります。SSL Checkerまたはコマンドラインで証明書の有効期限を確認してください。

# 証明書の有効期限を確認
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Certbotで強制更新
sudo certbot renew --force-renewal

# 更新後にWebサーバーを再起動
sudo systemctl reload nginx    # Nginx
sudo systemctl reload apache2  # Apache

修正4: 証明書がドメインと一致していることを確認

SSL証明書は、Common Name（CN）およびSubject Alternative Name（SAN）フィールドにリストされた特定のドメイン名に対して発行されます。Webサイトがwww.example.comでアクセスされているが証明書がexample.comのみをカバーしている場合、またはSANに含まれていないサブドメインにアクセスする場合、ChromeはERR_CERT_AUTHORITY_INVALIDを表示する可能性があります。

ワイルドカード証明書（*.example.com）はすべてのサブドメインをカバーしますが、SANとして明示的にリストされていない限りルートドメインはカバーしません。ワイルドカード証明書を生成する際は、常にexample.comと*.example.comの両方を含めてください。

修正5: サーバーのTLS設定を確認

TLS設定のミスは、有効な証明書があっても証明書の信頼の問題を引き起こす可能性があります。サーバーがTLS 1.2とTLS 1.3をサポートしていることを確認してください — TLS 1.0やTLS 1.1などの古いプロトコルは2020年以降すべての主要ブラウザで廃止されています。また、サーバーが正しい順序で証明書を送信していることを確認してください（リーフが最初、次に中間証明書）。

# Nginx推奨TLS設定
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

# TLS設定をテスト
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

LocalhostでのERR_CERT_AUTHORITY_INVALID（開発者向け）

開発者は、開発用のローカルHTTPSサーバーを実行する際にこのエラーに頻繁に遭遇します。localhost証明書は常に自己署名であるため、Chromeはデフォルトでブロックします。これに対処するいくつかの方法があります。

• mkcert — 最も簡単な解決策。mkcertをインストールし、mkcert -installを実行してローカルCAをトラストストアに追加し、次にcertsを生成：mkcert localhost 127.0.0.1 ::1。Chrome、Firefox、Edgeで自動的に信頼されます

• Chromeバイパス — エラーページでthisisunsafeと入力（入力フィールドはなし — キーボードで直接入力）。現在のセッションのみ警告をバイパスします

• Chromeフラグ — chrome://flags/#allow-insecure-localhostに移動して有効にします。localhostのみの証明書エラーを抑制します

• Vite/Next.js/Webpack — ほとんどのdevサーバーは自己署名certsを生成する--httpsフラグをサポートしています。mkcertと組み合わせて信頼されたローカルセットアップを構築できます

# mkcertをインストール（macOS）
brew install mkcert
mkcert -install

# localhost証明書を生成
mkcert localhost 127.0.0.1 ::1
# 作成: localhost+2.pem と localhost+2-key.pem

# Node.jsで使用
const https = require('https');
const fs = require('fs');
https.createServer({
  cert: fs.readFileSync('localhost+2.pem'),
  key: fs.readFileSync('localhost+2-key.pem')
}, app).listen(3000);

関連するSSL証明書エラー

NET::ERR_CERT_AUTHORITY_INVALIDは、遭遇する可能性のあるいくつかのSSL証明書エラーの1つにすぎません。各エラーは、証明書検証プロセスの異なる問題を示しています。