Moby: Zugriff auf private Registry: x509: Zertifikat von unbekannter Autorität signiert

Erstellt am 30. Okt. 2014  ·  39Kommentare  ·  Quelle: moby/moby

Ich Setup Docker-Registry mit nginx , indem Sie hier .

Ich führe 'docker login' aus und erhalte diese Fehlermeldung:

# 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

Ausgabe des Docker-Daemons:

[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

Ich habe den Code überprüft. Ich denke, die Funktion Login benötigt möglicherweise 'tlsConfig'
https://github.com/docker/docker/blob/master/registry/auth.go#L163

so wie
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.

Hilfreichster Kommentar

Danke, das hat bei mir auch funktioniert. Äquivalente Schritte unter Ubuntu/Debian:

  1. Kopieren Sie das CA-Zertifikat nach /usr/local/share/ca-certificates .
  2. sudo update-ca-zertifikate
  3. sudo service docker neu starten

Hier liegt aber noch ein Bug vor. In der Dokumentation steht, das CA-Zertifikat in /etc/docker/certs.d/<registry> zu installieren, und das ist eindeutig nicht ausreichend. Tatsächlich habe ich nach der globalen Installation des Zertifikats das Zertifikat in /etc/docker/certs.d , Docker neu gestartet und es funktionierte immer noch.

Alle 39 Kommentare

@hustcat Ab Docker 1.3.1 können Sie --insecure-registry dev.registry.com:5000 tun, Sie können 5000 durch den Port ersetzen, auf dem Ihre Registrierung lauscht.

Ich schließe das jetzt, aber lass es uns in den Kommentaren wissen, wenn dies dein Problem nicht gelöst hat.

Ich lasse das hier, weil ich ein paar Minuten gebraucht habe, um es herauszufinden, und könnte jemandem die Zeit sparen. Der Befehl wäre:

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

Vielen Dank für die Umstellung auf 1.3!

Ich stehe vor dem gleichen Problem. Die Zertifikatsvalidierung funktioniert für den Ping (und Push/Pull), aber nicht für die Anmeldung.

Das Flag --insecure-registry ist ein Workaround, kein Fix. Die Zertifikatsvalidierung sollte funktionieren, wenn das CA-Zertifikat in /etc/docker/certs.d/<registry> geladen wird, tut es aber nicht.

Ich kann es nicht zum Laufen bringen, indem ich --insecure-registry setze Ich bin auf Docker 1.3.2 auf RedHat 7

[ root@ip-10-2-20-209 ec2-user]# docker --insecure-registry=qa.docker.repo Login https://qa.docker.repo
Benutzername: qa
Passwort:
E-Mail: [email protected]
19.01.2015 14:26:40 Fehlerantwort vom Daemon: Serverfehler : Post

curl funktioniert gut, wenn ich die generierte ca.pem-Datei verwende.

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

Ich habe das gleiche Problem mit Docker-Version 1.3.2 und Openuse 13.1. Ich habe sogar versucht, --cafile cacert.pem statisch an jeden curl-Aufruf zu übergeben (da ich davon ausgegangen bin, dass docker intern nur curl verwendet), hat dies jedoch auch nicht geholfen.

Jede Hilfe wäre sehr dankbar.

Vielen Dank.
Mario

Bevor ich dieses Problem gefunden habe, habe ich #10150 geöffnet. Sie scheinen das gleiche Problem zu sein.

Ich scheine das gleiche Problem zu haben. Archlinux-Client 1.4.1 und die Registrierung, die vom offiziellen Docker-Container ausgeführt wird. Hat jemand irgendwelche Gedanken?

Wenn Sie das Zertifikat global (über CA-Zertifikate) installiert haben, stellen Sie sicher, dass Sie Docker neu starten, da es die globalen SSL-Zertifikate nicht neu lädt. Das heißt, meiner funktioniert immer noch nicht, aber ich bin bei der Arbeit darauf gestoßen :)

Danke Grimmy, das hat bei mir geholfen und es funktioniert endlich. Ich tat:

  1. Holen Sie sich cacert.pem von http://curl.haxx.se/docs/caextract.html
  2. Kopieren Sie die Datei cacert.pem nach /etc/pki/trust/anchors/
  3. sudo update-ca-zertifikate
  4. sudo systemctl docker stop
  5. sudo systemctl docker start

Mario

Danke, das hat bei mir auch funktioniert. Äquivalente Schritte unter Ubuntu/Debian:

  1. Kopieren Sie das CA-Zertifikat nach /usr/local/share/ca-certificates .
  2. sudo update-ca-zertifikate
  3. sudo service docker neu starten

Hier liegt aber noch ein Bug vor. In der Dokumentation steht, das CA-Zertifikat in /etc/docker/certs.d/<registry> zu installieren, und das ist eindeutig nicht ausreichend. Tatsächlich habe ich nach der globalen Installation des Zertifikats das Zertifikat in /etc/docker/certs.d , Docker neu gestartet und es funktionierte immer noch.

+1 für die Wiedereröffnung, wie @rhasselbaum erwähnte

Ist --insecure-registry verschwunden?

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

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

Was sollen wir jetzt verwenden?

Das geht in die Docker-Konfigurationsdatei. Sie können überprüfen, ob sie festgelegt ist, indem Sie sich ansehen
Im Docker-Prozess sollten Sie das Flag --insecure-registry sehen

Am Mittwoch, 16. September 2015 um 03:01 Uhr, Chris Withers [email protected]
schrieb:

Ist --insecure-registry verschwunden?

$ docker --version
Docker-Version 1.8.2, Build 0a8c2e3

$ docker --insecure-registry
Flag bereitgestellt, aber nicht definiert: --insecure-registry
Siehe 'docker --help'.

Was sollen wir jetzt verwenden?


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/8849#issuecomment -140693481.

Ich habe den gleichen Fehler für den Docker-Pull-Befehl erhalten und denke, dass Folgendes funktionieren sollte.
Kopieren Sie das SSL-Zertifikat, das die Datei '.crt' ist, in das Verzeichnis

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt
Lassen Sie Ubuntu den Pfad der '.crt'-Datei relativ zu /usr/share/ca-certificates zu /etc/ca-certificates.conf hinzufügen

sudo dpkg-reconfigure CA-Zertifikate

Wenn Ihr Maschinenstatus nicht wichtig ist, können Sie docker-machine rm <machine-name> ausführen und einen anderen erstellen ;)

Wenn Sie LetsEncrypt verwenden und nichts ohne richtiges TLS ausführen möchten, stellen Sie sicher, dass Sie die vollständige Kette des Zertifikats einschließlich der Zwischenstufen angeben (dh REGISTRY_HTTP_TLS_CERTIFICATE=.../fullchain.pem). dieser Fehler von Docker.

Danke schön!

Auf Ubuntu. Wenn ein Fehler auftritt:

  • x509: Zertifikat für [IP-Adresse oder Domänenname] kann nicht validiert werden, da es keine IP-SANs enthält

Auf der Docker-Registry musste das Zertifikat mit dem subjectAltName wie hier beschrieben kompiliert werden:
https://docs.docker.com/engine/security/https/

Hier ist der Code zur Vereinfachung:
$ 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

Beachten Sie, dass ich mit dem folgenden Befehl überprüfen konnte, ob der alternative Antragstellername im Zertifikat vorhanden ist:
openssl x509 -in certificate.crt -text -noout

Allerdings auf dem Ubuntu 14-Client (dh Docker Engine)
Dieser Fehler wurde gefolgt von
x509: Zertifikat von unbekannter Autorität signiert

Für Leute, die Ubuntu 14 verwenden.
Die Konfigurationsdatei, die für die Docker-Engine verwendet wird (die ich verwenden möchte, um eine Verbindung zur Docker-Registrierung herzustellen):
/etc/default/docker

Darin müssen Sie die Docker-Optionen angeben:
DOCKER_OPTS = "- unsicher-Registry myinsecure. Com: 5000 "

Starten Sie dann den Daemon neu (fügen Sie sudo hinzu, wenn Ihr Benutzer keinen Docker-Dienst starten darf):
$ [sudo] Service Docker Neustart

Der Wert muss kein Domänenname sein, er muss einfach mit dem übereinstimmen, mit dem Ihr Zertifikat registriert ist; Ich habe eine IP-Adresse mit Port und das funktioniert... (zB 100.100.100.100:100)

Das alles hat mich einen Tag gekostet, also poste ich das in der Hoffnung, dass es für andere nützlich ist...

@JazzDeben Danke für deine Anmerkungen! sehr hilfreich ! Ich bin mir nicht sicher, wie man es mit einem von Let's Encript certbot generierten Zertifikat macht.
Ich bekomme diesen Fehler im Registrierungsserver

tls: client didn't provide a certificate

Chrome beschwert sich über ERR_BAD_SSL_CLIENT_AUTH_CERT
wenn ich einschließe

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

@cjw296 Für RHEL7.2 habe ich die Datei /usr/lib/systemd/docker.service bearbeitet und in der Zeile ExecStart --insecure-registry=your.docker.registry.com hinzugefügt.

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

Dann habe ich sudo systemctl daemon-reload , um die Konfigurationsänderung aufzunehmen, gefolgt von sudo systemctl restart docker . Und jetzt funktioniert es.

Um ehrlich zu sein, bin ich immer noch ein System-Noob und es gibt wahrscheinlich bessere Möglichkeiten, dies sauberer zu machen. Aber ich habe zu lange damit gekämpft und wollte einen Workaround posten. Danke an @cdub50, dass du mich in die richtige Richtung geführt hast.

@david-drinn Für Fedora 25 habe ich etwas Ähnliches gemacht, aber da die Docker-Daemon-Konfiguration (in /usr/lib/systemd/system/docker.service ) das Setup aus Konfigurationsdateien bezieht, habe ich die Änderung in /etc/sysconfig/docker :

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

Wenn curl funktioniert und Docker nicht, können Sie:
o erstellen Sie die Datei "/etc/docker/certs.d/"/..." Verzeichnis & Dateien (gilt nur für private Registrys ?)
o fügen Sie einen "tlscert"-Eintrag in Ihre Datei "/etc/docker/daemon.json" ein, damit dockerd dieselben Zertifikate wie curl verwendet.

Für diejenigen, die auf dieses Problem stoßen und selbstsignierte Zertifikate haben und die Anweisung "insecure-registry" nicht verwenden möchten, müssen Sie Ihre selbstsignierten Zertifikate in /etc/docker/certs.d/{host}/ laden. Denken Sie nach dem Laden daran, den Docker-Daemon NEU ZU STARTEN. Um noch etwas näher zu erläutern.....

Wenn Ihre Registrierung unter https://exampleregistry.com gehostet wird, sollten Sie ein Verzeichnis namens /etc/docker/certs.d/exampleregistry.com mit Ihren selbstsignierten Zertifikaten haben. Jetzt können Sie docker login exampleregistry.com ohne x509-Fehler ausführen.
Nun, hier ist ein Vorbehalt zu all dem, nehmen wir an, Sie möchten aus irgendeinem Grund den Port explizit in Ihrem Login-Befehl wie folgt definieren docker login exampleregistry.com:443 (was keinen Sinn machen würde, aber dies ist nur ein Beispiel), dann brauchen Sie um sicherzustellen, dass sich Ihre selbstsignierten Zertifikate in einem Ordner namens /etc/docker/certs.d/exampleregistry.com:443/ . Docker macht keine Annahmen über die Auflösung von Zertifikaten basierend auf dem Hostnamen, nur wenn ein Port verwendet wird. Sie müssen Zertifikate tatsächlich pro Port bereitstellen, indem Sie Ihre selbstsignierten Zertifikate in einen Ordnernamen laden, der den Port enthält, auf den Sie zugreifen möchten.

Hoffentlich erspart dies vielen von Ihnen eine Menge Debugging, die Ports verwenden, um sich mit Ihrer Docker-Registrierung zu verbinden.

Dies ist in meinem Fall nicht gelöst:
Ich möchte ein selbstsigniertes Zertifikat für das Nexus OSS-Repository verwenden. Aber ich erhalte diesen Fehler: Fehlerantwort vom Daemon: Get https://:10250/v1/users/: x509: Zertifikat von unbekannter Autorität signiert

Ich habe die .crt-Datei in /etc/docker/certs.d sowie /usr/share/ca-certificates auf meinem Intel-Computer mit Ubuntu 16.04 platziert. Ich habe dann update-ca-certificates ausgeführt und Docker neu gestartet. das ist meine cert-Datei 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 :
Überprüfen Sie in diesem Fall, welche Zertifikatsdatei curl verwendet, und bearbeiten Sie Ihre Datei daemon.json, um dieselbe Datei zu verwenden.
In meinem Fall war es:
[ root@localhost ]# cat /etc/docker/daemon.json
{ "insecure-registries":["registry-1.docker.io/v2:5000"],
"debug":wahr,
"tlscert": "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem" <<<<======
}

Ich wollte diese unsicheren Registrys nicht verwenden.. geht das nicht ohne?? Außerdem ist das Zertifikat das gleiche wie das Repos. cz Ich habe es von dort kopiert.

Ich denke, Sie können ohne unsichere Registrierungen ausführen. Können Sie Ihr Repo mit einem „curl“-Befehl erreichen?
Mit freundlichen Grüßen.

De : Abhishek Dasgupta [mailto:[email protected]]
Gesandter: Mardi 18. Juli 2017 18:30
À : moby/moby
Cc: Frédéric Castelain; Kommentar
Objekt: Betreff: [moby/moby] Zugriff auf private Registry: x509: Zertifikat von unbekannter Autorität signiert (#8849)

Ich wollte diese unsicheren Registrys nicht verwenden.. geht das nicht ohne?? Außerdem ist das Zertifikat das gleiche wie das Repos. cz Ich habe es von dort kopiert.


Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/moby/moby/issues/8849#issuecomment-316120117 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ANgcLAxGE34n7fSByG0svUJry3vtTAR7ks5sPN2C0Jspv .

HINWEIS: Diese E-Mail (einschließlich aller Anhänge) kann Informationen enthalten, die private, vertrauliche oder rechtlich geschützte Informationen oder Materialien sind und ausschließlich für den/die Adressaten bestimmt sind. Sollten Sie diese E-Mail irrtümlicherweise erhalten, löschen Sie diese bitte ohne Kopieren von Ihrem System und benachrichtigen Sie den/die Absender umgehend per Antwort-E-Mail. Jede unbefugte Verwendung oder Weitergabe dieser Nachricht ist strengstens untersagt. STEF garantiert nicht die Integrität dieser Übertragung und kann daher niemals haftbar gemacht werden, wenn die Nachricht verändert oder verfälscht wird, noch für Viren, Abfangen oder Schäden an Ihrem System.

AVIS : Ce-Nachricht (y compris toutes pièces jointes) für vertrauliche und vertrauliche Informationen und für die Verwendung von seul(s) destinataire(s). Sie haben eine Nachricht ohne Fehler, eine schnelle Antwort auf eine sofortige E-Mail-Rücksendung und ein Verfahren zur Zerstörung des Ensembles der Elemente, ohne eine Kopie zu erstellen. Verbreitung, Nutzung oder Kopie der Nachricht oder des Wiedererscheinens des Inhalts einer une personne autre que le(les) destinataire(s) désigné(s) est interdite. STEF ne Garantit pas l'intégrité de cette Transmission and ne saurait être tenu responsable du message, de son contenu, de toute modification or falsification, d'une interception ou de dégâts à votre système.

@abdasgupta , mir ist aufgefallen, dass die Version 17.03.1~ce-0~ubuntu-xenial nicht funktioniert, aber die Version 17.06.0~ce-0~ubuntu funktioniert.

Ich platziere einen crt in /usr/local/share/ca-certificates/my-org/my-domain.crt , dann mache ich sudo update-ca-certificates und sudo systemctl restart docker .

Können Sie versuchen, den Anweisungen in https://docs.docker.com/v17.03/engine/security/certificates/ zu folgen? Docker 1.13 und höher sollte ansonsten auch Zertifikate aus den Systemstandardeinstellungen lesen;

Ein benutzerdefiniertes Zertifikat wird konfiguriert, indem ein Verzeichnis unter /etc/docker/certs.d , das denselben Namen wie den Hostnamen der Registrierung verwendet (zB localhost ). Alle *.crt Dateien werden diesem Verzeichnis als CA-Roots hinzugefügt.

Nach der Konfiguration der Zertifikate kann es erforderlich sein, den Daemon neu zu starten

Für jeden, der mit der /etc/docker/certs.d Lösung zu kämpfen hat, stellen Sie sicher, dass Ihr Verzeichnisname darunter den Registrierungsport enthält. Also /etc/docker/certs.d/myregistry.net:8443 .

Hat bei mir mit Photon OS gut funktioniert.

Ich hatte mit diesem Fehler zu kämpfen, bis ich dachte, dass ich die Datei /etc/docker/certs.d/myregistry/ ca.pem statt /etc/docker/certs.d/myregistry/ ca.crt nenne

Ich hatte das gleiche Problem unter Windows, bis ich mir die Dokumentation ansah, die vorschlägt, meine Zertifizierungsstelle im Windows Explorer ( ca.pem umbenannt in ca.crt ) und Right-Click > Install Certificate und auszuwählen Vertrauenswürdige Stammzertifizierungsstellen für den aktuellen Benutzer. Docker neu gestartet und es hat funktioniert.

in coreos musste ich bearbeiten
/etc/docker/daemon.json
{ "insecure-registries": ["registry:8443"] }
dann sudo systemctl restart docker

Hinweis: Wenn Sie Ihr privates Repository über einen Proxy erreichen, können Sie dieselbe Fehlermeldung erhalten, den Proxy deaktivieren oder eine Ausnahme (evtl. NO_PROXY) für den privaten Registrierungshost konfigurieren.

Ich betreibe docker-registry als Kubernetes POD auf Rancher. Ich habe einen L7 Ingress konfiguriert und das SSL-Zertifikat befindet sich dort. Wenn ich über einen Webbrowser darauf zugreife, habe ich kein Problem mit SSL, und die Anmeldeinformationen funktionieren einwandfrei. aber wenn ich den Docker-Login-Befehl ausführe, erhalte ich das x509:-Zertifikat, das von einer unbekannten Autorität signiert wurde, von der ich glaube, dass sie versucht, das Standard-Ingress-Backend mit dem gefälschten selbstsignierten SSL-Zertifikat zu erhalten. Ich starte Docker auf meinem Computer neu, um zu sehen, ob das hilft.

Früher hat es funktioniert.... Ich habe an meinem Ingress eine kleine Änderung vorgenommen, um ein neues SSL-Zertifikat für zwei Hostnamen zu unterstützen
Nach dem Neustart von Docker auf meinem Laptop immer noch das gleiche Problem :(

Hallo Bro.. Dieses Problem ist das gleiche wie bei meinem Problem.
Openshift kann kein Image für das Nexus-Repository importieren, die Sintax ist
oc import-image nexus- coba:3.5 --from=192.168.250.250:8083/node-nexus --confirm
error: tag last failed: Interner Fehler ist aufgetreten: https://192.168.250.250 :8083/v2/: x509: Zertifikat von unbekannter Autorität signiert abrufen
imagestream.image.openshift.io/nexus-coba importiert mit Fehlern
Diese Lösung fügt nur --insecure nach --confirm hinzu.

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

Danke, das hat bei mir auch funktioniert. Äquivalente Schritte unter Ubuntu/Debian:

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

2. sudo update-ca-certificates

3. sudo service docker restart

Hier liegt aber noch ein Bug vor. In der Dokumentation steht, das CA-Zertifikat in /etc/docker/certs.d/<registry> zu installieren, und das ist eindeutig nicht ausreichend. Tatsächlich habe ich nach der globalen Installation des Zertifikats das Zertifikat in /etc/docker/certs.d , Docker neu gestartet und es funktionierte immer noch.

So ein großes Dankeschön! Ich habe genau das getan, was Sie beschrieben haben, und meine Haare aus der offiziellen Dokumentation gezogen, was falsch war ... :)

Ich glaube es nicht! 5 Jahre später immer noch wahr, danke für die Lösung.

Danke, das hat bei mir auch funktioniert. Äquivalente Schritte unter Ubuntu/Debian:

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

2. sudo update-ca-certificates

3. sudo service docker restart

Hier liegt aber noch ein Bug vor. In der Dokumentation steht, das CA-Zertifikat in /etc/docker/certs.d/<registry> zu installieren, und das ist eindeutig nicht ausreichend. Tatsächlich habe ich nach der globalen Installation des Zertifikats das Zertifikat in /etc/docker/certs.d , Docker neu gestartet und es funktionierte immer noch.

Bedeutet es, dass ich das Zertifikat im Docker-Image der Registrierung auch in der nginx installieren muss?

Docker-Desktop-Symbol -> Einstellungen -> Daemon -> "Unsichere Registrierungen", klicken Sie auf das +-Symbol
Fügen Sie Ihr Repository "your-registry.com" hinzu
Klicken Sie auf "Übernehmen und neu starten"

image

Weitere Informationen finden Sie unter https://forums.docker.com/t/docker-private-registry-x509-certificate-signed-by-unknown-authority/21262/6 .

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen