“Unable to get Local Issuer Certificate” is a common SSL certificate error. It is related to the incomplete certificate chain such as (most commonly) missing the intermediate certificate. The fix is to ensure the entire certificate chain is present.
We will dive into this issue to see why this happens and how to fix it.
Understanding certificate chain
A certificate chain is an ordered list of certificates, containing an SSL/TLS server certificate, intermediate certificate, and Certificate Authority (CA) Certificates, that enable the receiver to verify that the sender and all CA’s are trustworthy.
- Root Certificate. A root certificate is a digital certificate that belongs to the issuing Certificate Authority. It comes pre-downloaded in most browsers and is stored in what is called a “trust store.” The root certificates are closely guarded by CAs.
- Intermediate Certificate. Intermediate certificates branch off root certificates like branches of trees. They act as middle-men between the protected root certificates and the server certificates issued out to the public. There will always be at least one intermediate certificate in a chain, but there can be more than one.
- Server Certificate. The server certificate is the one issued to the specific domain the user is needing coverage for.
We will use these files in this example.
- CA certificate file (usually called ca.pem or cacerts.pem)
- Intermediate certificate file (if exists, can be more than one. If you don’t know if you need an intermediate certificate, run through the steps and find out)
- Server certificate file
How to get a free SSL certificate?
If you need a free SSL certificate for your website, Elementor Cloud Website is a great option. They offer fast speeds, good uptime, and excellent customer support. It is an end-to-end solution gives you everything you need in one place for your website. Web Hosting on Google Cloud + SSL certificate + WordPress + Website Builder + Templates.
We recommend using Elementor Cloud Website to build a website. It is very easy to start. You can get your website online in minutes. The price is $99 for one year. Plus, they offer a 30-day money-back guarantee, so you can try it out with no risk.
How do Certificate Chains work?
When we install our TLS certificate, we also be sent an intermediate root certificate or bundle.
When a browser downloads our website’s TLS certificate upon arriving at our homepage, it begins chaining that certificate back to its root. It will begin by following the chain to the intermediate that has been installed, from there it continues tracing backwards until it arrives at a trusted root certificate.
If the certificate is valid and can be chained back to a trusted root, it will be trusted. If it can’t be chained back to a trusted root, the browser will issue a warning about the certificate.
View Certificate Chain
Use the openssl utility that can display a certificate chain. The following command will display the certificate chain for google.com.
openssl s_client -connect google.com:443 -servername google.com
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
In the openssl output, the numbered lines start with the server certificate (#0) followed by the intermediate (#1) and the root (#2).
The s: indicates the certificate subject, and i: indicates the issuing certificate’s subject.
Guidelines to verify the certificate chain is valid
- Subject of each certificate matches the Issuer of the preceding certificate in the chain (except for the Entity certificate).
- Subject and Issuer are the same for the root certificate.
If the certificates in the chain adhere to these guidelines, then the certificate chain is considered to be complete and valid.
- The Subject of the intermediate certificate matches the Issuer of the entity certificate.
- The Subject of the root certificate matches the Issuer of the intermediate certificate.
- The Subject and Issuer are the same in the root certificate.
Example of a valid certificate chain
server certificate
openssl x509 -text -in entity.pem | grep -E '(Subject|Issuer):'
Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1
Subject: C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.enterprise.apigee.com
Intermediate certificate
openssl x509 -text -in intermediate.pem | grep -E '(Subject|Issuer):'
Issuer: OU = GlobalSign Root CA – R2, O = GlobalSign, CN = GlobalSign
Subject: C = US, O = Google Trust Services, CN = GTS CA 1O1
Root certificate
openssl x509 -text -in root.pem | grep -E '(Subject|Issuer):'
Issuer: OU = GlobalSign Root CA – R2, O = GlobalSign, CN = GlobalSign
Subject: OU = GlobalSign Root CA – R2, O = GlobalSign, CN = GlobalSign
Check SSL Certificate with OpenSSL
Validate certificate chain with server and root Certificate
openssl verify cert.pem
cert.pem: C = Country, ST = State, O = Organization, CN = FQDN
error 20 at 0 depth lookup:unable to get local issuer certificate
We can use the following two commands to make sure that the issuer in the server certificate matches the subject in the ca certificate.
openssl x509 -noout -issuer -in cert.pem
issuer= /CN=the name of the CA
$ openssl x509 -noout -subject -in ca.pem
subject= /CN=the name of the CA
In the following case, we need to add the CAfile to verify the root certificate.
$ openssl verify -CAfile ca.pem cert.pem
cert.pem: OK
Validate certificate chain with server, intermediate, and root Certificate
$ openssl verify cert.pem
cert.pem: C = Countrycode, ST = State, O = Organization, CN = yourdomain.com
error 20 at 0 depth lookup:unable to get local issuer certificate
To complete the validation of the chain, we need to provide the CA certificate file and the intermediate certificate file when validating the server certificate file.
We can do that using the parameters CAfile (to provide the CA certificate) and untrusted (to provide intermediate certificate):
$ openssl verify -CAfile ca.pem -untrusted intermediate.cert.pem cert.pem
cert.pem: OK
If we have multiple intermediate CA certficates, we can use the untrusted parameter multiple times like -untrusted intermediate1.pem -untrusted intermediate2.pem .
Fix routines:X509_check_private_key:key values mismatch in 2 Ways
Related:
- Exploring SSL Certificate Chain with Examples
- Understanding X509 Certificate with Openssl Command
- OpenSSL Command to Generate View Check Certificate
- Converting CER CRT DER PEM PFX Certificate with Openssl
- SSL vs TLS and how to check TLS version in Linux
- Understanding SSH Key RSA DSA ECDSA ED25519
- Understanding server certificates with Examples
Quick step by step to fix SSL certificate problem: Unable to get local issuer certificate error.
Have you experienced the ‘SSL certificate problem unable: to get local issuer certificate’ problem while attempting to move from HTTP to HTTPS? We know how overwhelming it can be to deal with this issue but don’t let that frighten you. Here, we can help you fix it with this piece of writing and don’t make the wrong decisions like uninstalling your SSL certificate.
Regardless of which error pops up or the complexities involved in fixing it, never uninstall your SSL Certificate to get rid of SSL errors as doing that could prove to be fatal and expose you to serious security risks. Always remember that your SSL certificate protects the communication exchanged between the server and the browser, which prevents data interception of a third party.
Even, data privacy laws are getting stricter by the day, and therefore, you cannot make the unwise decision to uninstall your SSL. So, your only option is to get to the bottom of the ‘unable to get local issuer certificate’ error and fix it.
Before we help you do that, let us figure out how an SSL Certificate works and why it shows up the ‘curl: (60) SSL certificate problem: unable to get local issuer certificate’ or the ‘git SSL certificate problem unable to get local issuer certificate’ errors.
Why SSL Certificate Problem: Unable to get Local Issuer Certificate Error Happen?
Your SSL certificate’s primary purpose is to confirm authentication and ensure a secure exchange of information between the server and the client by referring to the HTTPS protocol. That is only possible when you have a working root certificate that is either directly or indirectly signed by a Certificate Authority. However, the error unable to get local issuer certificate’ occurs when the root certificate is not working properly especially when an SSL client makes an HTTPS request and during this, the client has to share an SSL certificate for identity verification.
Therefore, you need to take the necessary actions required to help bridge the gap.
How to Fix SSL Certificate Problem: Unable to get Local Issuer Certificate?
Now that we know the reasons for the ‘unable to get local issuer certificate’ glitch, it’s time to act. You could be experiencing this glitch due to many reasons, and those reasons could vary from software interfering in the SSL/TSL session or your Git application. Once you identify the cause, it becomes a whole lot easier to fix it. If you are unable to do that, then we recommend that you try out all the fixes one after another and something will work.
Unverified Self-signed SSL Certificate
Anyone can sign an SSL certificate by generating a signing key; however, the OS and the Web Browser may not be able to identify that. This could be the reason why you see the ‘SSL certificate problem: unable to get local issuer certificate’ or the ‘curl: (60) SSL certificate problem: unable to get local issuer certificate’ error.
Solution – Buy an SSL Certificate that is authenticated by a reputed certificate Authority and install it.
Alter the php.ini file to solve ‘unable to get local issuer certificate’
Log in to your web control panel such as cPanel and locate the file manager. You will then find the PHP software, and inside that, you can find the php.ini file that you need to edit. Follow the below-mentioned steps.
Change Php.ini
- Click on http://curl.haxx.se/ca/cacert.pem and download cacert.pem.
- After that, copy cacert.pem to openssl/zend, like ‘/usr/local/openssl-0.9.8/certs/cacert.pem’.
- Finally, navigate to the php.ini file, modify CURL. Add “cainfo = ‘/usr/local/openssl-0.9.8/certs/cacert.pem’” to modify it.
- Restart PHP
- Confirm if CURL can now read the HTTPS URL.
Without Altering php.ini file
Use the code given below:
$ch = curl_init();
$certificate_location = ‘/usr/local/openssl-0.9.8/certs/cacert.pem’;
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, $certificate_location);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, $certificate_location);
Git Users
Most Git users experience the ‘SSL certificate problem: unable to get local issuer certificate’ or the ‘git SSL certificate problem unable to get local issuer certificate’ error at some point in time. If you have encountered it, then there are two ways of solving this — the first one is a permanent fix and the second one is a temporary fix, which we shall discuss below.
Permanent Fix
If you are a Git user-facing the ‘git SSL certificate problem unable to get local issuer certificate’ error, then you need to tell Git where the CA bundle is located.
To help Git find the CA bundle, use the below-mentioned command:
git config –system http.sslCAPath /absolute/path/to/git/certificates
Temporary Fix
To temporarily fix the ‘SSL certificate problem: unable to get local issuer certificate’ error, you could disable the verification of your SSL certificate. However, we recommend that you use it sparingly as it could lower your website’s security.
Use the following command to disable the verification of your SSL certificate:
git config –global http.sslVerify false
If neither of the two options work, consider removing and reinstalling Git.
Conclusion:
We are confident that one of the above ‘SSL certificate problem: unable to get local issuer certificate’ error fixes would work for you. Finally, we strongly recommend that you entirely avoid removing your SSL certificate. Your website needs to be protected, and one of your most robust defenses is an active SSL certificate.
Related SSL Errors:
- ERR_CONNECTION_REFUSED
- Secure Connection Failed in Firefox
- NET::ERR_CERT_AUTHORITY_INVALID
- ERR_SSL_VERSION_INTERFERENCE
- ERR_SSL_PROTOCOL_ERROR
What is the ‘ssl certificate problem unable to get local issuer certificate’ error
The unable to get local issuer certificate
is a common issue faced by developers when trying to push, pull, or clone a git repository using Git Bash, a command-line tool specific to Windows.
The unable to get local issuer certificate
error often occurs when the Git server’s SSL certificate is self-signed. The issue with self-signed certificates is that the private key associated with them cannot be revoked, making it a security vulnerability.
Alternatively, it can be due to incorrect configuration for Git on your system or when using git inside Visual Studio Code (VS Code) terminal.
What causes ‘ssl certificate problem unable to get local issuer certificate’
The unable to get local issuer certificate
error is caused by the misconfiguration of the SSL certificate on your local machine. When pushing, pulling, or cloning, Git cannot verify your SSL certification, which leads to the error.
A valid HTTPS handshake requires both the client and the server to create a secure connection, allowing for safe communication between your local machine and where the source code is hosted. When the SSL certificate cannot be verified, Git cannot complete the HTTPS handshake with the server that hosts the repository.
When the unable to get local issuer certificate error
occurs in VS Code, it is often because Visual Studio cannot locate the SSL certificate. This may be due to the path being misconfigured on the local machine.
How can you fix ‘ssl certificate problem unable to get local issuer certificate errors’
When ssl certificate problem unable to get local issuer certificate
error is caused by a self-signed certificate, the fix is to add the certificate to the trusted certificate store.
By default, the trusted certificate store is located in the following directory for Git Bash:
C:Program FilesGitmingw64sslcerts
Open the file ca-bundle.crt
located in the directory above, then copy and paste the Git SSL certificate to the end of the file. Once completed, save the file and run your git pull, push, or clone command.
Disabling SSL certificate validation is not recommended for security purposes. However, it is an option for fixing the ssl certificate problem unable to get local issuer certificate
error.
You can disable SSL certificate validation locally in Git using the following command:
$ git -c http.sslVerify=false clone [URL]
You can also disable SSL certificate validation at a global level using the following command:
$ git config --global http.sslVerify false
To re-enable SSL certificate validation, use the following command:
$ git config --global http.sslVerify true
Another method for fixing the ssl certificate problem unable to get local issuer certificate
error is to reinstall Git and choose the SSL transport backend option during the installation process.
If the unable to get local issuer certificate error
occurs inside Visual Studio Code, you need to grant your repository access to the SSL certificates. To do this, git can be reconfigured with the --global
flag on your SSL certificate configuration. This will give the Git server accessibility to the required SSL certificate.
To do this, run the following command in the Terminal:
git config --global http.sslBackend schannel
Accessibility to SSL certificate verification can also be set at the system level. To do this, you must be running in administrator mode before executing the following command:
git config --system http.sslBackend schannel
If the unable to get local issuer certificate error
in Visual Studio Code is not due to accessibility but a location misconfiguration, this can be fixed by reassigning the path. This can be done through the following command:
git config --global http.sslcainfo "Path"
How to prevent ‘ssl certificate problem unable to get local issuer certificate’ errors
The main purpose of a SSL certificate is to confirm authentication so that the information passed between client and server is secure. When an unable to get local issuer certificate error
occurs, a secure connection cannot be established, and the git client rejects your attempt to push, pull, or clone a repository for security reasons.
While disabling SSL certificates altogether is an option and common fix, it is not recommended. It opens up a security vulnerability for your repository and your local machine. Nevertheless, you can negate the unable to get local issuer certificate error by disabling SSL certificates at a local and global level. If SSL certificates are disabled at a global level, it is good to always enable them again so that other projects are not impacted by the intentional security disablement.
To prevent the error, ensure that you have a valid SSL certificate in your certificate store. Alternatively, you can reinstall your Git Bash with SSL Transport backend selected during the installation process.
If you are using Git via Visual Studio Code and have a valid SSL certificate in your certificate store but still encounter the certificate problem
error, use the --global
flag on your SSL certificate configuration to grant the Git server accessibility.
Kubernetes Troubleshooting With Komodor
We hope that the guide above helps you better understand the troubleshooting steps you need to take in order to fix the unable to get local issuer certificate
error.
Keep in mind that this is just one of many Git errors that can pop up in your k8s logs and cause the system to fail. Due to the complex and distributed nature of k8s, the search for the root cause of each such failure can be stressful, disorienting, and time-consuming.
Komodor is a Kubernetes troubleshooting platform that turns hours of guesswork into actionable answers in just a few clicks. Using Komodor, you can monitor, alert and troubleshoot incidents in your entire K8s cluster.
For each K8s resource, Komodor automatically constructs a coherent view, including the relevant deploys, config changes, dependencies, metrics, and past incidents. Komodor seamlessly integrates and utilizes data from cloud providers, source controls, CI/CD pipelines, monitoring tools, and incident response platforms.
- Discover the root cause automatically with a timeline that tracks all changes made in your application and infrastructure.
- Quickly tackle the issue, with easy-to-follow remediation instructions.
- Give your entire team a way to troubleshoot independently, without having to escalate.
In last blog, I introduced how SSL/TLS connections are established and how to verify the whole handshake process in network packet file. However capturing network packet is not always supported or possible for certain scenarios. Here in this blog, I will introduce 5 handy tools that can test different phases of SSL/TLS connection so that you can narrow down the cause of SSL/TLS connection issue and locate root cause.
curl
Suitable scenarios: TLS version mismatch, no supported CipherSuite, network connection between client and server.
curl is an open source tool available on Windows 10, Linux and Unix OS. It is a tool designed to transfer data and supports many protocols. HTTPS is one of them. It can also used to test TLS connection.
Examples:
1. Test connection with a given TLS version.
curl -v https://pingrds.redis.cache.windows.net:6380 —tlsv1.0
2. Test with a given CipherSuite and TLS version
curl -v https://pingrds.redis.cache.windows.net:6380 —ciphers ECDHE-RSA-NULL-SHA —tlsv1.2
Success connection example:
curl -v https://pingrds.redis.cache.windows.net:6380 --tlsv1.2
* Rebuilt URL to: https://pingrds.redis.cache.windows.net:6380/
* Trying 13.75.94.86...
* TCP_NODELAY set
* Connected to pingrds.redis.cache.windows.net (13.75.94.86) port 6380 (#0)
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 202 bytes...
* schannel: sent initial handshake data: sent 202 bytes
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 2/3)
* schannel: encrypted data got 4096
* schannel: encrypted data buffer: offset 4096 length 4096
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 2/3)
* schannel: encrypted data got 1024
* schannel: encrypted data buffer: offset 5120 length 5120
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 2/3)
* schannel: encrypted data got 496
* schannel: encrypted data buffer: offset 5616 length 6144
* schannel: sending next handshake data: sending 3791 bytes...
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 2/3)
* schannel: encrypted data got 51
* schannel: encrypted data buffer: offset 51 length 6144
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 3/3)
* schannel: stored credential handle in session cache
Fail connection example due to either TLS version mismatch. Not supported ciphersuite returns similar error.
curl -v https://pingrds.redis.cache.windows.net:6380 --tlsv1.0
* Rebuilt URL to: https://pingrds.redis.cache.windows.net:6380/
* Trying 13.75.94.86...
* TCP_NODELAY set
* Connected to pingrds.redis.cache.windows.net (13.75.94.86) port 6380 (#0)
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 144 bytes...
* schannel: sent initial handshake data: sent 144 bytes
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with pingrds.redis.cache.windows.net port 6380 (step 2/3)
* schannel: failed to receive handshake, SSL/TLS connection failed
* Closing connection 0
* schannel: shutting down SSL/TLS connection with pingrds.redis.cache.windows.net port 6380
* Send failure: Connection was reset
* schannel: failed to send close msg: Failed sending data to the peer (bytes written: -1)
* schannel: clear security context handle
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
Failed due to network connectivity issue.
curl -v https://pingrds.redis.cache.windows.net:6380 --tlsv1.2
* Rebuilt URL to: https://pingrds.redis.cache.windows.net:6380/
* Trying 13.75.94.86...
* TCP_NODELAY set
* connect to 13.75.94.86 port 6380 failed: Timed out
* Failed to connect to pingrds.redis.cache.windows.net port 6380: Timed out
* Closing connection 0
curl: (7) Failed to connect to pingrds.redis.cache.windows.net port 6380: Timed out
openssl
Suitable scenarios: TLS version mismatch, no supported CipherSuite, network connection between client and server.
openSSL is an open source tool and its s_client acts as SSL client to test SSL connection with a remote server. This is helpful to isolate the cause of client.
- On majority Linux machines, OpenSSL is there already. On Windows, you can download it from this link: https://chocolatey.org/packages/openssl
- Run Open SSL
- Windows: open the installation directory, click /bin/, and then double-click openssl.exe.
- Mac and Linux: run openssl from a terminal.
- Issue s_client -help to find all options.
Command examples:
1. Test a particular TLS version:
s_client -host sdcstest.blob.core.windows.net -port 443 -tls1_1
2. Disable one TLS version
s_client -host sdcstest.blob.core.windows.net -port 443 -no_tls1_2
3. Test with a given ciphersuite:
s_client -host sdcstest.blob.core.windows.net -port 443 -cipher ECDHE-RSA-AES256-GCM-SHA384
4. Verify if remote server’s certificates are trusted.
Success connection example:
CONNECTED(000001A0)
depth=1 C = US, O = Microsoft Corporation, CN = Microsoft RSA TLS CA 02
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = *.blob.core.windows.net
verify return:1
---
Certificate chain
0 s:CN = *.blob.core.windows.net
i:C = US, O = Microsoft Corporation, CN = Microsoft RSA TLS CA 02
1 s:C = US, O = Microsoft Corporation, CN = Microsoft RSA TLS CA 02
i:C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIINtDCCC5ygAwIBAgITfwAI6NfesKGuQGWPYQAAAAjo1zANBgkqhkiG9w0BAQsF
ADBPMQswCQYDVQQGEwJVUzEeMBwGA1UEChMVTWljcm9zb2Z0IENvcnBvcmF0aW9u
pK8hqxL0zc4NQLRTq9RNpdPwnNmGn5SZ4Nu5ktUgWokR97THzgs6a/ErHH2tigLF
jwkgB8UuV/hhu3vEa0jxstSBgbjQPgSNexAl7XwgawaucIF+wkRpPW2w0VTcDWtT
1bGtFCpewAo=
-----END CERTIFICATE-----
subject=CN = *.blob.core.windows.net
issuer=C = US, O = Microsoft Corporation, CN = Microsoft RSA TLS CA 02
---
No client certificate CA names sent
Peer signing digest: MD5-SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5399 bytes and written 293 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: B60B0000F51FFB7C9DDB4E58CD20DC20987C13CFD31386BE435D612CF5EFDBF9
Session-ID-ctx:
Master-Key: DA402F6E301B4E4981B7820CAF6E0AF3C633290E85E2998BFAB081788488D3807ABD3FF41FF48DA55DB56281C024C4F4
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1615557502
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: yes
Fail connection example due to TLS mismatch:
OpenSSL> s_client -host sdcstest.blob.core.windows.net -port 443 -tls1_3
CONNECTED(0000017C)
write:errno=10054
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 254 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
error in s_client
Fail connection example due to network connectivity:
OpenSSL> s_client -host sdcstest.blob.core.windows.net -port 7780
30688:error:0200274C:system library:connect:reason(1868):crypto/bio/b_sock2.c:110:
30688:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111:
connect:errno=0
error in s_client
Online tool
https://www.ssllabs.com/ssltest/
Suitable scenarios: TLS version mismatch, no supported CipherSuite.
This is a free online service performs a deep analysis of the configuration of any SSL web server on the public Internet. It can list all supported TLS versions and ciphers of a server. And auto detect if server works fine in different types of client, such as web browsers, mobile devices, etc.
Please note, this only works with public access website. For internal access website will need to run above curl or openssl from an internal environment. And it only supports domain name and does not work with IP address.
Web Browser:
Suitable scenarios: Verify if server certificate chain is trusted on client.
Web Browser can be used to verify if remote server’s certificate is trusted or not locally:
- Access the url from web browser.
- It does not matter if the page can be load or not. Before loading anything from the remote sever, web browser tried to establish SSL connection.
- If you see below error returned, it means certificate is not trusted on current machine.
Certutil
Suitable scenarios: Verify if server certificate on client, verify client certificate on server.
Certutil is a tool available on windows. It is useful to verify a given certificate. For example verify server certificate from client end. If mutual authentication is implemented, this tool can also be used to verify client certificate on server.
The command auto verifies trusted certificate chain and certificate revocation list (CRL).
Command:
certutil -verify -urlfetch <client cert file path>
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil#-verify
Next blog, I will introduce solutions for common causes of SSL/TLS connection issues.
Platform Notice: Cloud, Server, and Data Center — This article applies equally to all platforms.
Problem
The following is seen on the command line when pushing or pulling:
SSL Certificate problem: unable to get local issuer
Cause
There are two potential causes that have been identified for this issue.
- A Self-signed certificate cannot be verified.
- Default GIT crypto backend (Windows clients)
Resolution
Resolution #1 — Self Signed certificate
Workaround
Tell git to not perform the validation of the certificate using the global option:
git config --global http.sslVerify false
Please be advised disabling SSL verification globally might be considered a security risk and should be implemented only temporarily
Resolution — Client Side
Please notice that we refer to the Certificate Authority in this article by the acronym CA.
There are several ways this issue has been resolved previously. Below we suggest possible solutions that should be run on the client side:
- Ensure the root cert is added to git.exe’s certificate store. The location of this file will depend on how/where GIT was installed. For instance, the trusted certificate store directory for Git Bash is C:Program FilesGitmingw64sslcerts. This is also discussed on this Microsoft blog.
-
Tell Git where to find the CA bundle, either by running:
git config --system http.sslCAPath /absolute/path/to/git/certificates
where
/absolute/path/to/git/certificates
is the path to where you placed the file that contains the CA certificate(s).or by copying the CA bundle to the
/bin
directory and adding the following to thegitconfig
file:sslCAinfo = /bin/curl-ca-bundle.crt
- Reinstall Git.
-
Ensure that the complete certificate chain is present in the CA bundle file, including the root cert.
Resolution — Server Side
This issue can also happen on configurations where Bitbucket Server is secured with an SSL-terminating connector rather than a proxy
- Ensure that the Java KeyStore has the entire certificate chain (Intermediate CA and Root CA)
- View the Certificate Chain Details inside the KeyStore using a tool like the KeyStore Explorer to check
Resolution #2 — Default GIT crypto backend
When using Windows, the problem resides that git by default uses the «Linux» crypto backend, so the GIT operation may not complete occasionally. Starting with Git for Windows 2.14, you can configure Git to use SChannel, the built-in Windows networking layer as the crypto backend. To do that, just run the following command in the GIT client:
git config --global http.sslbackend schannel
This means that it will use the Windows certificate storage mechanism and you don’t need to explicitly configure the curl CA storage (http.sslCAInfo
) mechanism.