NET::ERR_CERT_AUTHORITY_INVALIDの原因と直し方（Chrome・Android）

NET::ERR_CERT_AUTHORITY_INVALIDとは？

NET::ERR_CERT_AUTHORITY_INVALIDは、Webサイトの証明書を発行した相手をブラウザが信頼していないことを意味します。 Chromeは「この接続ではプライバシーが保護されません」と表示し、詳細設定を開くと、セキュリティ証明書が信頼されていないため「このサーバーが example.com であることを確認できませんでした」と説明し、「原因としては、不適切な設定や、悪意のあるユーザーによる接続妨害が考えられます」と続けます。Chromiumではエラー -202 として定義されています（net_error_list.h）。

接続は確立され、サーバーは証明書を送ってきましたが、ブラウザはそれを自分が信頼する認証局（CA）に結び付けられませんでした。Chromium自身のコメントは理由を3つ挙げています。攻撃者が証明書をすり替えた、サイトがブラウザの知らないCAを使っている、または証明書が自己署名である、のいずれかです。

証明書に複数の問題がある場合、Chromeは最も深刻なものだけを表示し、信頼できない発行元は名前の不一致や期限切れより優先されます。そのため、自己署名で期限も切れている証明書では、ERR_CERT_DATE_INVALIDではなくこのコードが表示されます。

各ブラウザでのERR_CERT_AUTHORITY_INVALIDの表示

表示される文言はブラウザごとに異なります。次の表示を探してください。

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

すべての証明書は、ブラウザがすでに信頼しているルート認証局で終わる信頼チェーンにつながっています。

接続時、サーバーは自身の証明書と1つ以上の中間証明書を送ります。ブラウザは、サイトの証明書が中間証明書によって署名され、その中間証明書が自分のリストにあるルートによって署名されていることを確認します。Chromeはこの確認にOSのリストをもう使っていません。WindowsとmacOSではChrome 108から、AndroidではChrome 115から、独自のリストであるChrome Root Storeを内蔵しています（Appleのリストの使用が必須のiPhoneとiPadは例外）。このリストには約100のルートがあり、バックグラウンドで更新されます（Chrome Root Store）。WindowsとmacOSのEdgeはMicrosoftのリストを、FirefoxはMozillaのリストを内蔵しており、いずれもユーザーや会社がコンピューターに追加したルートも信頼します。

チェーンのどこか1つでも欠けていたり不明だったりすると、このエラーになります（詳しくはSSL証明書チェーンとはを参照）。チェーンは次の4つで構成されます。

• ルートCA — 自己署名されており、ブラウザのルートリストに組み込まれています
• 中間CA — ルートが署名し、サーバーが必ず送信する必要があります。欠けている場合、Chromeは証明書に記載されたアドレスから自分でダウンロードしますが、curlやアプリなど多くのクライアントはそれができません
• サイトの証明書 — 中間CAが署名し、Subject Alternative Nameリストにある名前に対して発行されます
• 検証 — ブラウザがサイトの証明書から信頼されたルートまでたどり、すべての署名が正しいことを確認します

NET::ERR_CERT_AUTHORITY_INVALIDの原因

どこで表示されるかで原因を絞り込めます。1つのWebサイトだけなら、ほぼ確実にそのサイトの証明書が原因です。すべてのHTTPSサイトなら、デバイスかネットワークが原因です。

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

自分が運営していないサイトでこのエラーが出る場合は、次の順に試してください。この警告が出ているページでは、パスワードやカード番号を絶対に入力しないでください。

修正1: Wi-Fiにログインするか、別のネットワークで試す

ホテル、空港、カフェのWi-Fiは、ログインページを表示するために最初の通信を横取りすることが多く、そのときHTTPSサイトにはサイト自身の証明書ではなくネットワークの証明書が届きます。Chromeのヘルプによると、こうしたネットワークではログインが必要で、http://を使うページにアクセスするとログインページが表示されます。Chromeはこのエラーの代わりに「Wi-Fi 接続」ページを表示することもあります。ログインを済ませてから再読み込みしてください。

職場や学校のネットワークも、独自の証明書でHTTPSを検査していることがあります。モバイルデータ通信ではエラーが消える場合は、そのネットワークのIT担当者に相談してください。管理対象のデバイスには通常そのルート証明書がインストールされていますが、あなたのデバイスにはないかもしれません。

修正2: ウイルス対策ソフトのHTTPSスキャンを確認する

Kaspersky、Avast、ESET、Bitdefenderなどのウイルス対策ソフトは、HTTPSを独自の証明書で復号してスキャンし、再び暗号化することがあります。そのルート証明書がブラウザに信頼されていない場合や、アップデート後にこの機能が不具合を起こした場合、すべてのHTTPSサイトで一斉にこのエラーが出ます。

テストするには、HTTPSスキャンまたはWebスキャンの機能だけを一時停止して再読み込みします。エラーが消えたら、ウイルス対策ソフトを修復またはアップデートして証明書を再インストールさせるか、HTTPSスキャンをオフのままにしてください。

修正3: ブラウザとOSを更新する

ブラウザとOSはルートリストを定期的に更新しており（Chromeはバックグラウンドのコンポーネント更新で）、古いシステムには新しいルートがありません。たとえば7.1.1より前のAndroidはISRG Root X1を信頼しないため、システムのリストに頼るブラウザやアプリではLet's Encryptのサイトが開けません。

まずブラウザを更新してください。WindowsとmacOSのChromeとEdgeは独自のルートリストを持ち、AndroidのChromeもバージョン115からそうです。次にOSを更新します。

修正4: 日付と時刻を確認する

時計が数か月、数年単位でずれていると、証明書はまだ有効期間前か期限切れに見えます。その場合Chromeは通常、別の警告（「時計が遅れています」やERR_CERT_DATE_INVALID）を表示しますが、CMOS電池が切れた後や仮想マシンを復元した後のように時計が大きく狂っていると、信頼の確認まで失敗することがあります。確認は10秒で済みます。

Windows：設定 → 時刻と言語 → 日付と時刻 →「時刻を自動的に設定する」をオン。macOS：システム設定 → 一般 → 日付と時刻 →「日付と時刻を自動的に設定」。Android：設定 → システム → 日付と時刻 →「日時を自動的に設定」（Android 16では「日時の自動設定」）。

修正5: シークレットモードで試し、ブラウザを再起動する

シークレット ウィンドウ（ChromeとEdgeはCtrl+Shift+N、FirefoxのプライベートウィンドウはCtrl+Shift+P）では、許可していない拡張機能は動きません。VPNやプロキシの拡張機能は、独自の証明書を提示するサーバー経由で通信を送ることがあります。シークレットモードでサイトが開けるなら、chrome://extensionsで拡張機能をすべてオフにし、1つずつオンに戻してください。

サイトが証明書を直したばかりなら、ブラウザのウィンドウをすべて閉じて開き直し、新しい証明書を最初から確認させてください。

修正6: Androidの場合

Androidには独自の確認ポイントがいくつかあります。

• 日付と時刻を自動に設定する：設定 → システム → 日付と時刻 →「日時の自動設定」。
• ChromeとAndroid System WebViewを更新する：Google Play ストアから更新します。WebViewでWebページを表示するアプリはAndroid自身のルートリストで証明書を確認するため、古いAndroidではそこで失敗することがあります。
• HTTPSをフィルタリングするVPN、広告ブロック、「セーフブラウジング」系のアプリをオフにする：これらが動いているとステータスバーに鍵やVPNのアイコンが表示されます。
• Wi-Fiにログインする：公衆ネットワークでは、ログインページで同意するまでこのエラーが出ます。
• 7.1.1より前のAndroidでは、Let's Encryptのルートがシステムのリストにないため、そのリストに頼るアプリやブラウザはそれらのサイトを検証できません。独自のルートリストを持つブラウザを使うことが唯一の回避策です。

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

自分のサイトでNET::ERR_CERT_AUTHORITY_INVALIDが出ると訪問者から報告があった場合、多くは配信している証明書が公開ルートにつながっていません。まずSSL Checkerで確認し、見つかった問題を直してください。インストールしたものと違う証明書が表示される場合は、DNS Lookupでドメインが想定どおりのサーバーを指しているか、HTTPヘッダーチェックでどのサーバーが応答しているかを確認します。

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

自己署名証明書や自前のCAが発行した証明書は、訪問者のブラウザに信頼されることはありません。署名者がどの公開ルートリストにも載っていないからです。

代わりに、公的に信頼されたCAの証明書をインストールしてください。Let's Encryptは主要なすべてのブラウザが信頼する無料の自動化証明書を発行しており、DigiCert、Sectigo、GlobalSignは組織認証やサポート付きの証明書を販売しています。

# Install Let's Encrypt certificate with Certbot (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Install Let's Encrypt certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

# Verify the installed certificate
sudo certbot certificates

修正2: 完全な証明書チェーンを送信する

証明書自体は完全に有効でも、サーバーが中間証明書を送り忘れていることがあります。Chromeは欠けた中間証明書を自分でダウンロードしてこの問題を覆い隠すことが多いため、サイトはChromeでは開けるのに、curl、アプリ、決済のコールバック、一部のスマートフォンでは失敗します。

DNS RobotのSSL Checkerでサイトを調べると、サーバーが送るチェーンと、Mozilla、Chrome、Apple、Microsoftのそれぞれがそのチェーンを信頼しているかがわかります。ターミナルから確認することもできます。

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# letsencrypt.org on 26 Oct 2026, a complete chain:
#  0 s:CN=letsencrypt.org
#    i:C=US, O=Let's Encrypt, CN=YE2
#  1 s:C=US, O=Let's Encrypt, CN=YE2
#    i:C=US, O=ISRG, CN=Root YE
#  2 s:C=US, O=ISRG, CN=Root YE
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#  3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
# Only certificate 0 listed = the intermediate is missing.

# nginx: point ssl_certificate at the full chain, not the leaf alone
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache 2.4.8+
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

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

信頼されたCAの証明書が期限切れになると、このエラーではなくERR_CERT_DATE_INVALIDが表示されます。Chromeはより深刻な問題を報告するため、ERR_CERT_AUTHORITY_INVALIDが出るのはチェーンも信頼されていない場合だけです。いずれにしても、日付を確認して更新してください。

# Check the certificate's dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
# notBefore=Sep 30 12:00:00 2026 GMT
# notAfter=Dec 29 11:59:59 2026 GMT

# Renew now with Certbot, then reload the web server
sudo certbot renew --force-renewal
sudo systemctl reload nginx    # or apache2

修正4: 訪問者が使うすべての名前をカバーする

信頼された証明書でも、アドレスバーの名前が含まれていなければ、代わりにERR_CERT_COMMON_NAME_INVALIDが表示されます。このエラーに変わるのは証明書も信頼されていない場合だけなので、まず信頼の問題を直し、それから名前を直してください。

ブラウザが確認するのはSubject Alternative Nameのリストだけで、古いCommon Nameは見ません。ワイルドカード（*.example.com）は1階層のサブドメインをカバーしますが、example.com自体はカバーしないため、申請時に両方を含めてください。SSL Checkerで証明書の名前リスト全体を確認できます。

修正5: プライベートCAや社内CAを使う場合

社内サイトでは、意図的に社内CAを使うことがよくあります。これが機能するのは会社のルート証明書がインストールされたデバイスだけで、ChromeとEdgeはWindowsやmacOSに追加されたルートを信頼します（Chrome Root Store FAQ）。グループ ポリシーやデバイス管理ツールで配布するか、次のコマンドで手動で追加してください。

# Windows (Command Prompt as Administrator): trust for all users
certutil -addstore -f Root company-root.crt

# macOS: trust in the System keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root.crt

LocalhostでのERR_CERT_AUTHORITY_INVALID（開発者向け）

自己署名証明書を使うローカルのHTTPSサーバーでは、このエラーは仕様どおりです。警告をクリックして先に進むのではなく、自分のマシンで証明書を信頼させましょう。

• mkcert — mkcert -installがローカルCAを作成してシステムのトラストストアに追加します（NSSのcertutilがインストールされていればFirefoxにも）。続けてmkcert localhost 127.0.0.1 ::1を実行すると、Chrome、Edge、Firefoxが信頼する証明書ができます
• Next.js — next dev --experimental-httpsが、mkcertでローカルに信頼される証明書を自動で作成します
• Vite — @vitejs/plugin-basic-sslは信頼されない証明書を作るため、このエラーは消えません。代わりにserver.httpsでmkcertのファイルを指定してください
• もう使えない古い方法 — chrome://flags/#allow-insecure-localhostのスイッチはChrome 130以降で期限切れになり、chrome://flagsから消えました

# Install mkcert (macOS)
brew install mkcert
mkcert -install

# Generate localhost certificate
mkcert localhost 127.0.0.1 ::1
# Creates: localhost+2.pem and localhost+2-key.pem

# Use with 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は、Chromeの「この接続ではプライバシーが保護されません」ページの裏にある証明書エラーの1つです。コードごとに、失敗したチェックが異なります。