18

I installed MSYS2-64bits on my Windows Server 2016 to support some Linux librairies, such as OpenSSL, which I need in my Ruby on Rails development. MSYS2 has been partially installed with Ruby 2.7, but did not complete due to certificates error messages.

I first downloaded and install msys2-x86_64-20210725.exe. It took a very long time and finished after a few messages about Updating the trust database:

==> Generating pacman master key. This may take some time.

==> Updating trust database...

==> Appending keys from msys2.gpg...

==> Locally signing trusted keys in keyring...

  -> Locally signed 6 keys.
==> Importing owner trust values...

==> Disabling revoked keys in keyring...

  -> Disabled 1 keys.
==> Updating trust database...

It stayed about 10 minutes at this stage, but finally declared a successful installation.

Then I tried to update the existing software by running pacman -Syuu. I restarted MSYS2 as requested, typed the statement, and got lots of errors such as the following, repeatedly:

$ pacman -Syuu
:: Synchronizing package databases...
 mingw32.db failed to download
 mingw64.db failed to download
 ucrt64.db failed to download
 clang64.db failed to download
 msys.db failed to download
error: failed retrieving file 'mingw32.db' from mirror.msys2.org : SSL certificate problem: self signed certificate in certificate chain
error: failed retrieving file 'mingw64.db' from mirror.msys2.org : SSL certificate problem: self signed certificate in certificate chain
error: failed retrieving file 'ucrt64.db' from mirror.msys2.org : SSL certificate problem: self signed certificate in certificate chain
warning: too many errors from mirror.msys2.org, skipping for the remainder of this transaction

I am afraid that the corporate proxy could refuse self-signed certificates. Is there a way to obtain correctly signed certificates and finalise the installation of all the packages?

Thanks for your help!

user1185081
  • 1,898
  • 2
  • 21
  • 46

3 Answers3

33

Great question, but it's not exactly the corporate proxy refusing self-signed certificates; it's pacman's SSL agent.

In your browser, go to repo.msys2.org to find which certificates are being used: Show connection details

Open details:

Certificate details

You'll need to export all certificates individually, but don't need the lowest one for repo.msys2.org:

View certificate

Save to a local file:

Copy to File...

Export using Base-64 encoding:

Base-64 encoding

Can save directly to the trust source anchors folder. Things move around from time to time, but as of now, that's C:\msys64\etc\pki\ca-trust\source\anchors\<anyfilename>.cer

Go through the same steps to import the top-level root certificate. Save in the same path, different file name.

$ update-ca-trust
## Done.
$ pacman -Syu
AaronDanielson
  • 2,230
  • 28
  • 29
  • 1
    my Certificate is `.crt` and need to rename to `ca-bundle.crt` then put in `C:\msys64\usr\ssl\certs`. relative https://github.com/msys2/MSYS2-packages/issues/2529 – user2959760 May 20 '23 at 18:11
3

My screen did not look exactly as the screenshots above and I did not have a choice of saving the Certificate with the .cer extension; I could only do it with a .der extension. It worked the same way, though. Here's how my screen looked like when I clicked on the padlock icon:

General tab Details tab

Eric Aya
  • 69,473
  • 35
  • 181
  • 253
1

If your computer is managed by an organization, they may MITM all of your TLS connections and install their own custom CA certificate on your machine, causing MITM connections to be reported as secure. Because OpenSSL in MSYS2 presently does not interface with the Windows system CA store and so is unaware of your organization's unique certificates, you must manually add and trust them.

https://www.msys2.org/docs/faq/

Here, it is mentioned how to add your organization's CA certificate to the trusted certificates of MSYS2 and register them.

Satyam Raj
  • 11
  • 3
  • the "/etc/..." location is inside the default location of your MSYS2 installation – Satyam Raj Aug 02 '23 at 21:50
  • Yes, you are right. This also happened in another context where I had to specify the following trusted-hosts to avoid certificates check: pip3 install --trusted-host pypi.org --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host raw.githubusercontent.com "apache-airflow==${AIRFLOW_VERSION}" – user1185081 Aug 11 '23 at 20:22