Azure DevOps Server · git over HTTPS and JetBrains IDEs · Checked November 2, 2026

Azure DevOps Server: "unable to get local issuer certificate", "SEC_E_UNTRUSTED_ROOT" and "PKIX path building failed"

Your Azure DevOps Server has a certificate signed by your company's own certificate authority, or a self-signed one, and the program that complains does not trust that authority. The token and the server are fine. Each program keeps its own list of trusted authorities, which is why the browser or Visual Studio can open the server while git clone fails. Add the company's root certificate to the list of the program that complains, and leave the check on.

The whole answer, from each program

We gave a local HTTPS server a certificate signed by a test company CA that the computer did not trust, and pointed each program at https://localhost:8443/tfs/DefaultCollection/Proj/_git/Repo:

Git 2.53 for Windows with Schannel (its setting on our computer):
fatal: unable to access 'https://localhost:8443/tfs/DefaultCollection/Proj/_git/Repo/': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325)

Git 2.53 with 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, which the JetBrains IDEs run on, with its default trust store:
javax.net.ssl.SSLHandshakeException: (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Git built with libcurl 8.16 or older words the OpenSSL one as SSL certificate problem: unable to get local issuer certificate. libcurl 8.17 changed the wording; our Git 2.53 has libcurl 8.18.

Which list each program trusts

• Git for Windows with Schannel: the Windows certificate store. If your company already put its CA there, often by group policy, Git trusts the server with no setting at all.
• Git with OpenSSL (Git for Windows when set to OpenSSL, and Git on macOS and Linux): its own bundle of public authorities, not the Windows store.
• Visual Studio: the Windows certificate store, per Microsoft's Set up HTTPS with Secure Sockets Layer (SSL) for Azure DevOps Server.
• IntelliJ IDEA, Rider and the other JetBrains IDEs: the JDK's cacerts, the IDE's own Server Certificates list, and the system trust store; on Windows that includes system-wide, user and group policy certificates (JetBrains' Trusted root certificates). Plain Java reads only cacerts, so a Java tool can fail where the IDE works.

The same Microsoft page, last updated October 30, 2025, still says that Git "does not recognize the Windows certificate store" and uses OpenSSL. The Git for Windows we tested was set to Schannel in C:/Program Files/Git/etc/gitconfig. See which one yours uses before you change anything:

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

Git with Schannel: SEC_E_UNTRUSTED_ROOT

The company's root certificate is not in the Windows store of this computer. Ask IT to distribute it, or import it into Trusted Root Certification Authorities (JetBrains' page above walks through it with mmc; it needs an administrator). Then Git, Visual Studio and the IDE all trust the server.

To change only Git, give it the root certificate as a PEM file for that one server:

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

Both lines are needed. Git tells Schannel to ignore http.sslCAInfo unless http.schannelUseSSLCAInfo is on (git-config). In our test the first line alone still ended in SEC_E_UNTRUSTED_ROOT; with both, Git connected, and github.com still worked through the Windows store.

Git with OpenSSL: unable to get local issuer certificate

On Windows, if the browser opens the server without a warning, the CA is already in the Windows store, and switching Git to Schannel is enough:

git config --global http.sslBackend schannel

Otherwise, or on macOS and Linux, give Git the root certificate for that one server:

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

In our test this connected, and github.com still worked. Leave out the address and it goes wrong: the file then replaces Git's whole bundle, and github.com failed with unable to get local issuer certificate (20). Microsoft's page avoids that another way, with a private copy of Git's bundle that has the company root added. The page also says to export the root certificate from the browser as a Base-64 encoded X.509 file, which is the PEM format Git reads.

Not http.sslVerify false: Git would then send your token to whatever answers at that address.

The name has to match too

A trusted certificate is still refused when it was issued for another name than the one in the remote URL, for example when the remote uses the server's IP address or a short name. Our certificate was for localhost, with the CA trusted this time:

Git with OpenSSL, remote 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'

Git with Schannel, remote 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.

Use the name the certificate has. The browser's certificate viewer lists it under Subject Alternative Name. Change the remote with git remote set-url origin https://<that name>/….

In IntelliJ IDEA and Rider

Clone, fetch and push in the IDE run Git itself, so they need the Git fix above. What the IDE does through its own connections, a plugin's REST calls among them, follows the IDE's list. If the system store does not have the certificate, add it under Settings | Appearance & Behavior | System Settings | Server Certificates (JetBrains' help). It takes a .crt, .cer or .pem file, keeps it in ssl/cacerts in the IDE configuration directory, and changes only that IDE. Leave Accept non-trusted certificates automatically off; it accepts every certificate without asking.

If the IDE still refuses, JetBrains' Trusted root certificates page names two debug categories to switch on under Help | Diagnostic Tools | Debug Log Settings: org.jetbrains.nativecerts and #com.intellij.util.net.ssl.

Azure DevOps Server pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, talks to Azure DevOps Server 2019 and later, and TFS 2018 Update 2, through the IDE's own connection, so it trusts what the IDE trusts and uses its proxy settings. When the certificate is not trusted, it says so in plain words and names the Server Certificates setting, with Java's reason in brackets after the server's name. When the certificate is for another name, it says to use the address the certificate has. The review inbox is free; voting, commenting and completing are Pro (US$1 a month, with a 30-day trial).

Get it on JetBrains Marketplace

Azure DevOps and Visual Studio are trademarks of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: TFS 2018 and Azure DevOps Server 2019 · "fatal: Authentication failed": the token was refused · 日本語