Bug 1706030
| Summary: | Docker Image Registry - Swift Configuration - Certificate Error | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Aytunc BEKEN <aytuncbeken.ab> |
| Component: | Networking | Assignee: | Dan Mace <dmace> |
| Networking sub component: | DNS | QA Contact: | Hongan Li <hongli> |
| Status: | CLOSED WONTFIX | Docs Contact: | |
| Severity: | medium | ||
| Priority: | unspecified | CC: | adam.kaplan, aos-bugs |
| Version: | 3.11.0 | Keywords: | Reopened |
| Target Milestone: | --- | ||
| Target Release: | 3.11.z | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-10-16 13:39:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Aytunc BEKEN
2019-05-03 12:13:17 UTC
Looks like the certificate provided by auth.cloud.ovh.net is not valid. Either contact the administrator of the auth server to update their certificate, or update the storage settings to set `insecureskipverify` setting to `true` [1]. [1] https://docs.docker.com/registry/storage-drivers/swift/ Certificates are valid, as you can find in the comments same configuration works when it is run as docker container only. It give error when it runs on OpenShift. "*.cluster.octochroniq.de" is the dns address of the openshift cluster it self. Why openshift tries to use selfsigned server certificates ? Can you try `curl -v https://auth.cloud.ovh.net/v2.0/tokens` from within the registry container (oc -n default rsh dc/docker-registry)? Hi, Below the result from command. Especially 159.69.113.247 is the server's ip not auth.cloud.ovh.net, why it tries to connect to server. I created a bash image directly on docker, ping resolved the true IP 51.68.65.247. bash-4.2$ curl -v https://auth.cloud.ovh.net/v2.0/tokens * About to connect() to auth.cloud.ovh.net port 443 (#0) * Trying 159.69.113.247... * Connected to auth.cloud.ovh.net (159.69.113.247) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Server certificate: * subject: CN=*.cluster.octochroniq.de * start date: May 02 09:49:21 2019 GMT * expire date: May 01 09:49:22 2021 GMT * common name: *.cluster.octochroniq.de * issuer: CN=openshift-signer@1556790248 * NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER) * Peer's certificate issuer has been marked as not trusted by the user. * Closing connection 0 I'm not sure why this was assigned to my team. Because it's a DNS problem: $ dig +noall +answer auth.cloud.ovh.net auth.cloud.ovh.net. 84 IN A 51.68.65.247 but from inside the pods it resolves to 159.69.113.247. $ whois 51.68.65.247 | grep ^org-name: org-name: OVH SAS $ whois 159.69.113.247 | grep ^org-name: | sort -u org-name: Hetzner Online GmbH If you suspect a DNS issue, please provide: 1. Packet captures (tcpdump) of the request from inside the pod, and also from wherever the query working (the node?) 2. The /etc/resolv.conf from the pod, and from the node hosting the pod 3. The Dnsmasq configuration files from the node Thanks! We are not using this feature anymore. We can close the issue. Thanks. |