対象者
- いざAmazon Q Developerと会話を始めようとしたら「self-signed certificate」と言われてダンマリを決め込まれた方
- Amazon Q DeveloperをローカルPCから使おうとしている方
（特に、そこそこの規模でセキュリティのソリューションが中間に入っているような会社） - Windows・Macどちらでも
発生する事象（self-signed certificate）
よし、とりあえずAmazon Q Developerを使ってみるぞと意気揚々とVSCodeの拡張機能を入れ、いざ会話を始めてみると
↓
何を聞いてみても「self-signed certificate」としか言ってもらえないことがあります。萎えますよね。
解決方法
これを解決するためにはCA証明書の場所を環境変数に登録してNode.jsに認識してもらう
ということが必要になります。
- Windowsの場合
# 環境変数を設定
set NODE_EXTRA_CA_CERTS=C:\path\to\your-ca-bundle.pem
# 永続化（システム環境変数として設定）
setx NODE_EXTRA_CA_CERTS "C:\path\to\your-ca-bundle.pem"
- Macの場合
# CA証明書を指定
export NODE_EXTRA_CA_CERTS="/path/to/your-ca-bundle.pem"
# 永続化（~/.zshrcに追加）
echo 'export NODE_EXTRA_CA_CERTS="/path/to/your-ca-bundle.pem"' >> ~/.zshrc
source ~/.zshrc
環境変数に設定する方法以外の方法として、VSCodeのsettings.jsonに書く、というのもよくある話なのですが、この方法は私の環境ではうまくいきませんでした。
ちなみに肝心のCA証明書はIT部門から直接入手するか、以下のようにブラウザからエクスポートしておくという方法もあります。
- 任意のサイトにアクセス（Chromeを例にしています）
- アドレスバーの左の部分から証明書を表示
- 証明書ビューアから、証明書の最上位の階層を選択し「エクスポート」、ファイルを「.pem」ファイルで保存しておく
（本事象が発生している場合、証明書発行元があまり聞き馴染みのないところか、所属している会社の名前になっていたりするはずです）
なぜこんなことに
特に企業ネットワークなどの使用を強制されているようなPCの場合、セキュリティとして通信を「代理」することがあります。これを「SSL/TLS インターセプション」と言ったりします。
以下のような感じ
- VSCodeでAmazon Q Developerにアクセス
- 会社のプロキシが接続を代理
- プロキシが『偽装（中間）証明書』を動的生成
- VSCodeに『偽装証明書』で返却
→ このタイミングでAmazon Q Developer（厳密にはNode.js）が、誰これ知らない！となる。 - プロキシが実際のAWSと通信
- データを復号化・検査・再暗号化
簡単にいうと、友人に手紙を送ったら、郵便局が「セキュリティのため内容を確認します」と言って封筒を開封し、内容をチェックしてから友人に転送。返事も同様に郵便局が確認してから届ける。ただし、郵便局が「私が代理で署名しました」という署名を残したので、受け取った側は「この署名知らない！信頼できない！」となってしまう状況。
そういうことで、この人の署名は信頼してもいいんだな、ということをPC上に覚えてもらう必要があります。そのため環境変数にpemファイルを登録しました。
終わりに
Amazon Q Developerは無料から使える上、とても便利なツールですのでどんどん使っていきましょう。
ただ、きっとこのような環境の企業では、オプトアウトも求められると思いますので、以下を参考にして合わせて忘れずに設定しておいてくださいね。