I have a container from where I am trying to reach an HTTPS URL using:
curl -v https//myserver:7050
The SSL issuer certificate of the server is placed on the VM where I run the container in /etc/ssl/certs. This VM location is volume mapped to /etc/ssl/certs of the container. This means the cert should be available to the container.
However, when I issue the curl command, I get a message saying "unable to get issuer certificate".
Then I need to run
update-ca-certificates --refresh
After this the curl command succeeds.
If I am starting the container with a volume map, why am I required to run the update-ca-certificates command? Shouldn't the container already have all the certs in its cache when it starts up?
Regards
Yash
Files on /etc/ssl/certs are symlinks to other files, if you mount a folder with symlinks, it will try to load the files they are linked, which probally doesnt exists inside your container.
U will need to mount the original file locations too.
lrwxrwxrwx. 1 root root 49 Jul 19 06:51 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
lrwxrwxrwx. 1 root root 55 Jul 19 06:51 ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
Or you can mount the original single files to your container /etc/ssl/certs
Related
I need to get an certificate for my domain hosted on AWS Route 53 from LetsEncrypt. I do not have any port 80 or 443 exposed since the server is used for VPN and does not have a public access.
So the only way to do this is via DNS validation of route 53.
So far I have installed certbot and dns-route53 plugin
sudo snap install --beta --classic certbot
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install --beta certbot-dns-route53
sudo snap connect certbot:plugin certbot-dns-route53
I have created a special user in my AWS account who has access to Route53 and I have added the access key id and secret access key in the ~/.aws/config and also ~/.aws/credentials which looks something like this
[default]
aws_access_key_id=foo
aws_secret_access_key=bar
Basically followed every step given here: https://certbot-dns-route53.readthedocs.io/en/stable/
Now when I run the following command:
sudo certbot certonly -d mydomain.com --dns-route53
It gives the following output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-route53, Installer None
Requesting a certificate for mydomain.com
Performing the following challenges:
dns-01 challenge for mydomain.com
Cleaning up challenges
Unable to locate credentials
To use certbot-dns-route53, configure credentials as described at https://boto3.readthedocs.io/en/latest/guide/configuration.html#best-practices-for-configuring-credentials and add the necessary permissions for Route53 access.
I went to the documentation given in the error message: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#best-practices-for-configuring-credentials
but I do not think there is anything wrong I am doing
I even went to the root level by doing sudo su and exported the AWS keys as env vars there and even exported the AWS keys in the home as well but it still throws me the same error.
so I also ran into this same issue, and it's likely because of you running certbot with sudo, when do you do that, whatever user you've used as ~/, is ignored, as instead, it's looking in /root/.
I fixed it by (centos) is my user where I have the .aws/ directory with config and credential files.
sudo -s
ln -s /home/centos/.aws/ ~/.aws
ls -lsa ~/.aws
... /root/.aws -> /home/centos/.aws/
I have 3 KVM/libvirt hypervisors that I would like to communicate with each other.
I have my own CA and subordinate CA.
I created the certificates for each machine and I have the following one each /etc/libvirt/libvirtd.conf of them:
listen_tls = 1
key_file = "/etc/pki/tls/private/serverX_libvirt_key.pem"
cert_file = "/etc/pki/tls/certs/serverX_crt.pem"
ca_file = "/etc/pki/tls/certs/CA_chain.pem"
The CA_chain.pem file obviously contains the chain certificates (Int-CA & CA).
The key file and the certificates are validated correctly.
openssl verify -CAfile /etc/pki/tls/certs/CA_chain.pem /etc/pki/tls/certs//etc/pki/tls/certs/serverX_crt.pem
/etc/pki/tls/certs/serverX_crt.pem: OK
Client certificates are defined as in the documentation as:
ls -lrt /etc/pki/libvirt/private/clientkey.pem
-r--------. 1 root root 3243 Apr 30 09:45 /etc/pki/libvirt/private/clientkey.pem
And of course it's verified from our CA:
openssl verify -CAfile /etc/pki/tls/certs/CA_chain.pem /etc/pki/libvirt/clientcert.pem
/etc/pki/libvirt/clientcert.pem: OK
ls -lrt /els -lrt /etc/pki/libvirt/clientcert.pem
-rw-r--r--. 1 root root 2297 Apr 30 10:07 /etc/pki/libvirt/clientcert.pemtc/pki/libvirt/private/clientkey.pem
However, I cannot connect to the hypervisors!
Using virsh, I get the following error:
[root#serverX ~]# virsh -c qemu+tls://serverY list
error: failed to connect to the hypervisor
error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
The certificate permissions are correct, the SELinux is correct.
But obviously, something is missing and I cannot connect to the servers.
Any help would be appreciated.
OK, I found it.
The issue seems to be that the libvirt's client has no option for TLS. Thus, we are forced to use the default locations. And although I used the default locations for the private key and the certificate, I didn't do the same for the CA.
Thus, I created a link from /etc/pki/tls/certs/CA_chain.pem to /etc/pki/CA/cacert.pem and now everything is fine.
mkdir -p /etc/pki/CA/
ln -s /etc/pki/tls/certs/CA_chain.pem /etc/pki/CA/cacert.pem
I have this error when I want install a commercial SSL in Zimbra
Your certificate was not installed due to the error : system failure:
exception executing command: zmcertmgr verifycrtkey comm
/opt/zimbra/mailboxd/webapps/zimbraAdmin/tmp/current_comm.key
/opt/zimbra/mailboxd/webapps/zimbraAdmin/tmp/current.crt with
{RemoteManager: mail.mydomain.com->zimbra#mail.mydomain.com:22}
Use below script for SSL install in Zimbra.
#!/bin/bash -x
# SSL certificate installation in Zimbra
# with SSL certificate provided by Let's Encrypt (letsencrypt.org)
# Author: Subhash (serverkaka.com)
# Check if running as root
if [ "$(id -u)" != "0" ]; then
echo "This script must be run as root" 1>&2
exit 1
fi
read -p 'letsencrypt_email [xx#xx.xx]: ' letsencrypt_email
read -p 'mail_server_url [xx.xx.xx]: ' mail_server_url
# Check All variable have a value
if [ -z $mail_server_url ] || [ -z $letsencrypt_email ]
then
echo run script again please insert all value. do not miss any value
else
# Installation start
# Stop the jetty or nginx service at Zimbra level
su - zimbra -c 'zmproxyctl stop'
su - zimbra -c 'zmmailboxdctl stop'
# Install git and letsencrypt
cd /opt/
apt-get install git
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
# Get SSL certificate
./letsencrypt-auto certonly --standalone --non-interactive --agree-tos --email $letsencrypt_email -d $mail_server_url --hsts
cd /etc/letsencrypt/live/$mail_server_url
cat <<EOF >>chain.pem
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----
EOF
# Verify commercial certificate
mkdir /opt/zimbra/ssl/letsencrypt
cp /etc/letsencrypt/live/$mail_server_url/* /opt/zimbra/ssl/letsencrypt/
chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*
ls -la /opt/zimbra/ssl/letsencrypt/
su - zimbra -c 'cd /opt/zimbra/ssl/letsencrypt/ && /opt/zimbra/bin/zmcertmgr verifycrt comm privkey.pem cert.pem chain.pem'
# Deploy the new Let's Encrypt SSL certificate
cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.$(date "+%Y%m%d")
cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key
sudo chown zimbra:zimbra /opt/zimbra/ssl/zimbra/commercial/commercial.key
su - zimbra -c 'cd /opt/zimbra/ssl/letsencrypt/ && /opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem chain.pem'
# Restart Zimbra
su - zimbra -c 'zmcontrol restart'
# setting auto https redirect
cd /opt && touch https-redirect.sh && chown zimbra:zimbra https-redirect.sh && chmod +x https-redirect.sh
cat <<EOF >>/opt/https-redirect.sh
zmprov ms $mail_server_url zimbraReverseProxyMailMode redirect
EOF
su - zimbra -c '/opt/https-redirect.sh'
rm /opt/https-redirect.sh
fi
For more reference check this link: https://github.com/SubhashPatel/Install-Zimbra-mail-server-ubuntu/blob/master/configure-ssl-zimbra.sh
You should try using CLI to install SSL certificate for Zimbra. Also you need to verify that you have the same certificate which you have downloaded from the certificate authority.
For commercial.crt you need to copy one certificate downloaded from the authority. For commercial_ca.crt, there must be one CA bundle file, you will have from certificate authority.
Private key, you need to verify during generating your CSR and also verify with the hosting. After that restart the Zimbra by command
zmcontrol restart
finally i found the solution.
you shouldn't fill the subject alternative name when you want create csr!
thats all.
Every other year I spend hours on renewing the ssl certificates on zimbra with the help of hopeless outdated tutorials. A tedious process that I don't do often enough to remember how I did it. I learned the hard way that it is easier to use the admin console, than using CLI and messing around with concatinating the different certificates.
Hereby the steps that I take:
Please note that this is a walkthrough, dedicated to the
GoGetSSL Sectigo PositiveSSL Wildcard certificate, and may not work for other SSL providers.
Zimbra version: 8.8.15
We use the wildcard certificate on several servers, but we generate the CSR always(!) on the zimbra server. So go to admin console > Configure > Certificates, click the domain in the list and then in top right corner, choose install certificate. Choose the generate CSR option (second of the 3 options). Make sure that in the common name field you use the wildcard symbol: e.g.
*.example.com
Also check the checkbox that it concerns a wildcard common name
Fill out the rest of the info according to your situation. At the bottom, there's option to add other names; remove all of them (if any). Go to next page and download the CSR, finish the wizard.
on the GoGetSSL page create the new/renew the SSL certificate with the by Zimbra generated CSR. Finish up the entire process, including the validation. All the way up to that the certificate is issued and files can be downloaded. Choose to download the 'All files' zip file. extract on your local system.
browse to: https://www.gogetssl.com/wiki/intermediate-certificates/sectigo-intermediate-root-certificates/
On this page download the file: DV RSA Files > RSA DV Bundle with SHA-1 (TXT file)
go back to admin console > Configure > Certificates, click the domain in the list and then in top right corner, choose install certificate. This time you choose the 3rd option: install commercial signed certificate. First screen of the wizard shows the info you entered earlier for the CSR. The info may show up empty. For me this didn't give me any problems, so I left it. On the next screen: You have to upload 3 certificate files by default, but we need to upload 4, so we need to do Add Intermediate CA for the fourth file.
Choose files as follows:
Certificate: server certificate from the zip file: e.g. _example.com.crt
Root CA: RSA DV Bundle with SHA-1 (TXT file), from the link above
Intermediate CA: USERTrust_RSA_Certification_Authority.crt from zip file
(Added) Intermediate CA: AAA_Certificate_Services.crt
NOTE: I can't remember which Intermediate CA I chose first, so if any problems, try switching the last 2 mentioned files around.
Finish the wizard and test by sending and receiving email.
Then I take the certificates and update other servers with these certificates. (e.g. nginx, apache2, etc). Note: you may need to get the commercial.key file for use on other servers. On linux this file is located in: /opt/zimbra/ssl/zimbra/commercial/
If permission denied, you may use root account or do: sudo su - zimbra
I hope this helps for people struggling with the same certificate and zimbra
My server uses Let's Encrypt to get its TLS certificate to serve over HTTPS.
I'm electing to use the standard net/http package over Apache or nginx, so I used the webroot installation method, and it placed the cert files in /etc/letsencrypt/live/mysite.
The issue is that the live directory is only accessible by the root user. My golang program requires the certs in this directory to function and serve over HTTPS.
However for obvious reasons I'm not running my program as the root user.
So that leads me to wonder: how do I access these files without having to insecurely run my web server as root permanently?
You have few options:
sudo chown -R your-user /etc/letsencrypt/live/mysite
Or
sudo cp -a /etc/letsencrypt/live/mysite ./ssl/ && sudo chown -R your-user ./ssl/
Or
Use a container for your app and copy your app and the certs to it, and since it will be running as root inside the container, it won't matter.
I followed the Docker Registry installation docs precisely, and have a registry running on a remote Ubuntu VM. On that VM, the Docker container is running with the following command:
docker run -d -p 5000:5000 --restart=always --name registry \
-v `pwd`/auth:/auth \
-e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
-e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
-v `pwd`/certs:/certs \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/registry.key \
registry:2
On the remote VM, I have the following directory structure:
/home/myuser/
certs/
registry.crt
registry.key
/etc/docker/certs.d/myregistry.example.com:5000/
ca.crt
ca.key
The ca.crt is the same exact cert as ~/certs/registry.crt (just renamed); same goes for ca.key and registry.key being the same/just renamed. I created the ca* files per a suggestion from the error output you'll see below.
I am almost 100% sure the CA cert is still valid, although any help ruling that out (e.g. how can I actually tell?) would be appreciated. When I start the container and look at the Docker logs, I don't see any errors.
I then attempt to login from my local laptop (Mac):
docker login myregistry.example.com:5000
It queries me for my username, password and email (although I don't recall ever specifying an email when setting up Basic Auth). After entering these correctly (I have checked and double checked...) I get the following error:
myuser#mymachine:~/tmp$docker login myregistry.example.com:5000
Username: my_ciuser
Password:
Email: myuser#example.com
Error response from daemon: invalid registry endpoint https://myregistry.example.com:5000/v0/:
unable to ping registry endpoint https://myregistry.example.com:5000/v0/ v2 ping attempt failed with error:
Get https://myregistry.example.com:5000/v2/: x509: certificate has expired or is not yet valid
v1 ping attempt failed with error: Get https://myregistry.example.com:5000/v1/_ping: x509:
certificate has expired or is not yet valid. If this private registry supports only HTTP or
HTTPS with an unknown CA certificate, please add
`--insecure-registry myregistry.example.com: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/myregistry.example.com:5000/ca.crt
So from my perspective, I guess the following are possible:
The CA cert is invalid (if so, why?!?)
The CA cert is an intermediary cert (if so, how can I tell?)
The CA cert is expired (if so, how do I tell?)
This is a bad error message, and some other facet of the registry is not configured properly (if so, how do I troubleshoot further?)
Perhaps my cert is not located in the correct place on the server, or doesn't have the right permissions set (if so, where does the cert need to be?)
Something else that I would never expect in a million years
Any ideas/thoughts?
As said in the error message:
... 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/myregistry.example.com:5000/ca.crt
where myregistry.example.com:5000 - your CN with port.
You should copy your ca.crt into each Docker Daemon that will connect to your Docker Registry and put it in this folder: /etc/docker/certs.d/myregistry.example.com:5000/ca.crt
After this action you need to restart Docker daemon, for example, via sudo service docker stop && service docker start on CentOS (or call similar procedure on your OS).
I had the similar error:
Then I added my private registry to the insecureregistries list.
See below image for docker-desktop