For testing purposes, I have deployed an insecure nexus registry using self-signed certificates.
-
I have created the rootCA, certificates and the signatures using this cheat-sheet.
-
I have updated the certificates in the host
root@master:~/cert2# sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
- I have added certificates to an
nginx
which acts as a proxy for thenexus
:
root@mec5g:~/minidevops# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
NAMES
720b50c77f24 nginx:1.18.0 "/docker-entrypoint.…" 47 minutes ago Up 47 minutes 80/tcp, 0.0.0.0:5000->5000/tcp, :::5000->5000/tcp, 0.0.0.0:8585->8081/tcp, :::8585->8081/tcp, 0.0.0.0:8586->8082/tcp, :::8586->8082/tcp minidevops_nginx_1
e6712602b614 sonatype/nexus3:3.37.0 "sh -c ${SONATYPE_DI…" 47 minutes ago Up 47 minutes 0.0.0.0:32768->8081/tcp, :::32768->8081/tcp
minidevops_nexus_1
- The
nexus
runs properly ashelm repository
anddocker registry
:
- The certificates are added to
ArgoCD
:
- The
helm repository
is included:
- The application is deployed:
However, the "certificate signed by unknown authority" error, persists.
Any leads?
Note this issue is related to the other one published but is not the same: questions/75898641
Update 2023-04-01
I have followed the steps recommended but error persists:
-
I have converted pem to crt extension:
openssl x509 -outform der -in ca-cert.pem -out ca-cert.crt
-
I have also update the ca-certificates:
usuario@mec5g:~/cert3$ sudo dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
rehash: warning: skipping ca-cert.pem,it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Processing triggers for ca-certificates (20211016ubuntu0.20.04.1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
- I have tried to test certificates and I got this answer (I have deleted the rest of the cryptographic material):
root@master:~/cert3# openssl s_client -connect 10.63.27.49:8585 -showcerts </dev/null
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN = 10.63.27.49
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = 10.63.27.49
verify error:num=21:unable to verify the first certificate
verify return:1
...
...
...
Update 2023-04-02.1
- I have followed the recommendations in the docker documentation about using self-signed certificates:
sudo mkdir -p /etc/docker/certs.d/10.63.27.49:6000/
sudo cp ca-cert.crt /etc/docker/certs.d/10.63.27.49:6000/ca.crt
- I am able now to docker login in the nexus registry:
usuario@mec5g:~/cert2$ docker login 10.63.27.49:6000 -u xxx -p xxx
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /home/usuario/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
- The error in ArgoCD is different now:
Update 2023-04-02.2
- I have added a secret to argocd namespace:
root@master:~# kubectl create secret docker-registry regcred -n argocd --docker-username=xxx --docker-password=xxx --docker-server=10.63.27.49:6000
secret/regcred created
- I have added a tag to the helmchart deployment file:
spec:
imagePullSecrets:
- name: regcred
The error still persists.
2
Answers
Following this ArgoCD recommendation: issue-6048:
"Argo CD uses a kind of certificate pinning - that means, each certificate is pinned to the name of the repository server, and must be configured accordingly. The CN in the configured certificate is irrelevant, as long as it can be used to validate the server's certificate (e.g. when you supply a CA certificate to validate TLS connections). What is relevant is the certificate supplied by the remote server - this needs to be properly set-up with a SAN that actually identifies the server (through SAN extension DNS:, for example). One of the SAN entries must match the name of the server as being used to connect to it."
I have used a detailed SAN to create the self-signed certificate. E.g.:
subjectAltName=DNS:10.63.27.49,DNS:localhost,DNS:mec5g.es,DNS:master,IP:10.63.27.49,IP:127.0.0.1,IP:10.5.0.2"
I have added certs to /ca-certificates folder. E.g.:
daemon.json
file. E.g.:If the certificate is self-signed, you’ll need to add it to the host’s root CAs.
If you don’t know how, have a look here: https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list