compose: [1.7.0] Compose fails to execute tls, even when docker succeeds

Docker client handles certs without issue. Compose refuses to schedule any containers.

$ export DOCKER_HOST=tcp://leader.me.priv:2375
$ export DOCKER_TLS_VERIFY=1
$ export DOCKER_CERT_PATH=/home/ubuntu/.docker

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

$ docker-compose up -d service
ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

$ docker-compose version
docker-compose version 1.7.0, build 0d7bf73
docker-py version: 1.8.0
CPython version: 2.7.10
OpenSSL version: OpenSSL 1.0.2d 9 Jul 2015

$ docker version
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:59:07 2016
 OS/Arch:      linux/amd64

Server:
 Version:      swarm/1.2.0
 API version:  1.22
 Go version:   go1.5.4
 Git commit:   a6c1f14
 Built:        Wed Apr 13 05:58:31 UTC 2016
 OS/Arch:      linux/amd64

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 10
  • Comments: 31

Most upvoted comments

I am guessing that people running into this are following the instructions here https://docs.docker.com/engine/security/https/ to generate certificates.

The problem is this line:

$ echo subjectAltName = IP:10.10.10.20,IP:127.0.0.1 > extfile.cnf

The fix is simple:

$ echo subjectAltName = DNS:$HOST,IP:10.10.10.20,IP:127.0.0.1 > extfile.cnf

After reading hints regarding potential a subjectAltName “issue”, I’ve debugged a bit and discovered that not all subjectAltName entries were actually being used, e.g. there was no “IP Address” entry being evaluated although my cert contained them. Only the DNS entry containing the IP was evaluated and failed - in my case.

I’ll discovered that the SubjectAltName was provided by a wrapper around ndg-httpsclient. PIP showed me that I had 0.4.0 installed. After uninstalling ndg-httpsclient completely using pip the problem was solved for me.

My configuration is

docker-compose version 1.7.1, build unknown
docker-py version: 1.8.1
CPython version: 2.7.10
OpenSSL version: OpenSSL 0.9.8zh 14 Jan 2016

Fix floated in issue #890 does resolve this issue. Using something like:

$ CURL_CA_BUNDLE= docker-compose ps
      Name          Command   State             Ports            
----------------------------------------------------------------

Suspect that makes this a duplicate?

@darkermatter is right! I followed these instructions:

https://docs.docker.com/engine/security/https/

And I got the docker-compose certficiate hostname error. The instructions need to be updated. Where it says:

$ echo subjectAltName = IP:10.10.10.20,IP:127.0.0.1 > extfile.cnf

It should say:

$ echo subjectAltName = DNS:$HOST,IP:10.10.10.20,IP:127.0.0.1 > extfile.cnf

And it would be helpful that it also stated that the DNS:$HOST part is mandatory according to the specifications of subjectAltName.

Rather than disable the CURL_CA_BUNDLE you can run using: CURL_CA_BUNDLE=~/.docker/machine/machines/default/ca.pem docker-compose ps

I just spent a long time fighting this problem. It turned it that if you use the same CN when generating your CA certificate (https://docs.docker.com/engine/security/https/ says this is the way to go via the $HOST variable) it doesn’t seem to work. I changed the CN of my CA certificate to something else (not the hostname of the server) and boom, docker-compose works.

I updated to docker-compose version ‘1.14.0-rc2’, things seem to be working fine, now.

Actually, I don’t think it’s a bug, it’s a breaking fix. The software is now behaving correctly as specified by the RFCs.

The info is here: http://wiki.cacert.org/FAQ/subjectAltName

What is subjectAltName ?

subjectAltName specifies additional subject identities, but for host names (and everything else defined for subjectAltName) :

subjectAltName must always be used (RFC 2818 4.2.1.7, 1. paragraph). CN is only evaluated if subjectAltName is not present and only for compatibility with old, non-compliant software. So if you set subjectAltName, you have to use it for all host names, email addresses, etc., not just the “additional” ones.

@aboutlo it does not at least on my linux system:

➜  spark-env docker-compose --verbose version
docker-compose version 1.7.1, build 6c29830
docker-py version: 1.8.1
CPython version: 2.7.6
OpenSSL version: OpenSSL 1.0.1f 6 Jan 2014

➜  spark-env docker version
Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:30:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      swarm/1.2.2
 API version:  1.22
 Go version:   go1.5.4
 Git commit:   34e3da3
 Built:        Mon May  9 17:03:22 UTC 2016
 OS/Arch:      linux/amd64

Master machine is created using:

  docker-machine create \
      -d virtualbox \
      --swarm --swarm-master \
      --swarm-discovery="consul://${consul_ip}:8500" \
      --engine-opt="cluster-store=consul://${consul_ip}:8500" \
      --engine-opt="cluster-advertise=eth1:2376" \
      master

So actually this gives same error

➜  spark-env CURL_CA_BUNDLE=~/.docker/machine/machines/master/ca.pem docker-compose ps
...
  File "/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connection.py", line 313, in _match_hostname
    match_hostname(cert, asserted_hostname)
  File "/usr/local/lib/python2.7/dist-packages/backports/ssl_match_hostname/__init__.py", line 151, in match_hostname
    % (hostname, dnsnames[0]))
backports.ssl_match_hostname.CertificateError: hostname '192.168.99.107' doesn't match 'localhost'

as just this:

➜  spark-env docker-compose ps 
...
  File "/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connection.py", line 313, in _match_hostname
    match_hostname(cert, asserted_hostname)
  File "/usr/local/lib/python2.7/dist-packages/backports/ssl_match_hostname/__init__.py", line 151, in match_hostname
    % (hostname, dnsnames[0]))
backports.ssl_match_hostname.CertificateError: hostname '192.168.99.107' doesn't match 'localhost'