6

I have apache nginx server running with https:// correctly configured with letsencrypt certificate. I can connect with firefox, chrome, ie. All of them reports connection as secure. However centos7 and ubuntu 14.04 reports certificate error:

wget https://gitlab.timeless.cz:8443

Resolving gitlab.timeless.cz (gitlab.timeless.cz)... 82.100.8.23
Connecting to gitlab.timeless.cz (gitlab.timeless.cz)|82.100.8.23|:8443... connected.
ERROR: cannot verify gitlab.timeless.cz's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3’:
  Unable to locally verify the issuer's authority.

According https://www.ssllabs.com/ the page is correct.

Output of 

openssl s_client -connect gitlab.timeless.cz:8443

is 

CONNECTED(00000003)
depth=0 CN = gitlab.timeless.cz
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = gitlab.timeless.cz
verify error:num=27:certificate not trusted
verify return:1
depth=0 CN = gitlab.timeless.cz
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=gitlab.timeless.cz
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---

but should be like this, which this is working for wget and curl)

CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=bk1.timeless.cz
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

I have also some apache servers, which will work fine with lets-encrypt certificates. I mean for wget...

I don't know why this is working in browsers, but not in cli.

Edit:

I'm using gitlab installed from omnibus package on Ubuntu running bundled nginx on http port 8080 and https 8443. It had self signed certificates installed by default.

Then I installed apache (standard ports 80,443) and configured it using letsencrypt-auto utility. The https works fine, trusted by all.

First I tried to configure apache to terminate https and froward traffic to unencrypted nginx (port 8080). It basically worked, but I had problem to log in and git clone. Which makes it unusable.

Second I tried to link lets encrypt certificates generated for apache to nginx, but theres only .crt and .key files in /etc/gitlab/ssl. So I don't know how to include chain certificate. Strange is that browsers are happy without it but wget, git and curl fails.

Today I found

https://gitlab.com/gitlab-org/gitlab-recipes/blob/master/web-server/apache/gitlab-omnibus-apache24.conf

and managed to fix my first solution. This proffered for me because I get certificates updated automatically and can use standard port for gitlab and finally I can use one ip for multiple services.

Solving the second solution is to include chain into nginx, but it's giltab bundled, so normal config doesn't apply.

Improve this question
2
  • What is the wget version? If you are using SNI, it may not be supported by your current version. There may be additional issues, but I have run into the SNI issue with wget.
    – Paul
    Jul 21, 2016 at 16:35
  • GNU Wget 1.14 built on linux-gnu, it's fresh centos7, problem appears in git and curl too
    – Pavel Niedoba
    Jul 21, 2016 at 16:41

3 Answers 3

Reset to default
8

In REDHAT 7/ CentOS 7/ Oracle Linux 7:

Install the certificate in your enviroment.

  1. Download Active PEM certificate from: https://letsencrypt.org/certificates/ in /etc/pki/ca-trust/source/anchors
  2. Execute: sudo update-ca-trust

That's all!

Improve this answer
4
  • worked perfectly for me, thanks. without this, python clients, e.g. the one for reviewboard, reported bad certificate.
    – Paul M
    Jun 17, 2019 at 13:46
  • Note that you have to download PEMs from both the Root Certificates and the Intermediate Certificates (scroll down on the page a bit)
    – Oz Solomon
    Oct 29, 2020 at 15:31
  • @OzSolomon you got it there! Just installing Root Active pem did not work for me, then I saw your comment and both pems worked perfect for me. Thank you.
    – Laurence Cope
    Dec 31, 2020 at 16:50
  • 1
    This didn't work on a Red Hat 7.9 system. I downloaded and copied isrg-root-x1-cross-signed.pem, isrgrootx1.pem, lets-encrypt-r3.pem, and lets-encrypt-r3-cross-signed.pem into /etc/pki/ca-trust/source/anchors. Then I did the update-ca-trust command. My wget sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz still fails.
    – Mike S
    Nov 23, 2021 at 14:49
6

I recently had an issue where a C7 system would not upgrade some packages because the remote cert was not trusted. I could verify this using wget. After some searching and head-scratching I decided to reinstall the ca-certificates package 

yum reinstall ca-certificates

This solved my problem. Try reinstalling the ca-certificates package on the system you are running wget on.

Improve this answer
1
  • That's what I did first, but it doesn't solve nginx problem
    – Pavel Niedoba
    Jul 22, 2016 at 13:37
3

Like your own output of openssl the web server (is it apache or nginx? a bit unclear in your question) misses the intermediate chain certificate. You need the SSLCertificateChainFile config in apache

The output of ssllabs is correct because you are testing port 443, which does work using wget or curl. You are not allowed to test other ports than 443 in the sslabs tool.

Improve this answer
2
  • You are right about ssllabs. I was testing the "right" site. I'll edit my question. I have work around solution for my problem.
    – Pavel Niedoba
    Jul 22, 2016 at 13:43
  • (At least some) browsers worked because they have ways to fetch the intermediate cert on their own without needing the server to provide it, but programs like openssl s_client, wget, curl, etc don't do that.
    – dave_thompson_085
    Jan 5, 2018 at 3:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.