rpm -Uvh tet-sensor-1.101.2-1.el6-dev.x86_64.rpm

   error: cannot create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied).

A：エージェントをインストールするための適切な権限がない場合は、root に切り替えるか、sudo を使用してエージェントをインストールしてください。

Q：「sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm」を実行すると、次のエラーが発生しました。

   Preparing...              ########################################### [100%]
   which: no lsb_release in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
   error: %pre(tet-sensor-site-1.0.0-121.1b1bb546.x86_64) scriptlet failed, exit status 1
   error:   install: %pre scriptlet failed (2), skipping tet-sensor-site-1.0.0-121.1b1bb546

A：システムはエージェントをインストールするための要件を満たしていません。今回のケースでは、lsb_release ツールはインストールされていません。

詳細については、「ソフトウェアエージェントの展開ラベル」の項を参照し、必要な依存関係をインストールしてください。

Q：「sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm」を実行すると、次のエラーが発生しました。

  Unsupported OS openSUSE project
  error: %pre(tet-sensor-1.101.1-1.x86_64) scriptlet failed, exit status 1
  error: tet-sensor-1.101.1-1.x86_64: install failed
  warning: %post(tet-sensor-site-1.101.1-1.x86_64) scriptlet failed, exit status 1

A：お使いの OS では、ソフトウェアエージェントの実行がサポートされていません（今回のケースでは、「openSUSE project」はサポートされていないプラットフォームです）。

詳細については、「ソフトウェアエージェントの展開ラベル」の項を参照してください。

Q：すべての依存関係をインストールした後、適切な権限でインストールを実行し、エラーは発生しませんでした。エージェントのインストールが成功したことを確認するにはどうすればよいですか。

A：エージェントをインストールした後、インストールされているかどうかを確認するには、次のコマンドを実行します。

$ ps -ef | grep -e csw-agent -e tet-
root     14158     1  0 Apr03 ?        00:00:00 csw-agent
root     14160 14158  0 Apr03 ?        00:00:00 csw-agent watch_files
root     14161 14158  0 Apr03 ?        00:00:03 csw-agent check_conf
root     14162 14158  0 Apr03 ?        00:01:03 tet-sensor -f conf/.sensor_config
root     14163 14158  0 Apr03 ?        00:02:38 tet-main --sensoridfile=./sensor_id
root     14164 14158  0 Apr03 ?        00:00:22 tet-enforcer --logtostderr
tet-sen+ 14173 14164  0 Apr03 ?        00:00:21 tet-enforcer --logtostderr
tet-sen+ 14192 14162  0 Apr03 ?        00:07:23 tet-sensor -f conf/.sensor_config

csw-agent の 3 つのエントリと、tet-sensor の少なくとも 2 つのエントリが表示されている必要があります。サービスが実行されていない場合は、次のディレクトリが使用可能であることを確認します。使用可能でない場合、インストールは失敗します。

• /usr/local/tet（ほとんどの Linux ディストリビューションの場合）

• /opt/cisco/tetration（AIX、Ubuntu の場合）

• /opt/cisco/secure-workload（Solaris、Debian の場合）

Q：PowerShell エージェント インストーラ スクリプトを実行すると、次のいずれかのエラーが表示されます。

1. 基礎となる接続がクローズしました。受信時に予期せぬエラーが発生しました。

2. 共通のアルゴリズムがないため、クライアントとサーバーが通信できません

[Net.ServicePointManager]::SecurityProtocol

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]’Ssl3,Tls,Tls11,Tls12’

This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.

msiexec /i “TetrationAgentInstaller.msi” /l*v “msi_install.log” /norestart

Q：基盤となる NIC が Nutanix VirtIO ネットワークドライバの場合、Windows Sensor ソフトウェアのアップグレードに失敗するようです。

A：Npcap 0.9990 と、Nutanix VirtIO ネットワークドライバ 1.1.3 以前のバージョンの間には、非互換性の問題があります。また、Receive Segment Coalescing が有効になっています。

この問題を解決するには、Nutanix VirtIO ネットワークドライバをバージョン 1.1.3 以降にアップグレードします。

Q：Windows Sensor をインストールしました。そのセンサーが登録されていないようであり、sensor_id ファイルには uuid-invalid-platform が含まれています。

set PATH=%PATH%;C:\Windows\System32\

Q：Windows ノードの Kubernetes ポッドからネットワークフローを受信していません。

A：Windows ノードの Kubernetes ポッドからフローをキャプチャするために必要なセッションが実行されているか確認するには、次の手順を実行します。

1. 管理者権限で cmd.exe を実行します。

2. logman query -ets コマンドを実行します。

   次のセッションが実行されていることを確認します。

   • CSW_MonNet：ネットワークフローをキャプチャ

   • CSW_MonHCS：ポッドの作成をモニター

   • CSW_MonNat：NATed フローをモニター

Kubernetes Daemonset のインストール中にインストーラスクリプトが失敗する場合、多くの理由が考えられます。

Q：ノードから到達可能なイメージを提供する Docker レジストリはありますか。

A：Cisco Secure Workload クラスタからイメージをプルするクラスタに関するダイレクトまたは HTTPS プロキシの問題をデバッグします。

Q：コンテナランタイムは SSL/TLS の安全でないエラーを報告していますか。

A：コンテナランタイムの適切な場所にあるすべての Kubernetes ノードに、Secure Workload HTTPS CA 証明書がインストールされていることを確認します。

Q：Docker レジストリ認証とイメージダウンロードの許可が失敗しましたか。

A：各ノードから、Helm チャートによって作成されたシークレットからの Docker プルシークレットを使用して、Daemonset 仕様のレジストリ URL から Docker が手動でイメージをプルするようにしてみてください。手動でのイメージプルも失敗した場合は、問題をさらにデバッグするため、Secure Workload クラスタの registryauth サービスからログをプルする必要があります。

Q：Kubernetes クラスタは Secure Workload アプライアンス内で正常にホストされていますか。

A：クラスタの [サービスステータス（service status）] ページをチェックして、関連するすべてのサービスが正常であることを確認します。[探索（explore）] ページから dstool スナップショットを実行し、生成されたログを取得します。

Q：Docker イメージビルダデーモンは実行されていますか。

A：dstool ログから、ビルドデーモンが実行されていることを確認します。

Q：Docker イメージをビルドするジョブは失敗しますか。

A：dstool ログから、イメージがビルドされていないことを確認します。Docker ビルドポッドログを使用して、ビルドキットを構築中のエラーをデバッグできます。適用コーディネータのログを使用して、ビルドの失敗をさらにデバッグすることも可能です。

Q：Helm チャートを作成するジョブは失敗しますか。

A：dstool ログから、Helm チャートが構築されていないことを確認します。適用コーディネータのログには Helm 構築ジョブの出力が含まれます。Helm チャートの構築ジョブの失敗の正確な理由をデバッグするために使用できます。

Q：インストール bash スクリプトが壊れていましたか。

A：インストール bash スクリプトのダウンロードを再試行します。bash スクリプトには、追加のバイナリデータが含まれています。bash スクリプトをテキストエディタで編集したり、テキストファイルとして保存したりすると、バイナリデータの特殊文字がテキストエディタによって破損または変更される可能性があります。

Q：Kubernetes クラスタ設定：亜種とフレーバーが多すぎます。クラシック K8 をサポートしています。

A：お客様が Kubernetes の亜種を実行している場合、展開のさまざまな段階で多くの障害モードが発生する可能性があります。失敗の段階を分類します： kubectl コマンド実行の失敗、helm コマンド実行の失敗、ポッドイメージのダウンロードの失敗、ポッドの特権モードオプションの拒否、ポッドイメージの信頼コンテンツ署名の失敗、ポッドイメージのセキュリティスキャンの失敗、ポッドバイナリ実行の失敗（アーキテクチャの不一致）、ポッドを実行しても Secure Workload サービスの開始が失敗、Secure Workload サービスが開始しても異常な動作環境が原因でランタイムエラーが発生。

Q：Kubernetes RBAC 資格情報が失敗していますか。

A：特権 DaemonSet を実行するには、K8s クラスタに対する管理者権限が必要です。kubectl 設定ファイルに、ターゲットクラスタおよびそのクラスタの管理者と同等のユーザーを指すデフォルトのコンテキストがあることを確認します。

Q：BusyBox イメージは、すべてのクラスタノードから利用可能またはダウンロード可能ですか。

A：接続の問題を修正し、BusyBox イメージがダウンロードできることを手動でテストします。ポッド仕様で使用されている BusyBox の正確なバージョンは、すべてのクラスタノードで使用可能（事前シード済み）またはダウンロード可能である必要があります。

Q：インストール中に、API サーバーおよび etcd エラーまたは通常のタイムアウトが発生しましたか。

A：Kubernetes クラスタ内のすべてのノードで DaemonSet ポッドがインスタンス化されるため、クラスタの CPU/ディスク/ネットワークの負荷が突然スパイクする可能性があります。この問題は、お客様固有のインストールの詳細に大きく依存します。過負荷が原因で、インストールプロセス（すべてのノードでプルされてディスクに書き込まれるイメージ）に時間がかかりすぎたり、Kubernetes API サーバー、または Secure Workload Docker レジストリエンドポイントが過負荷になったり、プロキシサーバー（設定されている場合）が一時的に過負荷になったりする可能性があります。すべてのノードでイメージのプルが完了し、Kubernetes クラスタノードの CPU/ディスク/ネットワークの負荷が軽減されるのを少し待ってから、インストールスクリプトを再試行します。API サーバーと Kubernetes コントロールプレーンからの etcd エラーは、Kubernetes コントロールプレーンノードがアンダープロビジョニングであるか、アクティビティの突然のスパイクの影響を受けている可能性があることを示しています。

Q：Secure Workload エージェントの操作でランタイムの問題が発生していますか。

A：ポッドが正しく展開され、エージェントの実行が開始されているが、ランタイムの問題が発生している場合は、Linux エージェントのトラブルシューティング セクションを参照してください。Kubernetes の展開が正常にインストールされ、ポッドが開始された後のトラブルシューティング手順は同じです。

エージェントによるクラスタサービスへのチェックが停止しています。この現象は次のような原因で発生する可能性があります。

• ホストがダウンしている可能性がある

• ネットワーク接続が壊れているか、ファイアウォールルールによってブロックされている

• エージェントサービスが停止している

エージェントのアップグレードに失敗しました。これは、次のようないくつかのケースでトリガーされます。

• チェックインスクリプトがパッケージのダウンロードを試行したときにパッケージが見つからない - アップグレードパッケージを解凍できないか、パッケージ内のインストーラを検証できません。

• OS の問題または依存関係によるインストールプロセスの失敗。

現在のエージェントタイプが目的のエージェントタイプと一致しないため、コンバートの試行がタイムアウトしました。この問題は、エージェントがパッケージをダウンロードするために check_in を実行したとき、または wss サービスが convert_commnad をエージェントにプッシュできなかったときに、通信の問題が原因で発生する可能性があります。

エージェントをあるタイプ（優れた可視性など）から別のタイプ（適用など）に変換する能力は、すべてのエージェントが利用できるわけではありません。変換を実行できないエージェントで変換が要求された場合、異常が報告されます。

エージェントによって最後に報告された現在のポリシー（NPC）バージョンが、クラスターで生成された現在のバージョンと一致しません。これは、エージェントとクラスタ間の通信エラー、エージェントがローカルファイアウォールでポリシーを適用できない、またはエージェントの適用サービスが実行されていないことが原因である可能性があります。

Secure Workload エージェントが Pcap デバイスをオープンしてフローをキャプチャできない場合、エージェントログにエラーが表示されます。Pcap デバイスが正常に開かれた場合は、次のように報告されます。

I0609 15:25:52.354 24248 Started capture thread for device <device_name>
I0609 15:25:52.354 71912 Opening device {<device_id>}

I0610 03:24:22.354 16614 Opening device <device_name>
[2020/06/10 03:24:23:3524] NOTICE: lws_client_connect_2: <device_id>: address 172.29.
˓→136.139

エージェントとクラスタ間の接続は外部でブロックされているため、フローやその他のシステム情報が配信されません。これはホスト上のネットワーク ファイアウォール、SSL 復号化サービス、またはサードパーティのセキュリティエージェントに関する 1 つ以上の設定の問題が原因で発生します。

• エージェントとクラスタの間に既知のファイアウォールまたは SSL 復号化セキュリティデバイスがある場合は、すべての Secure Workload コレクタと VIP の IP アドレスへの通信が許可されていることを確認してください。オンプレミスクラスタの場合、コレクタのリストは、Secure Workload Web インターフェイスの左側にあるナビゲーションバーの、[トラブルシューティング（Troubleshoot）] > [仮想マシン（Virtual Machines）] の下に表示されます。collectorDatamover-* を参照してください。Secure Workload クラウドの場合、許可する必要があるすべての IP アドレスがポータルにリストされます。

• SSL 復号化があるかどうかを判断するために、openssl s_client を使用して接続を確立し、返された証明書を表示できます。チェーンに証明書が追加されると、エージェントのローカル CA によって拒否されます。SSL のトラブルシューティング

  Note	通常、「フローエクスポート異常ステータス」を更新するサービスは 5 分ごとに実行されます。この期間は、エージェントのステータス更新が 5000 の小さなバッチで実行されているため、異なる場合があります。そのため、クラスタのエージェントが少ないほど、更新は速くなります。エージェントの数が多い場合、更新には最大 70 分かかることがあります。 データベースに含まれるエージェントレコードの最初のソート後、クラスタとエージェントが安定し、最終的に更新間隔が短くなり、一貫性が向上します。

バージョン 3.10.1.1 では、 Secure Workload エージェントは次のディストリビューションで Extended Berkeley Packet Filter（eBPF）を使用します。

• Ubuntu 22/24

• Debian 11/12

• EL9 ファミリ

Secure Workload エージェントがフロー キャプチャに対して eBPF を使用できない場合、エージェント ログにエラーが表示されます。

成功したフロー キャプチャは、次に示すように、ネットワークデバイスごとに報告されます。

I0604 21:29:20.357 833292 Opening device <device_name>
I0604 21:29:20.394 833292 Using eBPF TC to capture packets for <device_name>

• コマンド winver.exe を実行します。

• 「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

• cat /etc/os-release を実行します。

• 「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

• コマンド uname -a を実行します

• 注：メジャーバージョンとマイナーバージョンが逆になっています。

  p7-ops2> # uname -a
  AIX p7-ops2 1 7 00F8AF944C00

• この例では、ホスト名の後の最初の数字がマイナーバージョン、2 番目の数字がメジャーバージョンであるため、AIX バージョン 7.1 になります。「サポートされるプラットフォームと要件」に記載されている内容とこのリリースを比較します

• プロセスが現在 Npcap ライブラリを使用している場合、Npcap は正常にアンインストールされないことがあります。実行状況を調べるには、次のコマンドを実行します。

  PS C:\Program Files\Npcap> .\NPFInstall.exe -check_dll
  WindowsSensor.exe, Wireshark.exe, dumpcap.exe
  

プロセスが一覧表示される場合は、Npcap アップグレードを続行する前にそれらのプロセスを停止する必要があります。Npcap を使用しているプロセスがない場合、上記のコマンドにより<NULL>のみが表示されます。

• システムにインストールされている CA 証明書を確認します：NPCAP インストーラの証明書の問題

• Windows インストーラの問題を確認します：Windows インストーラの問題

• システム上の他のユーザーがネットワーク インターフェイスに変更を加えていないことを確認します。これが原因で COM ロックが発生し、NDIS ドライバのバインドが妨げられている可能性があります。

Windows 2016 のみに適用

サードパーティの LWF（ライトウェイトフィルタ）ドライバー（netmon など）がある場合、またはセットアップでチーミングアダプタが構成されており、エージェントの展開中に NPCAP がインストールされている場合、次のような状況が発生する可能性があります。

RDP が再接続される

NetBios サービスが再起動する

同様なネットワーク接続に関する問題

これは、Windows 2016 OS のバグが原因です。

チーミング NIC 機能は、物理 NIC（Intel、Broadcom、Realtek、MS 仮想アダプタなど）とチーミングドライバ構成 (スイッチベースでロードバランシングまたはフェールオーバーを備え、複数の NIC にパケットを分散するアルゴリズム) を基盤としています。

一部の NPCAP バージョンでは、特に下位のチーミング NIC へのバインド時に、チーミング NIC との互換性の問題があります。

NIC type : Intel(R) 82574L Gigabit Network Connection
Teaming Mode : Switch Independent
Load Balancing Mode: Address Hash
OS : Windows 2012 , Windows 2012 R2, Windows 2016, Windows 2019
NPCAP version: 1.55

Note	Windows 2008R2 は、Microsoft がサポートする NIC チーミングに対応していません。

TetSensor サービスは、NPCAP サービスが実行されているときに、複製された VM のネットワークフローをキャプチャしないことがあります。この問題は、MSI インストーラを使用して [nostart] フラグなしでエージェントがインストールされた場合、または VM テンプレートかゴールデンイメージで PowerShell インストーラを使用し、[goldenImage] フラグなしでエージェントがインストールされた場合に発生することがあります。

この場合、Secure Workload エージェントサービスは VM テンプレートで実行を開始します。NPCAP がインストールされ、VM テンプレートのネットワークスタックにバインドされます。新しい VM が VM テンプレートから複製されると、NPCAP は新しく複製された VM のネットワークスタックに正しくバインドされません。その結果、NPCAP はネットワークフローをキャプチャできません。

Windows TetSensor サービスが実行されていると、ネットワークパフォーマンスが影響を受けることが確認されています。Windows TetSensor サービス（tetsen.exe）は、Npcap を使用してネットワークフローをキャプチャします。ネットワークフローをキャプチャする Npcap の実装と、tetsen.exe へのネットワークフローが、ネットワークパフォーマンスに影響を及ぼします。

TetSensor をインストール後にネットワークパフォーマンスを比較：クライアント：Windows 2016

Npcap 1.55

TetSensor 構成：適用モード WFP を使用した会話モード

サーバー：Windows 2016

Npcap 1.55

TetSensor 構成：適用モード WFP を使用した会話モード

cmd の実行：iperf3.exe -c<server_ip> -t 40

Npcap 0.9990 でのネットワークパフォーマンス

TetSensor をインストール後にネットワークパフォーマンスを比較：クライアント：Windows 2016

Npcap 0.9990

TetSensor 構成：適用モード WFP を使用した会話モード

サーバー：Windows 2016

Npcap 0.9990

TetSensor 構成：適用モード WFP を使用した会話モード

cmd の実行：iperf3.exe -c<server_ip> -t 40。表：Npcap 0.9990 のネットワークパフォーマンス

class longtable

Note	パフォーマンスは、インストールされている Windows Npcap バージョン、Windows OS、およびネットワーク構成によって異なる場合があります。

インストールされている NPCAP のバージョンや構成が Secure Workload ソフトウェアでサポートされていない場合、OS で未知のパフォーマンス問題や安定性の問題が発生する可能性があります。

サポートされている NPCAP バージョン：0.991 および 1.55

• WSS：クラスタへのポート 443 を介した永続的なソケット接続

• チェックイン：15 ～ 20 分ごとにクラスタへの HTTPS コールを行い、現在の構成を確認し、更新を確認し、クラスタに対してエージェントのアクティブ状態を更新します。これは、アップグレードの失敗も報告します。

• フローエクスポート：フローメタデータをクラスタに送信するための、ポート 443（TaaS）または 5640（オンプレミス）を介した永続的な SSL 接続

• 適用：ポート 443（Taas）または 5660（オンプレミス）を介した永続的な SSL 接続により、適用ポリシーを取り込み、適用状態を報告します。

Teration UI は、非アクティブな（チェックインしなくなった）エージェント、（[統計（Stats）] の [エージェントワークロードプロファイル（Agent Workload Profile ）] ページにある）エクスポートされていないフロー、または失敗した適用のいずれかを報告します。エラーに応じてワークロードのさまざまなログを確認し、問題の原因を特定することができます。

Tue 06/09/2020 17:25:25.08 check_conf_update: "curl did not return 200 code, it's 304,
˓→ exiting"
Tue 06/09/2020 17:25:25.08 check_conf_update: "error code after running check_conf_
˓→update = 2"

cfgserver.go:261] config server: StateConnected, wss://<config_server_ip>:443/wss/
˓→<sensor_id>/forensic, proxy:

collector.go:258] next collector: StateConnected, ssl://<collector_ip>>:5640

ssl_client.cpp:341] Successfully connected to EFE server

Secure Workload エージェントは、TLS を使用して Secure Workload Cloud SaaS サーバーへの TCP 接続を保護します。これらの接続は、次の 3 つの特徴的なチャネルに分類されます。

• エージェント -> ポート TCP/443（TLS）（sensorVIP）経由の Cisco Secure Workload SaaS 制御チャネル

  これは、エージェントが Secure Workload に登録できるようにする低ボリュームの制御チャネルであり、設定のプッシュとソフトウェアアップグレード通知も処理します。

• エージェント -> TCP/443（TLS）（コレクタ）経由の Cisco Secure Workload SaaS フローデータ

  フローデータは、抽出されたフローメタデータ情報であり、このデータは一度に 16 個の IP アドレスのセット 1 つに送信されます。2 番目の IP アドレスのセットはスタンバイ用です。これは、実際のサーバートラフィックの約 1 ～ 5% を占めます。

• エージェント -> TCP/443（TLS）（efe）を介した Cisco Secure Workload SaaS 適用データ

  適用データチャネルは、ポリシーをセンサーにプッシュし、適用統計を収集するために使用される低ボリュームの制御チャネルです。

センサーは、エージェントとともにインストールされているローカル CA に対して、Secure Workload クラウドの制御、データ、および適用サーバーからの TLS 証明書を検証します。他の CA は使用されないため、エージェントに送信される他の証明書は検証に失敗し、エージェントは接続されません。結果的に、エージェントは登録、チェックイン、フローの送信、または適用ポリシーの受信を行わなくなります。

前のセクションで説明したとおり、エージェント通信の SSL/TLS 復号化をバイパスするために、明示的または透過的な Web プロキシを設定することが重要です。バイパスが設定されていない場合、これらのプロキシは復号化を試みる可能性があります

SSL/TLS トラフィックは、自身の証明書をエージェントに送信することによるトラフィックです。エージェントはローカル CA のみを使用して証明書を検証するため、これらのプロキシ証明書によって接続エラーが発生します。

症状には、エージェントがクラスタに登録できない、エージェントがチェックインしない、エージェントがフローを送信しない、（適用が有効になっている場合）エージェントが設定の適用を受信しないなどがあります。

Note	以下のトラブルシューティング手順は、デフォルトのインストールパスが使用されたことを前提としています。Windows: C:Program FilesCisco Tetration Linux: /usr/local/tet. エージェントを別の場所にインストールした場合は、手順をその場所に置き換えてください。

SSL/TLS 接続の問題は、エージェントログで報告されます。ログに SSL エラーがあるかどうかを確認するには、観察された関連する問題に対して次のコマンドを実行します。

grep "NSS error" /usr/local/tet/log/check_conf_update.log

get-content "C:\Program Files\Cisco Tetration\logs\TetUpdate.exe.log" | select-
˓→string -pattern "curl failed SSL peer certificate"

grep "SSL connect error" /usr/local/tet/log/tet-sensor.log

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Certificate verification error"

grep "Unable to validate the signing cert" /usr/local/tet/log/tet-enforcer.log

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Handshake failed"

curl -v -x http://<proxy_address>:<port> https://<sensorVIP>:443

cd "C:\Program Files\Cisco Tetration"
.\curl.exe -kv -x http://<proxy_address>:<port> https://<sensorVIP>:443

openssl s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile /usr/local/tet/
˓→cert/ca.cert

cd C:\Program Files\Cisco Tetration
.\openssl.exe s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile cert\ca.cert

Verify return code: 0 (ok)

0 s:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration, Insieme BU/CN=129.146.
˓→155.109
i:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration Analytics/CN=Customer CA

[Net.ServicePointManager]::SecurityProtocol

Ssl3, Tls

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Ssl3,
˓→Tls,Tls11,Tls12'