I'm building an elderly Yocto project. repo (https://gerrit.googlesource.com/git-repo) is used to pull all the sources from their respective repositories & keep on top of changes. Recently, repo has started checking CA certs for the https locations of these sources & refusing to download them as the host machine doesn't have them in its CA store (its an elderly host, to match the elderly Yocto project). Under the hood, repo is using curl to download the sources, which handily provides a -k or --insecure option to bypass SSL certificate validation.
Is there a way to instruct the repo init command to do the same? Or is my only option to keep visiting the sites, downloading the certs, adding them to the host cert store on a case by case basis? (This, whilst protecting me from MITM attacks is impractical in this case).
I've tried export PYTHONHTTPSVERIFY=0 in my script that calls repo, but that doesn't help.
The errors from bitbake look like this: 17:18:25 fatal: unable to access 'https://git.openembedded.org/meta-openembedded/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Related
I am trying to create a GitHub action that runs on a windows server self-hosted runner and I'm stuck on my checkout failing at the LFS download portion
I'm using
- uses: actions/checkout#v3
with:
lfs: true
The checkout for the normal code works fine, but when it gets to the LFS download step I get a lot of messages complaining about x509: certificate signed by unknown authority.
LFS: Get "https://github-cloud.githubusercontent.com/alambic/details_changed_to_protect_the_innocent": x509: certificate signed by unknown authority
The self-hosted runner is on a domain that is behind a firewall that interrogates https traffic and inserts its own certificate into the chain, so I'm guessing that the unknown authority is that certificate, but I don't know where that certificate needs to be trusted so that things work.
The certificate is trusted by the OS and is installed in the certificate store through a group policy, but it seems that git LFS is verifying the certificate chain separate from that and complains anyway because the certificate is unexpected.
A common solution I've seen floating around for things like this is just turn off SSL checking, but that feels like just a temporary hack and not a real solution. I would like for this to work with all security in place.
As an additional note, this is running on a server that is also running TeamCity, and the TeamCity GitHub config is able to clone repos with LFS from that same server, so these problems are just inside of the GitHub action runner environment that gets set up.
Since the firewall only inserts its certificate into https traffic, I was able to get things working using an ssh-key. I added the private key as a secret and the public key to the repo's deploy keys, and now everything is working as expected.
- uses: actions/checkout#v3
with:
lfs: true
ssh-key: ${{secrets.repo_ssh}}
I've already purchased the SSL Certifcate from DigiCert and install it into my Nexus server (running in tomcat, jks)
It works well in firefox and chrome(green address bar indicates that a valid certificate received) , builds could be downloaded from Nexus WebUI too.
But, wget could not get the result without --no-check-certificate
something like
ERROR: cannot verify mydomain.com's certificate, issued by `/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3':
Unable to locally verify the issuer's authority.
To connect to mydomain.com insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
Found something,
SSL connection fails with wget, curl, but succeed with firefox and lynx
linux wget not certified?
But neither of them gives a final solution, I want to know whether there are some (special) configurations on Nexus or this's a bug of wget command?
Google return many results about "digitcert wget",but I cannot find a clue either, Thank you!
You need to add the DigiCert root certificate to a store accessible by wget:
http://wiki.openwrt.org/doc/howto/wget-ssl-certs
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .
Is it possible to use pip with a requirements file to install from a Mercurial repository which needs to be accessed using --insecure in order to work.
The repository is accessed via SSL, and due to pip ignoring Server Name Indication (SNI), a valid SSL certificate is not being honoured (it uses the main certificate for the IP address). --insecure gets round this issue
ie:
hg clone https://username#domain.org/username/app_name --insecure
So where you can usually do something like this:
pip install -e hg+https://username#domain.org/username/app_name#egg=app_name
or have the following in a pip requirements file:
hg+https://username#domain.org/username/app_name#egg=app_name
Neither of these work due to the SSL SNI issue.
Does anyone have any good suggestions?
Why don't you try to use [hostfingerprints] in your ~/.hgrc?
For example:
[hostfingerprints]
example.com = 38:76:52:7c:87:26:9a:8f:4a:f8:d3:de:08:45:3b:ea:d6:4b:ee:cc
To obtain the self-signed certificate, follow the steps suggested in https://www.mercurial-scm.org/wiki/CACertificates
The root CA certificate for a server can for example be retrieved with
Firefox. Browse to https://example.com/repo and verify that this is the
repository you trust, click the lock symbol in the lower right corner,
View Certificate, Details, select the certificate at the top of the
Certificate Hierarchy, Export, "X.509 Certificate (PEM)" and save
somewhere for example as server.pem. With other browsers on Windows
you have to view the certificate at the top of the Certification Path
and "Copy to File" as "Base-64 encoded X.509 (.CER)". Several such
files can be concatenated into one cacerts file.
I am getting the below error while making ssl connection with self signed certificate.
"Peer certificate cannot be authenticated with known CA certificates"
It is working fine with CA signed certificate.
I am setting the below using curl_easy_setopt().
curl_easy_setopt(MyContext, CURLOPT_CAPATH, CA_CERTIFICATE_PATH)
curl_easy_setopt(MyContext, CURLOPT_SSL_VERIFYPEER,TRUE);
The curl version:
libcurl-7.19.7-26
Openssl version is:
0_9_8u
Please let me know how to solve this issue.
By default CURL will generally verify the SSL certificate to see if its valid and issued by an accepted CA. To do this, curl uses a bundled set of CA certificates.
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Here's an example:
curl --noproxy -k \* -D - https://127.0.0.1:443/some-secure-endpoint
Security issue: This answer disables a security feature. Do not use this in production!
For php it is possible to switch off curl's verification of the certificate (see warning below) e.g. for curl_exec
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
http://php.net/manual/en/function.curl-setopt.php
(evaluate the security risk yourself, in my case it was on a partner company's server and the file required contained no secure information - just happened to be on a secure server)
We fixed a similar issue on CentOS 6 by updating curl to the latest version available in the standard repositories and installing the newest ca-certificates bundle:
yum update curl
yum install ca-certificates
libcurl performs peer SSL certificate verification by default. This is done
by using CA cert bundle that the SSL library can use to make sure the peer's
server certificate is valid.
If you communicate with HTTPS or FTPS servers using certificates that are
signed by CAs present in the bundle, you can be sure that the remote server
really is the one it claims to be.
Until 7.18.0, curl bundled a severely outdated ca bundle file that was
installed by default. These days, the curl archives include no ca certs at
all. You need to get them elsewhere. See below for example.
For more to know about Peer SSL Certificate Verification visit http://curl.haxx.se/docs/sslcerts.html
Though this error happened in the case of using git clone rather than with using curl, I've recently stumbled across an identical error message:
Peer certificate cannot be authenticated with known CA certificates
Similar to Arth's findings, something that worked for CentOS 6 (in order to successfully use HTTPS URLs with git clone for related GitLab repositories) involved updating the trusted certificates on the server (i.e., the server that is using HTTPS), using the following steps:
sudo yum install ca-certificates
sudo update-ca-trust enable
sudo cp /path/to/your_new_cert.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
Perhaps the same certificate steps can be applied for the case of curl (or other similar scenarios) for users on CentOS in the future.
Security issue: This answer disables a security feature. Do not use this in production!
In 'C'
curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYPEER, 0);
worked for me
As we checked and observed/ Found in Centos 8 .
Due to Proxy issue your packages not allowing you to get accessible to update or download any packages.
try to add sslverify=0 in file /etc/dnf/dnf.conf
Its worked for me.
Also make sure you must have proper internet acess on your server.