The docker cli tool provides two options for tls auth: --tls and --tlsverify.
What's the difference between these two options?
I've set up my remote docker daemon to use some TLS certs I've made using openssl. I'm able to connect to the daemon using the --tls flag but not using the --tlsverify
If you "made" the certificates yourself (i.e., self-signed), it's unlikely that the certificates can be verified. Using the --tls option simply instructs Docker to use the certificates as-is without verifying the certificate with root authorities. --tlsverify requires that the certificate can be verified with a root authority before it is used.
See https://docs.docker.com/engine/security/https/ for more details, specifically (emphasis mine):
If you need Docker to be reachable via the network in a safe manner, you can enable TLS by specifying the tlsverify flag and pointing Docker’s tlscacert flag to a trusted CA certificate.
In the daemon mode, it will only allow connections from clients authenticated by a certificate signed by that CA. In the client mode, it will only connect to servers with a certificate signed by that CA.
In other words, the behavior you're experiencing is less of a Docker problem and more of a certificate problem.
Related
I have multiple Intel NUCs out in the field that I use for displaying digital signage. Out of the thousands I have in the field, a couple complain with this error:
SSL certificate problem: self signed certificate in certificate chain. 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.
I've confirmed that the cert is not expired, and the domain name matches
These units are running on Debian 7
Could the network they are on cause this issue with some sort of firewall setting?
When you visit the website what certificate is shown in the web browser? In your curl bundle is that the same certificate which is supposed to be used for SSL encryption? I'd guess no. CA will sign your cert.pem so that web browsers will show your green lock thereby authenticating your website. You most likely have an issue on the back end with the configuration of your curl bundle. You need to make sure that your server is using the CA cert not a self signed certificate like ssl-cert-snakeoil.pem for example.
Essentially your website should be using a static IPv4 address. As far as a network firewall stopping an SSL handshake from happening that may be possible, I have seen it happen on specific ports for example port 22 for ssh connections may be blocked at the network gateway for inbound traffic on a client side computer attempting a connection to a server. The SYN/ACK https://tools.ietf.org/rfc/rfc793.txt TCP handshake may time out in that type of network fire wall situation. However since you are getting an explicit response from your server about a self signed cert a firewall issue does not seem to be the problem.
I'm trying to set up Drone using TLS but the drone agent can't connect to the server with the error:
connection failed, retry in 15s. websocket. Dial wss://drone-server:8000/ws/broker: x509: certificate signed by unknown authority
I've generated the necessary files and my docker-compose file for the drone server has DRONE_SERVER_CERT and DRONE_SERVER_KEY values set with the certificates, so I think the only problem is that it's self-signed. But I'm not sure how to set up the certificates with the drone image to have it recognize the certificate's CA. Is there a way to set that up or am I going about this in completely the wrong way?
As far as I understand the drone CLI client, uses the systems' trusted certificate storage as most* applications do. So for your client to start trusting the server's self signed certificate, you should add the CA cert to your system storage.
A good guide on how to install a CA cert can be found in this answer.
*browsers usually have their own CA cert DB
I read that ejabberd recommends to use STARTTLS negotiation for secure connection between communicating entities. When I install ejabberd, by default it comes with a TLS certificate.
Then, why do I need to buy a certificate to install? what is the purpose of buying a new certificate from Certificate Authoririty since we have a default certificate?
When I deploy ejabberd on the machine, how the default certificate will be used for my domain? How the default certificate will be verified by client?
You can use ejabberd with SSL / STARTTLS with the provided TLS certificate. However, that certificate is only a self-signed certificate. It means that:
You will still be able to encrypt the traffic between the client and the server.
You client will not be able to check that the server is the domain it pretends to be. To be able to know that the certificate can be trusted the client need to refer to a trust authority in some way.
In the second case, it means that if an intermediate network device (i.e Wifi access point) tries to impersonate your server, it can present any self-signed certificate to the user, pretending to be your domain.
So, you can definitely use self-signed certificate to encrypt traffic, but to protect your users against man-in-the-middle type of attacks, you need to find a way to let the client now it can trust the certificate.
This can be done either by buying a certificate from a trusted authority (that will certify your certificate domain) or by making the client support a list of well defined certificates. This is called certificates pinning, however it requires to build the list of acceptable certificates into your client, which may not be possible.
It may be fine in your case, so buying a certificate is not mandatory.
However, not use the default ejabberd self-signed certificate, even if you plan using a self-signed certificate. The certificate provided with ejabberd will not match your own domain. You should at least generate your own self signed certificate that match your actual XMPP domain: How to create a self-signed certificate with openssl?
The client will verify whether the certificate is issued for the domain name of the Jabber ID (JID), the part behind the '#'. (There are other options, but they are incompatible with the policies enforced by the browser vendors against CAs and therefore not practical.)
Unless you already have a business relationship to a certificate authority (CA), I would recommend anyone to use Let's Encrypt and stay away from self-signed certificates.
Some instructions to automate this and be nice to the Let's Encrypt servers can be found here and the linked wiki pages.
Summary (assuming you are running Ubuntu 16.04 LTS, want to run it on the domain example.org and only use the certificate for ejabberd):
Create /usr/local/sbin/auto-renew-letsencrypt with the following content:
#!/bin/bash
# Renew all Let's Encrypt certificates which are due for renewal
t=`mktemp`
# Try to be quiet unless an error is returned
letsencrypt renew > $t || cat $t
# Hooks are not yet supported by `letsencrypt` shipping with Ubuntu 16.04 LTE
# Crudely emulate --renew-hook; breaks if diagnostic messages change
if grep -q "The following certs have been renewed" $t; then
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
service ejabberd reload
fi
rm $t
Run the following commands to create and activate the certificate and the automatic renewal
apt install letsencrypt
letsencrypt certonly --standalone --domain example.org
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
chown ejabberd:ejabberd /etc/ejabberd/ejabberd.pem
chmod 640 /etc/ejabberd/ejabberd.pem
chmod 755 /usr/local/sbin/auto-renew-letsencrypt
echo $(($RANDOM % 60)) $((RANDOM % 6)) "* * * root /usr/local/sbin/auto-renew-letsencrypt" > /etc/cron.d/auto-renew-letsencrypt
I created self signed certificate and is being used in my express project. The problem is when I do
curl https://<domain>
doesn't and only works with -k option, it doesn't use the certificate to encrypt its content. I don't see how that is effective since that is similar to http itself.
Also from what I understand in CA signing request is that browsers like chrome they are preinstalled with the information trusted CAs in the web such as Verisign. So how does curl work in this way, does it also know before hand like in chrome regarding who are the trusted CAs?
Also in my project the app communicates with the ec2 machine does it need client side certificate for https ?
Yes, curl has a pointer to a list of trusted Certificate Authority keys. You can override it with the --capath flag.
When generating a self-signed certificate using keytool, can I use an IP address for the Common Name?
Once I generated the certificate, I exported it so I can install it in my clients/browsers. In Windows, I ran mmc.exe and added it as a Trusted Root Certificate Authority.
However, when I navigate to the IP address in my browser, it is still an untrusted connection. I ensured Tomcat had all the correct Connector settings.
Am I doing this correctly? do I need to be my own CA? How can I use SSL for development purposes? I'm still trying to understand SSL completely.
First question: if you'll be connecting by IP, then yes.
Second question: No, you don't install your self-signed certificate as CA, you just add exception when your browser warns you that it's self-signed.
You can set up CA — you generate root certificate first, install it in the client, and then generate CSR and then server certificate from it (see e.g. this), but for development purposes this is a complete waste of time.