Certificate signed by unknown authority linux

getting ` x509: certificate signed by unknown authority` error while verifying certificates for rest application

I am generating a self signed certificate using openssl in Ubuntu. I want to use it for localhost rest server. But while verification, I am getting error : x509: certificate signed by unknown authority , can anyone please tell me how I can resolve this error? Thanks!

3 Answers 3

Place your .crt certificate to /usr/share/ca-certificates

Edit /etc/ca-certificates.conf and add your certificate name there.
(Look at update-ca-certificates man page for more information.)

Then run sudo update-ca-certificates

Works for me in Ubuntu 22

Place your root certificate and intermediate (if you have one) in /usr/share/local/ca-certificates with the .crt extension.

sudo update-ca-certificates Updating certificates in /etc/ssl/certs. 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d. done. 

In this case, curl is your friend:

curl -Iv https://localhost/path/to/api 

Also you can run openssl s_client

openssl s_client localhost:443 

Additionally, you can interrogate your certificate by providing your certificate:

openssl s_client -connect localhost:443 -CAfile /path/to/your/cert.pem 

If you certificate does not match, you know. Possibly you are using the wrong certificate for your REST API or the certificate is not being installed, which you can verify by looking in /etc/ssl/certs directory on your system (if you are running Linux)

In the official documentation, they mentioned the error and how to solve it.

x509: certificate signed by unknown authority [ERROR ImagePull]: failed to pull image registry.k8s.io/kube-apiserver:v1.13.3: output: Error response from daemon: Get https://registry.k8s.io/v2/: x509: certificate signed by unknown authority This is because minikube VM is stuck behind a proxy that rewrites HTTPS responses to contain its own TLS certificate. The solution is to install the proxy certificate into a location that is copied to the VM at startup, so that it can be validated.

Ask your IT department for the appropriate PEM file, and add it to:

~/.minikube/files/etc/ssl/certs

or

~/.minikube/certs

Then run minikube delete and minikube start

Then I discovered where my company keep the .pem files, then I executed the next commands:

cp /etc/pki/ca-trust/source/anchors/* ~/.minikube/certs/ minikube delete --all minikube start 

if you`re not behind a proxy/vpn, then you need to generate a ssl certificate as Randall Svancara explained in the answer above and then put the cert file in the ~/.minikube/certs directory.

Источник

Ошибка проверки корневого сертификата

Это еще одна краткая шпаргалка по решению проблемы, с которой я столкнулся. Как оказалось по итогу это была ошибка проверки корневого сертификата.

Я приведу пример ошибки с сертификатом для системы хранения кода Gitea. Gitea может выступать в качестве репозитория контейнеров. Именно в сценарии использования Gitea в качестве репозитория контейнеров генерировалась ошибка. Точнее это даже не ошибка самой системы Gitea, а скорее ошибка клиента Docker и curl, которые вызваны отсутсвием необходимых корневого и промежуточного ЦС.

Симптомы

Есть wilcard сертификат от GlobalSign. Есть система для хранения и версионирования исходного кода Gitea. Для доступа к веб сервисам Gitea используется wildcard сертификат от GlobalSign. При использовании браузера проблем с сертификатом или доступами нет. Сертификат идентифицируется, как сертификат от доверенного ЦС.

Однако, если попробовать использовать клиент утилиту curl, то генерируется ошибка проверки корневого сертификата:

curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.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.

Еще одна ошибка при попытке авторизоваться в репозитории Docker контейнеров:

docker login code.infoplex.ru

Error response from daemon: Get code.infoplex.ru/v2/: x509: certificate signed by unknown authority

Окружение

Ошибка воспроизводилась на следующих ОС – Linux Mint 21.1 Cinnamon и Ubuntu Server 22.04.

На RHEL дистрибутивах не проверял.

Ошибка проверки корневого сертификата – решение

По итогу ошибку удалось устранить установкой соответствующего сертификата корневого и промежуточного ЦС на клиентском рабочем месте, т.е. на том рабочем месте с которого вы подключаетесь к репозиторию контейнеров.

Сохранение сертификата

Сначала нужно сохранить сертификат корневого ЦС и промежуточного ЦС. Можно использовать любой удобный способ, но я сохраню их через Chrome. Откроем просмотр сведений о сертификате:

Сначала сохраним сертификат корневого ЦС:

Укажем расположение, имя и формат файла:

Аналогичным образом сохраним сертификат промежуточного ЦС:

Импорт сертификата в доверенные (метод 1)

Скопируем сертификаты в директорию ca-certificates:

cd $HOME/Downloads/crts/ sudo cp GlobalSign_Root_CA.crt AlphaSSL_CA.crt /usr/share/ca-certificates

Запустим обновление списка корневых ЦС:

sudo dpkg-reconfigure ca-certificates

На первой странице мастера подтверждаем вносимые изменения:

Отмечаем новый добавленные сертификаты:

Вы должны увидеть примерно следующий вывод на консоль:

Updating certificates in /etc/ssl/certs. rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL rehash: warning: skipping duplicate certificate in A.pem rehash: warning: skipping duplicate certificate in GlobalSign_Root_CA.pem 2 added, 0 removed; done. Processing triggers for ca-certificates (20211016ubuntu0.22.04.1) . Updating certificates in /etc/ssl/certs. rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL rehash: warning: skipping duplicate certificate in A.pem rehash: warning: skipping duplicate certificate in GlobalSign_Root_CA.pem 2 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d. Replacing debian:GlobalSign_Root_CA.pem Replacing debian:GlobalSign_Root_CA.pem done. done.

Правда, в моем случае сертификаты уже были добавлены и вывод немного отличается от первоначального. Но вы должны увидеть строчку вида:

После этого запросы по curl сразу начали работать корректно. Для корректной работы docker пришлось перезапустить службу:

sudo systemctl restart docker

После этого проблем с доступом к Docker репозиторию контейнеров на Gitea не наблюдалось.

Импорт сертификата в доверенные (метод 2)

Есть еще альтернативный способ испорта сертификата в доверенные – полностью через командную строчку.

Скопируем сертификаты в директорию ca-certificates:

cd $HOME/Downloads/crts/ sudo cp GlobalSign_Root_CA.crt AlphaSSL_CA.crt /usr/local/share/ca-certificates

Запустим обновление списка корневых ЦС:

sudo update-ca-certificates

roman@mintwks:~/Downloads/crts$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs. rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL rehash: warning: skipping duplicate certificate in A.pem rehash: warning: skipping duplicate certificate in GlobalSign_Root_CA.pem 4 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d. Replacing debian:GlobalSign_Root_CA.pem Replacing debian:GlobalSign_Root_CA.pem Adding debian:AlphaSSL_CA.pem Replacing debian:GlobalSign_Root_CA.pem done. done. roman@mintwks:~/Downloads/crts$ 

Как видно из скриншота выше – сертификаты были добавлены в список доверенных центров сертификации.

Решение при использовании Minikube

Если вы используете Minikube, то подход будет немного другой, но в целом поход.

Сначала нужно сохранить сертификат корневого ЦС и промежуточного ЦС аналогично пункту выше.

Затем нужно скопировать сертификаты на машину с Minikube в соответствующую директорию:

scp AlphaSSL_CA.crt GlobalSign_Root_CA.crt k8suser@10.10.10.19:/home/minikubeuser/.minikube/certs/

А затем на самой машине запустить Minikube с параметром, который “подтягивает” эти сертификаты:

minikube start --embed-certs

Источник

‘x509: certificate signed by unknown authority’ from Terraform CLI with a Terraform Enterprise remote

When utilizing a remote in Terraform to ensure runs are handled by Terraform Enterprise and a custom Certificate Authority (CA) is used, client commands such as terraform login that connect to Terraform Enterprise error with x509: certificate signed by unknown authority

Cause

Due to the way SSL/TLS works, when Terraform Enterprise is configured with a custom Certificate Authority, any connections to it must also trust the CA as well to ensure validity. When utilizing the Terraform CLI, this means that the machine running the terraform command must also contain the Terraform Enterprise CA in its trust store.

Solution

To ensure network traffic to Terraform Enterprise succeeds SSL/TLS validation, the client machine must add the Terraform Enterprise CA to its trust store of certificates. This trust store is different depending on the host OS. After the store has the new Certificate Authority, the terraform commands should work as expected.

Windows

1. Download the Terraform Enterprise CA certificate in the PFX format to the client machine. (This can be converted from Terraform Enterprise’s PEM-formatted CA certificate with openssl pkcs12 -export -in ca.pem -out ca.pfx )
2. Click Start, type mmc , and press Enter.
3. Click Yes, this starts the Microsoft Management Console.
4. Select File -> Add/Remove Snap-in.
5. Under Available snap-ins, select Certificates. Click Add.
6. Select Computer account, then click Next.
7. Click Finish, and click OK.
8. Expand Certificates, right click Trusted Root Certification Authority, and select All Tasks -> Import.
9. Click Next.
10. Click Browse, select your root CA certificate from Step 1. Click Open.
11. Click Next ->Next ->Finish.
12. When the import was successful message is displayed, click OK.
13. Select File -> Save -> Save.
14. Close the Microsoft Management Console.

Mac OS

1. Download the Terraform Enterprise CA certificate in the DER format to the client machine. (This can be converted from Terraform Enterprise’s PEM-formatted CA certificate with openssl x509 -inform PEM -in ca.pem -outform DER -out ca.cer ). In this example, the file is in the Downloads folder. If the certificate is located in a different folder, navigate to this folder in the Terminal before running the command to add the certificate.
2. Click Launchpad, in the search field, type terminal . Click the Terminal icon.
3. In Terminal, run cd ~/Downloads .
4. Run sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt . In this example, the root CA certificate is named ca.crt . If the certificate has a different file name, be sure to change it in the command before running it.
5. Type your password and press Return.
6. Close the Terminal.

Linux

Note: This assumes the Linux distribution utilizes ca-certificates as its trust store. This includes all flavors of Linux supported by Terraform Enterprise, including Red Hat-based, Debian-based, and more.

1. Download the Terraform Enterprise CA certificate in the DER format to the client machine. (This can be converted from Terraform Enterprise’s PEM-formatted CA certificate with openssl x509 -inform PEM -in ca.pem -outform DER -out ca.cer ). In this example, the file is in the Downloads folder. If the certificate is located in a different folder, change the path before running the cp command to add the certificate to the trust store.
2. Open a command-line terminal.
3. The CA certificate can be copied into the store with sudo cp ~/Downloads/ca.crt /etc/pki/ca-trust/ source/anchors/tfe-ca.crt . In this example, the root CA certificate is named ca.crt and is copied into a file named tfe-ca.crt . If the certificate has a different file name or the destination file should be named differently, be sure to change it in the command before running it.
4. Run sudo update-ca-trust .

Источник