Zscaler (プレビュー) に関する問題のトラブルシューティング - Power Apps

この記事では、PAC CLI (Power Apps コマンドラインインターフェイス) pac コード add-data-source が Zscaler または同様の SSL 検査プロキシの背後で繰り返し失敗する場合のトラブルシューティング手順について説明します。

Zscaler は、HTTPS トラフィックを復号化して再暗号化することで、Secure Socket Layer/Transport Layer Security (SSL/TLS) 検査を実行するクラウドベースのセキュリティプラットフォームです。これは、(設計上) 中間者として機能し、脅威のコンテンツを検査します。 Zscaler SSL 検査の概要を参照してください

症状

次の表に、Zscaler 関連の問題を示す可能性のある症状を示します。

症状	メッセージ/パターンの例
フェッチに失敗しました	`TypeError: fetch failed` / `[AddDataSource.ServiceCall.GetConnector.Failure] ... fetch failed`
空のリクエストが失敗しました	`Error: Request failed: {}` (本文なし)
TLS ハンドシェイク/証明書エラー	`UNABLE_TO_VERIFY_LEAF_SIGNATURE` / `SELF_SIGNED CERT IN CHAIN` (デバッグが有効な場合)
企業ネットワークを介さずに動作する	Zscaler から切断されるとコマンドが成功する

前提条件のチェックリスト

開始する前に、以下を確認します。

最新の Power Platform CLI がインストールされています。不明な場合は更新してください。
あなたは正しい環境に認証されています。 pac auth createコマンドとpac auth listコマンドを使用します。
インストール Node.js バージョンが v22 以上です。以前のバージョンでは、信頼に関する動作が現在のバージョンよりも厳しくなっています。
ユーザー証明書ストアを読み取ることができる。ロックダウンプロファイルの制限はありません。
会社のポリシーでは、開発者ツールのユーザー信頼に Zscaler ルート CA を追加できます。

トラブルシューティングの手順

トラブルシューティングを行うには、次のセクションの情報を使用します。

手順 1: ベースラインを検証する

プロキシに関連しない原因を排除するには、 pac env who コマンドを実行します。

このコマンドが成功した場合、一般的な接続は問題ありません。エラーはデータソース呼び出しに分離されます。

手順 2: Zscaler がインストールされていることを確認する

このコマンドを実行して、Zscaler 証明書がストアに存在することを確認します。

Get-ChildItem Cert:\CurrentUser\Root |
    Where-Object { $_.Subject -like "*Zscaler*" } |
    Select-Object Subject, Thumbprint

Zscaler が証明書を挿入すると、Microsoft ではなく Zscaler 発行者が表示されます。

注

Zscaler のようなプロキシが HTTPS トラフィックをインターセプトすると、元のサーバー証明書が、企業ルート CA によって署名された独自の証明書に置き換えられます。これにより、プロキシはトラフィックの暗号化解除、検査、再暗号化を行えます。企業ルート CA がシステム信頼ストアにインストールされているため、ブラウザーはこれを信頼します。 HTTPS インターセプトのしくみを確認する

手順 3: Zscaler ルート CA を PEM にエクスポートする

このコマンドを実行して、Zscaler ルート証明機関 (CA) をプライバシー強化メール (PEM) にエクスポートします

$cert = Get-ChildItem Cert:\CurrentUser\Root |
    Where-Object { $_.Subject -like "*Zscaler*" } |
    Select-Object -First 1

$pem = @(
    '-----BEGIN CERTIFICATE-----'
    [System.Convert]::ToBase64String(
        $cert.RawData,
        [System.Base64FormattingOptions]::InsertLineBreaks
    )
    '-----END CERTIFICATE-----'
) -join "`n"

Set-Content -Path "$env:USERPROFILE\.zscaler-root-ca.pem" -Value $pem

結果: ~\.zscaler-root-ca.pem 作成されます。

注意事項

PEM ファイルを保護します。 エクスポートされた証明書に対する適切なファイルアクセス許可を確認します。悪意のあるアクターがこのファイルを置き換えることができる場合は、Node.js プロセスからの HTTPS トラフィックを傍受する可能性があります。推奨されるセキュリティ強化 (継承が削除され、読み取り専用が許可されます):

icacls "$env:USERPROFILE\.zscaler-root-ca.pem" /inheritance:r /grant:r "$env:USERNAME:(R)"

継承の削除が企業ポリシーと競合する場合、またはエンドポイント保護制御をトリガーする場合は、 /inheritance:r スキップし、明示的な読み取りアクセス許可のみを付与します。

icacls "$env:USERPROFILE\.zscaler-root-ca.pem" /grant:r "$env:USERNAME:(R)"

Windows 証明書ストアと PEM 形式

Get-ChildItem Cert:\CurrentUser\Root コマンドは、PowerShell の証明書プロバイダーを介して Windows 証明書ストアにアクセスします。 PEM は、証明書の Base64 でエンコードされた形式です。変換は、windows が DER (識別エンコード規則) 形式で証明書を格納する間、Node.js には PEM 形式が必要であるために必要です。 PowerShell 証明書プロバイダーと PEM 形式の RFC を参照してください

Windows `icacls` コマンド

icacls (整合性制御アクセス制御リスト) は、ファイルのアクセス許可を管理するための Windows コマンドラインユーティリティです。使用されるパラメーター: /inheritance:r 継承されたアクセス許可が削除 /grant:r 、既存のアクセス許可が、指定したユーザーの読み取り専用アクセスに置き換えられます。 icacls のドキュメントを参照する

手順 4: 証明書を信頼するように Node.js に指示する

次のスクリプトを実行して、証明書を信頼するように Node.js に指示します。

[System.Environment]::SetEnvironmentVariable('NODE_EXTRA_CA_CERTS', "$env:USERPROFILE\.zscaler-root-ca.pem", 'User')

ターミナル/VS Code を閉じて再度開いて伝達します。

注意事項

スコープの影響: この NODE_EXTRA_CA_CERTS環境変数は、ユーザーアカウントによって実行されるすべての Node.js プロセスに影響します。 PEM ファイルが改ざんされた場合、すべての Node.js アプリケーションは、PAC CLI だけでなく、変更された証明機関を信頼します。ファイルハッシュを定期的に確認し、セキュリティ保護を維持します。

環境変数NODE_EXTRA_CA_CERTS

この Node.js 環境変数は、Node.js組み込みリスト (Mozilla の CA バンドル) 以外の信頼できる証明機関を含むファイルを指定します。設定すると、Node.js は、組み込みリストと指定したファイルの両方で CA によって署名された証明書を信頼します。 Node.js CLI 環境変数を参照

修正の検証

手順 5 に進む前に、手順 3 から 4 で修正プログラムが正しく適用されたことを確認するには、次の手順に従います。

PEM ファイルが作成され、想定される場所に存在することを確認します
```
 Test-Path "$env:USERPROFILE\.zscaler-root-ca.pem" # Expect True
```
環境変数が正しく設定されていることを確認し、PEM ファイルへのパスを返します
```
[System.Environment]::GetEnvironmentVariable(
    'NODE_EXTRA_CA_CERTS',
    'User'
)
```
PEM ファイルに空または破損しているのではなく、有効なコンテンツがあることを確認します
```
Get-Content "$env:USERPROFILE\.zscaler-root-ca.pem" -TotalCount 2
# First line should be: -----BEGIN CERTIFICATE-----
```

手順 5: コマンドを再実行する

コマンドをもう一度実行してみてください。

pac code add-data-source -a <apiId> -c <connectionId> [-t <tableName>] [-d <dataset|siteUrl>]

フェッチエラーではなく、コネクタの取得が成功すると予想されます。

(回避)安全でない回避策

避けるべき最終的な明確なテストは、TLS 検証を一時的に無効にすることにあります。

この回避策では、自己署名証明書やスプーフィングされた証明書など、提示された証明書を Node.js に強制的に受け入れます。これにより、HTTPS のすべての信頼性と整合性の保証が削除されます。セッションは中間者攻撃 (MITM)、資格情報の収集、コンテンツの改ざんのリスクにさらされます。有効期間の短い診断セッションの外部では使用しないでください。

Warnung

セキュリティリスク: これにより、現在のセッションのすべての Node.js HTTPS 接続に対する SSL 証明書の検証が完全に無効になります。ネットワークアクセス権を持つ攻撃者は、MITM 攻撃を実行できます。この回避策は、1 回限りの診断にのみ使用して、証明書の信頼が根本原因であることを証明します。スクリプトにコミットしないでください。運用環境では使用しないでください。テスト後すぐに設定を解除します。

$env:NODE_TLS_REJECT_UNAUTHORIZED = "0"

テスト後に設定を解除するには:

Remove-Item Env:\NODE_TLS_REJECT_UNAUTHORIZED

Validation

ソリューションを適用した後、コマンドを再試行します。コネクタの正常な取得を確認します。

[AddDataSource.ServiceCall.GetConnector.Start] { apiId: 'shared_office365users' }
[AddDataSource.ServiceCall.GetConnector.Success] { apiId: 'shared_office365users' }

代替案:

[AddDataSource.ServiceCall.GetConnector.Failure] { apiId: 'shared_office365users', error: 'fetch failed' }

トラブルシューティングマトリックス

トラブルシューティングの手順を完了しても問題が引き続き発生する場合は、次の問題を調査します。

`fetch failed` が続く

シェルの再起動後に設定 NODE_EXTRA_CA_CERTS 再確認します。PEM が 0 バイトでないことを確認します。修正の検証でコマンドを実行して、ファイルが存在し、環境変数が正しく設定されていることを検証します。

複数の Zscaler 証明書

Get-ChildItem Cert:\CurrentUser\Root | Where-Object { $_.Subject -like "*Zscaler*" }が複数の証明書を返す場合は、ルート CA (通常は Zscaler Root CA という名前) を特定します。手順 3 を変更して、発行者名または拇印で正しいものを選択します。

異なるプロキシ製品

このソリューションは、SSL 検査 (Blue Coat、Forcepoint、Netskope など) を実行するすべての企業プロキシに対して機能しますが、手順 3 では証明書のサブジェクトで *Zscaler* を検索します。プロキシに合わせてフィルターを調整します。

# For Blue Coat:
$cert = Get-ChildItem Cert:\CurrentUser\Root |
    Where-Object { $_.Subject -like "*Blue Coat*" } |
    Select-Object -First 1

# For Forcepoint:
$cert = Get-ChildItem Cert:\CurrentUser\Root |
    Where-Object { $_.Subject -like "*Forcepoint*" } |
    Select-Object -First 1

次に、一致した証明書を使用して手順 3 から 4 を完了します。

VPN の外部でのみ機能する

コマンドが外部 VPN のみを使用して動作する場合は、証明書の信頼の問題ではなく、ネットワークレベルのブロックを示します。企業の分割トンネル VPN 構成では、Power Platform API トラフィックをオンプレミスのファイアウォール経由でルーティングし、Node.js/CLI ツールをブロックしたり、ブラウザー以外のトラフィックに制限付きポリシーを適用したりする場合があります。

NODE_EXTRA_CA_CERTSの修正プログラムはここでは役に立ちません。ネットワーク/セキュリティチームに依頼して次の作業を行わせます。

*.powerplatform.com、*.dynamics.com、*.azure.net への PAC CLI トラフィックを許可リストに載せる
開発者ワークステーションから Microsoft クラウドサービスへの直接 HTTPS (ポート 443) を許可する
信頼された Microsoft エンドポイントの検査/フィルター処理をバイパスするように分割トンネル規則を構成する

スプリットトンネリング/許可リスト設定ガイダンス

一部のエンタープライズ VPN では、トラフィックのサブセットのみを直接ルーティングしながら、検査ゲートウェイを介して他の宛先を強制します。ブロックまたは SSL インターセプトの競合なしに、Power Platform エンドポイントに到達できる必要があります。エンドポイント許可リストのガイダンスについては、Microsoft の接続要件を参照してください。

`SELF_SIGNED CERT IN CHAIN`

証明書チェーンが不完全です。完全な証明書チェーン (ルート + 中間) をエクスポートするか、完全なルート CA バンドルを提供するようにネットワークチームに要求します。一部のプロキシでは、ルート CA と中間 CA の両方を信頼する必要があります。

注記

Zscaler のような SSL 検査プロキシの背後で作業する場合は、セキュリティで保護された信頼性の高いセットアップを維持するために、次の注意事項に留意してください。

Zscaler が証明書をローテーションする場合は、エクスポートを繰り返します。
変更は現在のユーザースコープにのみ影響します。システム全体のリスクはありません。
安全: 信頼を追加し、検証を無効化しません。
ポリシーによって証明書のエクスポートが制限されている場合は、専用の開発機を使用します。

エスカレーションデータ

この記事のどの手順も役に立たなかった場合は、テクニカルサポートに問い合わせる前に、次の情報を収集して提供してください。

PAC CLI のバージョン: pac --version
Node.js バージョン: node --version
OS + シェル (Windows PowerShell 7/Windows CMD など)
実行された完全なコマンド（サニタイズ済み）
サニタイズされたエラーブロック (最初の発生)
NODE_EXTRA_CA_CERTSの値 (PowerShell: [System.Environment]::GetEnvironmentVariable('NODE_EXTRA_CA_CERTS','User'))
PEM ファイルのプレゼンスとハッシュ (例: Get-FileHash $env:USERPROFILE\.zscaler-root-ca.pem)

Power Platform の接続要件
 Node.js NODE_EXTRA_CA_CERTS ドキュメント

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-11-21