Machine: error occurred trying to connect on mac OS X

Created on 22 Feb 2016  路  32Comments  路  Source: docker/machine

I've download docker to a mac running 10.10.5.

After installation, I can't communicate with the docker instance and I can't do hello world:

515918-mitll:~ go22670$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default * virtualbox Running tcp://192.168.99.100:2376 v1.10.0

515918-mitll:~ go22670$ docker images
An error occurred trying to connect: Get https://192.168.99.100:2376/v1.22/images/json: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs

515918-mitll:~ go22670$ docker -v
Docker version 1.10.0, build 590d5108

515918-mitll:~ go22670$ docker run hello-world
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.

Any ideas on next steps? Thanks!

Most helpful comment

Well, I was able to make this work, here were my steps:

$> docker-machine rm -f default

$> docker-machine create -d virtualbox  \
  --engine-env HTTP_PROXY=http://proxyserver:port \
  --engine-env HTTPS_PROXY=https://proxyserver:port \
  --engine-env NO_PROXY=192.168.99.100 \  # Turns out this line is not neccessary
  default

<close previous window and launch new 'Docker Quickstart Terminal' just because it feels right>

$> export NO_PROXY=192.168.99.100
$> docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world

03f4658f8b78: Pull complete 
a3ed95caeb02: Pull complete 
Digest: sha256:8be990ef2aeb16dbcb9271ddfe2610fa6658d13f6dfb8bc72074cc1ca36966a7
Status: Downloaded newer image for hello-world:latest

Hello from Docker.
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
 https://hub.docker.com

For more examples and ideas, visit:
 https://docs.docker.com/userguide/

Now... for reasons unknown to me, my virtual box is hosting the daemon on 192.168.99.101 for this go-around build above. I am just entering 192.168.99.100 for saneness because whom ever reads this is probably on 100...

For future reference: I was able to troubleshoot my issue, by launching the default image using VirtualBox, and performing a tail -f /var/log/docker.log within the actual image itself. Lots of useful information there.

I must point out, because I still think there is something wrong... I need to, export NO_PROXY=192.168.99.100 before attempting to docker run hello-world. This seems absolutely necessary. If I do not do this, my tail command shows zero activity when running that, or any other docker command. Not to mention, if I do not export no_proxy, I receive the same error as the OP.

I hope this helps some folks!

Edit: setting no_proxy while building the new virtual machine didn't seem to affect it. For me and my corporate environment, it seems to all boil down to rebuilding the default image with proxy settings set (--engine-env) and exporting no_proxy to be what ever the default machine says its IP is at the time.

Looks like this issue was solved in the docker/toolbox project: https://github.com/docker/toolbox/issues/102

All 32 comments

Did you try docker-machine regenerate-certs -f?

No luck -

docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com

515918-mitll:netPron2 go22670$ docker run hello-world
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.

515918-mitll:netPron2 go22670$ docker-machine regenerate-certs -f
Regenerating TLS certificates
Waiting for SSH to be available...
Detecting the provisioner...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...

515918-mitll:netPron2 go22670$ docker run hello-world
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.

What's the output of openssl x509 -in ~/.docker/machine/machines/default/server.pem -text -noout?

Also, if you don't mind losing DM VM state, can you please try:

docker-machine rm -f default && rm -rf ~/.docker/machine && docker-machine create -d virtualbox --virtualbox-memory 2048 default

(this will remove the existing machine, rm ~/.docker/machine, and re-try the create -- basically start from scratch)

515918-mitll:netPron2 go22670$ openssl x509 -in ~/.docker/machine/machines/default/server.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5a:6b:b6:5f:bb:9e:94:5e:8e:06:08:00:67:7c:4e:41
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=go22670
        Validity
            Not Before: Feb 22 21:12:00 2016 GMT
            Not After : Feb  6 21:12:00 2019 GMT
        Subject: O=go22670.default
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:f2:c9:f4:cc:af:5b:4d:b0:98:fc:c9:a5:90:11:
                    d8:87:e1:28:b8:5b:4b:20:fc:3b:55:0d:a4:ae:9c:
                    54:d1:81:bd:0c:50:cc:51:9b:cb:ce:3c:2a:f9:58:
                    b9:43:43:7d:28:e0:83:f2:6f:ba:06:1d:77:6a:da:
                    ff:6e:ee:d3:85:d7:c5:42:b7:45:f3:9d:9c:e3:d2:
                    22:cf:2c:88:35:75:d3:25:51:53:7f:32:1f:71:5d:
                    56:c8:46:6e:a5:45:23:88:c7:b3:c3:a2:93:51:1c:
                    9f:51:57:96:7b:96:67:6c:02:24:79:b7:9a:a9:9c:
                    a9:56:65:7e:98:2c:23:05:c8:c3:07:5f:1b:a1:96:
                    df:10:9e:71:7a:de:99:01:45:1e:0a:16:b1:68:38:
                    98:4c:9e:03:60:63:94:e4:89:c2:2a:5b:a7:0d:cf:
                    a0:c4:21:b3:6c:bf:e3:06:b3:3c:cb:72:a7:3b:81:
                    3d:9f:fd:ea:b9:1f:41:90:6f:a3:b0:9e:7c:87:66:
                    9f:d4:54:ea:b0:6c:a8:34:dd:be:94:35:69:1a:55:
                    43:d7:b8:78:b2:1d:14:fc:f7:69:dd:56:45:fc:64:
                    6e:3d:07:7d:54:42:fc:50:6f:7f:40:ac:22:19:17:
                    d1:24:ec:a0:f0:60:8f:a9:12:24:9e:56:ae:a4:5a:
                    27:8d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name: 
                DNS:localhost, IP Address:192.168.99.100
    Signature Algorithm: sha256WithRSAEncryption
        b1:e1:e1:28:ee:c8:a6:98:ae:d8:ab:6f:dc:c0:a0:6d:b1:b3:
        77:aa:d2:de:cc:b8:58:af:e7:00:8b:b7:d9:83:0f:40:6a:0a:
        5c:da:3f:98:55:0e:b9:58:12:f8:20:9d:b0:e4:7e:ba:6f:2f:
        80:0d:5e:c5:7a:a4:5c:83:25:a0:7b:86:6c:4e:58:01:fa:91:
        f1:b7:50:4e:e5:36:79:e0:99:21:0f:a2:eb:3f:b9:74:34:d5:
        c1:79:b2:3a:b6:9c:d1:b1:51:a6:fa:9f:53:8d:72:e6:76:26:
        02:38:91:38:22:e5:56:be:25:0f:13:1b:1a:1f:39:28:d6:42:
        e3:48:61:e2:53:08:ed:a9:d6:00:9a:fd:cc:97:a2:40:2f:3a:
        2d:37:29:f0:c9:8e:fa:81:d3:0f:ca:91:d8:92:34:e3:3f:6b:
        d7:70:e0:6f:48:a8:a5:cb:3e:95:d7:7f:e0:74:8f:66:8c:6b:
        05:f9:75:ba:ba:80:fd:f0:55:f0:6f:f5:98:3c:90:e8:b2:d3:
        78:df:83:ec:91:8d:ed:bd:67:84:47:ad:f1:bd:45:d3:11:04:
        ec:d8:3d:a5:70:0d:51:db:51:09:82:4b:dc:4c:e1:7a:aa:12:
        f3:6e:ea:ed:a7:3d:bb:dc:12:e8:47:9e:06:dc:fc:6e:a7:47:
        4e:87:46:b6

The cert _does_ seem to have valid IP SANs:

            X509v3 Subject Alternative Name: 
                DNS:localhost, IP Address:192.168.99.100

Maybe you need to re-run eval $(docker-machine env)?

And the next one:

515918-mitll:netPron2 go22670$ docker-machine rm -f default && rm -rf ~/.docker/machine && docker-machine create -d virtualbox --virtualbox-memory 2048 default
About to remove default
Successfully removed default
Creating CA: /Users/go22670/.docker/machine/certs/ca.pem
Creating client certificate: /Users/go22670/.docker/machine/certs/cert.pem
Running pre-create checks...
(default) Image cache directory does not exist, creating it at /Users/go22670/.docker/machine/cache...
(default) No default Boot2Docker ISO found locally, downloading the latest release...
(default) Latest release for github.com/boot2docker/boot2docker is v1.10.1
(default) Downloading /Users/go22670/.docker/machine/cache/boot2docker.iso from https://github.com/boot2docker/boot2docker/releases/download/v1.10.1/boot2docker.iso...
(default) 0%....10%....20%....30%....40%....50%....60%....70%....80%....90%....100%
Creating machine...
(default) Copying /Users/go22670/.docker/machine/cache/boot2docker.iso to /Users/go22670/.docker/machine/machines/default/boot2docker.iso...
(default) Creating VirtualBox VM...
(default) Creating SSH key...
(default) Starting the VM...
(default) Check network to re-create if needed...
(default) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env default
515918-mitll:netPron2 go22670$ docker run hello-world
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.
515918-mitll:netPron2 go22670$ eval $(docker-machine env)
515918-mitll:netPron2 go22670$ docker run hello-world
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.

Hmm, I also did the eval:

515918-mitll:netPron2 go22670$ eval $(docker-machine env)
515918-mitll:netPron2 go22670$ docker run ls
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.
515918-mitll:netPron2 go22670$ docker run hello-world
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.

I get a similar error. Any resolution for this?

Is it Docker Machine 0.6.0 for both of you?

I believe I'm using 1.10.0:

docker -v
Docker version 1.10.0, build 590d5108

That's Docker version, which is different than Machine version. What does docker-machine -v say?

Sorry -
docker-machine -v
docker-machine version 0.6.0, build e27fb87

OK, so it is 0.6.0. Thanks.

docker-machine version 0.6.0, build e27fb87

I have the same problem running docker on windows. Same docker-machine version 0.6.0, build e27fb87.

The cert aolso does seem to have valid IP SANs after several regenerations nohing changed. Running docker run hello-world delivers the same error message as for the other guys...

What's the output of openssl version on your system?

$ openssl version
OpenSSL 1.0.2e 3 Dec 2015

OpenSSL 0.9.8zg 14 July 2015

I get the same error on two machines. Mac OS X 10.11.4
1st machine Command Line Tools 7.3, Homebrew
2nd machine Command Line Tools 7.2
Command Line Tools can have a huge effect on things, so its a good idea to post it when/if you have it.

Both machines operate behind a Proxy. First machine I tinkered with adjusting proxy settings with machine-create -d virtualbox --engine-env default.

The second machine I decided to attempt a vanilla install of Docker beta and not modify _anything_... to see if I would receive the same results, which unfortunately I do.

The results are the same, but the following is a paste from the 2nd box:

#> docker run hello-world
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.

#> docker run ls
docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs.
See 'docker run --help'.

#> docker --version
Docker version 1.10.3, build 20f81dd

I have many Mac machines at my disposal and can 'vanilla' image them at will within minutes. So I stand ready to assist you, if anyone here has some things you would like me to test.

No such issue when I take one of our MacBook Pros home, and attempt a vanilla build (No Corporate Proxy)

Same issue with me.
docker - version - 1.10.3, build 20f81dd
openssl - version - 1.0.2e 3 Dec 2015
docker-machine version - 0.6.0, build e27fb87

I am behind corporate proxy as well; tried to set the http_proxy and https_proxy but still no luck. Getting this error
"docker: An error occurred trying to connect: Post https://192.168.99.100:2376/v1.22/containers/create: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs."

Just posting more things I've tried, maybe this will help others...

#> export NO_PROXY='192.168.99.100'
#> env | grep -i proxy
<The correct list of HTTPS_PROXY, HTTP_PROXY, https_proxy, http_proxy, NO_PROXY are listed>

#> docker --tlsverify=false run hello-world
Unable to find image 'hello-world:latest' locally
Pulling repository docker.io/library/hello-world
docker: Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/hello-world/images. You may want to check your internet connection or if you are behind a proxy..
See 'docker run --help'.


#> docker run -e https_proxy="proxyserver:port" -e http_proxy="proxyserver:port" hello-world
Unable to find image 'hello-world:latest' locally
Pulling repository docker.io/library/hello-world
docker: Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/hello-world/images. You may want to check your internet connection or if you are behind a proxy..
See 'docker run --help'.


#> unset NO_PROXY
#> docker --tlsverify=false run hello-world
Our common Proxy Server error message gets printed here.
Our Proxy Server states it was not able to connect to 192.168.99.100
(which makes sense, how could anyone expect a proxy
server to connect back to a locally created virtual private network?) 


#> export NO_PROXY=/var/run/docker.sock,192.168.99.100
#> docker --tlsverify=false run hello-world
Unable to find image 'hello-world:latest' locally
Pulling repository docker.io/library/hello-world
docker: Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/hello-world/images. You may want to check your internet connection or if you are behind a proxy..
See 'docker run --help'.

Note: when I remove the --tlsverfiy=false argument and not have a NO_PROXY set, is when I get the same error as the OP

Thoughts: I need to find a way to explain to docker _not_ to use proxies when attempting to connect back to its locally running daemon, but _do_ use proxies for everything else...? What tells me that I am missing something, is that our Linux machines do not exhibit this behavior behind the same corporate proxy server.

Note 2: The Macbook Pro I took home which I mentioned in an earlier post, that worked (and now has the hello-world image stored locally) will not run when subjected to our corporate proxy, _unless_ I export NO_PROXY=192.168.99.100

Well, I was able to make this work, here were my steps:

$> docker-machine rm -f default

$> docker-machine create -d virtualbox  \
  --engine-env HTTP_PROXY=http://proxyserver:port \
  --engine-env HTTPS_PROXY=https://proxyserver:port \
  --engine-env NO_PROXY=192.168.99.100 \  # Turns out this line is not neccessary
  default

<close previous window and launch new 'Docker Quickstart Terminal' just because it feels right>

$> export NO_PROXY=192.168.99.100
$> docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world

03f4658f8b78: Pull complete 
a3ed95caeb02: Pull complete 
Digest: sha256:8be990ef2aeb16dbcb9271ddfe2610fa6658d13f6dfb8bc72074cc1ca36966a7
Status: Downloaded newer image for hello-world:latest

Hello from Docker.
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
 https://hub.docker.com

For more examples and ideas, visit:
 https://docs.docker.com/userguide/

Now... for reasons unknown to me, my virtual box is hosting the daemon on 192.168.99.101 for this go-around build above. I am just entering 192.168.99.100 for saneness because whom ever reads this is probably on 100...

For future reference: I was able to troubleshoot my issue, by launching the default image using VirtualBox, and performing a tail -f /var/log/docker.log within the actual image itself. Lots of useful information there.

I must point out, because I still think there is something wrong... I need to, export NO_PROXY=192.168.99.100 before attempting to docker run hello-world. This seems absolutely necessary. If I do not do this, my tail command shows zero activity when running that, or any other docker command. Not to mention, if I do not export no_proxy, I receive the same error as the OP.

I hope this helps some folks!

Edit: setting no_proxy while building the new virtual machine didn't seem to affect it. For me and my corporate environment, it seems to all boil down to rebuilding the default image with proxy settings set (--engine-env) and exporting no_proxy to be what ever the default machine says its IP is at the time.

Looks like this issue was solved in the docker/toolbox project: https://github.com/docker/toolbox/issues/102

@milljm fix works for me. However, I didn't have to have "--engine-env NO_PROXY=192.168.99.100" on the docker-machine create command.

Thank you!!! Spent a decent chunk of last Friday on this issue.

@milljm Thank you.. your post helped me to isolate the issue and solve it.. Thanks a lot.

All, docker-machine env has a --no-proxy flag to set NO_PROXY for the VM IP automatically in the eval if that is the issue at hand...

$ docker-machine env --no-proxy
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/nathanleclaire/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
export NO_PROXY="192.168.99.100"
# Run this command to configure your shell:
# eval $(/usr/local/bin/docker-machine env --no-proxy)

I also faced this problem and for me this one worked:

docker-machine regenerate-certs -f

I'm thinking it's possible that you have to run the docker-machine regenerate-certs -f from OUTSIDE the VM. It wasn't working for me at first, but it did work after restarting the whole darn thing and before jumping into the VM. Those old certs were still present even after re-creating the servers, so regenerating certs is a necessity no matter what.

I've been battling the same thing for a day or so. I found that my docker client was talking to the daemon through my proxy server. I added an exclusion and now everything works

Exporting NO_PROXY worked for me on Mac OS @milljm. That gets the job done for me on OS X although I think the --no-proxy option highlighted by @nathanleclaire is how I'll do it going forward. Thanks for pointing that out!

Was this page helpful?
0 / 5 - 0 ratings