すぐに解決したい場合は--no-verify-sslオプションを使えば警告は出るものの一応使えるようになります。
しかしここでは証明書を指定する方法で解決します。

原因

典型的にはセキュリティソフトが通信に介入していることで発生します。
通常はOS側にセキュリティソフト用の証明書がインストールされているためエラーにはならないのですが、
AWSCLIなど独自に証明書ストアを持っているアプリケーションでは、OS側の証明書を参照せずにタイトルのエラーが出ることになります。

解決策

OS側から証明書を取り出しAWSCLIに渡します。

Windowsボタンでメニューが開いた状態で「証明書」と日本語入力すれば「コンピューター証明書の管理」が出てきますので起動します。
信頼されたルート証明機関＞証明書とツリーを開きます。
今回はZscalerやNetskopeが怪しいので「Zscaler」や「Netsokpe」と記載のある証明書を探します。
見つけたら右クリック＞すべてのタスク＞エクスポートと選択します。
途中で聞かれる形式は「Base 64 encoded X.509 (.CER)」を選択し保存します。

あとは--ca-bundle "保存した証明書のパス"としてAWSコマンドのオプションを足せば解決すると思います。

なおコマンドラインオプションだと普段使いには不便なので、
AWS_CA_BUNDLEという環境変数に証明書のパスを設定するか、
aws configure set default.ca_bundle "保存した証明書のパス"で設定値として保存できます。

続き

自分の環境ではここでは終わらなくて、サブコマンド（接続先ホスト）によってNetskopeが介入するときとしないときがあるようでした。
つまりNetskopeの証明書のみを指定することによって逆に動かなくなるコマンドも出てきました。
そこで証明書を追加することにします。

今度は「Starfield Class 2」と記載のある証明書をエクスポートします。
エクスポートした証明書はテキストファイルで複数格納可能な形式ですので、以下のように並べたテキストファイルを作成します。

awscli.pem

-----BEGIN CERTIFICATE-----
AAAAAAA...
AAAAAAA...
(略)
AAAAAAA...
AAAAAAA...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
AAAAAAA...
AAAAAAA...
(略)
AAAAAAA...
AAAAAAA...
-----END CERTIFICATE-----

今度はこちらの証明書を指定することで問題が解決しました。