计算机安全是当前社会的一个重要议题，证书是一种重要的安全机制，负责证明数据、软件或者人的身份和信誉。certmgr（即“证书管理器”）是Windows中专门用于证书管理的工具。本文将从多个方面对certmgr进行深入浅出的阐述，向大家介绍证书管理的基本知识和certmgr的工作原理。
证书是计算机安全中的一个基本概念，常用于验证身份和加密通信。在加密通信中，证书可以确保你和对方交换的信息只有你们两个人能够读取，防止信息在传输过程中被窃听、篡改或者伪造。在证书的认证过程中，公钥和私钥被用来保护数据和证书，确保数据和证书在传输过程中不被恶意篡改。证书通常会包含了相关信息的摘要和证书签名，用来证明数据的完整性和不可否认性。
证书种类非常多，包括数字证书、加密证书、SSL证书等等。除了Web浏览器和邮件客户端等常见的应用，证书在电子政务、电子商务、在线银行等许多领域中都有着广泛的应用。
certmgr是证书管理器，一般在Windows操作系统中自带。它可以让用户安装、浏览、导入和导出证书，同时也可以撤销、删除和管理证书链等操作。除了在命令行中使用certmgr.msc来打开证书管理器之外，用户还可以在控制面板或直接在运行框中输入certmgr打开证书管理器。
证书的安装与浏览是certmgr最常用的功能之一。通过证书管理器，用户可以将证书文件（.pfx或者.crt）添加到计算机中。证书管理器会将证书保存在对应的存储位置中，如个人、根证书授权或者受信任人等。
证书安装到根证书授权列表中，意味着该证书被信任，可以被用于认证其他证书或者加密通信。通过双击证书，用户可以查看证书的详细信息，如证书序列号、颁发机构、有效期、公钥等等。此外，证书管理器还支持导入或导出证书。
证书的导出是certmgr管理证书的另一个重要功能，可以将证书导出为文件，保存在磁盘或者移动存储设备上进行备份。导出的证书可以在其他计算机上使用，也可以作为备份进行恢复。
证书的删除与管理也是certmgr重要的功能之一。通过证书管理器，用户可以删除需要撤销或者过期的证书，还可以管理证书链的情况。比如，用户可以检查证书是否过期或者是否被撤销，以保证证书的有效性。
本文对Windows下的证书管理器certmgr进行了简要介绍，主要涉及证书的作用、certmgr的基本介绍、证书的安装与浏览、证书的导出与备份以及证书的删除与管理。certmgr是证书管理的重要工具之一，可以帮助用户完成各种证书管理任务。希望本文能对证书管理、证书安全和证书网络应用有所启迪。
certreq.exe -new -f -config "http://192.168.101.39/certsrv" -UserName "111" -p "123456" D:\Certificate\ClientCert.inf.txt D:\Certificate\ClientCert.req
certreq.exe -submit D:\Certificate\ClientCert.req D:\Certificate\ClientCert.cer
该工具是SDK Tool的一部分，您可以下载最新的Windows SDK发行版获得此工具；若您安装了visual studio，该工具也包含在安装目录中。C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
D:\certificate>certmgr.exe -add clientcert.cer -c -s -r localMachine TrustedPublisher
Error: Failed to save to the destination store
CertMgr Failed （需要管理员权限）
/r registry location 标识系统存储区的注册表位置。仅当指定 /s 选项时才考虑此选项。Registry location 必须是下列值之一：
currentUser 指示证书存储区在 HKEY_CURRENT_USER 键下。此为默认值。
localMachine 指示证书存储区在 HKEY_LOCAL_MACHINE 键下。
certmgr.exe -del -c -n "Tencent Technology(Shenzhen) Company Limited" -s -r localMachine addressbook
CertMgr -del -c -n abc -s my 删除电脑里my区域（可以改成root--受信任的根证书...）内"abc"开头的证书。
certmgr /v /s my 查询my内所有证书。
Certutil.exe is a command-line program, installed as part of Certificate Services. You can use certutil.exe to dump and display certification authority (CA) configuration information, configure Certificate Services, backup and restore CA components, and verify certificates, key pairs, and certificate chains.
Certutil.exe是一个命令行程序，作为证书服务的一部分安装。你可以用certutil.exe转储和显示证书颁发机构（CA）配置信息，配置证书服务，备份和还原CA组件，以及验证证书、密钥对和证书链。
certutil -f -p 123456789 -importpfx Root C:\Users\clientcert.pfx
In many companies, proxy including MITM (man-in-the-middle) SSL forward proxy are added to enhance network security. This can cause problems when you use Docker Desktop with WSL 2 base engine. For example, when you need to connect to internet to download packages for your applications, the https may not work due to error - SSL certificate problem: unable to get local issuer certificate.
This article provides some learnings I had in the past few days and the resolutions to fix these problems.
Environment
- Host OS: Windows 10
- WSL 2 distro: Ubuntu 20.04
- Docker version: 4.2.0. WSL 2 is used as base engine.
- Proxy is enforced in the network (i.e. SSL forward proxy occurs).
These issues can apply to Docker in Ubuntu or other WSL Linux distros, Linux distros, or Docker in Hyper-V virtual machines, etc.
Prerequisites
The high-level approach to fix this problem is to add the proxy certificate for example, Zscaler's root certificate to your docker images as part of docker build. If you don't know the specific certificate, check with your IT network security team.
If you know it, you can export the certificate directly by following these steps:
warning The following step is for demo purpose only and the actual certificate name and path in your company can be different.
Double-confirm the issue
Before we dive into the solutions, let's double confirm you have this issue.
Scenario 1 - openssl connection
Logon to your Ubuntu WSL 2 distro and use openssl to verify.
openssl s_client -connect https://the-domain-you-are-connecting-to.com -showcerts
If your company's proxy cert is not trusted in the distro, the following error can show:
Verify return code: 20 (unable to get local issuer certificate)
Scenario 2 - node:gallium-alpine
Create a Dockerfile file in a project folder. Add the following content:
FROM node:gallium-alpine
WORKDIR /app
RUN apk update && apk add bash netcat-openbsd
RUN ["echo", "Hello, Kontext!"]
Run docker command under the project folder context:
docker build .
The following error will show up:
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
140124873489224:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.13/main: Permission denied
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.13/main: No such file or directory
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/APKINDEX.tar.gz
140124873489224:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.13/community: Permission denied
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.13/community: No such file or directory
Scenario 3 - amazon/aws-cli:2.1.35
Create another project folder with docker file Dockerfile:
FROM amazon/aws-cli:2.1.35
WORKDIR /app
RUN yes y | yum install jq
RUN ["echo", "Hello, Kontext!"]
Run docker command under the project folder context:
docker build .
The following error will show up:
failure: repodata/repomd.xml from amzn2-core: [Errno 256] Mo more mirrors to try.
https://cdn.amazonlinux.com/2/core/2.0/x86_64/****** [Errno 14] curl#60 - "SSL certificate problem: unable to get local issuer certificate"
So all the three scenarios complain about local issuer certificate issue. Thus the resolution is simple - adding the proxy certificate myproxy.crt to the trusted store in the distro or container.
Solutions to fix SSL local issuer certificate issue
Now let's add the solutions for each of the three scenarios listed above.
Scenario 1 - openssl connection
To fix this issue, we just need to trust the certificate using the following command:
$ sudo apt-get install -y ca-certificates
$ sudo cp myproxy.crt /usr/local/share/ca-certificates
$ sudo update-ca-certificates
Then run the OpenSSL connection command again, it should work like a charm.
Scenario 2 - node:gallium-alpine
AS the image name suggests, it is based on Alpine Linux. To update the certificates in Alpine, we need to connect to internet thus we cannot add it directly (Correct me if I am wrong as I am not a Linux expert). One workaround is to replace Alpine repositories file () to change https to http./etc/apk/repositories
This can be done by adding a line into docker file:
FROM node:gallium-alpine
WORKDIR /app
RUN sed -i 's/https/http/' /etc/apk/repositories
RUN apk update && apk add bash netcat-openbsd
RUN ["echo", "Hello, Kontext!"]
Now it should also work.
warning By changing from https to http, it can add security concerns. Thus please use it cautiously. Another approach is to change your base image to use other Linux/UNIX distros.
Scenario 3 - amazon/aws-cli:2.1.35
Similar as scenario 2, we just need to either avoid SSL or trust the proxy cert myproxy.crt.
Add myproxy.crt to your project folder and copy it to Docker image and then trust it there:
Run docker command under the project folder context:
docker build .
The following error will show up:
failure: repodata/repomd.xml from amzn2-core: [Errno 256] Mo more mirrors to try.
https://cdn.amazonlinux.com/2/core/2.0/x86_64/****** [Errno 14] curl#60 - "SSL certificate problem: unable to get local issuer certificate"
So all the three scenarios complain about local issuer certificate issue. Thus the resolution is simple - adding the proxy certificate myproxy.crt to the trusted store in the distro or container.
Solutions to fix SSL local issuer certificate issue
Now let's add the solutions for each of the three scenarios listed above.
Scenario 1 - openssl connection
To fix this issue, we just need to trust the certificate using the following command:
$ sudo apt-get install -y ca-certificates
$ sudo cp myproxy.crt /usr/local/share/ca-certificates
$ sudo update-ca-certificates
Then run the OpenSSL connection command again, it should work like a charm.
Scenario 2 - node:gallium-alpine
AS the image name suggests, it is based on Alpine Linux. To update the certificates in Alpine, we need to connect to internet thus we cannot add it directly (Correct me if I am wrong as I am not a Linux expert). One workaround is to replace Alpine repositories file () to change https to http./etc/apk/repositories
This can be done by adding a line into docker file:
FROM node:gallium-alpine
WORKDIR /app
RUN sed -i 's/https/http/' /etc/apk/repositories
RUN apk update && apk add bash netcat-openbsd
RUN ["echo", "Hello, Kontext!"]
Now it should also work.
warning By changing from https to http, it can add security concerns. Thus please use it cautiously. Another approach is to change your base image to use other Linux/UNIX distros.
Scenario 3 - amazon/aws-cli:2.1.35
Similar as scenario 2, we just need to either avoid SSL or trust the proxy cert myproxy.crt.
Add myproxy.crt to your project folder and copy it to Docker image and then trust it there:
FROM amazon/aws-cli:2.1.35
WORKDIR /app
COPY myproxy.crt /etc/pki/ca-trust/source/anchors/
RUN update-ca-trust extract
RUN yes y | yum install jq
RUN ["echo", "Hello, Kontext!"]
This now also works. The highlighted part can be different from one Linux distro to another, please change them accordingly to apply to your own environments. The AWS CLI docker image is based on Amazon Linux 2, thus I am using the above two command lines.
I hope this article helps you to get your container application build or other build work under company proxy environment. Let me if you find other issues and I will try my best to help.
References
Installing a root CA certificate in the trust store | Ubuntu
Installing a root CA certificate in the trust store
Installing a root CA certificate in the trust store | Ubuntu
Installing a root CA certificate in the trust store
Enterprise environments sometimes have a local Certificate Authority (CA) that issues certificates for use within the organization. For an Ubuntu server to be functional and trust the hosts in this environment this CA must be installed in Ubuntu’s trust store.
How to recognize the form (PEM or DER)?
To install a certificate in the trust store it must be in PEM form. A PEM-formatted certificate is human-readable in base64 format, and starts with the lines ----BEGIN CERTIFICATE----. If you see these lines, you’re ready to install. If not, it is most likely a DER certificate and needs to be converted.
Installing a certificate in PEM form
Assuming a PEM-formatted root CA certificate is in local-ca.crt, follow the steps below to install it.
Note: It is important to have the .crt extension on the file, otherwise it will not be processed.
$ sudo apt-get install -y ca-certificates
$ sudo cp local-ca.crt /usr/local/share/ca-certificates
$ sudo update-ca-certificates
After this point you can use Ubuntu’s tools like curl and wget to connect to local sites.
Converting from DER-form to PEM-form
Convert a DER-formatted certificate called local-ca.der to PEM form like this:
$ sudo openssl x509 -inform der -outform pem -in local-ca.der -out local-ca.crt
The CA trust store location
The CA trust store as generated by update-ca-certificates is available at the following locations:
- As a single file (PEM bundle) in
/etc/ssl/certs/ca-certificates.crt
- As an OpenSSL compatible certificate directory in
/etc/ssl/certs
Security - Certificates
Security - Certificates | Ubuntu
One of the most common forms of cryptography today is public-key cryptography. Public-key cryptography utilizes a public key and a private key. The system works by encrypting information using the public key. The information can then only be decrypted using the private key.
A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. One example: configuring Apache to provide HTTPS, the HTTP protocol over SSL/TLS. This allows a way to encrypt traffic using a protocol that does not itself provide encryption.
A certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. Certificates can be digitally signed by a Certification Authority, or CA. A CA is a trusted third party that has confirmed that the information contained in the certificate is accurate.
Types of Certificates
To set up a secure server using public-key cryptography, in most cases, you send your certificate request (including your public key), proof of your company’s identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server. Alternatively, you can create your own self-signed certificate.
Note
Note that self-signed certificates should not be used in most production environments.
Continuing the HTTPS example, a CA-signed certificate provides two important capabilities that a self-signed certificate does not:
-
Browsers (usually) automatically recognize the CA signature and allow a secure connection to be made without prompting the user.
-
When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser.
Most of the software supporting SSL/TLS have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection. Also, other applications may generate an error message when using a self-signed certificate.
The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:
-
Create a private and public encryption key pair.
-
Create a certificate signing request based on the public key. The certificate request contains information about your server and the company hosting it.
-
Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.
Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.
-
When the CA is satisfied that you are indeed who you claim to be, they send you a digital certificate.
-
Install this certificate on your secure server, and configure the appropriate applications to use the certificate.
Generating a Certificate Signing Request (CSR)
Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.
If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc., a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.
This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.
Warning
Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.
To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:
openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 2048 bit long modulus
..........................++++++
.......++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:
You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying is four characters. As a best practice it should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.-des3
Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the file.server.key
Now create the insecure key, the one without a passphrase, and shuffle the key names:
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
The insecure key is now named , and you can use this file to generate the CSR without passphrase.server.key
To create the CSR, run the following command at a terminal prompt:
openssl req -new -key server.key -out server.csr
It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the file.server.csr
You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.
Creating a Self-Signed Certificate
To create the self-signed certificate, run the following command at a terminal prompt:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the file.server.crt
Warning
If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.
Installing the Certificate
You can install the key file and certificate file , or the certificate file issued by your CA, by running following commands at a terminal prompt:server.keyserver.crt
sudo cp server.crt /etc/ssl/certs
sudo cp server.key /etc/ssl/private
Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.
Certification Authority
If the services on your network require more than a few self-signed certificates it may be worth the additional effort to setup your own internal Certification Authority (CA). Using certificates signed by your own CA, allows the various services using the certificates to easily trust other services using certificates issued from the same CA.
First, create the directories to hold the CA certificate and related files:
sudo mkdir /etc/ssl/CA
sudo mkdir /etc/ssl/newcerts
The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:
sudo sh -c "echo '01' > /etc/ssl/CA/serial"
sudo touch /etc/ssl/CA/index.txt
The third file is a CA configuration file. Though not strictly necessary, it is very convenient when issuing multiple certificates. Edit , and in the [ CA_default ] change:/etc/ssl/openssl.cnf
dir = /etc/ssl # Where everything is kept
database = $dir/CA/index.txt # database index file.
certificate = $dir/certs/cacert.pem # The CA certificate
serial = $dir/CA/serial # The current serial number
private_key = $dir/private/cakey.pem# The private key
Next, create the self-signed root certificate:
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650
You will then be asked to enter the details about the certificate.
Now install the root certificate and key:
sudo mv cakey.pem /etc/ssl/private/
sudo mv cacert.pem /etc/ssl/certs/
You are now ready to start signing certificates. The first item needed is a Certificate Signing Request (CSR), see Generating a Certificate Signing Request (CSR) for details. Once you have a CSR, enter the following to generate a certificate signed by the CA:
sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf
After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.
There should now be a new file, , containing the same output. Copy and paste everything beginning with the line: -----BEGIN CERTIFICATE----- and continuing through the line: ----END CERTIFICATE----- lines to a file named after the hostname of the server where the certificate will be installed. For example , is a nice descriptive name./etc/ssl/newcerts/01.pemmail.example.com.crt
Subsequent certificates will be named , , etc.02.pem03.pem
Note
Replace mail.example.com.crt with your own descriptive name.
Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is . This enables multiple services to use the same certificate without overly complicated file permissions./etc/ssl/certs
For applications that can be configured to use a CA certificate, you should also copy the file to the directory on each server./etc/ssl/certs/cacert.pem/etc/ssl/certs/
References
https://github.com/MicrosoftDocs/sql-docs/issues/3843
When running this command in WSL Ubuntu:
sudo curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
I get the following error:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
gpg: no valid OpenPGP data found.
I have "Ubuntu" installed, not the specific versions from the Microsoft Store.
Here is the verbose output:
sudo curl -v https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 40.76.35.62...
- TCP_NODELAY set
- Connected to packages.microsoft.com (40.76.35.62) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
- TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
- TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2542 bytes data]
- TLSv1.2 (OUT), TLS alert, Server hello (2):
} [2 bytes data]
- SSL certificate problem: unable to get local issuer certificate
- stopped the pause stream!
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
- Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
gpg: no valid OpenPGP data found.
Try setting env CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt .
Work for me.
I am using debian 10 under WSL2, confirm add line blow
export CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
to ~/.bashrc fix the problem.
You may also need to run 2 extra commands to make you modify work.
to update certs
sudo update-ca-certificates -f
to use updated envs
source ~/.bashrc
After a PC reconfiguration I am unable to use Docker properly, since some curl commands are rejected due to SSL/TLS issues.
In just one example curl -vfsSL https://apt.releases.hashicorp.com/gpg returns the following error:
* Trying 52.222.214.125:443...
* TCP_NODELAY set
* Connected to apt.releases.hashicorp.com (52.222.214.125) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
After some digging, I now now know that this issue also occurs within my WSL image, but not on host Windows OS. Hence, I believe this must be an issue that originates with my WSL setup, and not caused by Docker itself (?).
There are quite a few related questions on StackOverflow, but no solutions I found really apply to this case (and it is not an option to disable verification, which is quite frequently a suggested solution):
FWIW I work at an enterprise, with IT-issued OS. Obviously that could be a source of error, but they are unable to help me debug this issue. One a colleague's PC, however, it works flawlessly.
Any ideas?
PC Setup:
- Windows 10 Enterprise
- Version: 21H1
- OS build: 19043.1645
- Windows Feature Experience Pack: 120.2212.4170.0
- WSL 2 with Ubuntu-20.04
- Docker Desktop 4.7.1 (77678) with WSL 2 based engine
I had a similar problem at my company. The problem was that our firewall replaced the certificate. The certificate of the firewall was untrusted/unknown from within my wsl setup.
I solved the problem by exporting the firewall certificate from the windows certmanager (certmgr.msc).
The certificate was located at "Trusted Root Certification Authorities\Certifiactes"
Export the certificate as a DER coded x.509 and save it under e.g. "D:\eset.cer".
From within your WSL you can add the certificate with:
openssl x509 -inform DER -in /mnt/d/eset.cer -out ./eset.crt
sudo cp eset.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
answered Aug 26, 2022 at 7:06
10111 silver badge77 bronze badges
Zscaler Root CAcertificate