Azure DevOps Server・HTTPS の git と JetBrains IDE・2026年11月2日に確認

Azure DevOps Server：「unable to get local issuer certificate」「SEC_E_UNTRUSTED_ROOT」「PKIX path building failed」

Azure DevOps Server の証明書が、会社の認証局の署名か自己署名で、文句を言っているプログラムがその認証局を信頼していません。トークンにもサーバーにも問題はありません。信頼する認証局の一覧はプログラムごとに別々です。そのため、ブラウザーや Visual Studio では開けるのに git clone だけ失敗する、ということが起きます。文句を言っているプログラムの一覧に会社のルート証明書を足してください。確かめ自体は切らずに残します。

プログラムごとの文面

手元に HTTPS のサーバーを立て、パソコンが信頼していない試験用の「会社の認証局」で署名した証明書を持たせて、それぞれ https://localhost:8443/tfs/DefaultCollection/Proj/_git/Repo に向けました。

Git 2.53 for Windows、Schannel（このパソコンでの設定）：
fatal: unable to access 'https://localhost:8443/tfs/DefaultCollection/Proj/_git/Repo/': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325)

Git 2.53、OpenSSL：
fatal: unable to access 'https://localhost:8443/tfs/DefaultCollection/Proj/_git/Repo/': SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)

Java 21（JetBrains IDE の土台）、既定の信頼ストア：
javax.net.ssl.SSLHandshakeException: (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

libcurl 8.16 以前で作られた Git では、OpenSSL の文面が SSL certificate problem: unable to get local issuer certificate になります。言い回しが変わったのは libcurl 8.17 からで、試した Git 2.53 には 8.18 が入っています。

どのプログラムが、どの一覧を信頼するか

• Git for Windows（Schannel）：Windows の証明書ストア。会社がグループ ポリシーなどで認証局をすでに配っていれば、設定なしでそのまま通ります。
• Git（OpenSSL）（OpenSSL に設定した Git for Windows と、macOS・Linux の Git）：自前で持つ公開の認証局の束。Windows のストアは見ません。
• Visual Studio：Windows の証明書ストア。Microsoft のHTTPS の設定（Azure DevOps Server の SSL の文書）にそう書かれています。
• IntelliJ IDEA・Rider など JetBrains IDE：JDK の cacerts、IDE の「サーバー証明書」の一覧、それに OS の信頼ストア。Windows ならシステム全体・ユーザー・グループ ポリシーで配られた証明書まで含みます（JetBrains の信頼されたルート証明書）。素の Java は cacerts しか見ないので、IDE では通るのに Java の道具だけ失敗することがあります。

同じ Microsoft の文書は、2025年10月30日の更新でも「Git は Windows 証明書ストアを認識しない」「OpenSSL を使う」としたままです。試した Git for Windows は、C:/Program Files/Git/etc/gitconfig で Schannel に設定されていました。何かを変える前に、自分の Git がどちらかを見てください。

git config --show-origin --get http.sslBackend

Schannel の Git：SEC_E_UNTRUSTED_ROOT

このパソコンの Windows のストアに、会社のルート証明書がありません。情報システムの担当に配ってもらうか、「信頼されたルート証明機関」に取り込みます（手順は上の JetBrains のページに mmc を使う形で載っています。管理者の権限が要ります）。そうすれば Git も Visual Studio も IDE も、そろってサーバーを信頼します。

Git だけを変えるなら、そのサーバーに限って、ルート証明書を PEM のファイルで渡します。

git config --global http.https://tfs.example.com/.sslCAInfo C:/certs/company-root.pem
git config --global http.https://tfs.example.com/.schannelUseSSLCAInfo true

2行とも要ります。http.schannelUseSSLCAInfo が有効でない限り、Git は Schannel に http.sslCAInfo を使わせません（git-config・英語）。試すと、1行目だけでは SEC_E_UNTRUSTED_ROOT のままでした。2行そろえるとつながり、github.com もこれまでどおり Windows のストアで通りました。

OpenSSL の Git：unable to get local issuer certificate

Windows で、ブラウザーが警告なしにサーバーを開けるなら、認証局はもう Windows のストアにあります。Git を Schannel に切り替えれば足ります。

git config --global http.sslBackend schannel

そうでなければ、または macOS や Linux なら、そのサーバーに限ってルート証明書を渡します。

git config --global http.https://tfs.example.com/.sslCAInfo /path/to/company-root.pem

試すとつながり、github.com も通ったままでした。住所を付けずに設定すると話が変わります。ファイルが Git の束をまるごと置き換え、github.com が unable to get local issuer certificate (20) で失敗しました。Microsoft の文書は別のやり方で、Git の束の写しを自分用に作って会社のルートを足しています。ルート証明書はブラウザーから Base-64 エンコードの X.509 で書き出す、とも書かれています。Git が読む PEM の形です。

http.sslVerify false は使いません。その住所で答えた相手が誰でも、Git はトークンを渡してしまいます。

名前も合っている必要がある

信頼した証明書でも、リモートの URL と別の名前に出された証明書なら断られます。リモートがサーバーの IP アドレスや短い名前になっているときに起きがちです。試した証明書は localhost 用で、今度は認証局を信頼させた状態です。

OpenSSL の Git、リモート https://127.0.0.1:8443/…：
fatal: unable to access 'https://127.0.0.1:8443/…/': SSL: no alternative certificate subject name matches target ipv4 address '127.0.0.1'

Schannel の Git、リモート https://tfs.example.test:8443/…：
fatal: unable to access 'https://tfs.example.test:8443/…/': schannel: CertGetNameString() failed to match connection hostname (tfs.example.test) against server certificate names

Java 21：
javax.net.ssl.SSLHandshakeException: (certificate_unknown) No subject alternative DNS name matching tfs.example.test found.

証明書にある名前を使います。ブラウザーで証明書を開くと、サブジェクト代替名（Subject Alternative Name）に並んでいます。リモートは git remote set-url origin https://<その名前>/… で変えられます。

IntelliJ IDEA・Rider では

IDE のクローン・フェッチ・プッシュは Git そのものを動かすので、上の Git の直し方が要ります。一方、IDE が自分でつなぐ通信（プラグインの REST の呼び出しも含む）は IDE の一覧に従います。OS のストアに証明書が無ければ、設定 | 外観 & 振る舞い | システム設定 | サーバー証明書 に足します（JetBrains のヘルプ）。.crt・.cer・.pem のファイルを受け付け、IDE の構成ディレクトリの ssl/cacerts に置かれ、その IDE だけに効きます。信頼できない証明書を自動的に受け入れる はオフのままにしてください。どんな証明書でも聞かずに受け入れてしまいます。

それでも IDE が断るときは、JetBrains の「信頼されたルート証明書」のページにある2つのデバッグ カテゴリを、ヘルプ | 診断ツール | デバッグログ設定 で有効にします。org.jetbrains.nativecerts と #com.intellij.util.net.ssl です。

IntelliJ IDEA・Rider で Azure DevOps Server のプルリクを見るなら

Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。Azure DevOps Server 2019 以降と TFS 2018 Update 2 に、IDE 自身の通信でつなぐので、IDE が信頼する証明書をそのまま信頼し、プロキシの設定も使います。証明書が信頼されていなければ、そのことと「サーバー証明書」の設定の場所を言葉で伝え、Java の理由はサーバー名の後ろの括弧に添えます。証明書が別の名前のものなら、証明書にある住所を使うよう伝えます。受信箱は無料、投票・コメント・完了は Pro（月 US$1・30日間の無料試用つき）です。画面は日本語です。

JetBrains Marketplace で入れる

Azure DevOps と Visual Studio は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：TFS 2018・Azure DevOps Server 2019 で使う · 「fatal: Authentication failed」：トークンが断られた · English