When I’m out of the office, I connect to my team’s TFS server through the firewall and get served up with a properly signed (by a widely trusted CA) SSL certificate.
This means that my browser, and git have no issues connecting and cloning. When I’m in the office and connected to our corporate WiFi network, I get a self-signed SSL certificate.
It’s always been a hassle to add these certificates to Git’s local certificate store but luckily Visual Studio didn’t require you to do the same, seeing as they used Lib2Git. With VS2017, Microsoft switched to git.exe (which is good) but they aren’t using the one already on your path but rather a bundled installation which resides in the VS2017 extensions directory. This means that you have to add SSL certificates to yet another git trusted store.
Microsoft has done a https://blogs.msdn.microsoft.com/phkelley/2014/01/20/adding-a-corporate-or-self-signed-certificate-authority-to-git-exes-store/ of how to add a certificates should be added to your git.exe client and now this must be applied to Visual Studio as well to prevent this from happening:
The Git client resides in your VS2017 installation dir, which by default is
C:\Program Files (x86)\Microsoft Visual Studio\2017\. Now if you browse to your edition (i.e. ‘Enterprise’), you will see the familiar
Common7\IDE directory and then to the
CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\ssl\certs folder, you will find the ca-bundle.crt that Visual Studio uses. So the full path (for a default installation of VS2017 Enterprise) would be:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\ssl\certs
Add your Base64 encoded certificate and the next time you attempt to clone a repo within VS2017, you should be presented with the trusted VS logo ASCII art from TFS:
Hope this saves you a bit of trouble ;-)