I would like to use microk8s with private registry, but pull image is not working (I'm using self-signed cert):
root#master-1:/var/snap/microk8s/common/var/lib/containerd# microk8s.ctr --debug images pull priv.repo:5000/busybox/hellomicrok8s:latest
DEBU[0000] fetching image="priv.repo:5000/busybox/hellomicrok8s:latest"
DEBU[0000] resolving host="priv.repo:5000"
DEBU[0000] do request host="priv.repo:5000" request.header.accept="application/vnd.docker.distribution.manifest.v2+json, application/vnd.docker.distribution.manifest.list.v2+json, application/vnd.oci.image.manifest.v1+json, application/vnd.oci.image.index.v1+json, */*" request.header.user-agent=containerd/v1.3.4 request.method=HEAD url="https://priv.repo:5000/v2/busybox/hellomicrok8s/manifests/latest"
ctr: failed to resolve reference "priv.repo:5000/busybox/hellomicrok8s:latest": failed to do request: Head "https://priv.repo:5000/v2/busybox/hellomicrok8s/manifests/latest": x509: certificate signed by unknown authority
here is my containerd-template.tom:
root#master-1:/var/snap/microk8s/common/var/lib/containerd# cat /var/snap/microk8s/current/args/containerd-template.toml
version = 2
oom_score = 0
[grpc]
uid = 0
gid = 0
max_recv_message_size = 16777216
max_send_message_size = 16777216
[debug]
address = ""
uid = 0
gid = 0
[metrics]
address = "127.0.0.1:1338"
grpc_histogram = false
[cgroup]
path = ""
[plugins."io.containerd.grpc.v1.cri"]
stream_server_address = "127.0.0.1"
stream_server_port = "0"
enable_selinux = false
sandbox_image = "k8s.gcr.io/pause:3.1"
stats_collect_period = 10
enable_tls_streaming = false
max_container_log_line_size = 16384
[plugins."io.containerd.grpc.v1.cri".containerd]
snapshotter = "${SNAPSHOTTER}"
no_pivot = false
default_runtime_name = "${RUNTIME}"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v1"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia-container-runtime]
runtime_type = "io.containerd.runc.v1"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia-container-runtime.options]
BinaryName = "nvidia-container-runtime"
[plugins."io.containerd.grpc.v1.cri".cni]
bin_dir = "${SNAP}/opt/cni/bin"
conf_dir = "${SNAP_DATA}/args/cni-network"
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://registry-1.docker.io", ]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."priv.repo:5000"]
endpoint = ["https://priv.repo:5000"]
I restarted microk8s via systemctl restart snap.microk8s.daemon-containerd.service && microk8s.stop && microk8s.start.
Command docker login docker https://priv.repo:5000 is working and I can pull that image via docker pull priv.repo:5000/busybox/hellomicrok8s:latest. Do you know why it is not working?
Thanks in advance!
EDIT:
This is also set:
root#master-1:/var/snap/microk8s/common/var/lib/containerd# cat /etc/docker/daemon.json
{
"insecure-registries" : ["priv.repo:5000"]
}
EDIT1:
This is working: microk8s.ctr --debug images pull -u ???:??? --skip-verify priv.repo:5000/busybox/hellomicrok8s:latest. How should I set --skip-verify, because when I create a pod via microk8s kubectl apply -f ... still getting x509: certificate signed by unknown authority.
I added my crt file to /etc/ssl/certs (on master node) and it started working.
BTW newly added rows in containerd-template.tom file are not needed for me.
if you are using ubuntu microk8s cert-manager, you can fetch the certificate and install it like this:
Find the correct certificates name (you could have multiple)
microk8s kubectl get secrets -n cert-manager --field-selector type=kubernetes.io/tls
if the correct name is e.g. dev-da
microk8s kubectl -n cert-manager get secrets dev-ca -o jsonpath='{.data.ca\.crt}' | base64 -d > cert-manager-ca.crt
sudo cp cert-manager-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
Hereafter, you can check with curl, if the certificate is installed correctly.
And when genstart microk8s.
microk8s stop && microk8s start
I had the same issue and these commands below may fix this issue for others
openssl s_client -showcerts -connect <IP>:<PORT>< /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ca.crt
cp ca.crt /etc/ssl/certs
update-ca-certificates
Related
We have ci in docker executor with docker-dind on gitlab. Here it is:
docker-build-job:
stage: build
image: docker:20.10.6
scripts:
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.our.ru
config.toml:
[runners.docker]
image = "docker:20.10.6"
tls_verify = false
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache", "/certs/client", "/usr/share/ca-certificates:/certs"]
shm_size = 0
[[runners.docker.services]]
alias = "docker"
name = "docker:20.10.12-dind"
volumes = ["/cache", "/certs/client", "/etc/gitlab-runner/certs:/certs/ca:ro"]
command = ['/bin/sh', '-c', 'ls -alh /certs/client && dockerd-entrypoint.sh || exit']
I have following questions, help please:
There is docker:20.10.12-dind in runners.docker.services section of config.toml. As far as I understand scripts of all ci jobs will be executed inside docker-dind container, and it doesn't depend on absence of 'services: docker:19.03.12-dind' instruction in ci job. Am I right?
So, will this [[runners.docker.services]] filled section automatically execute job scripts inside dind container?
As far as I understood this command is executed in dind container:
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.our.ru
The following error appears:
Error response from daemon: Get "https://registry.our.ru/v2/": x509: certificate signed by unknown authority
I also execute this command openssl s_client -showcerts -connect registry.our.ru:443 and get response with 'Verification: OK'. I understand that all my certificates are right. I can login registry.our.ru from my gitlab-runner computer with no problem.
Tell me , please, What I do wrong.
There is following text in docker registry config file (config.yml):
auth:
token:
realm: https://gitlab.our.ru/jwt/auth
service: container_registry
issuer: omnibus-gitlab-issuer
rootcertbundle: /etc/docker/registry/ssl/gitlab-registry.crt
Do I understand correctly that $CI_BUILD_TOKEN is involved in the creation of the certificate? Where should this certificate be located in the dind container? is this certificate verified by the root certificate located at /etc/docker/registry/ssl/gitlab-registry.crt?
Thank u in advance!
Trying to add insecure registry to containerd config as below:
[plugins."io.containerd.grpc.v1.cri".cni]
bin_dir = "/opt/cni/bin"
conf_dir = "/etc/cni/net.d"
max_conf_num = 1
conf_template = ""
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://registry-1.docker.io"]
[plugin."io.containerd.grpc.v1.cri".registry.mirrors."test.http-registry.io"]
endpoint = ["http://v048011.dom600.lab:5000"]
Even after adding it to config.toml, when pulling image from the insecure registry, it fails:
sudo ctr image pull v048011.dom600.lab:5000:5000/myjenkins:latest
ctr: failed to resolve reference "v048011.dom600.lab:5000/myjenkins:latest": failed to do request: Head https://v048011.dom600.lab:5000:5000/v2/myjenkins/manifests/latest: http: server gave HTTP response to HTTPS client
In docker we could just add the insecure registry to daemon.json file and docker would pull images from it, how can i achieve the same in containerd ?
Replacing docker as runtime in k8s cluster.
ctr does not read the /etc/containerd/config.toml config file, this config is used by cri, which means kubectl or crictl would use it.
The error log http: server gave HTTP response to HTTPS client, shows that the registry is using http, but ctr is trying to connect it using https. So if you want to pull the image from http, you should add the param --plain-http with ctr like this:
$ ctr i pull --plain-http <image>
The registry config doc is here.
You should be able to pull the image with crictl, remember to restart containerd.
$ sudo crictl -r /run/containerd/containerd.sock pull <image>
# or config runntime once for all
$ sudo crictl config runtime-endpoint /run/containerd/containerd.sock
$ sudo crictl pull <image>
Config example:
# /etc/containerd/config.toml
# change <IP>:5000 to your registry url
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."<IP>:5000"]
endpoint = ["http://<IP>:5000"]
[plugins."io.containerd.grpc.v1.cri".registry.configs]
[plugins."io.containerd.grpc.v1.cri".registry.configs."<IP>:5000".tls]
insecure_skip_verify = true
Restart the service after configuration modification.
$ sudo systemctl restart containerd
Adding the following config:
[plugins."io.containerd.grpc.v1.cri".cni]
bin_dir = "/opt/cni/bin"
conf_dir = "/etc/cni/net.d"
max_conf_num = 1
conf_template = ""
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://registry-1.docker.io"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."test.http-registry.io"]
endpoint = ["http://v048011.dom600.lab:5000"]
[plugins."io.containerd.grpc.v1.cri".registry.configs]
[plugins."io.containerd.grpc.v1.cri".registry.configs."test.http-registry.io".tls]
insecure_skip_verify = true
should skip TLS verification for the test registry. See also the documentation on registry TLS communication configuration.
Edit: Please note the "s" in plugins, there is a typo in your configuration.
NOTE: Be sure to restart containerd aferwards:
$ sudo systemctl restart containerd
In my case, I simply added [[registry]] field into /etc/containers/registries.conf file simply because I was using crio
[[registry]]
insecure = true
location = "IP ADDRESS"
and restart crio
systemctl restart crio.service
Please refer
https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md
I've configured a docker w rabbitmq, copied the certs from tls-gen there, stop/started and I can only get the connection established and a server reset right after sending a TLS Client Hello. No useful message from ssl. Logs all empty. Troubleshoot TLS guide didn't help. Thanks for any help.
docker run -d -it --hostname=[REDACTED] -e RABBITMQ_LOGS=/var/log/rabbitmq/ -e RABBITMQ_SASL_LOGS=/var/log/rabbitmq/ -e RABBITMQ_DEFAULT_USER=[REDACTED] -e RABBITMQ_DEFAULT_PASS=[REDACTED] --name rabbitmq1 -p [REDACTED]:5672 -p [REDACTED]:15672 -v /scratch/databases/rabbitmq/var/lib/rabbitmq:/var/lib/rabbitmq rabbitmq:3-management
docker cp tls-gen/basic/result/ca_certificate.pem rabbitmq1:/etc/rabbitmq/
docker cp tls-gen/basic/result/server_key.pem rabbitmq1:/etc/rabbitmq/
docker cp tls-gen/basic/result/server_certificate.pem rabbitmq1:/etc/rabbitmq/
docker exec -it rabbitmq1 /bin/bash -c "cd /etc/rabbitmq;chown rabbitmq:rabbitmq *.pem"
docker cp rabbitmq.conf rabbitmq1:/etc/rabbitmq/
docker exec -it rabbitmq1 /bin/bash -c "cd /etc/rabbitmq;chown rabbitmq:rabbitmq rabbitmq.conf"
I was sure to restart the container so the changes were applied. Also double checked cert permissions.
docker:/etc/rabbitmq/
-rw-rw-r--. 1 rabbitmq rabbitmq 1.2K Nov 22 02:29 ca_certificate.pem
drwxrwxrwx. 1 rabbitmq rabbitmq 61 Nov 6 01:51 conf.d
-rw-r--r--. 1 root root 71 Nov 22 07:34 enabled_plugins
-rw-r--r--. 1 rabbitmq rabbitmq 578 Nov 22 07:34 rabbitmq.conf
-rw-rw-r--. 1 rabbitmq rabbitmq 1.3K Nov 22 02:29 server_certificate.pem
-rw-------. 1 rabbitmq rabbitmq 1.9K Nov 22 02:29 server_key.pem
Redirected logs here knowing that the container start env variables should overide. Either way, logs seemed empty.
/etc/rabbitmq/rabbitmq.conf
loopback_users.guest = false
# listeners.tcp.default = 5672
management.tcp.port = 15672
listeners.tcp = none
listeners.ssl.default = 5671
ssl_options.cacertfile = /etc/rabbitmq/ca_certificate.pem
ssl_options.certfile = /etc/rabbitmq/server_certificate.pem
ssl_options.keyfile = /etc/rabbitmq/server_key.pem
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = false
ssl_options.password = [REDACTED]
log.dir = /tmp/
log.file = r.log
log.file.level = debug
Tried multiple configurations for context.options to no avail.
receive.py (python)
#!/usr/bin/env python
import ssl, pika, sys, os
import traceback
from pika.credentials import ExternalCredentials
def main():
connection = None
credentials = pika.PlainCredentials('[REDACTED]', '[REDACTED]')
context = ssl.create_default_context(cafile="tls-gen/basic/result/ca_certificate.pem")
context.load_cert_chain("tls-gen/basic/result/client_certificate.pem", "tls-gen/basic/result/client_key.pem")
#context.options = dict(ssl_version=ssl.PROTOCOL_TLSv1, cert_reqs=ssl.CERT_REQUIRED)
ssl_options = pika.SSLOptions(context, "[REDACTED]")
#ssl_options = pika.SSLOptions(ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT), "local")
#ssl_options = pika.SSLOptions(ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER), "localhost")
#ssl_options = ssl_options | pika.SSLOptions(ssl.SSLContext(ssl.PROTOCOL_TLSv1_2), "[REDACTED]")
try:
connection = pika.BlockingConnection(pika.ConnectionParameters(host='[REDACTED]',
port=[REDACTED],
virtual_host='/',
ssl_options = ssl_options)),
credentials=credentials))
#credentials=ExternalCredentials()))
except Exception as e:
exc_type, _, exc_tb = sys.exc_info()
fname = os.path.split(exc_tb.tb_frame.f_code.co_filename)[1]
print("receive: ({0}) {1} {2} {3}".format(str(e), exc_type, fname, exc_tb.tb_lineno))
traceback.print_exc()
sys.exit(1)
channel = connection.channel()
channel.queue_declare(queue='hello')
def callback(ch, method, properties, body):
print(" [x] Received %r" % body)
channel.basic_consume(queue='hello', on_message_callback=callback, auto_ack=True)
print(' [*] Waiting for messages. To exit press CTRL+C')
channel.start_consuming()
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
print('Interrupted')
try:
sys.exit(0)
except SystemExit:
os._exit(0)
A wrong PEM password here generates a very different message, I'm sure I'm using the right one.
python3 receive.py
Enter PEM pass phrase:
receive: ([Errno 104] Connection reset by peer) <class 'ConnectionResetError'> receive.py 18
Traceback (most recent call last):
File "receive.py", line 18, in main
connection = pika.BlockingConnection(pika.ConnectionParameters(host='[REDACTED]',
File "[REDACTED]/rabbitmq/pika/venv/lib/python3.8/site-packages/pika/adapters/blocking_connection.py", line 359, in __init__
self._impl = self._create_connection(parameters, _impl_class)
File "[REDACTED]/rabbitmq/pika/venv/lib/python3.8/site-packages/pika/adapters/blocking_connection.py", line 450, in _create_connection
raise self._reap_last_connection_workflow_error(error)
File "[REDACTED]/rabbitmq/pika/venv/lib/python3.8/site-packages/pika/adapters/utils/io_services_utils.py", line 636, in _do_ssl_handshake
self._sock.do_handshake()
File "/usr/local/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ConnectionResetError: [Errno 104] Connection reset by peer
It looks like openssl likes the connection.
openssl s_client -connect localhost:5671
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = TLSGenSelfSignedtRootCA, L = $$$$
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=0 CN = [REDACTED], O = server
verify return:1
---
Certificate chain
0 s:CN = [REDACTED], O = server
i:CN = TLSGenSelfSignedtRootCA, L = $$$$
1 s:CN = TLSGenSelfSignedtRootCA, L = $$$$
i:CN = TLSGenSelfSignedtRootCA, L = $$$$
---
Server certificate
-----BEGIN CERTIFICATE-----
[REDACTED]
-----END CERTIFICATE-----
subject=CN = [REDACTED], O = server
issuer=CN = TLSGenSelfSignedtRootCA, L = $$$$
---
Acceptable client certificate CA names
CN = TLSGenSelfSignedtRootCA, L = $$$$
Client Certificate Types: ECDSA sign, RSA sign, DSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2338 bytes and written 431 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: [REDACTED]
Session-ID-ctx:
Master-Key: [REDACTED]
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1606031943
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Extended master secret: no
---
closed
here the steps I took to fix this:
Get rid of the docker and install a local rabbitmq on mac for debugging this configuration. For some reason, the rabbitmq docker wasn't logging anything;
I've added a real valid letsencrypt certificate to the server;
first error I saw in the client after that was the following:
ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:1076)
This is because verify_peer is enabled, in that case we needed to bundle the ca_certificate.pem from tls-gen/basic/result/ca_certificate.pem to the chain.pem
cat ../tls-gen/basic/result/ca_certificate.pem chain.pem > chain_bundle.pem
rabbitmq.conf
...
ssl_options.cacertfile = /usr/local/etc/rabbitmq/chain_bundle.pem # <- bundled w self signed cert
ssl_options.certfile = /usr/local/etc/rabbitmq/cert.pem
ssl_options.keyfile = /usr/local/etc/rabbitmq/privkey.pem
...
after that, a different error on pika showed:
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)
That's because pika didn't like tls-gen/basic/result/ca_certificate.pem, instead, I used venv//lib/python3.7/site-packages/certifi/cacert.pem after installing pip install certifi.
Later on, I bundled tls-gen/basic/result/ca_certificate.pem + venv//lib/python3.7/site-packages/certifi/cacert.pem, and added a password to context.load_cert_chain
Wireshark shows messages fully encrypted, now I just need to deploy.
EDIT:
I was able to run it via docker after re-trying the configuration that worked:
#/bin/bash
docker run -d -it --hostname=\
-e RABBITMQ_LOGS=/tmp/log\
-e RABBITMQ_DEFAULT_USER=\
-e RABBITMQ_DEFAULT_PASS=\
-e RABBITMQ_SSL_CACERTFILE=/cert/chain_bundle2.pem \
-e RABBITMQ_SSL_CERTFILE=/cert/cert.pem\
-e RABBITMQ_SSL_KEYFILE=/cert/privkey.pem\
-e RABBITMQ_SSL_FAIL_IF_NO_PEER_CERT=true\
-e RABBITMQ_SSL_VERIFY=verify_peer\
--name rabbitmq1-verifypeer -p ... :5671 -p ... :15672\
-v ... /rabbitmq/var/log:/tmp/log\
-v ... /rabbitmq/var/lib/rabbitmq:/var/lib/rabbitmq\
-v ... /cert/:/cert/ rabbitmq:3.8.9-management
Installed the lxc container via lxc-create:
sudo lxc-create -t download -n dos1
I chose debian buster arm64 and run it:
sudo lxc-start -n dos1 -d
Outputs an error:
lxc-start: dos1: tools/lxc_start.c: main: 290 No container config specified
What is the problem? Am I doing something wrong?
PS: configs are configured /etc/lxc/default.conf:
lxc.net.0.type = veth
lxc.net.0.link = virbr0
lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
~/.config/lxc/default.conf:
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536
UPD
The problem is solved. You had to specify the path to the configuration file directly. For example:
sudo lxc-start -n dos1 -f /var/lib/lxc/dos1/config -d
Then all lxc-* commands must be executed with sudo
I got this error because I didn’t specify sudo. Without root permissions, lxc-start couldn’t find and read the container config to start it.
I'm trying to push an image to my docker private repository:
docker pull busybox
docker tag busybox living-registry.com:5000/busybox
docker push living-registry.com:5000/busybox
Docker tells me:
The push refers to a repository [living-registry.com:5000/busybox]
Get https://living-registry.com:5000/v1/_ping: read tcp 195.83.122.16:39714->195.83.122.16:5000: read: connection reset by peer
These commands are being performed on a CoreOS.
In another machine, I've started my registry using this command:
docker run -d -p 5000:5000 --restart=always --name registry \
-v /root/docker-registry/auth:/auth \
-e "REGISTRY_AUTH=htpasswd" \
-e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
-e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
-v /root/docker-registry/certs:/certs \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/registry.key \
-v /root/docker-registry/data:/var/lib/registry \
registry:2
Everything seems to be right:
# netstat -tupln | grep 5000
tcp6 0 0 :::5000 :::* LISTEN 3160/docker-proxy
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
27e79f6a504c registry:2 "/bin/registry serve " About an hour ago Restarting (2) 36 minutes ago 0.0.0.0:5000->5000/tcp registry
So, when I'm trying to log in:
[root#jenkins certs]# docker login living-registry.com:5000
Username: xxxx
Password: xxxx
Error response from daemon: Get https://living-registry.com:5000/v1/users/: read tcp 195.83.122.16:39756->195.83.122.16:5000: read: connection reset by peer
Any ideas?
EDIT
I've already added the certificate (ca.crt) in /etc/ssl/certs and in /etc/docker/certs.d/x.x.x.x:5000/.
From this CoreOS instance, I'm trying to perform that:
$ docker login https://x.x.x.x:5000
Username: xxx
Password:
Email: xxx#mail.com
And it tells me:
Error response from daemon: invalid registry endpoint https://x.x.x.x:5000/v0/: unable to ping registry endpoint https://x.x.x.x:5000/v0/
v2 ping attempt failed with error: Get https://x.x.x.x:5000/v2/: EOF
v1 ping attempt failed with error: Get https://x.x.x.x:5000/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add --insecure-registry x.x.x.x:5000 to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/x.x.x.x:5000/ca.crt
I've also tried to get the connection directly with openssl:
openssl s_client -connect x.x.x.x:5000
The output is:
CONNECTED(00000003)
140180300502672:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1467812448
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
For self-signed certificates, the crt must be copied into
/etc/docker/cert.d/hostname:port/ca.crt
cf : https://docs.docker.com/engine/security/certificates/
I create certificates :
openssl req -x509 -nodes -days 3650d -newkey rsa:2048 -keyout /root/docker-registry/certs/registry.key -out /root/docker-registry/certs/registry.crt -days 3650d
cp /root/docker-registry/certs/registry.crt /etc/docker/cert.d/x.x.x.x:5000/ca.crt