Moby: acessar registro privado: x509: certificado assinado por autoridade desconhecida

Criado em 30 out. 2014  ·  39Comentários  ·  Fonte: moby/moby

Eu configurei o docker-registry com o nginx seguindo aqui .

Eu executo o 'docker login' e recebo este erro:

# docker login -u docker -p docker -e [email protected] https://dev.registry.com
2014/10/30 11:12:08 Error response from daemon: Server Error: Post https://dev.registry.com/v1/users/: x509: certificate signed by unknown authority

Saída do daemon do docker:

[debug] server.go:1181 Calling POST /auth
[info] POST /v1.15/auth
[47687bb1] +job auth()
[debug] endpoint.go:109 Error unmarshalling the _ping RegistryInfo: json: cannot unmarshal bool into Go value of type registry.RegistryInfo
[debug] endpoint.go:113 Registry version header: '0.7.1'
[debug] endpoint.go:116 RegistryInfo.Version: "0.7.1"
[debug] endpoint.go:119 Registry standalone header: 'True'
[debug] endpoint.go:127 RegistryInfo.Standalone: true
[debug] endpoint.go:109 Error unmarshalling the _ping RegistryInfo: json: cannot unmarshal bool into Go value of type registry.RegistryInfo
[debug] endpoint.go:113 Registry version header: '0.7.1'
[debug] endpoint.go:116 RegistryInfo.Version: "0.7.1"
[debug] endpoint.go:119 Registry standalone header: 'True'
[debug] endpoint.go:127 RegistryInfo.Standalone: true
Server Error: Post https://dev.registry.com/v1/users/: x509: certificate signed by unknown authority
[47687bb1] -job auth() = ERR (1)
[error] server.go:1207 Handler for POST /auth returned error: Server Error: Post https://dev.registry.com/v1/users/: x509: certificate signed by unknown authority
[error] server.go:110 HTTP Error: statusCode=500 Server Error: Post https://dev.registry.com/v1/users/: x509: certificate signed by unknown authority

Eu verifiquei o código. Acho que a função Login pode ser necessária 'tlsConfig'
https://github.com/docker/docker/blob/master/registry/auth.go#L163

Assim como
https://github.com/docker/docker/blob/master/registry/registry.go#L49

# docker --version
Docker version 1.3.0, build c78088f
# curl --cacert ca.pem https://dev.registry.com/v1/_ping                 
true
# curl --cacert ca.pem -u docker:docker https://dev.registry.com/v1/users/
"OK"

# curl -u docker:docker https://dev.registry.com/v1/users/                
curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Comentários muito úteis

Obrigado, isso também funcionou para mim. Etapas equivalentes no Ubuntu / Debian:

  1. Copie o certificado CA para /usr/local/share/ca-certificates .
  2. sudo update-ca-certificates
  3. sudo service docker restart

Ainda há um bug aqui, no entanto. Os documentos dizem para instalar o certificado CA em /etc/docker/certs.d/<registry> , e claramente isso não é suficiente. Na verdade, depois de instalar o certificado globalmente, removi aquele em /etc/docker/certs.d , reiniciei o Docker e ainda funcionava.

Todos 39 comentários

@hustcat A partir do Docker 1.3.1, você pode fazer --insecure-registry dev.registry.com:5000 substituir 5000 por qualquer porta em que seu registro esteja escutando.

Estou encerrando agora, mas deixe-nos saber nos comentários se isso não resolver o seu problema.

Estou deixando isso aqui porque demorei alguns minutos para descobrir e pode economizar o tempo de alguém. O comando seria:

%> docker --insecure-registry=docker-registry.example.com:8080 login https://docker-registry.example.com:8080

Obrigado por colocar a chave em prática para 1.3!

Estou enfrentando o mesmo problema. A validação do certificado funciona para o ping (e push / pull), mas não para o login.

O sinalizador --insecure-registry é uma solução alternativa, não uma correção. A validação do certificado deve funcionar se o certificado CA for carregado em /etc/docker/certs.d/<registry> , mas não funciona.

Não consigo fazê-lo funcionar definindo --insecure-registry Estou no docker 1.3.2 no RedHat 7

[ root @ ip-10-2-20-209 ec2-user] # docker --insecure-registry = qa.docker.repo login https: //qa.docker.repo
Nome de usuário: qa
Senha:
Email: [email protected]
2015/01/19 14:26:40 Resposta de erro do daemon: Erro do servidor: Post https: //qa.docker.repo/v1/users/ : x509: certificado assinado por autoridade desconhecida

curl funciona bem quando eu uso o arquivo ca.pem gerado.

curl --cacert /home/ec2-user/ca.pem -u qa: xxxxx https: //qa.docker.repo/v1/users/
"OK"

Estou tendo o mesmo problema no docker versão 1.3.2 e no opensuse 13.1. Eu até tentei passar estaticamente --cafile cacert.pem para cada chamada curl (uma vez que assumi que docker internamente usa apenas curl), no entanto, isso também não ajudou.

Qualquer ajuda seria muito apreciada.

Obrigado.
Mario

Antes de encontrar esse problema, abri o # 10150. Eles parecem ser o mesmo problema.

Parece que estou tendo o mesmo problema. Cliente Archlinux 1.4.1 e o registro em execução no contêiner docker oficial. Alguém tem alguma ideia?

Se você instalou o certificado globalmente (por meio de certificados ca), certifique-se de reiniciar o docker, pois ele não recarregará os certificados SSL globais. Dito isso, o meu ainda não está funcionando, mas descobri isso no trabalho :)

Obrigado grimmy, isso funcionou do meu lado e finalmente funciona. Eu fiz:

  1. Obtenha cacert.pem em http://curl.haxx.se/docs/caextract.html
  2. Copie o arquivo cacert.pem para / etc / pki / trust / anchors /
  3. sudo update-ca-certificates
  4. sudo systemctl docker stop
  5. sudo systemctl docker start

mario

Obrigado, isso também funcionou para mim. Etapas equivalentes no Ubuntu / Debian:

  1. Copie o certificado CA para /usr/local/share/ca-certificates .
  2. sudo update-ca-certificates
  3. sudo service docker restart

Ainda há um bug aqui, no entanto. Os documentos dizem para instalar o certificado CA em /etc/docker/certs.d/<registry> , e claramente isso não é suficiente. Na verdade, depois de instalar o certificado globalmente, removi aquele em /etc/docker/certs.d , reiniciei o Docker e ainda funcionava.

+1 para reabri-lo, como @rhasselbaum mencionou

O --insecure-registry desapareceu?

$ docker --version
Docker version 1.8.2, build 0a8c2e3

$ docker --insecure-registry
flag provided but not defined: --insecure-registry
See 'docker --help'.

O que devemos usar agora?

que vai no arquivo de configuração do docker, você pode verificar se está definido olhando
o processo docker, você deve ver a sinalização --insecure-registry

Na quarta-feira, 16 de setembro de 2015 às 3:01, Chris Withers [email protected]
escreveu:

O --insecure-registry desapareceu?

$ docker --version
Docker versão 1.8.2, compilação 0a8c2e3

$ docker --insecure-registry
sinalizador fornecido, mas não definido: --insecure-registry
Veja 'docker --help'.

O que devemos usar agora?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/8849#issuecomment -140693481.

Recebi o mesmo erro para o comando docker pull e acho que o seguinte deve funcionar.
Copie o certificado SSL que é o arquivo '.crt' para o diretório

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt
Deixe o Ubuntu adicionar o caminho do arquivo '.crt' relativo a / usr / share / ca-certificates em /etc/ca-certificates.conf

sudo dpkg-reconfigure ca-certificados

se o estado da sua máquina não for importante, você pode executar docker-machine rm <machine-name> e criar outro;)

Se você usar LetsEncrypt e não quiser executar nada sem o TLS adequado, certifique-se de fornecer a cadeia completa do certificado, incluindo intermediários (ou seja, REGISTRY_HTTP_TLS_CERTIFICATE = ... / fullchain.pem), você pode ver verde no Chrome enquanto ainda está obtendo este erro do Docker.

Saúde!

No Ubuntu. Se você encontrar um erro:

  • x509: não é possível validar o certificado para [endereço IP ou nome de domínio] porque não contém SANs IP

No registro Docker, o certificado teve que ser compilado com o subjectAltName conforme descrito aqui:
https://docs.docker.com/engine/security/https/

Aqui está o código para sua conveniência:
$ echo subjectAltName = IP: 10.10.10.20, IP: 127.0.0.1> extfile.cnf
$ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \
-CAcreateserial -out server-cert.pem -extfile extfile.cnf

Observe que consegui verificar se o nome alternativo do assunto está presente no certificado usando o seguinte comando:
openssl x509 -in certificate.crt -text -noout

No entanto, no cliente Ubuntu 14 (ou seja, Docker Engine)
Este erro foi seguido por
x509: certificado assinado por autoridade desconhecida

Para pessoas que usam o Ubuntu 14.
O arquivo de configuração usado para o mecanismo Docker (que desejo usar para me conectar ao Docker Registry):
/ etc / default / docker

lá, você precisa especificar as opções do docker:
DOCKER_OPTS = "- inseguro-registro myinsecure. Com: 5000 "

Em seguida, reinicie o daemon (adicione sudo se o usuário não tiver permissão para iniciar um serviço docker):
Reinicialização do docker do serviço $ [sudo]

O valor não precisa ser um nome de domínio, ele simplesmente precisa corresponder ao que seu certificado está registrado; Eu tenho um endereço IP com uma porta e isso funciona ... (ieeg 100.100.100.100:100)

Tudo isso me levou um dia, então, estou postando isso na esperança de que seja útil para outras pessoas ...

@JazzDeben Obrigado por suas observações! muito útil ! Não tenho certeza de como fazer isso com um certificado gerado pelo certbot Let's Encript.
eu recebo este erro no servidor de registro

tls: client didn't provide a certificate

Chrome reclama de ERR_BAD_SSL_CLIENT_AUTH_CERT
se eu incluir

  tls:
...
    clientcas:
      - /path/to/ca.pem

@ cjw296 Para RHEL7.2, editei o arquivo /usr/lib/systemd/docker.service e na linha ExecStart adicionei --insecure-registry=your.docker.registry.com .

< ExecStart=/usr/bin/dockerd
---
> ExecStart=/usr/bin/dockerd --insecure-registry=your.docker.registry.com

Então eu executei sudo systemctl daemon-reload para pegar a mudança de configuração, seguido por sudo systemctl restart docker . E agora funciona.

Para ser honesto, ainda sou um novato em sistemas e provavelmente há maneiras melhores de fazer isso de forma mais limpa. Mas eu lutei com isso por muito tempo e queria postar uma solução alternativa. Obrigado a @ cdub50 por me guiar na direção certa.

@ david-drinn Para o Fedora 25, fiz algo semelhante, mas desde a configuração do daemon do docker (em /usr/lib/systemd/system/docker.service ) a partir dos arquivos de configuração, fiz a alteração em /etc/sysconfig/docker :

< # INSECURE_REGISTRY='--insecure-registry='
---
> INSECURE_REGISTRY='--insecure-registry=your.docker.registry.com'

Se curl estiver funcionando e o docker não, você pode:
o crie o "/etc/docker/certs.d// ... "diretório e arquivos (válido apenas para registros privados?)
o adicione uma entrada "tlscert" em seu arquivo "/etc/docker/daemon.json", para que o dockerd use os mesmos certificados que o curl.

Para aqueles que se deparam com esse problema e você tem certificados autoassinados e não deseja usar a diretiva "insecure-registry", você precisa carregar seus certificados autoassinados em /etc/docker/certs.d/{host}/ . Depois de carregá-los, lembre-se de RESTART daemon do docker. Para elaborar um pouco mais ...

Se o seu registro estiver hospedado em https://exampleregistry.com, você deve ter um diretório chamado /etc/docker/certs.d/exampleregistry.com com seus certificados autoassinados dentro. Agora você poderá fazer docker login exampleregistry.com sem nenhum erro x509.
Agora, aqui está uma advertência para tudo isso, digamos que você queira, por algum motivo, definir explicitamente a porta em seu comando de login como este docker login exampleregistry.com:443 (o que não faria sentido, mas este é apenas um exemplo), então você precisa para garantir que seus certificados autoassinados estejam dentro de uma pasta chamada /etc/docker/certs.d/exampleregistry.com:443/ . O Docker não faz suposições sobre a resolução de certificados com base no nome do host apenas ao usar uma porta. Você realmente precisa fornecer certificados por porta, carregando seus certificados autoassinados em um nome de pasta que inclua a porta que você está tentando acessar.

Esperançosamente, isso poupará muitos de vocês de uma grande quantidade de depuração que está usando portas para se conectar ao registro do docker.

Isso não está resolvido no meu caso:
Desejo usar um certificado autoassinado para o repositório OSS da Nexus. Mas estou recebendo este erro: Resposta de erro do daemon: Get https: //: 10250 / v1 / users /: x509: certificado assinado por autoridade desconhecida

Coloquei o arquivo .crt em /etc/docker/certs.d bem como / usr / share / ca-Certificados em minha máquina ubuntu 16.04 om intel. Eu executei o update-ca-certificates e reiniciei o docker. este é o meu arquivo cert nexus.cert:
$ openssl x509 -in nexus.crt -text

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=IN, ST=State, L=City, O=XYZ, OU=x, CN=<mydomain.com>
        Validity
            Not Before: Jul 17 20:28:26 2017 GMT
            Not After : Jul 17 20:28:26 2018 GMT
        Subject: C=IN, ST=State, L=City, O=XYZ, OU=x, CN=<mydomain.com>
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:b8:2c:97:c2:e4:bf:7a:e1:49:22:9b:a2:90:7a:
                    3a:de:3d:d3:f5:e9:c9:8b:9b:c8:13:37:4b:36:32:
                    4f:a7:0d:b9:53:4c:f4:10:fa:e7:d2:64:a5:e9:0a:
                    32:49:c3:aa:f8:2c:27:82:94:85:c3:11:07:a7:d0:
                    6c:0a:4a:45:66:94:cb:d3:27:28:cd:58:43:5b:f9:
                    e1:66:97:52:81:be:03:53:d5:e1:84:0c:4f:89:fd:
                    78:6d:8f:88:cf:29:af:6d:14:2e:2e:dc:d4:f3:87:
                    1c:73:5e:35:cb:d2:95:58:20:55:c0:f5:89:e1:40:
                    64:16:cd:25:a8:bd:6b:6a:9c:21:b0:97:d2:67:63:
                    5c:3c:4a:2c:21:1a:72:3a:68:c6:a0:e2:ea:4d:f8:
                    db:bd:02:81:93:db:60:51:ad:6e:bf:d7:7d:45:43:
                    95:e1:a5:d7:de:36:76:7c:a4:d7:4a:7f:b2:b1:98:
                    75:7d:27:2c:1d:ad:03:1b:5f:8a:ac:12:5e:76:9c:
                    2a:f7:03:b0:51:6c:23:a4:df:08:1f:02:0c:42:b6:
                    ff:7f:33:16:b0:86:fc:92:e7:db:7a:3b:a2:70:30:
                    f4:79:fa:f1:0f:75:0f:32:69:79:97:73:f4:de:11:
                    3e:bf:f8:63:49:21:dc:02:c6:ef:de:91:74:03:6d:
                    21:56:2e:c6:04:d1:02:30:73:6e:52:c7:93:07:6c:
                    f9:98:ff:1c:cc:dd:da:c7:45:2e:7b:ab:04:33:fe:
                    39:6c:5d:d5:dd:46:ae:25:d6:fd:9d:01:ae:8a:e8:
                    14:18:cc:6e:64:e4:11:8a:ce:3d:30:56:6d:0c:a7:
                    83:90:6c:f5:14:36:16:39:cc:10:7a:db:35:f6:9c:
                    68:da:84:f6:9c:07:d0:3e:b7:52:54:03:75:9a:ae:
                    eb:79:b5:5f:cb:10:cf:25:08:ae:f7:b3:13:79:f4:
                    4a:98:72:08:e3:23:e2:22:a1:31:47:41:ec:a4:76:
                    42:db:1c:46:31:3c:a2:14:14:94:bf:4f:1e:1f:85:
                    a0:9c:4c:3d:af:92:7a:90:d1:ad:23:f0:ea:3e:7d:
                    b4:21:79:f9:82:3a:16:04:42:60:b8:5d:15:1c:48:
                    9b:1e:b5:9b:0d:1f:aa:56:aa:a2:1a:a5:6f:ef:ab:
                    2a:22:6d:05:19:c0:2b:dc:46:c4:c2:4a:f8:89:25:
                    fc:dc:e6:ab:7b:8a:76:de:47:a3:e2:00:0e:d7:e8:
                    bd:86:86:d3:8d:6b:56:63:bf:40:1e:31:d7:74:fe:
                    63:fc:7e:e2:9f:21:31:1d:39:2a:44:a5:56:fd:dd:
                    66:5e:c2:4f:94:c7:ee:26:89:1a:d1:6b:13:00:f6:
                    4f:72:9b
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         25:26:77:55:50:0a:66:39:5f:79:c7:5e:af:5f:54:e2:92:6f:
         62:e5:90:3a:0f:de:9b:7a:02:df:66:47:c5:71:61:91:c4:74:
         ba:0e:55:34:47:0b:72:c5:f5:27:5d:d0:d6:06:a9:f7:5c:d5:
         41:30:4c:0f:0b:3a:3c:64:13:a0:28:9b:10:92:0e:c8:eb:e8:
         0f:00:ba:54:9d:d4:7a:8c:cd:f7:91:a9:55:69:0f:9b:12:77:
         e9:f2:28:c8:cb:07:d4:ab:a4:eb:b2:3d:ae:b4:6d:7a:15:85:
         cb:07:f6:e3:6b:58:1c:26:0a:ad:d5:e6:7c:b7:e7:19:6c:d1:
         31:80:5e:cb:17:85:88:a2:6c:fc:fe:3c:28:1f:f9:87:a6:0f:
         f6:85:d2:c0:76:25:fb:52:2f:8a:99:0c:88:4e:bd:84:6b:da:
         81:b4:41:f1:bf:1c:e7:7d:93:a5:e2:d7:66:8a:63:bf:9c:c4:
         ad:ea:cb:c4:c6:7d:1f:95:35:87:60:8b:e8:23:e8:4e:36:43:
         5e:86:de:c4:35:e0:29:7a:93:90:a4:9b:c3:d1:8e:13:55:9f:
         ea:ab:52:0a:a8:a0:54:cf:f4:5e:ff:12:40:09:43:3c:e7:55:
         e7:c1:de:62:ce:21:39:f5:d3:51:7a:92:f2:b2:3c:75:8c:1f:
         bd:aa:13:63
-----BEGIN CERTIFICATE-----
MIIEPDCCAyQCAQEwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UEBhMCSU4xEjAQBgNV
BAgTCUthcm5hdGFrYTESMBAGA1UEBxMJQmFuZ2Fsb3JlMQwwCgYDVQQKEwNJQk0x
DDAKBgNVBAsTA2x0YzERMA8GA1UEAxMIbHRjeC5jb20wHhcNMTcwNzE3MjAyODI2
WhcNMTgwNzE3MjAyODI2WjBkMQswCQYDVQQGEwJJTjESMBAGA1UECAwJS2FybmF0
YWthMRIwEAYDVQQHDAlCYW5nYWxvcmUxDDAKBgNVBAoMA0lCTTEMMAoGA1UECwwD
bHRjMREwDwYDVQQDDAhsdGN4LmNvbTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
AgoCggIBALgsl8Lkv3rhSSKbopB6Ot490/XpyYubyBM3SzYyT6cNuVNM9BD659Jk
pekKMknDqvgsJ4KUhcMRB6fQbApKRWaUy9MnKM1YQ1v54WaXUoG+A1PV4YQMT4n9
eG2PiM8pr20ULi7c1POHHHNeNcvSlVggVcD1ieFAZBbNJai9a2qcIbCX0mdjXDxK
LCEacjpoxqDi6k34270CgZPbYFGtbr/XfUVDleGl1942dnyk10p/srGYdX0nLB2t
AxtfiqwSXnacKvcDsFFsI6TfCB8CDEK2/38zFrCG/JLn23o7onAw9Hn68Q91DzJp
eZdz9N4RPr/4Y0kh3ALG796RdANtIVYuxgTRAjBzblLHkwds+Zj/HMzd2sdFLnur
BDP+OWxd1d1GriXW/Z0BroroFBjMbmTkEYrOPTBWbQyng5Bs9RQ2FjnMEHrbNfac
aNqE9pwH0D63UlQDdZqu63m1X8sQzyUIrvezE3n0SphyCOMj4iKhMUdB7KR2Qtsc
RjE8ohQUlL9PHh+FoJxMPa+SepDRrSPw6j59tCF5+YI6FgRCYLhdFRxImx61mw0f
qlaqohqlb++rKiJtBRnAK9xGxMJK+Ikl/Nzmq3uKdt5Ho+IADtfovYaG041rVmO/
QB4x13T+Y/x+4p8hMR05KkSlVv3dZl7CT5TH7iaJGtFrEwD2T3KbAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBACUmd1VQCmY5X3nHXq9fVOKSb2LlkDoP3pt6At9mR8Vx
YZHEdLoOVTRHC3LF9Sdd0NYGqfdc1UEwTA8LOjxkE6AomxCSDsjr6A8AulSd1HqM
zfeRqVVpD5sSd+nyKMjLB9SrpOuyPa60bXoVhcsH9uNrWBwmCq3V5ny35xls0TGA
XssXhYiibPz+PCgf+YemD/aF0sB2JftSL4qZDIhOvYRr2oG0QfG/HOd9k6Xi12aK
Y7+cxK3qy8TGfR+VNYdgi+gj6E42Q16G3sQ14Cl6k5Ckm8PRjhNVn+qrUgqooFTP
9F7/EkAJQzznVefB3mLOITn101F6kvKyPHWMH72qE2M=
-----END CERTIFICATE-----

@abdasgupta : você pode "curl" seu repo?
Em caso afirmativo, verifique qual arquivo de certificados curl está usando e edite seu arquivo daemon.json para usar esse mesmo arquivo.
No meu caso, foi:
[ root @ localhost ] # cat /etc/docker/daemon.json
{"insecure-registries": ["registry-1.docker.io/v2:5000"],
"debug": verdadeiro,
"tlscert": "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem" <<<< ======
}

Não queria usar aquele registro inseguro .. não dá pra rodar sem ele ?? além disso, o certificado é o mesmo do repo .. cz copiei de lá.

Eu acho que você pode executar sem registros inseguros. Você pode acessar seu repo com um comando “curl”?
Atenciosamente.

De: Abhishek Dasgupta [mailto: [email protected]]
Enviado: mardi 18 juillet 2017 18:30
À: moby / moby
Cc: Frédéric Castelain; Comente
Objet: Re: [moby / moby] acessar registro privado: x509: certificado assinado por autoridade desconhecida (# 8849)

Não queria usar aquele registro inseguro .. não dá pra rodar sem ele ?? além disso, o certificado é o mesmo do repo .. cz copiei de lá.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/moby/moby/issues/8849#issuecomment-316120117 ou desative o thread https://github.com/notifications/unsubscribe-auth/ANgcLAxGE34n7fSByG0svUJry3vtTAR7ks5CGPN2

AVISO: Este e-mail (incluindo quaisquer anexos) pode conter informações que são privadas, confidenciais ou informações ou materiais legalmente privilegiados e se destina exclusivamente ao uso do (s) destinatário (s). Se você receber este e-mail por engano, exclua-o de seu sistema sem copiá-lo e notifique imediatamente o (s) remetente (s) por e-mail de resposta. Qualquer uso não autorizado ou divulgação desta mensagem é estritamente proibido. STEF não garante a integridade desta transmissão e, portanto, nunca pode ser responsabilizada se a mensagem for alterada ou falsificada, nem por qualquer vírus, interceptação ou dano ao seu sistema.

AVIS: Ce mensagem (y compris toutes pièces jointes) peut contenir des informations privées, trustielles et est pour l'usage du (es) seul (s) destinataire (s). Si vous avez reçu ce message par erreur, merci d'en avertir l'expéditeur par retour d'email immédiatement et de procéder à destruição de l'ensemble des eléments reçus, não vous ne devez garder aucune copie. Difusão direta, utilização ou cópia da mensagem ou dese renseignements qu'il contient par une personne autre que le (les) destinataire (s) désigné (s) est interdite. STEF ne garantit pas l'intégrité de cette transmissão et ne saurait être tenu responsable du message, de son contenu, de toute modificação ou falsificação, d'une interception ou de dégâts à votre system.

@abdasgupta , notei que a versão 17.03.1~ce-0~ubuntu-xenial não funciona, mas a versão 17.06.0~ce-0~ubuntu funciona.

Eu coloco um crt em /usr/local/share/ca-certificates/my-org/my-domain.crt , então faço sudo update-ca-certificates e sudo systemctl restart docker .

Você pode tentar seguir as instruções em https://docs.docker.com/v17.03/engine/security/certificates/ ? O Docker 1.13 e superior também deve ler os certificados dos padrões do sistema, caso contrário;

Um certificado personalizado é configurado criando um diretório em /etc/docker/certs.d usando o mesmo nome do host do registro (por exemplo, localhost ). Todos os arquivos *.crt são adicionados a este diretório como raízes de CA.

Depois de configurar os certificados, pode ser necessário reiniciar o daemon

Para qualquer pessoa que tenha dificuldades com a solução /etc/docker/certs.d , certifique-se de que o nome do seu diretório inclua a porta do registro. Portanto, /etc/docker/certs.d/myregistry.net:8443 .

Funcionou bem para mim no Photon OS.

Eu estava lutando com este erro até que percebi que estava nomeando o arquivo /etc/docker/certs.d/myregistry/ ca.pem em vez de /etc/docker/certs.d/myregistry/ ca.crt

Eu estava tendo o mesmo problema no Windows, até que olhei os documentos , que sugerem o uso de minha autoridade de certificação no Windows Explorer ( ca.pem renomeado como ca.crt ) e Right-Click > Install Certificate e selecione Autoridades de certificação raiz confiáveis ​​para o usuário atual. Docker reiniciado e funcionou.

em coreos, tive que editar
/etc/docker/daemon.json
{ "insecure-registries": ["registry:8443"] }
então sudo systemctl restart docker

Dica: Se você acessar seu repositório privado por meio de um proxy, poderá receber a mesma mensagem de erro, desative o proxy ou configure uma exceção (talvez NO_PROXY) para o host de registro privado.

Estou executando o docker-registry como um POD do Kubernetes no Rancher. Eu configurei uma entrada L7 e o certificado SSL está localizado lá. quando eu acesso a partir do navegador da Web, não tenho problemas com o SSL e as credenciais de login funcionam bem. mas se eu executar o comando docker login, recebo o x509: certificado assinado por autoridade desconhecida, que acredito estar tentando obter o back-end de ingresso padrão com o certificado SSL autoassinado falso. Estou reiniciando o docker no meu computador para ver se isso ajuda.

Costumava funcionar .... Fiz uma pequena alteração na minha entrada para oferecer suporte a um novo certificado SSL para dois nomes de host
depois de reiniciar o docker no meu laptop ainda é o mesmo problema :(

Oi mano .. Este problema é igual ao meu problema.
O Openshift não pode importar imagem para o repositório Nexus, a sintaxe é
oc import-image nexus- coba: 3.5 --from = 192.168.250.250: 8083 / node-nexus --confirm
erro: falha da tag mais recente: ocorreu um erro interno: Obtenha https://192.168.250.250 : 8083 / v2 /: x509: certificado assinado por autoridade desconhecida
imagestream.image.openshift.io/nexus-coba importado com erros
Esta solução apenas adiciona --insecure após --confirm.

oc import-image nexus- coba: 3.5 --from = 192.168.250.250: 8083 / node-nexus --confirm --insecure

Obrigado, isso também funcionou para mim. Etapas equivalentes no Ubuntu / Debian:

1. Copy CA cert to `/usr/local/share/ca-certificates`.

2. sudo update-ca-certificates

3. sudo service docker restart

Ainda há um bug aqui, no entanto. Os documentos dizem para instalar o certificado CA em /etc/docker/certs.d/<registry> , e claramente isso não é suficiente. Na verdade, depois de instalar o certificado globalmente, removi aquele em /etc/docker/certs.d , reiniciei o Docker e ainda funcionava.

Um grande obrigado! Eu estava fazendo exatamente o que você estava descrevendo, puxando meu cabelo da documentação oficial por estar errado ... :)

Eu não acredito! 5 anos depois, ainda é verdade, obrigado pela solução.

Obrigado, isso também funcionou para mim. Etapas equivalentes no Ubuntu / Debian:

1. Copy CA cert to `/usr/local/share/ca-certificates`.

2. sudo update-ca-certificates

3. sudo service docker restart

Ainda há um bug aqui, no entanto. Os documentos dizem para instalar o certificado CA em /etc/docker/certs.d/<registry> , e claramente isso não é suficiente. Na verdade, depois de instalar o certificado globalmente, removi aquele em /etc/docker/certs.d , reiniciei o Docker e ainda funcionava.

Isso significa que devo instalar o certificado na imagem docker do registro também no nginx?

Ícone Docker-Desktop -> Preferências -> Daemon -> "Registros inseguros", clique em + ícone
Adicione seu repo "seu-registry.com"
clique em “Aplicar e reiniciar”

image

Consulte https://forums.docker.com/t/docker-private-registry-x509-certificate-signed-by-unknown-authority/21262/6 para mais informações.

Esta página foi útil?
0 / 5 - 0 avaliações