Ошибка ssl certificate problem self signed certificate - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

I try to send curl request with my correct APP_ID, APP_SECRET etc. to the

  https://oauth.vk.com/access_token?client_id=APP_ID&client_secret=APP_SECRET&code=7a6fa4dff77a228eeda56603b8f53806c883f011c40b72630bb50df056f6479e52a&redirect_uri=REDIRECT_URI

I need to get access_token from it, but get a FALSE and curl_error() print next message otherwise:

60: SSL certificate problem: self signed certificate in certificate chain

My code is:

    // create curl resource
    $ch = curl_init();

    // set url
    curl_setopt($ch, CURLOPT_URL, $url);
    //return the transfer as a string
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

    // $output contains the output string
    $output = curl_exec($ch);
    if ( ! $output) {
        print curl_errno($ch) .': '. curl_error($ch);
    }

    // close curl resource to free up system resources
    curl_close($ch);

    return $output;

When I move manually to the link above, I get access_token well. Why it doesn’t work with curl? Help, please.

James MV

8,51717 gold badges65 silver badges95 bronze badges

asked Jan 17, 2014 at 14:15

Victor BocharskyVictor Bocharsky

11.8k13 gold badges57 silver badges88 bronze badges

Answers suggesting to disable CURLOPT_SSL_VERIFYPEER should not be accepted. The question is «Why doesn’t it work with cURL», and as correctly pointed out by Martijn Hols, it is dangerous.

The error is probably caused by not having an up-to-date bundle of CA root certificates. This is typically a text file with a bunch of cryptographic signatures that curl uses to verify a host’s SSL certificate.

You need to make sure that your installation of PHP has one of these files, and that it’s up to date (otherwise download one here: http://curl.haxx.se/docs/caextract.html).

Then set in php.ini:

curl.cainfo = <absolute_path_to> cacert.pem

If you are setting it at runtime, use (where $ch = curl_init();):

curl_setopt ($ch, CURLOPT_CAINFO, dirname(__FILE__)."/cacert.pem");

answered May 10, 2014 at 19:40

This workaround is dangerous and not recommended:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

It’s not a good idea to disable SSL peer verification. Doing so might expose your requests to MITM attackers.

In fact, you just need an up-to-date CA root certificate bundle. Installing an updated one is as easy as:

Downloading up-to-date cacert.pem file from cURL website and
Setting a path to it in your php.ini file, e.g. on Windows:

curl.cainfo=c:phpcacert.pem

That’s it!

Stay safe and secure.

answered Sep 27, 2015 at 20:39

zxcmehranzxcmehran

1,43514 silver badges24 bronze badges

If the SSL certificates are not properly installed in your system, you may get this error:

cURL error 60: SSL certificate problem: unable to get local issuer
certificate.

You can solve this issue as follows:

Download a file with the updated list of certificates from https://curl.haxx.se/ca/cacert.pem

Move the downloaded cacert.pem file to some safe location in your system

Update your php.ini file and configure the path to that file:

VPK

3,0101 gold badge28 silver badges35 bronze badges

answered Sep 29, 2017 at 6:59

sunilsunil

491 bronze badge

Important: This issue drove me crazy for a couple days and I couldn’t figure out what was going on with my curl & openssl installations. I finally figured out that it was my intermediate certificate (in my case, GoDaddy) which was out of date. I went back to my godaddy SSL admin panel, downloaded the new intermediate certificate, and the issue disappeared.

I’m sure this is the issue for some of you.

Apparently, GoDaddy had changed their intermediate certificate at some point, due to scurity issues, as they now display this warning:

«Please be sure to use the new SHA-2 intermediate certificates included in your downloaded bundle.»

Hope this helps some of you, because I was going nuts and this cleaned up the issue on ALL my servers.

peterh

11.7k18 gold badges83 silver badges104 bronze badges

answered Nov 13, 2014 at 7:25

To add a more specific answer, I ran into this when using Guzzle v7, the PHP HTTP request package. Guzzle allows you to bypass this like so:

use GuzzleHttpClient;

$this->client = new Client([
    'verify' => false,
]);

Original source comment: https://github.com/guzzle/guzzle/issues/1490#issuecomment-375667460

answered Feb 4, 2022 at 20:11

Aaron KraussAaron Krauss

7,4261 gold badge16 silver badges19 bronze badges

Error: SSL certificate problem: self signed certificate in certificate
chain

Solution:
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);    
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_FAILONERROR, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);

answered May 19, 2020 at 4:35

SundarSundar

2532 silver badges6 bronze badges

Источник

If you’re using a self-signed certificate on your Bitbucket server, you may receive SSL certificate errors when you try to perform certain actions. This page will help you resolve these errors.

Problem

When trying to perform a clone using instructions stated in Debug logging for Git operations on the client the following error is reported:

$ export GIT_CURL_VERBOSE=1

$ git clone https://username@git.example.com/scm/repository.git
Cloning into 'repository'...
* Couldn't find host git.example.com in the _netrc file; using defaults

* Adding handle: conn: 0x22a7568
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x22a7568) send_pipe: 1, recv_pipe: 0
* About to connect() to git.example.com port 443 (#0)
*   Trying 10.253.136.142...
* Connected to git.example.com (10.253.136.142) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: C:Program Files (x86)Git/bin/curl-ca-bundle.crt
  CApath: c:/Users/username/Downloads
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
fatal: unable to access 'https://username@git.example.com/scm/repository.git': SSL certificate problem: self signed certificate in certificate chain

Cause

This is caused by git not trusting the certificate provided by your server.

Workaround

One possible workaround is to temporary disable SSL check for your git command in case you only need to perform a one time clone:

GIT_SSL_NO_VERIFY=true git clone https://username@git.example.com/scm/repository.git

or

git remote add origin <gitrepo>
git config --global http.sslVerify false

The workaround is intended to be used for one-time only operations and not to be used frequently. Removing the SSL verification disproves the whole concept of having SSL implemented.

Resolution

Step1: Get a self-signed certificate of the remote server

There is multiple ways of exporting the certificate, Either from the Browser or using the OpenSSL command

Get Certificate using OpenSSL

$ echo | openssl s_client -servername NAME -connect HOST:PORT |
  sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > certificate.pem

Get Certificate using the Web browser

Export Certificate in MAC

Trust Certificate in your browser

To trust a self-signed certificate, you need to add it to your Keychain.

The easiest way to do that is to open the site in question in Safari, upon which you should get this dialog box:

Click ‘Show Certificate’ to reveal the full details:

Export Certificate in .pem format

Git doesn’t use the Mac OS X keychain to resolve this, so you need to trust the certificate explicitly.

If you haven’t done so already, follow the steps in ‘Trust certificate in your browser, above
Open Applications > Keychain Access and select ‘Certificates’ in the lower-left pane
Type the website into the Search field in the top-right
Select the certificate entry for the website, then in the menu click File > Export Items
In the Save dialog, change ‘File Format’ to ‘Privacy Enhanced Mail (.pem)’ and save the file somewhere on your drive

Export Certificate From Firefox

Access the URL of the remote server
Click the Open padlock in the address bar.

Click the arrow beside OpenConnection Secure.

Click More Information. The OpenPage Info dialog box opens.

Click View Certificate.
The Certificate page opens.
Scroll down to the Miscellaneous section.
In the Download row, click the PEM (cert) link.
In the dialog box that opens, click OK to save the certificate file to a known location.
Navigate to the location for saving the file, and then click Save.

Step 2: Configure Git to trust the Certificate

For MAC/Linux:

Once the certificate is saved on the client you can instruct your git client to use it to trust the remote repository by updating the local git config:

# Initial clone
GIT_SSL_CAINFO=/path/to/certificate.pem
git clone https://username@git.example.com/scm/repository.git

# Ensure all future interactions with origin remote also work
cd repository
git config http.sslCAInfo /path/to/certificate.pem

For Windows Client:

Step 1: Import the certificate into the window trust store

Import a signed certificate into the local machine certificate store

Enter Start | Run | MMC.
Click File | Add/Remove Snap-in.

In the Add or Remove Snap-ins window, select Certificates and click Add.

Select the Computer account radio button when prompted and click Next

Select Local computer (selected by default) and click Finish.

Back in the Add or Remove Snap-ins window, click OK.

In the MMC main console, click on the plus (+) symbol to expand the Certificate snap-in.
To import the CA certificate, navigate to Trusted Root Certification Authorities | Certificates pane.

Right-click within the Certificates panel and click All Tasks | Import to start the Certificate Import wizard.

On successfully importing the CA certificate the wizard will bring you back to the MMC main console.

Close the MMC console.

Step 2: Configure git to use the certificate in the windows Trust store

When using Windows, the problem resides that git by default uses the «Linux» crypto backend. 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. Once you have updated the git config, Git will use the Certificate in the Windows certificate store and should not require http.sslCAInfo setting.

Источник

openssl s_client  -connect www.github.com:443
CONNECTED(000001E4)
depth=1 O = AO Kaspersky Lab, CN = Kaspersky Anti-Virus Personal Root Certificate
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=5157550/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
   i:/O=AO Kaspersky Lab/CN=Kaspersky Anti-Virus Personal Root Certificate
 1 s:/O=AO Kaspersky Lab/CN=Kaspersky Anti-Virus Personal Root Certificate
   i:/O=AO Kaspersky Lab/CN=Kaspersky Anti-Virus Personal Root Certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
….
-----END CERTIFICATE-----
subject=/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=5157550/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
issuer=/O=AO Kaspersky Lab/CN=Kaspersky Anti-Virus Personal Root Certificate
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2418 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: A1BCEE841D4DBF172402BAF63BC9A80D560ED0FBC8F66B89E692206D3613FD7E
    Session-ID-ctx:
    Master-Key: ************************************************************************
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1527649383
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
closed`

Источник

Useful OpenSSL Debugging Commands
Common SSL errors
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 replace port 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 replacing HOSTNAME: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 the x509 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.

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 the unable to request certificate error shown above. In that case, disable Let’s Encrypt by setting letsencrypt['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
run sudo 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 &amp;#39;https://gitlab.domain.tld/root/test-repo/&amp;#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 or sidekiq/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

Источник

If you get the following error:

fatal: unable to access <git>: SSL certificate problem: self signed certificate in certificate chain

..when trying to clone a git repo, then you can quickly get around it by doing one of the following.

Note that both of these solutions are merely workarounds and should be done at absolute worst case.

Workaround Solution 1

Disable SSL verification while running the git clone.

git -c http.sslVerify=false clone <repository-name>

Workaround Solution 2

Disable SSL verification globally while running the git clone.

git config --global http.sslVerify false

Solution 3 (recommended)

This solution is recommended, but takes a lot more work.

Download the actual certificate/certificate chain from the Git server and install it locally by pointing your --system configuration for http.sslCAPath to it.

git config --system http.sslCAPath /path/to/cacerts

How do you fix self-signed certificate in certificate chain?

If the certificate is self-signed, that means that you have the local cert file itself. You can then:

git config --system http.sslCAPath /your/self-signed/cacerts

How do I remove SSL certificate problem self-signed certificate in certificate chain?

You can follow the above solutions, or workarounds. Remember that it’s best to assign a valid cacerts files. If one doesn’t exist, you can always ignore ssl by passing the -c http.sslVerify=false flag.

What does self-signed certificate in certificate chain mean?

Self-signed certificates are where you have created a certificate yourself to be able to take advantage of TLS/SSL encryption in flight. As you created it yourself, this means that it was not signed by a trusted certificate authority, so other users of the service that uses this self-signed certificate will get a warning saying that the connection is not trusted.

How can I make git accept a self-signed certificate?

You will need to follow one of the steps above, dependent on the one that most meets your needs.

Источник