requests.exceptions.SSLError: hostname '192.168.59.103' doesn't match 'boot2docker'

[tbronchain]

Hey guys,

I'm try to access some boot2docker (1.3.1 - mac) VMs built under custom name with docker-py (latest pip version - 0.6.0), and it seems there is something wrong in the SSL module.

[thibaultbronchain@mactibo ~:]$    export DOCKER_HOST=tcp://192.168.59.103:2376
[thibaultbronchain@mactibo ~:]$    export DOCKER_CERT_PATH=/Users/thibaultbronchain/.boot2docker/certs/Docker-Wordpress-NoASG-DualNode-0
[thibaultbronchain@mactibo ~:]$    export DOCKER_TLS_VERIFY=1
[thibaultbronchain@mactibo ~:]$python
Python 2.7.6 (default, Sep  9 2014, 15:04:36)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import docker
>>> from docker.client import Client
>>> from docker.utils import kwargs_from_env
>>> client = docker.Client(**kwargs_from_env())
>>> kwargs_from_env()
{'tls': <docker.tls.TLSConfig object at 0x10a970b10>, 'base_url': 'https://192.168.59.103:2376'}
>>> client.images()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Python/2.7/site-packages/docker/client.py", line 634, in images
    res = self._result(self._get(self._url("/images/json"), params=params),
  File "/Library/Python/2.7/site-packages/docker/client.py", line 76, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Library/Python/2.7/site-packages/requests/sessions.py", line 469, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Python/2.7/site-packages/requests/sessions.py", line 457, in request
    resp = self.send(prep, **send_kwargs)
  File "/Library/Python/2.7/site-packages/requests/sessions.py", line 569, in send
    r = adapter.send(request, **kwargs)
  File "/Library/Python/2.7/site-packages/requests/adapters.py", line 420, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: hostname '192.168.59.103' doesn't match 'boot2docker'
>>> ^D
[thibaultbronchain@mactibo ~:]$docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE

Thanks for the help!

[cglewis]

I was able to fix this by adding an entry to /etc/hosts on OSX:
192.168.59.103 boot2docker
then exporting like so:
export DOCKER_HOST=tcp://boot2docker:2376

This is because SSL certs are signed against hostnames not IP addresses. Alternatively you could turn off the TLS_VERIFY, and it will ignore hostname mismatches.

[tbronchain]

Thanks!
It seems like to disable TLS, the only solution is to change the configuration file within the VM (any other solution in mind?).
-- Forget what I just said, it seems it's possible to disable TLS by editing the VM configuration file.
I'll use the host file solution.

[defermat]

@tbronchain did you try:
export DOCKER_TLS_VERIFY=

[tbronchain]

Actually after a lot of try yesterday, I still didn't manage to get it working. But I think it's a boot2docker issue rather than docker-py (reason why I closed this issue and opened another on in their repo - which didn't have been answered yet).

The problem is, boot2docker always require a TLS authentication, unless I add this DOCKER_TLS=no in a file within the VM (it doesn't work actually if you add it to the VM config file). This is really annoying because, in my case (I want to automate boot2docker deployments within a python software), well, I can't SSH the VM! (or it would be a very dirty hack). Using export DOCKER_TLS_VERIFY= then don't fix the issue (the boot2docker VM refuses the connection).
I tried to add the entry to my host files and, surprisingly, it didn't work. It seems anyway like not being a reasonable fix for my needs.

Thanks for the help anyway!

[anentropic]

@cglewis workaround works for me

[indygreg]

Modifying /etc/hosts is not a workaround available to everybody.

Disabling verification completely defeats the point.

The reason why assert_hostname=False isn't working is because of a bug in urllib3. See urllib3/urllib3#524.

This package is using urllib3 via requests. Downgrading requests to 2.4.3 will make assert_hostname=False work again (the first buggy version of urllib3 was included in requests 2.5.0). It will be safe to upgrade once urllib3 releases a fix and once requests imports that fix into their distribution. Alternatively, docker-py could change the import logic in docker.ssladapter.ssladapter to favor urllib3 over requests.packages.urllib3.

[anentropic]

assert_hostname=False seems to work without the /etc/hosts entry in recent boot2docker versions

[indygreg]

I spent a good chunk of time yesterday stepping through the debugger until I found some certificate verification code doing something it shouldn't have been with assert_hostname=False. I can tell you with confidence there is a bug in urllib3. The issue on their tracker (urllib3/urllib3#524) all but confirms it. See also #424, where someone else recently encountered this same issue.

On my machine, I can guarantee that assert_hostname=False used to work but no longer works with modern versions of urllib3/requests.

There may be co-dependency on Python 2.7.9 to reproduce this bug. When I was stepping through the code, I believe urllib3 was interacting with parts of ssl that weren't introduced until 2.7.9.

[mcfiredrill]

Running into this issue via fig.

[mparker17]

Is it worth re-opening this issue until it's been fixed upstream?

I can confirm that I'm getting the error on Mac OS/X 10.10.1 (14B25) "Yosemite", running Python 2.7.8, Boot2Docker-cli version: v1.4.1 (Git commit: 43241cb), fig 1.0.1, and VirtualBox 4.3.20 r96996.

[shin-]

Does this help? #424 (comment)

[dzwicker]

using the /etc/hosts fix works. But make sure to use
export DOCKER_HOST=tcp://boot2docker:2376
after the call to
$(boot2docker shellinit)
as it reexport the DOCKER_HOST with the ip i think.

[indygreg]

Yes, updating /etc/hosts is a workaround. But not every user has permission to update /etc/hosts. This includes my use case, where I'm using docker-py as part of testing automation and the Docker hostname is not static. Requiring root or write privileges to /etc/hosts is a non-starter.

[tbronchain]

Same problem here. I'm using docker-py to develop an automation tool,
automatically editing /etc/hosts file doesn't fit my needs.
Also, I may have multiple VMs running, and in this case, the hosts fix is
invalid.

On Wed, Jan 7, 2015 at 3:13 AM, Gregory Szorc notifications@github.com
wrote:

Yes, updating /etc/hosts is a workaround. But not every user has
permission to update /etc/hosts. This includes my use case, where I'm
using docker-py as part of testing automation and the Docker hostname is
not static. Requiring root or write privileges to /etc/hosts is a
non-starter.

—
Reply to this email directly or view it on GitHub
#406 (comment).

[shin-]

Guys, you need to report that to the boot2docker maintainers, there's nothing I can do at my level about this issue.

[indygreg]

You can work around this in docker-py. Read #406 (comment) again.

You could also throw a big giant warning in the docs that urllib3/requests is busted so future souls don't have to search out this issue.

[indygreg]

Also, this is purely a Python bug, not a boot2docker bug.

[shin-]

Sure, but ideally assert_hostname=True should work in the context of boot2docker, too. But I'll look into the proposed fixes, thanks.

[shin-]

Hopefully this helps 7a623c4

[shin-]

Also note that if the bug was indeed introduced in requests>=2.5.0, you shouldn't have any issue using the pinned dependencies from the requirements.txt file, which states requests==2.2.1.

[indygreg]

requirements.txt files are typically intended for "complete environments." In many cases, docker-py is used as a library as part of a larger tool. As such, its requirements.txt are likely completely ignored. A better way to do version enforcement is with install_requires in setup.py. See https://packaging.python.org/en/latest/requirements.html. Please note that it is not a good practice to pin versions in install_requires (like it is in requirements.txt).

[shin-]

I understand this, which is why we have strict requirements in requirements.txt and minimum requirements in setup.py (although if it was entirely up to me I'd pin versions everywhere ~ but that's another debate).

I only wanted to provide as much information as possible for people that might be affected. :) next release will prioritize system-provided urllib3 over the vendored version, so we should cover most cases this way.

Thank you for helping resolve this.