-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Login to corporate registry with self-signed cert fails #24101
Comments
@dschulten I set up a private registry locally with a self-signed certificate, and here is the [[registry]]
location = "localhost:5000"
insecure = true To log in, I used: root@zaasvmd:~/private-registry-certs# podman login localhost:5000
Username: testuser
Password:
Login Succeeded! Does this match your setup, or do you have a different configuration? |
I am trying to follow the same basic configuration, but it fails. The difference between your setup und mine could maybe lie in the fact that I am behind a corporate proxy (configured via ENV Vars) or maybe the podman version. Also, my registry is on a different machine and it is a gitlab registry, probably a different product than your registry. Furthermore, I am running rootful and in user-mode-networking. The error message says that podman does not trust the certificate. Is there some additional log I can enable to track how podman attempts to establish trust? I have tried to add the selfsigned cert as trusted cert, but obviously that doesn't have the expected effect, not even in combination with the insecure flag. In which file did you define the insecure registry? |
I defined in
yes podman login --log-level=debug localhost:5000 |
I take it we both previously logged into the podman machine with ssh, and edited the same file. The Which podman version did you use? |
A friendly reminder that this issue had no activity for 30 days. |
I have the similar problem with "certificate signed by unknown authority". The root certificate is publish in the windows system that browsers and apps accept it as valid. Only podman does not accept it. |
Issue Description
I need to access a corporate registry that uses a self-signed certificate. I am using a rootful podman engine with user-mode networking in Windows 10 with a corporate proxy and proxy settings that have NO_PROXY settings containing .registry.example.com as proxy exception.
Note that I have installed podman on a machine where Docker Desktop (Hyper-V) is installed, too. But I make sure to stop that docker engine when running the podman engine.
I had to go rootful with --user-mode-networking because of:
I am able to execute the test container:
Login into the corporate registry fails:
I have added the registry's PEM file to /etc/pki/ca-trust/source/anchors/gitlab-registry-example-com.pem using vi after establishing a root session using podman machine ssh.
Then I have executed
update-ca-trust
, which gives me no output, normally a sign that it worked.When I inspect the PEM file, it tells me that issuer and owner have the same DN, namely gitlab.registry.example.com.
In addition to adding the self-signed certificate as a trusted certificate, I also tried to mark the registry as insecure by adding the following entry to /etc/containers/registries.conf:
That makes no difference.
Pulling and running images from the registry also fails:
However, the service is not unavailable - login and pulling images in docker desktop works just fine (when I shut down the podman machine and run docker desktop instead)
I have also tried to use the Podman Desktop UI to add registries with self-signed certificates - after a lengthy period, the UI shows the following error message:
I also tried to enable --log-level=debug, but it gives me no clue why it cannot establish trust, only where it attempts to find credentials:
Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
Login failure, certificate signed by unknown authority
Describe the results you expected
Login should work
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
Yes
Additional environment details
no environment details
Additional information
no additional information
The text was updated successfully, but these errors were encountered: