Debugging TLS/SSL connections and protocols can be daunting due to their complexity. Here are some troubleshooting tips.
Separate client and server
Whenever testing TLS/SSL connections over the network, it’s best to really separate the client and the server. Remember that the crypto library configuration file is read by the library, not just by a server or a client. It’s read by both. Therefore having separate systems acting as clients and servers, with their own configuration files, makes things simpler to analyse.
Tools
Here are some tools to help troubleshooting a TLS/SSL configuration.
OpenSSL server and client apps
The OpenSSL server and client tools are very handy to quickly bring up a server with a selection of ciphers and protocols and test it with a client. Being part of OpenSSL, these tools will also initialize the library defaults directly from the OpenSSL config file, so they are very useful to test your configuration changes.
To bring up an OpenSSL server, a certificate with a private key is needed. There are many ways to generate a pair, and here is a quick one:
$ openssl req -new -x509 -nodes -days 30 -out myserver.pem -keyout myserver.key
Answer the questions as you prefer, but the one that needs special attention is the commonName (CN) one, which should match the hostname of this server. Then bring up the OpenSSL server with this command:
$ openssl s_server -cert myserver.pem -key myserver.key
That will bring up a TLS/SSL server on port 4433. Extra options that can be useful:
-
-port N
: Set a port number. Remember that ports below 1024 require root privileges, so usesudo
if that’s the case. -
-www
: Will send back a summary of the connection information, like ciphers used, protocols, etc. -
-tls1_2
,-tls1_3
,-no_tls1_3
,-no_tls1_2
: Enable only the mentioned protocol version, or, with theno_
prefix variant, disable it. -
-cipher <string>
: Use the specified cipher string for TLS1.2 and lower. -
-ciphersuite <string>
: Use the specified string for TLS1.3 ciphers.
The client connection tool can be used like this when connecting to server
:
$ echo | openssl s_client -connect server:port 2>&1 | grep ^New
That will generally show the TLS version used, and the selected cipher:
$ echo | openssl s_client -connect j-server.lxd:443 2>&1 | grep ^New
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
The ciphers and protocols can also be selected with the same command line options as the server:
$ echo | openssl s_client -connect j-server.lxd:443 -no_tls1_3 2>&1 | grep ^New
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
$ echo | openssl s_client -connect j-server.lxd:443 -no_tls1_3 2>&1 -cipher DEFAULT:-AES256 | grep ^New
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
The sslscan
tool
The sslscan
tool comes from a package with the same name, and it will scan a server and list the supported algorithms and protocols. It’s super useful for determining if your configuration has really disabled or enabled a particular cipher or TLS version.
To use the tool, point it at the server you want to scan:
$ sslscan j-server.lxd
And you will get a report of the ciphers and algorithms supported by that server. Consult its manpage for more details.
References
- OpenSSL s_server
- OpenSSL s_client
- sslscan
- https://badssl.com: excellent website that can be used to test a client against a multitude of certificates. algorithms, key sizes, protocol versions, and more.
SSL_ERROR_SYSCALL typically occurs when the server side is using an SSL certificate to authenticate. This article covers how to fix SSL_ERROR_SYSCALL error in 5 ways.
SSL_ERROR_SYSCALL Error
$ git clone https://github.com/xxx/xxx.git
fatal: unable to access ‘https://github.com/xxx/xxx.git/’: LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
Understanding SSL_ERROR_SYSCALL Error
This error typically occurs when the TCP three-way handshake between client and server completes but then a TCP reset packet (often written as “RST”) is received by the client, terminating the connection during the SSL phase.
This error is not produced when a client receives a RST packet during the three-way handshake, or after completion of the SSL/TLS negotiation (SSL phase).
Restart the computer
As we all know, restarting solves 90% of problems, and sometimes restarting the computer can directly solve the problem.
Modify Git network configuration
We can directly modify the global Git configuration file and delete the relevant configuration of HTTP / HTTPS in the file.
$ vim ~/.gitconfig
It can also be modified using the command:
- $ git config –global –unset http.proxy
- $ git config –global –unset https.proxy
Check SSL Certificate with OpenSSL
Change HTTP/HTTPS encryption library
Since the problem is that the LibreSSL library reports an error, we can modify Git to use the OpenSSL library for HTTPS communication.
$ git config –global http.sslBackend “openssl”
Use HTTPS proxy for git connection
When using HTTPS to connect to GitHub for push/pull, we need to change the local git configuration and use a proxy to initiate a request to GitHub.
Execute the following command: $ git config –global -e
This will bring us into git’s configuration file editing interface (which will open with the default editor specified by git). Add the following to this file:
[http]
proxy = socks5://127.0.0.1:7891
[https]
proxy = socks5://127.0.0.1:7891
“7891” is the designated entry and exit port of our proxy software, please modify it according to the actual situation.
Use SSH for git connection
It is well known that HTTPS or SSH can be used to clone the GitHub repository, but SSH does not have the network connection problem of HTTPS, so the connection method of push/pull can be changed from HTTPS to SSH.
Requirements: we need to generate an SSH public/private key pair in advance and add the public key to our GitHub account. See Connecting to GitHub with SSH for details on this part .
Enter the corresponding directory of the warehouse and execute the following command: $ git remote set-url origin git@github.com:xxx/xxx.git
After the change is complete, we can use the following command to view the current origin address:
$ git remote -v
Understanding X509 Certificate with Openssl Command
… right now it happens only to the website I’m testing. I can’t post it here because it’s confidential.
Then I guess it is one of the sites which is incompatible with TLS1.2. The openssl as used in 12.04 does not use TLS1.2 on the client side while with 14.04 it uses TLS1.2 which might explain the difference. To work around try to explicitly use
. If this does not help check if you can access the site with
--secure-protocol=TLSv1openssl s_client -connect ...
(probably not) and with openssl s_client -tls1 -no_tls1_1, -no_tls1_2 ...
.
Please note that it might be other causes, but this one is the most probable and without getting access to the site everything is just speculation anyway.
The assumed problem in detail: Usually clients use the most compatible handshake to access a server. This is the SSLv23 handshake which is compatible to older SSL versions but announces the best TLS version the client supports, so that the server can pick the best version. In this case wget would announce TLS1.2. But there are some broken servers which never assumed that one day there would be something like TLS1.2 and which refuse the handshake if the client announces support for this hot new version (from 2008!) instead of just responding with the best version the server supports. To access these broken servers the client has to lie and claim that it only supports TLS1.0 as the best version.
Is Ubuntu 14.04 or wget 1.15 not compatible with TLS 1.0 websites? Do I need to install/download any library/software to enable this connection?
The problem is the server, not the client.
Most browsers work around these broken servers by retrying with a lower version. Most other applications fail permanently if the first connection attempt fails, i.e. they don’t downgrade by itself and one has to enforce another version by some application specific settings.
I installed Ubuntu 20 on my VPS. This is why I’m trying to do:
curl -v https://imenik.tportal.hr/show?action=pretraga&type=bijeleStranice
[1] 438975
root@vps:/var/www/html/tportal# * Trying 195.29.166.100:443...
* TCP_NODELAY set
* Connected to imenik.tportal.hr (195.29.166.100) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
* Closing connection 0
curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
But when I try like this, it kinda works
curl -v http://imenik.tportal.hr/show?action=pretraga&type=bijeleStranice
[1] 438977
root@vps:/var/www/html/tportal# * Trying 195.29.166.100:80...
* TCP_NODELAY set
* Connected to imenik.tportal.hr (195.29.166.100) port 80 (#0)
> GET /show?action=pretraga HTTP/1.1
> Host: imenik.tportal.hr
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Date: Tue, 16 Jun 2020 07:44:32 GMT
< Server: Apache/2.2.3 (CentOS)
< Location: https://imenik.tportal.hr/show?action=pretraga
< Content-Length: 336
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://imenik.tportal.hr/show?action=pretraga">here</a>.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at imenik.tportal.hr Port 80</address>
</body></html>
* Closing connection 0
I can’t find a solution to this SSL problem
Akshat Zala
3833 gold badges4 silver badges19 bronze badges
asked Jun 16, 2020 at 7:45
The Website uses the old TLS protocol version 1.0, which has been disabled by default since Ubuntu 20.04.
To temporarily override the default for your curl
command, you can create a config file somewhere (e.g. ~/.openssl_allow_tls1.0.cnf
with following content:
openssl_conf = openssl_init
[openssl_init]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
CipherString = DEFAULT@SECLEVEL=1
Then run your command like this:
OPENSSL_CONF=~/.openssl_allow_tls1.0.cnf curl -v https://imenik.tportal.hr/show?action=pretraga&type=bijeleStranice
(this will only set OPENSSL_CONF
for that single command)
or
export OPENSSL_CONF=~/.openssl_allow_tls1.0.cnf
curl -v https://imenik.tportal.hr/show?action=pretraga&type=bijeleStranice
(this will only set OPENSSL_CONF
for the current session or script)
You could also set it globally in /etc/ssl/openssl.cnf
, but it has been disabled for good reasons and I would only override that when necessary.
(via)
answered Jun 16, 2020 at 8:55
pLumopLumo
26k2 gold badges57 silver badges87 bronze badges
5
Edit the openssl.conf
file:
sudo nano /etc/ssl/openssl.cnf
Add this line at the top:
openssl_conf = openssl_init
And add these lines at the end:
[openssl_init]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
CipherString = DEFAULT@SECLEVEL=1
It works for me.
For the Laravel, also run
sudo service php7.4-fpm restart
answered Dec 1, 2020 at 7:33
WHYWHY
3012 silver badges5 bronze badges
1
- Useful OpenSSL Debugging Commands
- Common SSL errors
- Git-LFS and other embedded services written in golang report custom certificate signed by unknown authority
- Reconfigure Fails Due to Certificates
- Custom Certificates Missing or Skipped
- Custom certificates not detected
- Let’s Encrypt fails on reconfigure
- Using an internal CA certificate with GitLab
- X.509 key values mismatch error
- Using GitLab Runner with a GitLab instance configured with internal CA certificate or self-signed certificate
- Mirroring a remote GitLab repository that uses a self-signed SSL certificate
- Unable to perform Git operations due to an internal or self-signed certificate
- SSL_connect wrong version number
schannel: SEC_E_UNTRUSTED_ROOT
This page contains a list of common SSL-related errors and scenarios that you
may encounter while working with GitLab. It should serve as an addition to the
main SSL documentation:
- Omnibus SSL Configuration.
- Self-signed certificates or custom Certification Authorities for GitLab Runner.
- Configure HTTPS manually.
Useful OpenSSL Debugging Commands
Sometimes it’s helpful to get a better picture of the SSL certificate chain by viewing it directly
at the source. These commands are part of the standard OpenSSL library of tools for diagnostics and
debugging.
-
Perform a test connection to the host over HTTPS. Replace
HOSTNAME
with your GitLab URL
(excluding HTTPS), and replaceport
with the port that serves HTTPS connections (usually 443):echo | /opt/gitlab/embedded/bin/openssl s_client -connect HOSTNAME:port
The
echo
command sends a null request to the server, causing it to close the connection rather
than wait for additional input. You can use the same command to test remote hosts (for example, a
server hosting an external repository), by replacingHOSTNAME:port
with the remote host’s domain
and port number.This command’s output shows you the certificate chain, any public certificates the server
presents, along with validation or connection errors if they occur. This makes for a quick check
for any immediate issues with your SSL settings. -
View a certificate’s details in text form using
x509
. Be sure to replace
/path/to/certificate.crt
with the certificate’s path:/opt/gitlab/embedded/bin/openssl x509 -in /path/to/certificate.crt -text -noout
For example, GitLab automatically fetches and places certificates acquired from Let’s Encrypt at
/etc/gitlab/ssl/hostname.crt
. You can use thex509
command with that path to quickly display
the certificate’s information (for example, the hostname, issuer, validity period, and more).If there’s a problem with the certificate, an error occurs.
-
Fetch a certificate from a server and decode it. This combines both of the above commands to fetch
the server’s SSL certificate and decode it to text:echo | /opt/gitlab/embedded/bin/openssl s_client -connect HOSTNAME:port | /opt/gitlab/embedded/bin/openssl x509 -text -noout
Common SSL errors
-
SSL certificate problem: unable to get local issuer certificate
This error indicates the client cannot get the root CA. To fix this, you can either trust the root CA of the server you are trying to connect to on the client or modify the certificate to present the full chained certificate on the server you are trying to connect to.
-
unable to verify the first certificate
This error indicates that an incomplete certificate chain is being presented by the server. To fix this error, you will need to replace server’s certificate with the full chained certificate. The full certificate chain order should consist of the server certificate first, followed by all intermediate certificates, with the root CA last.
-
certificate signed by unknown authority
This error indicates that the client does not trust the certificate or CA. To fix this error, the client connecting to server will need to trust the certificate or CA.
-
SSL certificate problem: self signed certificate in certificate chain
This error indicates that the client does not trust the certificate or CA. To fix this error, the client connecting to server will need to trust the certificate or CA.
-
x509: certificate relies on legacy Common Name field, use SANs instead
This error indicates that SANs (subjectAltName) must be configured in the certificate. For more information, see this issue.
Git-LFS and other embedded services written in golang report custom certificate signed by unknown authority
The gitlab-workhorse
and other services written in golang use the crypto/tls library from golang
instead of OpenSSL.
Add the following entry in /etc/gitlab/gitlab.rb
to work around the
issue as reported:
gitlab_workhorse['env'] = {
'SSL_CERT_DIR' => '/opt/gitlab/embedded/ssl/certs/'
}
Reconfigure Fails Due to Certificates
ERROR: Not a certificate: /opt/gitlab/embedded/ssl/certs/FILE. Move it from /opt/gitlab/embedded/ssl/certs to a different location and reconfigure again.
Check /opt/gitlab/embedded/ssl/certs
and remove any files other than README.md
that aren’t valid X.509 certificates.
Custom Certificates Missing or Skipped
GitLab versions 8.9.0, 8.9.1, and 8.9.2 all mistakenly used the
/etc/gitlab/ssl/trusted-certs/
directory. This directory is safe to remove if it
is empty. If it still contains custom certificates then move them to /etc/gitlab/trusted-certs/
and run gitlab-ctl reconfigure
.
If no symlinks are created in /opt/gitlab/embedded/ssl/certs/
and you see
the message “Skipping cert.pem
” after running gitlab-ctl reconfigure
, that
means there may be one of four issues:
- The file in
/etc/gitlab/trusted-certs/
is a symlink - The file is not a valid PEM or DER-encoded certificate
- Perl is not installed on the operating system which is needed for c_rehash to properly symlink certificates
- The certificate contains the string
TRUSTED
Test the certificate’s validity using the commands below:
/opt/gitlab/embedded/bin/openssl x509 -in /etc/gitlab/trusted-certs/example.pem -text -noout
/opt/gitlab/embedded/bin/openssl x509 -inform DER -in /etc/gitlab/trusted-certs/example.der -text -noout
Invalid certificate files produce the following output:
unable to load certificate
140663131141784:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE
To test if c_rehash
is not symlinking the certificate due to a missing perl interpreter:
$ /opt/gitlab/embedded/bin/c_rehash /etc/gitlab/trusted-certs
bash: /opt/gitlab/embedded/bin/c_rehash: /usr/bin/perl: bad interpreter: No such file or directory
If you see this message, you will need to install perl with your distribution’s package manager.
If you inspect the certificate itself, then look for the string TRUSTED
:
-----BEGIN TRUSTED CERTIFICATE-----
...
-----END TRUSTED CERTIFICATE-----
If it does, like the example above, then try removing the string TRUSTED
and running gitlab-ctl reconfigure
again.
Custom certificates not detected
If after running gitlab-ctl reconfigure
:
- no symlinks are created in
/opt/gitlab/embedded/ssl/certs/
; - you have placed custom certificates in
/etc/gitlab/trusted-certs/
; and - you do not see any skipped or symlinked custom certificate messages
You may be encountering an issue where Omnibus GitLab thinks that the custom
certificates have already been added.
To resolve, delete the trusted certificates directory hash:
rm /var/opt/gitlab/trusted-certs-directory-hash
Then run gitlab-ctl reconfigure
again. The reconfigure should now detect and symlink
your custom certificates.
Let’s Encrypt Certificate signed by unknown authority
The initial implementation of Let’s Encrypt integration only used the certificate, not the full certificate chain.
Starting in 10.5.4, the full certificate chain will be used. For installs which are already using a certificate, the switchover will not happen until the renewal logic indicates the certificate is near expiration. To force it sooner, run the following
rm /etc/gitlab/ssl/HOSTNAME*
gitlab-ctl reconfigure
Where HOSTNAME is the hostname of the certificate.
Let’s Encrypt fails on reconfigure
When you reconfigure, there are common scenarios under which Let’s Encrypt may fail:
-
Let’s Encrypt may fail if your server isn’t able to reach the Let’s Encrypt verification servers or vice versa:
letsencrypt_certificate[gitlab.domain.com] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [gitlab.domain.com] Validation failed for domain gitlab.domain.com
If you run into issues reconfiguring GitLab due to Let’s Encrypt make sure you have ports 80 and 443 open and accessible.
-
Your domain’s Certification Authority Authorization (CAA) record does not allow Let’s Encrypt to issue a certificate for your domain. Look for the following error in the reconfigure output:
letsencrypt_certificate[gitlab.domain.net] (letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: RuntimeError: ruby_block[create certificate for gitlab.domain.net] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [gitlab.domain.com] Validation failed, unable to request certificate
-
If you’re using a test domain such as
gitlab.example.com
, without a certificate, you’ll see theunable to request certificate
error shown above. In that case, disable Let’s Encrypt by settingletsencrypt['enable'] = false
in/etc/gitlab/gitlab.rb
.
You can test your domain using the Let’s Debug diagnostic tool. It can help you figure out why you can’t issue a Let’s Encrypt certificate.
Using an internal CA certificate with GitLab
After configuring a GitLab instance with an internal CA certificate, you might
not be able to access it by using various CLI tools. You may experience the
following issues:
-
curl
fails:curl "https://gitlab.domain.tld" curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html
-
Testing by using the rails console
also fails:uri = URI.parse("https://gitlab.domain.tld") http = Net::HTTP.new(uri.host, uri.port) http.use_ssl = true http.verify_mode = 1 response = http.request(Net::HTTP::Get.new(uri.request_uri)) ... Traceback (most recent call last): 1: from (irb):5 OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))
- The error
SSL certificate problem: unable to get local issuer certificate
is displayed when setting up a mirror
from this GitLab instance. -
openssl
works when specifying the path to the certificate:/opt/gitlab/embedded/bin/openssl s_client -CAfile /root/my-cert.crt -connect gitlab.domain.tld:443
If you have the previously described issues, add your certificate to
/etc/gitlab/trusted-certs
, and then run sudo gitlab-ctl reconfigure
.
X.509 key values mismatch error
After configuring your instance with a certificate bundle, NGINX may display
the following error message:
SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
This error message means that the server certificate and key you have provided
don’t match. You can confirm this by running the following command and then
comparing the output:
openssl rsa -noout -modulus -in path/to/your/.key | openssl md5
openssl x509 -noout -modulus -in path/to/your/.crt | openssl md5
The following is an example of an md5 output between a matching key and
certificate. Note the matching md5 hashes:
$ openssl rsa -noout -modulus -in private.key | openssl md5
4f49b61b25225abeb7542b29ae20e98c
$ openssl x509 -noout -modulus -in public.crt | openssl md5
4f49b61b25225abeb7542b29ae20e98c
This is an opposing output with a non-matching key and certificate which shows
different md5 hashes:
$ openssl rsa -noout -modulus -in private.key | openssl md5
d418865077299af27707b1d1fa83cd99
$ openssl x509 -noout -modulus -in public.crt | openssl md5
4f49b61b25225abeb7542b29ae20e98c
If the two outputs differ like the previous example, there’s a mismatch between
the certificate and key. Contact the provider of the SSL certificate for
further support.
Using GitLab Runner with a GitLab instance configured with internal CA certificate or self-signed certificate
Besides getting the errors mentioned in
Using an internal CA certificate with GitLab,
your CI pipelines may get stuck in Pending
status. In the runner logs you may
see the following error message:
Dec 6 02:43:17 runner-host01 gitlab-runner[15131]: #033[0;33mWARNING: Checking for jobs... failed
#033[0;m #033[0;33mrunner#033[0;m=Bfkz1fyb #033[0;33mstatus#033[0;m=couldn't execute POST against
https://gitlab.domain.tld/api/v4/jobs/request: Post https://gitlab.domain.tld/api/v4/jobs/request:
x509: certificate signed by unknown authority
Follow the details in Self-signed certificates or custom Certification Authorities for GitLab Runner.
Mirroring a remote GitLab repository that uses a self-signed SSL certificate
When configuring a local GitLab instance to mirror a repository
from a remote GitLab instance that uses a self-signed certificate, you may see
the SSL certificate problem: self signed certificate
error message in the
user interface.
The cause of the issue can be confirmed by checking if:
-
curl
fails:$ curl "https://gitlab.domain.tld" curl: (60) SSL certificate problem: self signed certificate More details here: https://curl.haxx.se/docs/sslcerts.html
-
Testing by using the Rails console also fails:
uri = URI.parse("https://gitlab.domain.tld") http = Net::HTTP.new(uri.host, uri.port) http.use_ssl = true http.verify_mode = 1 response = http.request(Net::HTTP::Get.new(uri.request_uri)) ... Traceback (most recent call last): 1: from (irb):5 OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))
To fix this problem:
- Add the self-signed certificate from the remote GitLab instance to the
/etc/gitlab/trusted-certs
directory on the local GitLab instance, and then
runsudo gitlab-ctl reconfigure
as per the instructions for
installing custom public certificates. - If your local GitLab instance was installed using the Helm Charts, you can
add your self-signed certificate to your GitLab instance.
You may also get another error message when trying to mirror a repository from
a remote GitLab instance that uses a self-signed certificate:
2:Fetching remote upstream failed: fatal: unable to access &#39;https://gitlab.domain.tld/root/test-repo/&#39;:
SSL: unable to obtain common name from peer certificate
In this case, the problem can be related to the certificate itself:
- Validate that your self-signed certificate isn’t missing a common name. If it
is, regenerate a valid certificate - Add the certificate to
/etc/gitlab/trusted-certs
. - Run
sudo gitlab-ctl reconfigure
.
Unable to perform Git operations due to an internal or self-signed certificate
If your GitLab instance is using a self-signed certificate, or if the
certificate is signed by an internal certificate authority (CA), you might
experience the following errors when attempting to perform Git operations:
$ git clone https://gitlab.domain.tld/group/project.git
Cloning into 'project'...
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': SSL certificate problem: self signed certificate
$ git clone https://gitlab.domain.tld/group/project.git
Cloning into 'project'...
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
To fix this problem:
- If possible, use SSH remotes for all Git operations. This is considered more
secure and convenient to use. - If you must use HTTPS remotes, you can try the following:
-
Copy the self-signed certificate or the internal root CA certificate to a
local directory (for example,~/.ssl
) and configure Git to trust your
certificate:git config --global http.sslCAInfo ~/.ssl/gitlab.domain.tld.crt
-
Disable SSL verification in your Git client. This is intended as a
temporary measure, as it could be considered a security risk.git config --global http.sslVerify false
-
SSL_connect wrong version number
A misconfiguration may result in:
-
gitlab-rails/exceptions_json.log
entries containing:"exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)", "exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)",
-
gitlab-workhorse/current
containing:http: server gave HTTP response to HTTPS client http: server gave HTTP response to HTTPS client
-
gitlab-rails/sidekiq.log
orsidekiq/current
containing:message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError) message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)
Some of these errors come from the Excon Ruby gem, and could be generated in
circumstances where GitLab is configured to initiate an HTTPS session to a
remote server that is serving only HTTP.
One scenario is that you’re using object storage, which
isn’t served under HTTPS. GitLab is misconfigured and attempts a TLS handshake,
but the object storage responds with plain HTTP.
schannel: SEC_E_UNTRUSTED_ROOT
If you’re on Windows and get the following error:
Fatal: unable to access 'https://gitlab.domain.tld/group/project.git': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted."
You must specify that Git should use OpenSSL:
git config --system http.sslbackend openssl
Alternatively, you can ignore SSL verification by running:
git config --global http.sslVerify false