Windows证书管理器 && SSL certification && WSL-Docker: curl: (60) SSL certificate problem: unable to get local issuer certificate
深入浅出certmgr——Windows证书管理器
https://www.fke6.com/html/91605.html
计算机安全是当前社会的一个重要议题，证书是一种重要的安全机制，负责证明数据、软件或者人的身份和信誉。certmgr（即“证书管理器”）是Windows中专门用于证书管理的工具。本文将从多个方面对certmgr进行深入浅出的阐述，向大家介绍证书管理的基本知识和certmgr的工作原理。
一、证书的作用
证书是计算机安全中的一个基本概念，常用于验证身份和加密通信。在加密通信中，证书可以确保你和对方交换的信息只有你们两个人能够读取，防止信息在传输过程中被窃听、篡改或者伪造。在证书的认证过程中，公钥和私钥被用来保护数据和证书，确保数据和证书在传输过程中不被恶意篡改。证书通常会包含了相关信息的摘要和证书签名，用来证明数据的完整性和不可否认性。
证书种类非常多，包括数字证书、加密证书、SSL证书等等。除了Web浏览器和邮件客户端等常见的应用，证书在电子政务、电子商务、在线银行等许多领域中都有着广泛的应用。
二、certmgr基本介绍
certmgr是证书管理器，一般在Windows操作系统中自带。它可以让用户安装、浏览、导入和导出证书，同时也可以撤销、删除和管理证书链等操作。除了在命令行中使用certmgr.msc来打开证书管理器之外，用户还可以在控制面板或直接在运行框中输入certmgr打开证书管理器。
三、证书的安装与浏览
证书的安装与浏览是certmgr最常用的功能之一。通过证书管理器，用户可以将证书文件（.pfx或者.crt）添加到计算机中。证书管理器会将证书保存在对应的存储位置中，如个人、根证书授权或者受信任人等。
证书安装到根证书授权列表中，意味着该证书被信任，可以被用于认证其他证书或者加密通信。通过双击证书，用户可以查看证书的详细信息，如证书序列号、颁发机构、有效期、公钥等等。此外，证书管理器还支持导入或导出证书。
四、证书的导出与备份
证书的导出是certmgr管理证书的另一个重要功能，可以将证书导出为文件，保存在磁盘或者移动存储设备上进行备份。导出的证书可以在其他计算机上使用，也可以作为备份进行恢复。
导出证书需要选择导出格式（如PFX或cer）、存储位置和口令（如果需要）等信息，并指定证书的导出位置。
五、证书的删除与管理
证书的删除与管理也是certmgr重要的功能之一。通过证书管理器，用户可以删除需要撤销或者过期的证书，还可以管理证书链的情况。比如，用户可以检查证书是否过期或者是否被撤销，以保证证书的有效性。
除此之外，用户还可以创建自己的证书，并管理自己的证书链。证书管理器提供了灵活的选项和操作，可以帮助用户完成各种证书管理任务。
六、总结
本文对Windows下的证书管理器certmgr进行了简要介绍，主要涉及证书的作用、certmgr的基本介绍、证书的安装与浏览、证书的导出与备份以及证书的删除与管理。certmgr是证书管理的重要工具之一，可以帮助用户完成各种证书管理任务。希望本文能对证书管理、证书安全和证书网络应用有所启迪。
// 示例代码
// 创建或安装证书
X509Certificate2 certificate = new X509Certificate2(certificateBytes, password, X509KeyStorageFlags.MachineKeySet);
X509Store store = new X509Store(StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadWrite);
store.Add(certificate);
store.Close();
// 删除证书
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadWrite);
X509Certificate2Collection certificates = store.Certificates.Find(X509FindType.FindBySubjectName, subjectName, false);
if (certificates.Count > 0)
{
store.Remove(certificates[0]);
}
store.Close();
Windows证书管理
https://blog.csdn.net/panjunnn/article/details/106988994
windows里提供了数字证书管理工具，用于管理我们PC里安装的许多数字证书。
数字证书是一种电子文件，那么它有一定的格式，也有拓展名。但是拓展名多种多样。使用CA证书可以防止未经过认证的人访问我们的系统。
证书的扩展名
Windows中的证书扩展名有好几种，比如.cer和.crt。通常而言 .cer文件是二进制数据，而.crt文件是ASCII码的文本文件。
cer文件包含依据DER（Distinguished Encoding Rules）规则编码的证书数据，这是x.590标准中指定的编码格式。
X.509
X.509是一个最基本的公钥格式标准，里面规定了证书需要包含的各种信息。通常我们提到的证书，都是这个格式的，里面包含了公钥、发布者的数字签名、有效期等内容。
CER = CRT证书的 微软型式。可以用微软的工具把CRT文件转换为CER文件。
用windows窗口打开 一个数字证书的命令行：
rundll32 CryptExt.dll,CryptExtOpenCER cert.cer
两个证书管理工具
windows系统有两个证书管理工具certlm.msc和certmgr.msc，前者是本地计算机的证书管理工具，而后者是当前用户的证书管理工具。在导入证书时需要注意。如果证书仅是给当前用户使用那么就可以使用certmgr.msc。并且在启动certmgr.msc时不需要管理员权限，而certlm.msc需要管理员权限，否则就只能查看证书而不能导入证书。
cmd命令里，打开证书管理器的命令
certlm.msc 本地计算机
certmgr.msc 当前用户
这两个工具是管理不同的存储区，所以在要特别注意不要安装错了，不然你会头疼迷惑一天：怎么安装了证书就是看不到，还以为是命令错了，代码错了。
实验环境
我们的环境里有一台安装CA服务器的电脑，一个客户端PC。与大的权威CA不同，这里的CA是自己搭建windows的服务器
申请CA证书工具
证书请求工具certreq.exe，用于向CA服务器申请证书：
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
这里就是向服务把ClientCert.cer证书文件下载到了本地PC。
ClientCert.inf.txt 文本里面内容：
[NewRequest]
Subject="CN=<DCFQDN>"
KeyLength=2048
ProviderName="Microsoft RSA SChannel Cryptographic Provider"
RequestType=CMC
[RequestAttributes]
CertificateTemplate="User"
[Extensions]
Certmgr.exe证书管理工具
软有一个名为Certmgr.exe的证书管理器工具可以用于命令安装证书，该工具主要用于管理证书、证书信任列表 (CTL) 和证书吊销列表 (CRL)，
Certmgr.exe具体参数的示例请参考：
http://msdn.microsoft.com/zh-cn/library/e78byta0(VS.80).aspx。
该工具是SDK Tool的一部分，您可以下载最新的Windows SDK发行版获得此工具；若您安装了visual studio，该工具也包含在安装目录中。C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
cermgr.exe:下载链接
https://pan.baidu.com/s/1wnA-i0ixhSftPsMxv8OQ-Q
Certmgr.exe的使用
在cmd中执行certmgr会弹出证书管理工具的GUI。
如何把数字证书导入到Windows根证书存储区
安装证书（导入证书）
下面列出两个例子来理解：
certmgr.exe -add "GeoTrust SSL CA - G3.cer" -s -r localMachine AuthRoot
certmgr.exe -add GeoTrust_Global_CA.cer -s -r localMachine Root
上面两条命令会分别把GeoTrust SSL CA - G3证书添加到第三方证书颁发机构，
GeoTrust_Global_CA证书添加到受信任的根证书颁发机构。
如果你的client端没有certmgr.exe，您可以下载它，并把它放到当前目录下
certmgr.exe -add D:\test.cer -s -r localMachine trustedpublisher （需要管理员权限）
certmgr.exe -add D:\test.cer -s -r AuthRoot （不需要管理员权限）
这里localMachine说明了是安装在本地计算机下，省略默认是在用户下。
这两个命令就把这个证书test.cer添加到 localMachine trustedpublisher和AuthRoot证书存储区里了。
安装证书：（进入到CertMgr.exe工具目录，并且是以管理员权限打开cmd，注册cer证书，将该证书文件添加到证书存储区）
CertMgr.exe -add -all D:\certificate\ClientCert.cer -s my （my是证书的个人personal项）（ my 是默认到了用户的my）
CertMgr Succeeded （执行成功）
添加证书
D:\certificate>certmgr.exe -add clientcert.cer -c -s -r localMachine TrustedPublisher
Error: Failed to save to the destination store
CertMgr Failed （需要管理员权限）
certmgr.exe -add clientcert.cer -c -s -r localMachine TrustedPublisher （本地计算机下）
CertMgr Succeeded
certmgr.exe -add clientcert.cer -c -s -r localMachine My （本地计算机下）
CertMgr Succeeded
certmgr.exe -add clientcert.cer -c -s my （当前用户下）
CertMgr Succeeded
参数r的作用：
/r registry location 标识系统存储区的注册表位置。仅当指定 /s 选项时才考虑此选项。Registry location 必须是下列值之一：
currentUser 指示证书存储区在 HKEY_CURRENT_USER 键下。此为默认值。
localMachine 指示证书存储区在 HKEY_LOCAL_MACHINE 键下。
证书存储区
My 个人证书的X.509证书存储区。
AddressBook 其他用户的X.509证书存储区。
AuthRoot 第三方证书颁发机构(CA)的X.509证书存储区。
CertificateAuthority 中间证书颁发机构(CA)的X.509证书存储区。
Disallowed 吊销的证书的X.509证书存储区。
Root 受信任的根证书颁发机构(CA)的X.509证书存储区。
TrustedPeople 直接受信任的人和资源的X.509证书存储区。
TrustedPublisher 直接受信任的发行者的X.509证书存储区。
卸载证书
例：删除指定证书：
删除证书
certmgr.exe -del clientcert.cer -c -s -r localMachine TrustedPublisher
CertMgr Succeeded
certmgr.exe -del clientcert.cer -c -s -r localMachine My
CertMgr Succeeded
certmgr.exe -del -c -n "Tencent Technology(Shenzhen) Company Limited" -s -r localMachine addressbook
下面这句是OK的
certmgr.exe -del -c -n "Tencent" -s -r localMachine my
查看证书
查看某个证书文件的信息：
certmgr.exe -c clientcert.cer
==============Certificate # 1 ==========
Subject::
[0,0] 0.9.2342.19200300.100.1.25 (DC) work
Issuer::
[2,0] 2.5.4.3 (CN)
SerialNumber::
MD5 Thumbprint::
NotBefore::
Tue Jun 23 14:21:13 2020
NotAfter::
Wed Jun 23 14:21:13 2021
==============================================
CertMgr Succeeded
查看所有证书
certmgr /v /s my
CertMgr -del -c -n abc -s my 删除电脑里my区域（可以改成root--受信任的根证书...）内"abc"开头的证书。
certmgr /v /s my 查询my内所有证书。
certmgr帮助说明
certmgr 输入参数错误，或者输入-help参数，都会给出提示如下：
certmgr [/add | /del | /put] [options]
[/s[/r registryLocation]] [sourceStorename]
[/s[/r registryLocation]] [destinationStorename]
参数
--------------------------------------------------------------------------------
参数 说明
sourceStorename StoreFile 类型或系统存储区类型的输入证书存储区。
destinationStorename 输出证书存储区或文件。
选项 说明
/add 将证书、CTL 和 CRL 添加到证书存储区中。
/all 当与 /add 一起使用时添加所有项。当与 /del 一起使用时删除所有项。不带 /add 或 /delete 选项使用时显示所 有项。/all 选项不能与 /put 一起使用。
/c 当与 /add 一起使用时添加证书。当与 /del 一起使用时删除证书。当与 /put 一起使用时保存证书。不带 /add、/delete 或 /put 选项使用时显示证书。
/CRL 添加或删除 CRL。不带 /add、/delete 或 /put 选项使用时显示 CRL。
/CTL 添加或删除 CTL。不带 /add、/delete 或 /put 选项使用时显示 CTL。
/delete 从指定的证书存储区中删除证书、CTL 和 CRL。
/e encodingType 指定证书编码类型。
/f dwFlags 指定存储区打开标志。这是传递到 CertOpenStore 的 dwFlags 参数。默认值为 CERT_SYSTEM_STORE_CURRENT_USER。仅当使用 /y 选项时才考虑此选项。
/h[elp] 显示该工具的命令语法和选项。
/n commonName String 指定要添加、删除或保存的证书的公共名。此选项只能用于证书，不能用于 CTL 或 CRL。
/put 将证书存储区中的 X.509 证书、CTL 或 CRL 保存到文件。该文件将以 X.509 格式保存。/7 选项可与 /put 选项一起使用以 PKCS #7 格式保存文件。/put 选项后面必须有 /c、/CTL 或 /CRL。/all 选项不能与 /put 一起使用。
/r registry location 标识系统存储区的注册表位置。仅当指定 /s 选项时才考虑此选项。Registry location 必须是下列值之一： currentUser 指示证书存储区在 HKEY_CURRENT_USER 键下。此为默认值。 localMachine 指示证书存储区在 HKEY_LOCAL_MACHINE 键下。
/s 指示证书存储区是系统存储区。如果不指定此选项，则该存储区为 StoreFile。
/sha1 sha1Hash 指定要添加、删除或保存的证书、CTL 或 CRL 的 SHA1 哈希。
/v 指定详细模式；显示有关证书、CTL 和 CRL 的详细信息。此选项不能与 /add、/delete 或 /put 选项一起使用。
/y storeProviderType 指定存储区提供程序类型。
/7 将目标存储区保存为 PKCS#7 对象。
/? 显示该工具的命令语法和选项。
certutil工具
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil
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 -store -user My
My "个人" 查询用户下，个人选项下的证书
================ 证书 0 ================
序列号: 2a0000016b40155bdce08d08da00010000016b
颁发者: CN= -HEG-DC01-CA, DC= , DC=work
NotBefore: 2020/6/23 14:21
NotAfter: 2021/6/23 14:21
使用者: E= ,
证书模板名称 (证书类型): User
非根证书
模板: User
证书哈希(sha1): 5df252e0e0580c4f2459bb1eb7b9a5a9588f8a38
没有密钥提供程序信息
找不到解密的证书和私钥。
CertUtil: -store 命令成功完成。
WINDOWS 导入p7b , cer证书
certutil -addstore -f root "c:\CA\CertnName.p7b"
CERTUTIL -addstore -enterprise -f -v root "C:\clientcert.cer"
导入pfx证书
certutil -user -f -p 123456789 -importpfx C:\Users\clientcert.pfx
安装证书到 “用户——个人” 下。 参数-user 是用户 证书管理下。
certutil -f -p 123456789 -importpfx Root C:\Users\clientcert.pfx
安装证书到 “本地计算机——受信任的根证书” 下的证书。
删除证书
CertUtil -f -delstore -user My 证书name
将删除在 用户——个人下的证书。
问题
打开证书管理弹窗提示： 无法打开 证书管理器 MYSTORE
这里丢失了证书项，进到证书管理器里，在相应的项里，添加一个证书，指明cer证书的文件路径，安装证书，这么操作系统会自行把丢失的证书项建立好。
————————————————
版权声明：本文为CSDN博主「边缘计算机」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/panjunnn/article/details/106988994
Docker with WSL 2, SSL Proxy and SSL Certificate Problem
Docker with WSL 2, SSL Proxy and SSL Certificate Problem (kontext.tech)
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:
- Type certmgr.msc using Windows search button.
- In the window, find out the certificate of the proxy:
- Double click the certificate row and go to Details tab:
- Click button Copy to File.
- Click Next button:
- Select Base-64 encoded X.509 (.CER)
- Choose the path and finish the export. For this article, we will call this certificate as myproxy.cer.
- Copy this certification file into your WSL distro.
- Install openssl package if not installed:
sudo apt-get install openssl
- Use the following command line to convert
openssl x509 -inform PEM -in <filepath>/myproxy.cer -out myproxy.crt
- We will use myproxy.crt in the following sections.
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.
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.
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
-
The Wikipedia HTTPS page has more information regarding HTTPS.
-
For more information on OpenSSL see the OpenSSL Home Page.
-
Also, O’Reilly’s Network Security with OpenSSL is a good in-depth reference.
Ubuntu WSL - "curl: (60) SSL certificate problem: unable to get local issuer certificate"#
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.
CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt .Work for me.
I am using debian 10 under WSL2, confirm add line blowexport 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 certssudo update-ca-certificates -f
to use updated envssource ~/.bashrc
WSL-Docker: curl: (60) SSL certificate problem: unable to get local issuer certificate
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):
- Unable to resolve "unable to get local issuer certificate" using git on Windows with self-signed certificate
- curl: (60) SSL certificate problem: unable to get local issuer certificate
- PayPal IPN: unable to get local issuer certificate
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
Zscaler Root CAcertificate