発端

そもそもそれに気が付いたのは、GitからpullしてくるときになぜかHttps経由で使えなかったことに端を発します。

幸いGitは, git://という経路が用意されているのでGit問題は、一旦終息を迎えました。

しかし、NuGetからパッケージを復元しようとしたところ、Visual Studioが以下のような例外を投げてきました。

「 基礎になる接続が閉じられました: SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした。」

ちょっと意味が分からないですよね。

NuGetでパッケージを復元できないって完全に詰んだ感じです。

ちなみにブラウザからは、普通に同じURL叩いても繋がるっていうのが最高にたちの悪い話で、明らかに全部自分が悪いじゃないかってことで言い訳できなくなりました。

 

原因調査

とりあえず詰んだって言ってるうちは解決しないので原因の究明をいろいろと。

 

試したこと

  1. 証明書の確認
  2. プロキシの有無
  3. Visual Studioの入れ直し
  4. 別アカウントを作成してサインイン

とりあえず何か原因っぽいことに心当たりがなかったので、上記4つを試してみました。

 

証明書の確認

まず最初に、証明書が期限切れとかそういう感じのことを調べましたが、まったく期限切れや変な証明書は、存在せず。関係ありませんでした。

 

プロキシの確認

よくありがちなプロキシが噛んでいたパターン

これもインターネットの設定から見たら設定されおらず。

コマンドラインから以下のコマンドを打って確認

  1. netsh
  2. winhttp
  3. show proxy

この手順で確認したところ

image

こんな感じでプロキシは、噛んでいなさそう

 

Visual Studioの入れ直し

Visual Studioをとりあえず修復するのと入れ直しをしてみましたが、変化せず。 Visual Studioは、悪くなかった。よかった

 

別アカウントを作って入ってみる

PCに別アカウントを作成して入ってみたところ、なぜかすんなりSSLが繋がりました。

???みたいになりましたが、冷静に考えてみるとこれは、おそらく環境変数じゃねえかと思い立ちいつものアカウントで確認してみました。

 

最終的な結果

以前ローカルのvagrantに対してプロキシ経由でアクセスするためのに書いた

  • http_proxy
  • https_proxy

の環境変数が悪さをしているような気がして思い切って削除してみました。

削除したところ見事SSLが繋がったということで、こいつらが悪さをしていたようです。

 

結論

環境変数でhttp_proxyとかhttps_proxyとかを書くときは、やらかした時の原因究明に時間がかかる気がするのでさっさと消してしまいましょうってことでした。

CATEGORIES