1

When executing

wget https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf

I have this error:

--2020-06-03 20:55:06--  https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf
Resolving docs.conda.io (docs.conda.io)... 104.31.71.166, 104.31.70.166, 172.67.149.185, ...
Connecting to docs.conda.io (docs.conda.io)|104.31.71.166|:443... connected.
ERROR: cannot verify docs.conda.io's certificate, issued by ‘CN=SSL-SG1-GFRPA2,OU=Operations,O=Cloud Services,C=US’:
  Unable to locally verify the issuer's authority.
To connect to docs.conda.io insecurely, use `--no-check-certificate'.

What I have tried to solve this problem:

  1. sudo update-ca-certificates -f

  2. Export the certificate from browser when opening the url, save it in a file conda.cer, then perform openssl x509 -in conda.cer -inform der -outform pem -out conda.pem, then execute:

    wget --ca-certificate=conda.pem \
    https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf
    

    => still the same error

  3. Put the file under /etc/ssl/certs, sudo cp conda.pem /etc/ssl/certs => still same error

I know I can use --no-check-certificate, but this is not what i want.

This problem occurs for some other websites too. Anyone know the reason? Thanks.

UPDATE1 I have tried the following steps: 1) sudo cp conda.crt /usr/share/ca-certificates/mozilla/

2) sudo vi /etc/ca-certificates.conf and append mozilla/conda.crt at the end

3) run sudo update-ca-certificates -f

4) i can see symbolic link created under /etc/ssl/certs which looks like: conda.pem -> /usr/share/ca-certificates/mozilla/conda.crt

However, it's still not working!

UPDATE2 - Deleted. Please refer to UPDATE3

UPDATE 3

The certificates chain in the URL above contains 4 certificates.

Just to ensure not missing any one, I put all the 4 certificates (namely conda1.crt, conda2.crt, conda3.crt, conda4.crt) in /usr/share/ca-certificates/mozilla/ and repeat the steps mentioned in UPDATE1.

Symbolic links are created successfully in /etc/ssl/certs.

Verification:

openssl verify -no-CAfile -no-CApath -partial_chain -CAfile conda1.pem conda2.pem
conda2.pem: OK

openssl verify -no-CAfile -no-CApath -partial_chain -CAfile conda2.pem conda3.pem
conda3.pem: OK


openssl verify -no-CAfile -no-CApath -partial_chain -CAfile conda3.pem conda4.pem
conda4.pem: OK

Result: still fail with wget


UPDATE4

Part of the cause is found

Bluecoat service which intercepts the network is the root cause (it has problem to VM Ubuntu only though, the host machine windows works fine with ssl).

Both of these works (conda1.crt is extracted from browser which should be from the Bluecoat service):

wget --ca-certificates=/etc/ssl/certs/ca-certificates.crt https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf

wget --ca-certificates=conda1.crt https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf

CURRENT STATUS

I have installed conda1.crt in /etc/ssl/certs following the steps described in UPDATE1. conda1.crt is believed to be the right one as shown in the wget step in UPDATE4.

However, even after this step, connection still failed.

If I disable Bluecoat service forecely, ssl problem disappeared.

However, I am required to use Bluecoat, hence any help to resolve the problem under Bluecoat is really appreciated!

6
  • Please add the following to the question: distro and version – Rui F Ribeiro Jun 3 '20 at 21:42
  • @RuiFRibeiro uname -a => 5.3.0-53-generic #47~18.04.1-Ubuntu SMP Thu May 7 13:10:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux – jack Jun 3 '20 at 21:47
  • The CA cert you show is from a BlueCoat SSL/TLS interception device often used on company/business networks but also some others. Yes this would usually apply to all SSL/TLS (and HTTPS) connections although some that are considered sensitive like banks or doctors might be allowed to bypass interception. If you are authorized to use this network and weren't informed about the interception, depending on your country this might violate the law, but if so that's offtopic for this Stack. – dave_thompson_085 Jun 5 '20 at 2:27
  • @dave_thompson_085 Thanks. I do not think there's special firewall issue in my current country, located in Europe – jack Jun 5 '20 at 8:01
  • @dave_thompson_085 I just realized how inspiring your answer has been but I didn't get the point in time. Yes, Bluecoat is the key! When I do this it works: wget --ca-certificate=conda1.crt https://... Note that this conda1.crt has been installed following the steps described in UPDATE1. What's the reason it's still failing then? – jack Jun 5 '20 at 13:21
1

meta: not really an answer but too much for comments

UPDATE1 I have tried the following steps:
[using certs exported by browser that are actually from Bluecoat, not really from conda]
1) sudo cp conda.crt /usr/share/ca-certificates/mozilla/
2) sudo vi /etc/ca-certificates.conf and append mozilla/conda.crt at the end
3) [] sudo update-ca-certificates -f
4) i can see symbolic link created under /etc/ssl/certs which looks like: conda.pem -> /usr/share/ca-certificates/mozilla/conda.crt
However, it's still not working! [without specifying wget --ca-certificates=]

That's surprising. It works for me on Ubuntu 18.04, using my test certs (because I don't have yours, of course). Note every cert is placed in /etc/ssl/certs three ways: (1) a 'friendly' filename like Digicert_something or Go_Daddy_whatever that links back to /usr/share/ca-certificates/; (2) a 'hashname' that links to the 'friendly' name like 3513523f.0 -> DigiCert_Global_Root_CA.pem; and (3) a single concatenated file ca-certificates.crt that contains the PEM blocks for all the certificates with no human-readable names. wget uses OpenSSL which uses the certificate data from (2) and/or (3) depending on the code -- which I don't have time to download and read through -- but never (1), so checking (1) doesn't prove much; check (2) and (3). If those are correct, then I would try openssl s_client which should use the same truststore and logic, but gives more detailed information about any problems it finds (cluttered by a lot of other info). If that doesn't help, I think you'd have to get the source for wget, rebuild with symbols, and debug it, which is just too much work.

That said, and although the update-ca-certificates(1) manpage only mentions it in passing, I think they intend you to put additions in /usr/local/share/ca-certificates not /usr/share/ca-certificates/mozilla because the latter is maintained by the package manager while the former is in /usr/local which is the place for site or machine local additions both traditionally and per hier(7). /usr/share/doc/ca-certificates/README.Debian is more specific:

If you want to install local certificate authorities to be implicitly
trusted, please put the certificate files as single files ending with
".crt" into /usr/local/share/ca-certificates/ and re-run
'update-ca-certificates'.  ...

some minor points

Export the certificate from browser ... and openssl x509 -inform der -outform pem ....

Chrome on Windows, and Internet Explorer, use the Windows 'cert wizard' (or one of them) which allows exporting a single cert in DER or 'base-64' -- which is actually PEM -- as well as 'p7b' which allows the whole chain. (It also has options to include the privatekey for one's own cert but that doesn't apply here.) Firefox allows the same choices, plus chain in PEM. AFAIK only Edge is limited to exporting in DER and requires that conversion step -- at least the version I currently have; Edge was supposed to pumpkin into Chromium early this year, but I don't know if mine actually did, since the W10 philosophy is to prevent you knowing, much less controlling, what happens on your computer.

[interception causes] problem to VM Ubuntu only though, the host machine windows works fine ...

Is the host owned, or managed, by the network owner? E.g. are both the machine and network for a business? If so it is common when installing an interceptor like Bluecoat to automatically install the root cert in the machines that will need to trust it -- especially Windows machines that can easily be centrally managed using a 'domain' and 'group policy'. (Note this type of Windows domain has nothing to do with the 'domain names' and 'domain name system DNS' used on the Internet -- don't mix them up.) A simple signal of this is if your login name is not a simple name like fred or email like fred@outlook.com, but in the form domain\fred.

1
  • Thanks so much for the explanation. Yes, the host machine windows is managed by the network owner and i suppose the certificate has been installed properly there. The VM is installed by myself and has the problem. I tried putting the certificate under /usr/local/share/ca-certificates instead of under /usr/share/ca-certificates/mozilla, the print out of sudo update-ca-certificates -f shows that the cert is added, but wget still failed. – jack Jun 7 '20 at 13:50
1

You made two mistakes:

  1. You mixed up server certificates with CA certificates. If I understand you correctly then you have downloaded the server certificate and tried to put in in the CA pool (same problem with --ca-certificate=). I don't think that is possible.

  2. Read the man page for update-ca-certificates. You need a file with a .crt extension, you havt to copy it to a different directory (may depend on the distro) and if the tool does not offers that interactively then you have to manually include that certificate in a config file.

verifying the certificates

Of course, the whole approach is doomed to fail if you do not have the correct CA certificate. You can use openssl for verifying whether a certain server certificate has been signed by a certain CA certificate (that does not work if an intermediate CA certificate is missing):

openssl verify -no-CAfile -no-CApath -partial_chain -CAfile ca-cert.pem server-cert.pem
11
  • Thanks! After using the CA certifcate, wget works with wget --ca-certificate=conda_ca.pem https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf – jack Jun 3 '20 at 21:52
  • However, what i want to do is copy the CA pem file to /etc/ssl/certs, and I expect wget https://docs.conda... to work without --ca-certificate=xxx. I understand it as putting the CA certificate to the truststore. Is it possible to do that? – jack Jun 3 '20 at 21:54
  • @jack Sure. As I already said: Read the man page for update-ca-certificates. – Hauke Laging Jun 3 '20 at 22:15
  • Thanks. I checked man page and tried the approach: 1) sudo cp conda.crt /usr/share/ca-certificates/mozilla/ 2) sudo vi /etc/ca-certificates.conf and append mozilla/conda.crt at the end 3) run sudo update-ca-certificates -f 4) i can see symbolic link created under /etc/ssl/certs which looks like: conda.pem -> /usr/share/ca-certificates/mozilla/conda.crt However, it's still not working! Do you have any idea? – jack Jun 4 '20 at 19:13
  • 1
    hauke: you can't usefully repeat -in on any openssl command, and you can't handle more than one cert in one opensssl x509 command. – dave_thompson_085 Jun 5 '20 at 2:28

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.