Я думаю, что испытываю то же самое, пытаясь использовать релиз-кандидата docker-compose ...

$ docker-compose ps
SSL error: hostname '192.168.59.103' doesn't match 'boot2docker'

Но fig отлично работает ...

$ fig -f docker-compose.yml ps
Name   Command   State   Ports
------------------------------

Я использую OSX, использую все те же версии, что и @gkostyanikov , за исключением того, что моя версия клиента Go - go1.3.3 . Мой python / openssl также устанавливается через Homebrew. Может быть, это как-то связано?

Изменить: на самом деле похоже, что Homebrew не связывает openssl, поэтому я использую версию OSX по умолчанию: OpenSSL 0.9.8za 5 Jun 2014 .

Проблема заключалась в доморощенном питоне.

docker-compose теперь работает после удаления homebrew python / openssl, установки pip с помощью easy_install и переустановки docker-composer с использованием системного python.

@adambiggs Ваше решение работает! Благодаря!

Это тоже сработало для меня, я использую новый Mac и настроил его с помощью homebrew python. Была эта ошибка с фиг при общении с докером. Дословно последовал совету

Это тоже происходит со мной. И я не хочу использовать системный питон, у кого-нибудь есть другое решение?

Вы пробовали использовать двоичный файл? У вас такая же проблема?

Нет, я не пробовал двоичный файл.
Если вы не хотите устанавливать его на свой системный Python, другой способ обхода - использовать virtualenv (оболочка).

mkvirtualenv --python=/usr/bin/python docker-compose
pip install docker-compose==1.1.0-rc2

Нашел лучшее решение, используя pyenv для отката до python 2.7.8:

http://stackoverflow.com/a/28216459/1166293
https://github.com/yyuu/pyenv

Изменить: Nevermind, pyenv представил кучу собственных проблем ...

Причиной этой ошибки для меня было то, что домашний openssl не был связан с / usr / local / bin / openssl.

openssl version

вернулся OpenSSL 0.9.8zc 15 октября 2014 г., а не OpenSSL 1.0.1j 15 октября 2014 г.

Бег

brew link --force openssl

и переустановка фига решила проблему.

Интересно, но моя версия OpenSSL -

@aan, а в моем случае у двоичного

Я получил эту ошибку, когда у меня был установлен fig через pip, а не homebrew. sudo pip uninstall fig и brew install fig исправили это для меня.

+1 для решения @NotBobTheBuilder , также работал у меня

: +1: для @NotBobTheBuilder

@NotBobTheBuilder хорошее решение для fig, но docker-compose, к сожалению, пока недоступен для homebrew.

@ocasta как насчет этого пугающего предупреждения от доморощенного о связывании OpenSSL?

Эта формула предназначена только для кег.
Mac OS X уже предоставляет это программное обеспечение и устанавливает другую версию в
параллель может вызвать всевозможные проблемы.

Apple отказалась от использования OpenSSL в пользу собственных TLS и криптобиблиотек.

Недурно @NotBobTheBuilder - У меня это тоже исправило.

кто-нибудь знает источник этой проблемы? это со мной происходит с рисом. Я предпочитаю придерживаться pip install fig как сейчас. Пару недель назад все работало нормально, не знаю, что изменилось в моей системе

Моя система OpenSSL - OpenSSL 0.9.8zc 15 Oct 2014 , мой доморощенный openssl новее, но не связан.

... Я предполагаю, что он сломался, когда я обновился до Python 2.7.9, похоже, в нем есть некоторые ошибки, связанные с SSL ... выглядит примерно так:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

запуск brew link --force openssl и переустановка фига ничего не сделали для меня.

Требуется ли обновление fig, чтобы обойти изменения SSL в Py 2.7.9?
https://www.python.org/dev/peps/pep-0476/#opting -out

Я использую boot2docker. Я только что обновился до 1.5.0, но без изменений.

In [1]: from fig.cli.docker_client import docker_client

In [2]: client = docker_client()

In [3]: client.version()

SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

In [4]: %debug
> /Users/anentropic/.virtualenvs/dpm/lib/python2.7/site-packages/requests/sessions.py(461)request()
    460         send_kwargs.update(settings)
--> 461         resp = self.send(prep, **send_kwargs)
    462

ipdb> p settings
{'verify': '/Users/anentropic/.boot2docker/certs/boot2docker-vm/ca.pem', 'cert': ('/Users/anentropic/.boot2docker/certs/boot2docker-vm/cert.pem', '/Users/anentropic/.boot2docker/certs/boot2docker-vm/key.pem'), 'proxies': {}, 'stream': False}

Код fig выглядит правильно, он пытается использовать сертификаты, установленные boot2docker ... Я предполагаю, что эти сертификаты в порядке, потому что они всегда работали, и я только что обновил b2d, чтобы срок их действия не истек.

Хм, мой Python (установленный через homebrew), похоже, использует доморощенную версию OpenSSL:

$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.2 22 Jan 2015

$ brew info openssl
openssl: stable 1.0.2 (bottled)
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/openssl/certs

and run
  /usr/local/opt/openssl/bin/c_rehash

... запуск /usr/local/opt/openssl/bin/c_rehash не помог :)

Я попробовал ранее установленную версию python (2.7.8_2) через $ brew switch python 2.7.8_2 с той же проблемой (даже если сообщение об ошибке было немного другим). Таким образом, версия python 2.7.9, похоже, не проблема.

Затем я попытался перейти на старую версию openssl, с 1.0.2 на 1.0.1j_1, которая, похоже, работает.

$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.2 22 Jan 2015
$ docker-compose ps
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
$ brew switch openssl 1.0.1j_1
$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.1j 15 Oct 2014
$ docker-compose ps
Name   Command   State   Ports 
------------------------------

Для меня я просто получаю другую ошибку, но, возможно, это помогает сузить то, что не так:

$ brew switch openssl 1.0.1j_1
Error: openssl does not have a version "1.0.1j_1" in the Cellar.
Versions available: 1.0.1e, 1.0.1f, 1.0.1g, 1.0.2
$ brew switch openssl 1.0.1g
Opt link created for /usr/local/Cellar/openssl/1.0.1g
$ fig up
SSL error: hostname '192.168.59.103' doesn't match 'boot2docker'

При обратном переключении на OpenSSL 1.0.2 возникает предыдущая ошибка CERTIFICATE_VERIFY_FAILED поэтому изменение версии определенно имеет некоторый эффект.

Одно из решений - запустить docker-compose в контейнере:

git clone [email protected]:docker/fig.git
cd fig
docker build --tag docker-compose .

alias docker-compose='docker run --rm -e "DOCKER_TLS_VERIFY=$DOCKER_TLS_VERIFY" -e DOCKER_HOST=tcp://172.17.42.1:2376 -e DOCKER_CERT_PATH=/usr/local/certs -v "$DOCKER_CERT_PATH:/usr/local/certs" -v "$PWD:/code" docker-compose --project-name "${PWD##*/}"'

Для этого необходимо открыть порт 2376 в VirtualBox:

VBoxManage controlvm boot2docker-vm natpf1 "docker-s,tcp,127.0.0.1,2376,,2376"

Ответ @kretz сработал для меня.

+1 @kretz brew switch openssl 1.0.1j_1
сделал трюк

brew switch openssl 1.0.1j у меня работает (обратите внимание на отсутствие _1)

Мне это не нравится, но удаление fig из моего virtualenv и установка через homebrew исправили для меня кое-что.

Спасибо @kretz - ваш ответ решил это для меня!

У меня это не работает, потому что:

$ brew switch openssl 1.0.1j_1
Error: openssl does not have a version "1.0.1j_1" in the Cellar.
Versions available: 1.0.2

Мое обходное решение заключалось в том, чтобы создать virtualenv с python 2.7.8, а не с 2.7.9, которую я получил от brew.

различные обходные пути ... есть ли у кого-нибудь представление о реальной проблеме?

причем тут App Engine?

11 марта 2015 года в 18:09 Райан Смолл [email protected] написал:

Я почти уверен, что ни один из движков приложений не работает с python 2.7.9.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/compose/issues/890#issuecomment -78329652.

@anentropic Вам необходимо установить старую версию openssl, прежде чем вы сможете использовать ее (переключиться на нее).

# Find available older versions to install
$ brew search openssl
openssl
homebrew/versions/openssl098  homebrew/versions/openssl101

# Install older 1.0.1 version
$ brew install homebrew/versions/openssl101

# See what versions are installed locally
$ brew info openssl
...
/usr/local/Cellar/openssl/1.0.1f (429 files,  15M)
  Built from source
/usr/local/Cellar/openssl/1.0.1i (430 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.1j (431 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.1j_1 (431 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.2 (459 files,  18M)
  Poured from bottle
...

# Switch to one of the 1.0.1 you got installed
$ brew switch openssl 1.0.1j_1

Я сделал brew install openssl101 но это не дало мне возможности переключиться на 1.0.1j ... это дало мне 1.0.1l и я беспокоился, что это запутает мою систему, так как это отдельные пакеты для варки, и у меня уже было 1.0.2 параллельно

похоже, не помогло, но, может быть, я недостаточно далеко зашел с этим

Извините, я ответил не на ту проблему с github (быстро удалил свой комментарий)
В среду, 11 марта 2015 г., в 11:30 anentropic [email protected]
написал:

Я заварил установку openssl101, но это не дало мне возможности
переключился на 1.0.1j ... он дал мне 1.0.1l, и я волновался, что он
запутать мою систему, так как это отдельные пакеты для варки, и у меня уже есть
1.0.2 параллельно

похоже, не помогло, но, может быть, я недостаточно далеко зашел с этим

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/compose/issues/890#issuecomment -78340580.

Так что я, похоже, тоже сталкиваюсь с этой проблемой, работая на Mac OSX. Используя docker-compose, это мой файл .yml.

web:
    build: .
    links:
        - db
        - cache
        - worker
    ports:
        - "8080:8080"
db:
    image: mysql
cache:
    image: redis
worker:
    build: .
    command: celery -A application.extentions worker -l info

При запуске docker-compose pull я получаю следующий результат, который не удался.

$ docker-compose pull
Pulling db (mysql:latest)...
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Кое-что я проверил.
which openssl; openssl version

/usr/local/bin/openssl
OpenSSL 1.0.2 22 Jan 2015

@psykzz Должно работать, если вы устанавливаете с пивом

brew install docker-compose

@arvindtest, что заставляет вас думать, что это связано с этой проблемой?

К вашему сведению, после долгой борьбы с этим оказалось, что это проблема boot2docker.
У меня сработало отключение TLS. Пока еще нет удобного способа сделать это, но инструкции приведены здесь:
https://github.com/deis/deis/issues/2230

В основном вам необходимо:

boot2docker ssh
sudo echo 'DOCKER_TLS = no'> / var / lib / boot2docker / profile

затем перезапустите boot2docker, т.е.
boot2docker стоп
запуск boot2docker

и что-то вроде этого в ваш ~ / .bashrc (убедитесь, что ip правильный)

экспорт DOCKER_HOST = tcp: //192.168.59.103 : 2375
сбросить DOCKER_CERT_PATH
сбросить DOCKER_TLS_VERIFY

В вашем bashrc почему бы просто не иметь $ (boot2docker shellinit)

Должно помочь во всем правильно?

Я имею в виду, что вам все еще нужно использовать решение TLS.
21 марта 2015 г. в 23:05 "coderfi" [email protected] написал:

К вашему сведению, после долгой борьбы с этим кажется, что это
проблема с boot2docker.
У меня сработало отключение TLS. Еще нет удобного способа
для этого, но инструкции изложены здесь:
deis / deis # 2230 https://github.com/deis/deis/issues/2230

В основном вам необходимо:

boot2docker ssh
sudo echo 'DOCKER_TLS = no'> / var / lib / boot2docker / profile

затем перезапустите boot2docker, т.е.
boot2docker стоп
запуск boot2docker

и что-то вроде этого в ваш ~ / .bashrc
убедитесь, что IP правильный

экспорт DOCKER_HOST = tcp: //192.168.59.103 : 2375
сбросить DOCKER_CERT_PATH
сбросить DOCKER_TLS_VERIFY

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/compose/issues/890#issuecomment -84468058.

@kretz работает! Благодарю.

@psykzz вы имеете в виду $(boot2docker shellinit) ?

да, я обновил свой комментарий. сумасшедший.

Я могу подтвердить, что решение @coderfi для отключения TLS у меня работает!

Рад, что это сработало для вас. :)

@Matt да, вы правы насчет подсказки расширения оболочки init оболочки.
Однако это может не сработать, если boot2docker еще не запущен, поэтому я просто
сделал пример явным.

Fi
26 марта 2015 г., 10:18, "anentropic" [email protected] написал:

Я могу подтвердить, что решение @coderfi https://github.com/coderfi для
отключить TLS у меня работает!

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/compose/issues/890#issuecomment -86630313.

Возможно, это очевидно, но тем, кто отключает TLS или понижает версию OpenSSL только для того, чтобы заставить эту работу работать, следует действовать осторожно, в зависимости от того, что они делают.

Это не относится ко всем, но у меня возникла аналогичная ошибка во время установки pip с использованием Dockerfile извлекаемого из gliderlabs/alpine:3.1 - минимального контейнера Linux от progrium & team. Проблема заключалась в том, что я не установил пакет системных сертификатов, проблема была устранена установкой пакета перед установкой pip и запуском файла требований:

RUN apk-install -X ca-certificates

Предлагаемые решения не помогли мне. Не удалось переключиться ни на одну из версий 1.0.1 OpenSSL. В конце концов, я обнаружил, что удаление всех установленных pip версий docker-compose и простое выполнение brew install docker-compose каким-то образом работает.

Приведенные выше решения работали, но были для меня слишком громоздкими. Быстрый boot2docker upgrade исправил все на моей стороне.

У меня уже есть последняя версия boot2docker, и она не работает для меня без исправлений выше

Разработчики Homebrew предлагают обновить docker-py и docker-compose до requests 2.6.0

https://github.com/Homebrew/homebrew/issues/38226#issuecomment -88083428

Надеюсь, это поможет кому-то ... не уверен в решении, но если вы используете Charles в качестве прокси Mac OS X, это вызовет это сообщение.

FWIW, установка docker-compose через pip заставила работать docker-compose (установка через curl в OS X Mavericks привела к ошибке illegal operation ). Впоследствии я также получал ошибку SSL. Запуск brew link --force openssl && brew switch openssl 1.0.1j кажется, исправил это для меня.

@rseymour ответ сработал для меня

Для тех, кто не может найти openssl-1.0.1j в brew - вы можете взять старую версию рецепта openssl из репозитория github и использовать ее:

» brew switch openssl 1.0.1j
Error: openssl does not have a version "1.0.1j" in the Cellar.
Versions available: 1.0.2a-1
» brew unlink openssl
Unlinking /usr/local/Cellar/openssl/1.0.2a-1... 1543 symlinks removed
» brew install https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
...
🍺  /usr/local/Cellar/openssl/1.0.1j_1: 431 files, 14M, built in 4.2 minutes
» docker-compose up                                                                                                                   
Creating myservice...

Я пробовал 1.0.1m, но ничего не вышло.
Я попробовал использовать @lazyval , у меня он работает.
Вот что я сделал.

brew установить https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
варить переключатель openssl 1.0.1j_1
brew unlink openssl101 // Потому что я связал 1.0.1m до этого
варить ссылку openssl --force
docker-compose ps

Спасибо!!

В настоящее время я изучаю это, так как теперь нам нужно собрать двоичные файлы на Python 2.7.9+.

_Перемещен из # 1427_

Сервер:

• CoreOS стабильная
• Докер 1.5.0

Клиент:

• CentOS 6.6, 64-битная
• ядро 2.6.32-042stab105.14
• Клиент Docker 1.5.0
• докер-составить 1.2.0
• SSL-сертификаты размещены в ~/.docker/{ca.pem,cert.pem,key.pem}
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

Использование следующего Makefile для создания сертификатов SSL:

#!/bin/bash

SERVER=docker-builder

clean:
    rm ca.* server.* client.* *.key

all: ca.crt server.crt client.crt

%.key:
    openssl genrsa -out $@ 4096

ca.crt: ca.key
    openssl req -new -x509 -days 365 -key ca.key -sha256 -out ca.crt \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=${SERVER}/[email protected]"

server.csr: server.key
    openssl req -new -key server.key -out server.csr \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=${SERVER}/[email protected]"

server.crt: ca.key ca.crt server.csr
    openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key \
        -CAcreateserial -out server.crt

client.csr: client.key
    openssl req -new -key client.key -out client.csr \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=Docker Client/[email protected]"

client.ext.cnf:
    echo "extendedKeyUsage = clientAuth" > client.ext.cnf

client.crt: client.csr ca.crt ca.key client.ext.cnf
    openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key \
        -CAcreateserial -out client.crt -extfile client.ext.cnf

Вот (по общему признанию, не идеальный) сценарий пользовательских данных для подготовки этой машины:

#cloud-config

write_files:
    - path: /home/core/server.crt
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN CERTIFICATE-----
        <cert goes here>
        -----END CERTIFICATE-----


    - path: /home/core/server.key
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN RSA PRIVATE KEY-----
        <key goes here>
        -----END RSA PRIVATE KEY-----


    - path: /home/core/ca.crt
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN CERTIFICATE-----
        <ca cert goes here>
        -----END CERTIFICATE-----

coreos:
  update:
    reboot-strategy: reboot
  units:
  units:
    - name: var-lib-docker.mount
      command: start
      content: |
        [Unit]
        Description=Mount RAM to /var/lib/docker
        Before=docker.service
        [Mount]
        What=tmpfs
        Where=/var/lib/docker
        Type=tmpfs
        Options=size=200g
    - name: docker.service
      command: restart
      content: |
        [Unit]
        Description=Docker Application Container Engine
        Documentation=http://docs.docker.io
        After=network.target
        [Service]
        ExecStartPre=/bin/mount --make-rprivate /
        # Run docker but don't have docker automatically restart
        # containers. This is a job for systemd and unit files.
        ExecStart=/usr/bin/docker -d \
          --tlsverify \
          --tlscert=/home/core/server.crt \
          --tlscacert=/home/core/ca.crt \
          --tlskey=/home/core/server.key \
          -H 0.0.0.0:2376 -H unix:///var/run/docker.sock

        [Install]
        WantedBy=multi-user.target

Используя клиент docker я успешно получаю доступ к удаленному серверу докеров. Мы звоним на удаленный сервер до ста тысяч раз в день с хорошим успехом.

При попытке использовать docker-compose , установленный либо через curl ИЛИ pip install --upgrade с python 2.7, мы получаем ошибку SSL:

$ docker-compose up -d
SSL error: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Это происходит после ручного указания DOCKER_CERT_PATH=/home/user/.docker/ а также REQUESTS_CA_BUNDLE=/home/user/.docker/ca.pem отдельности и вместе.

Чтобы было ясно: эта установка отлично работает с демоном докеров, но что-то в -compose не так.

Некоторые примечания:

1. Бинарный файл Compose 1.3.0 RC1 для OSX содержит эту ошибку. Наверное, не случайно, это первый раз, когда он был построен против Python 2.7.9 - раньше это было 2.7.6.
2. Как ни странно, я могу воспроизвести на виртуальной машине boot2docker, но не на виртуальной машине Virtualbox, предоставленной Машиной. @ehazlett , @nathanleclaire , @tianon - есть какие-нибудь идеи?
3. Всем, кто сталкивается с этим, когда Compose установлен с Pip, сообщите о выводе следующих команд:

$ python -V $ python -c 'import ssl; print ssl.OPENSSL_VERSION'

На моем локальном компьютере, где я могу воспроизвести ошибку, у меня есть Python 2.7.10 и OpenSSL 1.0.2a 19 Mar 2015 .

1. Об этом сообщили Homebrew, и некоторые люди говорят, что им удалось переустановить Python и OpenSSL, но у меня это не сработало. https://github.com/Homebrew/homebrew/issues/38226

Хм, это действительно странно. Какую версию b2d вы используете по сравнению с версией
машины? Мы оба используем b2d, поэтому я не уверен, что будет по-другому
помимо версии.

Я установлю через pip на свой компьютер с OS X и посмотрю, что у меня получится.

Чт, 28 мая 2015 г., в 9:19, Аананд Прасад [email protected]
написал:

Некоторые примечания:

1.

Бинарный файл Compose 1.3.0 RC1 для OSX содержит эту ошибку. Возможно нет
по совпадению, это первый раз, когда он был построен против Python 2.7.9.

• раньше было 2.7.6.
  2.

Как ни странно, я могу воспроизвести на виртуальной машине boot2docker, но не на
Виртуальная машина Virtualbox, подготовленная машиной. @ehazlett
https://github.com/ehazlett , @nathanleclaire
https://github.com/nathanleclaire , @tianon
https://github.com/tianon - есть какие-нибудь идеи?
3.

Всем, кто сталкивается с этим, когда Compose установлен с Pip, пожалуйста
сообщить о выводе следующих команд:

$ python -V
$ python -c 'import ssl; напечатать ssl.OPENSSL_VERSION '

На моем локальном компьютере, где я могу воспроизвести ошибку, у меня есть Python
2.7.10 и OpenSSL 1.0.2a 19 марта 2015 г.
4.

Об этом сообщили Homebrew, и некоторые люди говорят, что
успешная переустановка Python и OpenSSL, но у меня это не сработало.
Домашнее пиво / homebrew # 38226
https://github.com/Homebrew/homebrew/issues/38226

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/compose/issues/890#issuecomment -106306690.

$ boot2docker version
Boot2Docker-cli version: v1.6.2
Git commit: cb2c3bc

$ docker-machine --version
docker-machine version 0.2.0 (8b9eaf2)

Может быть, в генерации сертификатов что-то другое? Кажется, у меня больше файлов в каталоге сертификатов моей машины, чем в каталоге boot2docker.

$ $(boot2docker shellinit)
$ ls -l $DOCKER_CERT_PATH/*.pem
-rw-r--r--  1 aanand  staff  1042 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
-rw-r--r--  1 aanand  staff  1070 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
-rw-r--r--  1 aanand  staff  1675 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem

$ eval "$(docker-machine env)"
$ ls -l $DOCKER_CERT_PATH/*.pem
-rw-r--r--  1 aanand  staff  1029 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/ca.pem
-rw-r--r--  1 aanand  staff  1054 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/cert.pem
-rw-r--r--  1 aanand  staff  1679 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/key.pem
-rw-------  1 aanand  staff  1679 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/server-key.pem
-rw-r--r--  1 aanand  staff  1086 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/server.pem

Это нормально. Клиент просто будет использовать ca.pem, cert.pem и key.pem
(сервер - это просто локальная копия для хоста на машине). Я буду творить как
ну и проверьте сертификаты, чтобы увидеть, в чем может быть разница.

Чт, 28 мая 2015 г., в 9:30, Аананд Прасад [email protected]
написал:

версия $ boot2docker
Версия Boot2Docker-cli: v1.6.2
Git commit: cb2c3bc

$ docker-machine --version
докер-машина версии 0.2.0 (8b9eaf2)

Может быть, в генерации сертификатов что-то другое? Кажется, у меня больше
файлы в каталоге сертификатов моей машины, чем в моем boot2docker.

$ $ (shellinit boot2docker)
$ ls -l $ DOCKER_CERT_PATH / *. pem
-rw-r - r-- 1 aanand staff 1042 28 мая 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
-rw-r - r-- 1 aanand staff 1070 28 мая 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
-rw-r - r-- 1 aanand staff 1675 28 мая 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem

$ eval "$ (окружение докер-машины)"
$ ls -l $ DOCKER_CERT_PATH / *. pem
-rw-r - r-- 1 aanand staff 1029 11 мая 12:15 /Users/aanand/.docker/machine/machines/dev/ca.pem
-rw-r - r-- 1 aanand staff 1054 11 мая 12:15 /Users/aanand/.docker/machine/machines/dev/cert.pem
-rw-r - r-- 1 aanand staff 1679 11 мая 12:15 /Users/aanand/.docker/machine/machines/dev/key.pem
-rw ------- 1 aanand staff 1679 11 мая 12:15 /Users/aanand/.docker/machine/machines/dev/server-key.pem
-rw-r - r-- 1 aanand staff 1086 11 мая 12:15 /Users/aanand/.docker/machine/machines/dev/server.pem

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/compose/issues/890#issuecomment -106309885.

grahamc@snap$ python -V
Python 2.7.6

grahamc@snap$ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.1e-fips 11 Feb 2013

См. Также https://github.com/docker/docker-py/issues/465. Тестовый скрипт @garethr также воспроизводит ошибку для меня, после внесения одной модификации, чтобы отключить проверку имени хоста:

from docker.client import Client
from docker.utils import kwargs_from_env

kwargs = kwargs_from_env()
kwargs['tls'].assert_hostname = False

client = Client(**kwargs)
print client.version()

$ eval "$(boot2docker shellinit)" && python test.py
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    print client.version()
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 1108, in version
    return self._result(self._get(url), json=True)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 106, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 477, in get
    return self.request('GET', url, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", line 431, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

Тем не менее, он по-прежнему работает с виртуальной машиной, подготовленной машиной:

$ eval "$(docker-machine env)" && python test.py
{u'KernelVersion': u'4.0.3-boot2docker', u'Arch': u'amd64', u'ApiVersion': u'1.18', u'Version': u'1.6.2', u'GitCommit': u'7c8fca2', u'Os': u'linux', u'GoVersion': u'go1.4.2'}

Если я снова включу проверку имени хоста (закомментировав строку assert_hostname в тестовом сценарии), произойдет сбой с той же ошибкой для виртуальной машины boot2docker-cli, но с другой ошибкой для виртуальной машины машины, которая может или может не иметь отношения:

Traceback (most recent call last):
  File "test.py", line 8, in <module>
    print client.version()
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 1108, in version
    return self._result(self._get(url), json=True)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 106, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 477, in get
    return self.request('GET', url, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", line 431, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: no appropriate commonName or subjectAltName fields were found

Кроме того, я попытался использовать v1.3.0-rc1 через curl (двоичный выпуск, а не через pip) и получил ту же ошибку, что и раньше, на демоне docker 1.6.2:

SSL error: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Да, двоичный файл RC1 был построен с использованием Python 2.7.9 и OpenSSL 1.0.2a, что кажется одной из проблемных комбинаций.

Это имеет смысл, потому что я считаю, что генерация сертификатов в b2d находится на виртуальной машине.
тогда как машина генерирует их в машине. Мы могли обнаружить и добавить
имя машины в сети SAN, если необходимо. На самом деле это, наверное, было бы хорошо
особенно для ВМ b2d. Я думаю, что это работает сейчас потому, что ты
получить доступ к ядру, используя IP-адрес, который машина добавляет как IP-сеть SAN. Существует
PR открыт, чтобы разрешить произвольные дополнительные SAN, которые тоже будут работать.

В четверг, 28 мая 2015 года, Ананд Прасад [email protected] написал:

См. Также docker / docker-py # 465
https://github.com/docker/docker-py/issues/465. @garethr
https://github.com/garethr тестовый скрипт воспроизводит ошибку для
я тоже, после внесения одной модификации, чтобы отключить проверку имени хоста:

from docker.client import Clientfrom docker.utils import kwargs_from_env

kwargs = kwargs_from_env ()
kwargs ['tls']. assert_hostname = Ложь

client = Клиент (** kwargs) print client.version ()

$ eval "$ (boot2docker shellinit)" && python test.py
Написание /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Написание /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Написание /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Отслеживание (последний вызов последний):
Файл "test.py", строка 8, в
напечатать client.version ()
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", строка 1108, в версии
вернуть self._result (self._get (url), json = True)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", строка 106, в _get
вернуть self.get (url, * _self._set_request_timeout (kwargs))
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", строка 477, в get
return self.request ('GET', url, * _kwargs)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", строка 465, в запросе
resp = self.send (подготовка, * _send_kwargs)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", строка 573, в отправке
r = adapter.send (запрос, * _kwargs)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", строка 431, в отправке
поднять SSLError (e, request = request)
request.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] не удалось проверить сертификат (_ssl.c: 590)

Тем не менее, он по-прежнему работает с виртуальной машиной, подготовленной машиной:

$ eval "$ (docker-machine env)" && python test.py
{u'KernelVersion ': u'4.0.3-boot2docker', u'Arch ': u'amd64', u'ApiVersion ': u'1.18', u'Version ': u'1.6.2', u'GitCommit ': u'7c8fca2', u'Os ': u'linux', u'GoVersion ': u'go1.4.2'}

Если я снова включу проверку имени хоста (закомментировав assert_hostname
строки в тестовом сценарии), он не работает с _ той же ошибкой_ для
boot2docker-cli VM, но с _другой ошибкой_ для Machine VM, которая
могут иметь значение, а могут и не иметь:

Отслеживание (последний вызов последний):
Файл "test.py", строка 8, в
напечатать client.version ()
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", строка 1108, в версии
вернуть self._result (self._get (url), json = True)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", строка 106, в _get
вернуть self.get (url, * _self._set_request_timeout (kwargs))
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", строка 477, в get
return self.request ('GET', url, * _kwargs)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", строка 465, в запросе
resp = self.send (подготовка, * _send_kwargs)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", строка 573, в отправке
r = adapter.send (запрос, * _kwargs)
Файл "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", строка 431, в отправке
поднять SSLError (e, request = request)
request.exceptions.SSLError: не найдено подходящих полей commonName или subjectAltName

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/compose/issues/890#issuecomment -106363305.

Хорошо, я считаю, что нашел исправление для OS X: https://github.com/docker/compose/pull/1474

Исправление этого для Linux потребует обновления Dockerfile для привязки к Python 2.7.9 и OpenSSL 1.0.1, что будет забавным делом, учитывая, что оно начинается с debian:wheezy (что необходимо для гарантии того, что мы используем достаточно старый glibc - см. https://github.com/docker/compose/pull/505).

Переключение на 1.0.1k, как описано в комментарии @kretz , и установка 1.3.0 RC1 через pip

Перед переключением python сообщил 1.0.2a:

❯ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.2a 19 Mar 2015

После переключения он сообщил, что 1.0.1k, и docker-compose, похоже, работает должным образом:

❯ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.1k 8 Jan 2015

обходной путь, который устранил эту ошибку, заключался в установке следующих пакетов в моем virtualenv
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

В среде, описанной на https://github.com/docker/compose/issues/890#issuecomment -106289821, которая предоставляет Python 2.7.6 (через snap-ci.com, на котором вы можете получить бесплатную учетную запись)

со следующим сценарием, который использует обходной путь @ jsh2134 в установке pip (https://github.com/docker/compose/issues/890#issuecomment-106806702):

#!/bin/bash

set -e
set -u
set -x


readonly DOCKER_VERSION=1.5.0
readonly TARGETFILE=$SNAP_CACHE_DIR/docker-$DOCKER_VERSION
[[ -f "$TARGETFILE" ]] || curl https://get.docker.io/builds/Linux/x86_64/docker-$DOCKER_VERSION > $TARGETFILE
cp $TARGETFILE ~/docker
chmod +x ~/docker


export DOCKER_HOST="tcp://docker-builds:2376" DOCKER_TLS_VERIFY=1

mkdir -p ~/.docker
cat > ~/.docker/ca.pem <<EOC
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

EOC
cat > ~/.docker/key.pem <<EOC
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

EOC
cat > ~/.docker/cert.pem <<EOC
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
EOC

function install_docker_compose {
  pip install --upgrade pip
  pip install --upgrade docker-compose
  pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7
  export COMPOSE=docker-compose
}

install_docker_compose

export COMPOSE_PROJECT_NAME=$(basename "$(pwd)")-${SNAP_COMMIT:-HEAD}

# Before running anything, setup the EXIT trap to always rm the container on
# exit of the script.
function cleanup {
  $COMPOSE kill
  $COMPOSE rm --force
}

trap cleanup EXIT

$COMPOSE --version
$COMPOSE build
$COMPOSE up -d

set +e
$COMPOSE run $@
exitcode=$?
set -e

set +x
echo ""
echo "Component Data:"
for id in `$COMPOSE ps -q`; do
  ~/docker inspect \
    -f 'Container {{ .Name }} exited with status {{ .State.ExitCode }}' $id
  ~/docker logs $id 2>&1 | sed -e "s/^/        /"
  echo "---"
done

exit $exitcode

Получаю следующий результат:

+ readonly DOCKER_VERSION=1.5.0
+ DOCKER_VERSION=1.5.0
+ readonly TARGETFILE=/var/go/docker-1.5.0
+ TARGETFILE=/var/go/docker-1.5.0
+ [[ -f /var/go/docker-1.5.0 ]]
+ cp /var/go/docker-1.5.0 /var/go/docker
+ chmod +x /var/go/docker
+ export DOCKER_HOST=tcp://docker-builds:2376 DOCKER_TLS_VERIFY=1
+ DOCKER_HOST=tcp://docker-builds:2376
+ DOCKER_TLS_VERIFY=1
+ mkdir -p /var/go/.docker
+ cat
+ cat
+ cat
+ install_docker_compose
+ /bin/true
+ pip install --upgrade pip
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Collecting pip
  Using cached pip-7.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 6.0.8
    Uninstalling pip-6.0.8:
      Successfully uninstalled pip-6.0.8
Successfully installed pip-7.0.1
+ pip install --upgrade docker-compose
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Requirement already up-to-date: docker-compose in /var/go/py-virtualenv2.7/lib/python2.7/site-packages
Requirement already up-to-date: docopt<0.7,>=0.6.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: PyYAML<4,>=3.10 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: requests<2.6,>=2.2.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: texttable<0.9,>=0.8.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: websocket-client<1.0,>=0.11.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: docker-py<1.2,>=1.0.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: dockerpty<0.4,>=0.3.2 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: six<2,>=1.3.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: backports.ssl-match-hostname in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from websocket-client<1.0,>=0.11.0->docker-compose)
+ pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7
Collecting pyopenssl==0.14
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading pyOpenSSL-0.14.tar.gz (128kB)
Collecting ndg-httpsclient==0.4
  Downloading ndg_httpsclient-0.4.0.tar.gz
Collecting pyasn1==0.1.7
  Downloading pyasn1-0.1.7.tar.gz (68kB)
Collecting cryptography>=0.2.1 (from pyopenssl==0.14)
  Downloading cryptography-0.9.tar.gz (302kB)
Requirement already satisfied (use --upgrade to upgrade): six>=1.5.2 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from pyopenssl==0.14)
Collecting idna (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading idna-2.0.tar.gz (135kB)
Requirement already satisfied (use --upgrade to upgrade): setuptools in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from cryptography>=0.2.1->pyopenssl==0.14)
Collecting enum34 (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading enum34-1.0.4.tar.gz
Collecting ipaddress (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading ipaddress-1.0.7-py27-none-any.whl
Collecting cffi>=0.8 (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading cffi-1.0.3.tar.gz (317kB)
Collecting pycparser (from cffi>=0.8->cryptography>=0.2.1->pyopenssl==0.14)
  Downloading pycparser-2.13.tar.gz (299kB)
Installing collected packages: idna, pyasn1, enum34, ipaddress, pycparser, cffi, cryptography, pyopenssl, ndg-httpsclient
  Running setup.py install for idna
  Running setup.py install for pyasn1
  Running setup.py install for enum34
  Running setup.py install for pycparser
  Running setup.py install for cffi
  Running setup.py install for cryptography
  Running setup.py install for pyopenssl
  Running setup.py install for ndg-httpsclient
Successfully installed cffi-1.0.3 cryptography-0.9 enum34-1.0.4 idna-2.0 ipaddress-1.0.7 ndg-httpsclient-0.4.0 pyasn1-0.1.7 pycparser-2.13 pyopenssl-0.14
+ export COMPOSE=docker-compose
+ COMPOSE=docker-compose
+++ pwd
++ basename /var/snap-ci/repo/tests/composer
+ export COMPOSE_PROJECT_NAME=composer-a71ac4f39281a9571a2b5da1284ab1c05da40646
+ COMPOSE_PROJECT_NAME=composer-a71ac4f39281a9571a2b5da1284ab1c05da40646
+ trap cleanup EXIT
+ docker-compose --version
docker-compose 1.2.0
+ docker-compose build
test1 uses an image, skipping
test2 uses an image, skipping
test uses an image, skipping
+ docker-compose up -d
SSL error: [Errno bad handshake] [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]
+ cleanup
+ docker-compose kill
SSL error: [Errno bad handshake] [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]

Обратите внимание на ошибку (которая кажется новой):

/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.

Создал https://github.com/docker/compose/issues/1484, чтобы вывести мои выводы из головы.

Я создал несколько бинарных файлов с исправлением # 1474. Попробуйте их, если у вас возникли проблемы с SSL:

http://cl.ly/3W3a2S3t2c32/download/docker-compose-Linux-x86_64
http://cl.ly/0i00310l3x27/download/docker-compose-Darwin-x86_64

+ curl -L http://cl.ly/3W3a2S3t2c32/download/docker-compose-Linux-x86_64
+ /usr/bin/docker-compose --version
docker-compose version: 1.3.0rc1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013

+ /var/go/docker-compose up -d
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

@ jsh2134, почему вы закрепляете pyOpenSSL на 0.14?

+1 за ответ @kretz :)

+1 такая же проблема :( кажется, что докер полностью сломан на osx?

Решение @coderfi сработало для меня: Windows 7 docker 1.7 Cygwin и docker-compose, установленные через pip в Cygwin

Работа с одной из вариантных ошибок на виртуальной машине Centos7, которая действует как клиент для запуска контейнеров на машине-докере:

[ root @ xxxx cm] # docker-compose ps
Ошибка SSL: не найдены подходящие поля commonName или subjectAltName

Раньше это было временным; Я мог выйти из системы, снова войти по ssh и какое-то время не видеть ошибку. Теперь вижу это всегда.

[ root @ xxxx cm] # python -c 'import ssl; печать (ssl.OPENSSL_VERSION) '
OpenSSL 1.0.1e-fips 11 февраля 2013 г.

[ root @ xxxx cm] # версия докера
Версия клиента: 1.6.2
Версия клиентского API: 1.18
Версия Go (клиент): go1.4.2
Git commit (клиент): ba1f6c3 / 1.6.2
ОС / Arch (клиент): linux / amd64
Версия сервера: swarm / 0.2.0
Версия Go (сервер): go1.3.3
Git commit (сервер): 48fd993
ОС / Arch (сервер): linux / amd64

[ root @ xxxx cm] # docker-compose --version
докер-составить 1.2.0

Я не знаю, как применить некоторые из исправлений, указанных выше, в моей среде. Я не использую boot2docker; работа с docker 1.6.2 прямо в командной строке bash.

Здравствуйте. На самом деле я открыл проблему по этой причине, потому что не могу ее исправить. Я пробовал много чего, например, установить compose с версиями pip / brew / newst. То же, что и openssl, пробовал версии 0.x, 1.0.2x и т.д., но все еще не работает.

PS: Я не использую boot2docker. У меня есть собственная виртуальная машина, которую я создаю через vagrant, генерирую сертификаты и запускаю с ними демон докеров. По-видимому, он работает с докером, поэтому проблема не в моих сертификатах.

>>> docker run hello-world
Hello from Docker.
[...]
>>> docker-compose up
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
>>> docker-compose -v
docker-compose version: 1.3.1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014
>>> docker -v
Docker version 1.6.2, build 7c8fca2

получил и эту ошибку в одно время:

/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
SSL error: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Прочитав здесь и попробовав установить предлагаемые пакеты:

https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning

Сообщение об ошибке от docker-compose изменилось:

[ root @ xxx cm] # docker-compose up -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: SecurityWarning: в сертификате нет subjectAltName , возвращаемся к проверке наличия commonName для в настоящее время. Эта функция удаляется основными браузерами и устарела в соответствии с RFC 2818. (Подробнее см. Https://github.com/shazow/urllib3/issues/497.)
Предупреждение безопасности
Ошибка SSL: имя хоста 'xx.xx.xx.xx' не соответствует None

(Пунктирная четверка, которую я выделил, относится к хосту мастера / докера роя).

Можно ли решить эту проблему путем редактирования или повторного создания сертификата?

Приложение: сертификаты были созданы на этих ВМ с помощью команды «docker-machine create».

Неужели мы имеем дело с ошибкой в ​​докер-машине, которая приводит к недостаточно подробному сертификату?

Я вижу эту ошибку только с хостами Docker, созданными докер-машиной. Я считаю, что сертификаты SSL не создаются должным образом?

Есть ли у кого-нибудь обходной путь или солютин, чтобы это исправить? Сейчас для меня это немного блокирует: /

@prologic Вы получаете сообщение об ошибке с двоичным requests[security] .

@aanand Спасибо! Я попробую и сообщу, сработает это или нет!

@prologic Мы хотим упаковать requests[security] вместо того, чтобы полагаться на ошибочный модуль SSL Python; мы отслеживаем усилия в № 1530.

@aanand Спасибо! Это сработало отлично :)

@coderfi ваше решение сработало для меня, спасибо

@aan и

@neilsarkar У меня был прокси charles, ваш комментарий меня спас. : +1:

Я использую OS X 10.9.5, вот мое решение:

# ➜  openssl version
# OpenSSL 1.0.2d 9 Jul 2015

➜  pyenv local system # switch to built-in python 2.7.5 for current directory
# ➜  python --version
# Python 2.7.5
# ➜  python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
# OpenSSL 0.9.8zd 8 Jan 2015

# ➜  docker-compose --version
# docker-compose version: 1.3.1
# CPython version: 2.7.5
# OpenSSL version: OpenSSL 0.9.8zd 8 Jan 2015

# ➜  docker-compose ps
# /usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
#   InsecurePlatformWarning
# Name   Command   State   Ports
# ------------------------------

Мое решение:

закомментировать строки 246: 253 в
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

это часть, которая выбрасывает исключение безопасности

Проблема для меня заключалась в том, что даже если я указал brew link --force openssl, fig / docker-compose по-прежнему использует / usr / bin / openssl.

$ sudo mv /usr/bin/openssl /usr/bin/openssl_old
$ brew link --force openssl OR brew unlink openssl && brew link --force openssl

Это сработало для меня. Теперь я больше не получаю раздражающее сообщение.

К вашему сведению, рецепт brew fig / docker-compose использует системный python, поэтому даже если вы установите python через pyenv или brew, brew install fig / docker-compose все равно будет использовать системную библиотеку openssl, если она доступна, в противном случае она установит какую-то другую версию.

На моем MAC на работе я решил это с помощью pyenv install 2.7.8, затем easy_install pip и pip install docker-compose.

но на моем Mac дома, "оба работают yosemite", я сделал то же самое и все еще получаю предупреждение.

Буду копать дальше.

@dtunes - указано выше в https://github.com/boot2docker/boot2docker/issues/808. System-python / homebrew-python - отвлекающий маневр, потому что это просто зависит от того, связаны ли вы с новым или старым OpenSSL.

Да, я видел этот билет. Что меня беспокоит, так это то, что на моем Mac на работе, после того, как я попробовал разные подходы, указанные выше, ни один из них не работал.
Затем я переместил / usr / bin / openssl в / usr / bin / openssl_old, установил последнюю версию openssl, используя домашнее пиво, и принудительно связал его. только тогда я сделал следующее:

~ $ brew install pyenv
~ $ pyenv install 2.7.8
~ $ pyenv global 2.7.8
~ $ easy_install pip
~ $ pip install docker-compose

Это помогло на работе, но на моем Mac дома это не сработало. Но я попробую еще раз, если ошибусь, и сообщу о результатах.

@dtunes - Чтобы восстановить все ваши зависимости, вам нужно удалить ~/Library/Caches/pip чтобы кешированное двоичное колесо, созданное против неправильного OpenSSL, не использовалось повторно.

@glyph написал :

основная причина (как @aanand ) - boot2docker / boot2docker # 808. System-python / homebrew-python - отвлекающий маневр, потому что это просто зависит от того, связаны ли вы с новым или старым OpenSSL.

@glyph или @aanand, значит ли это предложить исправление, @aanand «с (обходным) слился с # 1474 просто приспосабливает сломанный b2d? @aanand , если boot2docker / boot2docker # 808 адресован правильно, нужно ли отказываться от # 1474? Надежды на следующий выпуск криптографии (см. Это и это ) тоже отвлекающий маневр?

@aanand написал :

Обратите внимание, что я не могу воспроизвести эту ошибку на виртуальной машине Boot2Docker, настроенной с помощью docker-machine - это происходит только с виртуальной машиной, настроенной с помощью команды boot2docker.

@ehazlett написал :

Это имеет смысл, потому что я считаю, что генерация сертификатов в b2d выполняется на виртуальной машине, тогда как машина генерирует их на машине.

Возможно, я неправильно понял, но есть много разговоров, обвиняющих различные комбинации Python / OpenSSL на стороне хоста в этой и других связанных проблемах. Если источником проблемы является сломанный OpenSSL, распространяемый с b2d, я не уверен, что лучший подход - убедиться, что OpenSSL на стороне хоста Compose также сломан? Как бы то ни было, эти типы искажений на стороне хоста вряд ли решат эту проблему для тех, кто запускает b2d через (например) Vagrant и обращается к нему за пределами Compose (см., Например, docker / docker-py # 465 ).

Если этот комментарий более уместен в boot2docker / boot2docker # 808, я могу переместить его туда.

Я сопровождаю Homebrew и помогал глифу разобраться с этим.

DN субъекта и эмитента сертификата сервера, сгенерированного boot2docker, идентично установлены на /O=Boot2Docker . Я считаю, что сертификат сервера фактически подписан сертификатом CA, но AFAICT OpenSSL 1.0.2 использует эту информацию (т. Е. Идентичные DN субъекта и эмитента), чтобы отклонить сертификат сервера как самоподписанный, вместо попытки проверить сертификат сервера на соответствие предоставленным CA сертификат. Версии OpenSSL до 1.0.2 проверяют сертификат сервера на соответствие предоставленному сертификату CA, что успешно.

Я считаю, но не тестировал, что предоставление сертификату сервера и CA различных DN субъекта (чтобы сертификат сервера имел разные DN субъекта и эмитента) позволит сертификатам проверяться во всех версиях OpenSSL. Я подозреваю (основываясь на моем прочтении этого руководства по выживанию X.509, но не на каких-либо связанных спецификациях), но не уверен, что поведение OpenSSL 1.0.2 является разумным и не представляет собой регрессию, которую должны решить разработчики OpenSSL.

1474 делает две разные вещи:

• установка минимальной версии Python 2.7.9: это позволяет urllib3 выполнять запросы без выдачи InsecurePlatformWarning, которая выдается при создании HTTPS-соединений, если выполняются оба из двух условий: версия Python до 2.7.9 и модуль PyOpenSSL нет. Объединение PyOpenSSL было бы столь же эффективным, но из обсуждения я понимаю, что он несовместим с PyInstaller. В любом случае InsecurePlatformWarning urllib3 не связан с проблемой сертификата boot2docker, и исправление сертификатов не устраняет необходимость в этом обходном пути.
• установка максимальной версии OpenSSL 1.0.1j. Я считаю, что после исправления сертификатов boot2docker в этом нет необходимости.

Если источник проблемы - сломанный OpenSSL, распространяемый с b2d

Нет; сертификаты boot2docker (сгенерированные этим кодом ) недействительны для клиентов, использующих OpenSSL ≥ 1.0.2; библиотека OpenSSL, распространяемая с boot2docker, не задействована.

@glyph или @aanand, значит ли это предложить исправление, @aanand «с (обходным) слился с # 1474 просто приспосабливает сломанный b2d? @aanand , если boot2docker / boot2docker # 808 адресован правильно, нужно ли отказываться от # 1474? Надежды на следующий выпуск криптографии (см. Это и это) тоже отвлекающий маневр?

Да, я так думаю. Я считаю, что OpenSSL с проблемой - 1.0.2, и, ограничив его до 1.0.1, можно избежать любой логики проверки, вызывающей сбой сертификата. Я до сих пор не знаю, что это за сертификат, который ему не нравится, поскольку сообщения об ошибках такие тупые.

Кроме того, я думаю, что то, что делает # 1474, слишком специфично; по крайней мере, с моей точки зрения, он не устанавливает _minimum_ версию python, но указывает _exact_ версию. Также кажется, что проверка не проходит, у вас есть версия 1.0.1, отличная от j, что означает, что обновления безопасности не будут применяться даже к 1.0.1, что _ определенно_ является проблемой.

Я считаю, но не тестировал, что предоставление сертификату сервера и CA различных DN субъекта (чтобы сертификат сервера имел разные DN субъекта и эмитента) позволит сертификатам проверяться во всех версиях OpenSSL. Я подозреваю (основываясь на моем прочтении этого руководства по выживанию X.509, но не на каких-либо связанных спецификациях), но не уверен, что поведение OpenSSL 1.0.2 является разумным и не представляет собой регрессию, которую должны решить разработчики OpenSSL.

Я исследую сертификат, созданный docker-machine и посмотрю, есть ли у него это свойство. Почему вы говорите, что такое поведение приемлемо / не является регрессом в OpenSSL? Доверять самозаверяющему сертификату - это нормально, и нет никаких особых ограничений на то, что может содержать субъект или издатель, о которых я знаю. Я бегло просмотрел это руководство и, кажется, просто указывает на то, что самозаверяющие сертификаты не будут иметь доверия CA-cartel, поэтому ваш веб-браузер не будет доверять им без дополнительной настройки.

Глядя на сертификат в моей docker-machine VM, я вижу:

...
        Issuer: O=glyph
...
        Subject: O=dev
...

так что вы можете быть правы насчет этого ...

Я исследую сертификат, созданный докер-машиной, и посмотрю, есть ли у него [совпадающие DN субъекта и эмитента].

Вы можете видеть, что сертификаты докер-машин aanand также имеют разные DN: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

Доверять самозаверяющему сертификату - это нормально

Но самозаверяющий сертификат недействителен, если вы не доверяете самозаверяющему сертификату. Мы не даем OpenSSL указание доверять сертификату сервера; мы даем OpenSSL указание доверять центру сертификации, выдавшему сертификат сервера.

Почему вы говорите, что такое поведение приемлемо / не является регрессом в OpenSSL?

IANAL, но мои рассуждения основаны на формулировке «На строгом уровне [самоподпись] означает, что поля эмитента и темы в сертификате совпадают». Так обстоит дело с сертификатом сервера boot2docker. Когда OpenSSL пытается проверить сертификат сервера boot2docker, можно построить полную цепочку доверия без учета сертификата CA, поскольку сертификат сервера кажется подписанным сам по себе, но явно не является доверенным и поэтому не может быть действительным. Я не уверен, что это строго правильное или обязательное поведение, и я не имею права принимать решения, но я думаю, что это кажется «разумным».

Спасибо за копание, ребята.

Кроме того, я думаю, что то, что делает # 1474, слишком специфично; по крайней мере, из моего чтения, он не устанавливает минимальную версию Python, а указывает точную версию. Кроме того, похоже, что проверка не проходит, у вас есть версия 1.0.1, отличная от j, что означает, что обновления безопасности не будут применяться даже к 1.0.1, что определенно является проблемой.

Согласовано. Предполагая, что OpenSSL 1.0.2 не согласуется с сертификатами boot2docker, эту часть следует хотя бы исправить - я посмотрю, как получить обновленную версию OpenSSL 1.0.1 в.

@tdsmith , спасибо за объяснение и извинения за недоразумение. @glyph , спасибо за разъяснения.

FWIW, я попытался проверить теорию @tdsmith и взломал generate_cert (это уродливо, простите меня), чтобы создать разные значения для Issuer и Subject . Это может показаться сдерживающим (но см. Предостережения ниже). Вот что я получаю при запуске b2d с сертификатами, сгенерированными из текущей generate_cert сравнению с моей взломанной версией:

0.9.8zd работает с orig generate_cert (0.1)

% /usr/bin/openssl version
OpenSSL 0.9.8zd 8 Jan 2015
% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2Docker
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAKt8Sy0ND8z8omBU0uhODVAwCwYJKoZIhvcNAQELMBYx
...
qKFg5oUO9wigoGlwnSjqC/5ZmFRf9B+nWeCUVi/vWl0skOIqCMlDamD8AOVtmtRg
tg==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
---
SSL handshake has read 2554 bytes and written 2188 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 621C9DF6883DA1FAF273408D0C984AC6E1DA33BA44ADA0EBA88BE59490560CFC
    Session-ID-ctx: 
    Master-Key: 39A75DE8551C41241CDBF889A5EF32DC7F86A45C792218B7E380E90627C7D0691BC5FCCAB69154B84142171F866F36C2
    Key-Arg   : None
    TLS session ticket:
    0000 - 77 ca 24 b7 2e 33 6a fc-9d 6e d0 eb aa 0d d5 89   w.$..3j..n......
    ...
    0630 - db 49 35 a1 97                                    .I5..

    Start Time: 1438703085
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

1.0.2d (устанавливается через MacPorts) _не_ работает с orig generate_cert (0.1)

% openssl version
OpenSSL 1.0.2d 9 Jul 2015
% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=0 O = Boot2Docker
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Boot2Docker
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAKt8Sy0ND8z8omBU0uhODVAwCwYJKoZIhvcNAQELMBYx
...
qKFg5oUO9wigoGlwnSjqC/5ZmFRf9B+nWeCUVi/vWl0skOIqCMlDamD8AOVtmtRg
tg==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2156 bytes and written 1373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: BAE02ACF63C2F4E28C46664CEB8E790DB0F00E8CB75913484BFE88CC215995D2
    Session-ID-ctx: 
    Master-Key: C7227519074A26A51D815655721F18C63932897D731D1BF077B8374F8A021D51EDF2E603386D249ED62127BD71A86048
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 14 b0 7a 58 68 91 62 10-14 53 04 cf da 41 63 6e   ..zXh.b..S...Acn
    ...
    0350 - 5f 8e fe fd 9c b0 d0                              _......

    Start Time: 1438703297
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

0.9.8zd работает с взломанным generate_cert (0.1.1; неудивительно)

% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2DockerCA
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2DockerCA
-----BEGIN CERTIFICATE-----
MIIC/zCCAemgAwIBAgIRAMLl0tA00F2BDjyktFSD5aEwCwYJKoZIhvcNAQELMBgx
...
jhzP4aW3a8uAdpQXjf8nmJ5Qrq4Xb6yWAezXRdmPWfG1u4neBQKy1Zp64PiBd+0v
1UPu
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2DockerCA
---
Acceptable client certificate CA names
/O=Boot2DockerCA
---
SSL handshake has read 2563 bytes and written 2193 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 1E52C9982BE1F98559529B9E804D330ADD5EC8654EE9F3AFE6139B2AEAB24919
    Session-ID-ctx: 
    Master-Key: 0714B120A52F735C484BF0F6612909CEB5FAF27D5E66B3DDB76DCB32FFE506F70E4BC5EFC42BB19E5CBE6223ACEA5803
    Key-Arg   : None
    TLS session ticket:
    0000 - c4 54 e0 2f 90 68 f2 22-7a c9 ee 2f fb da 25 7a   .T./.h."z../..%z
    ...
    0630 - 5c 95 c6 0a e9 bd 21 70-fd                        \.....!p.
    063a - <SPACES/NULS>

    Start Time: 1438703534
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

1.0.2d _works (!) _: Tada:: see_no_evil:: hear_no_evil:: speak_no_evil: с взломанным generate_cert (0.1.1)

% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 O = Boot2DockerCA
verify return:1
depth=0 O = Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2DockerCA
-----BEGIN CERTIFICATE-----
MIIC/zCCAemgAwIBAgIRAMLl0tA00F2BDjyktFSD5aEwCwYJKoZIhvcNAQELMBgx
...
jhzP4aW3a8uAdpQXjf8nmJ5Qrq4Xb6yWAezXRdmPWfG1u4neBQKy1Zp64PiBd+0v
1UPu
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2DockerCA
---
Acceptable client certificate CA names
/O=Boot2DockerCA
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2899 bytes and written 2111 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 0F1A3A0AB7B1E7C1CFD43CED169E730745DEB935C4DBEDDC7CD8AB698ECB8896
    Session-ID-ctx: 
    Master-Key: A48F441FD8677E1602BFB96DC7E9B39D0E9A7241D1C4AF93F3022ACB621C73E16BD69F557FF4428B033B1C07DF5EB0FB
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 30 e1 e9 1a 4d e0 48 78-14 22 e8 21 5d 84 e7 6f   0...M.Hx.".!]..o
    ...
    0630 - 27 15 8a 64 ff 2e 24 44-3d d8                     '..d..$D=.

    Start Time: 1438703550
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

Предостережения

Чтобы попытаться контролировать все изменения, обратите внимание, что когда был выпущен исходный generate_cert (0.1), он был построен, когда образ golang:1.3-cross Docker, использованный для его сборки, имел доступ к пакету называется ssh . С тех пор этот пакет был заменен на openssh-client . Версия OpenSSL, использованная при сборке моего взломанного generate_cert - это 1.0.1k . Похоже, что это статически связано:

% ldd generate_cert-0.1.1-linux-amd64
        linux-vdso.so.1 (0x00007ffd0936c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fddefe7f000)
        libc.so.6 => /lib/libc.so.6 (0x00007fddefb11000)
        /lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007fddf009a000)

Похоже, что может произойти одно из двух:

• Либо поздние версии OpenSSL запутаются, когда Issuer == Subject , как предлагает @tdsmith ; или же
• В генерации сертификатов есть еще кое-что, что изменилось в OpenSSL, так что в более поздних версиях OpenSSL возникают проблемы с проверкой сертификатов, созданных более ранними.

Один из способов проверить это - пересобрать generate_cert без моего взлома, но с обновленной версией OpenSSL. Я сделаю это дальше.

Так что, похоже, @tdsmith прав. После отказа от моего взлома, чтобы гарантировать Issuer <> Subject , но пересобирая generate_cert с новой версией OpenSSL из golang:1.3-cross , он возвращается к ошибке с более поздние версии OpenSSL на стороне клиента:

0.9.8zd работает с generate_cert (0.1.2) с обновленным OpenSSL

% /usr/bin/openssl version
OpenSSL 0.9.8zd 8 Jan 2015
% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2Docker
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAIVQ9IAYtPQwnu/FHM8HNS0wCwYJKoZIhvcNAQELMBYx
...
xZ+XhXvepeJ/mBIui1qT3yAMum0Mj1zLAxqCY/qsEU4odsgU9N9DbUGngoIkBCrY
gw==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
---
SSL handshake has read 2554 bytes and written 2188 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: FDE088ECF8D0EB2B36EC909B9A66C9C6770AE31355040761CB35150C5A56E92E
    Session-ID-ctx: 
    Master-Key: 86522F869CDE85C8171EEC3A7CF76FDF26F81AE6162DDDEA7D1C55FD5E49E4BDCA56D827C3BFECBFAD9AA2F71A5A94EE
    Key-Arg   : None
    TLS session ticket:
    0000 - 67 d0 60 8e 54 54 7c 7a-3e 5e 71 97 26 e0 06 2c   g.`.TT|z>^q.&..,
    ...
    0630 - cf 68 86 83 d7                                    .h...

    Start Time: 1438705996
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

1.0.2d (устанавливается через MacPorts) _не_ работает с generate_cert (0.1.2) с обновленным OpenSSL

% openssl version
OpenSSL 1.0.2d 9 Jul 2015
% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=0 O = Boot2Docker
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Boot2Docker
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAIVQ9IAYtPQwnu/FHM8HNS0wCwYJKoZIhvcNAQELMBYx
...
xZ+XhXvepeJ/mBIui1qT3yAMum0Mj1zLAxqCY/qsEU4odsgU9N9DbUGngoIkBCrY
gw==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2156 bytes and written 1373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: C2A8BF01E9B754CBF48C69243091C54DAD19DCF52D285C9379B684A3B333AFDD
    Session-ID-ctx: 
    Master-Key: F8510162517AF4C115A13B7CA9E05E04868B4D78CBFA57B28A5B9616EE6FBED6B7B4FC52C2003EBC5D150FA8BDE95F4C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - bc bc 2c 3e 2d b0 92 49-80 c2 c0 df 4f bd fb 84   ..,>-..I....O...
    ...
    0350 - 1e c7 c2 b2 e6 f5 74                              ......t

    Start Time: 1438705985
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

Требуется SvenDowideit / generate_cert # 10. Кстати, если кто-то хочет создать изображения b2d, указывающие на мои взломанные generate_cert s, вы можете попробовать их, пока не будет выпущено официальное исправление.

Если я правильно понимаю, это _должно_ устранять необходимость играть в игры версии OpenSSL / Python на стороне клиента (по крайней мере, в отношении этой проблемы).

отметка @SvenDowideit

У меня было немного споров с ребятами из OpenSSL. Вот краткое изложение Стива Хенсона:

From: Stephen Henson via RT <[email protected]>
Subject: [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
Date: August 5, 2015 at 04:32:18 PDT
Cc: [email protected]
Reply-To: [email protected]

... The bug is that OpenSSL 1.0.2 is less strict about
what counts as a valid self signed certificate. Before 1.0.2 the certificate
had to have issuer and subject matching, if present AKID==SKID and
keyUsage (if present) had to include keyCertSign. For1.0.2 and later the
keyCertSign check is no longer present.

The attached patch should fix it. Let me know if it works for you.

A workaround (other than making subject != issuer) is to include SKID/AKID in
all certificates.

Regards, Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

Изменение способа генерации сертификатов b2d для поддержки клиентов OpenSSL с ошибками кажется намного лучше, чем исправление и установка OpenSSL на стороне клиента. Я не уверен, какой конкретный подход более уместен (сделать subject! = Эмитент вместо включения SKID / ADID во все сертификаты). Я передам это на @SvenDowideit. : ухмылка:

Для любопытных (опять же, я не думаю, что нам стоит идти по этому пути), вот патч OpenSSL от Стива:

diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c
index 1f9296a..7a0130a 100644
--- a/crypto/x509v3/v3_purp.c
+++ b/crypto/x509v3/v3_purp.c
@@ -63,6 +63,7 @@
 #include <openssl/x509_vfy.h>

 static void x509v3_cache_extensions(X509 *x);
+static int check_ca(const X509 *x);

 static int check_ssl_ca(const X509 *x);
 static int check_purpose_ssl_client(const X509_PURPOSE *xp, const X509 *x,
@@ -493,7 +494,7 @@ static void x509v3_cache_extensions(X509 *x)
     if (!X509_NAME_cmp(X509_get_subject_name(x), X509_get_issuer_name(x))) {
         x->ex_flags |= EXFLAG_SI;
         /* If SKID matches AKID also indicate self signed */
-        if (X509_check_akid(x, x->akid) == X509_V_OK)
+        if (X509_check_akid(x, x->akid) == X509_V_OK && check_ca(x) == 1)
             x->ex_flags |= EXFLAG_SS;
     }
     x->altname = X509_get_ext_d2i(x, NID_subject_alt_name, NULL, NULL);

Полная история: http://rt.openssl.org/Ticket/History.html?user=guest&pass=guest&id=3979.

Подождите ... _less_ строгий? Я не понимаю, почему строгая проверка _less_ не работает там, где проходит более строгая?

Подождите ... _less_ строгий? Я не понимаю, почему строгая проверка _less_ не работает там, где проходит более строгая?

Да, у меня тоже были проблемы с выбором языка. Глядя на различие, я думаю, что он имеет в виду неправильное подметание большего количества сертификатов как самоподписанных, не выполняя столько проверок (т.е. менее строгое определение того, что _не__ квалифицируется как самоподписанное). Но ты прав. Странный оборот фразы.

Я не тратил много времени на изучение исходных текстов OpenSSL, но считаю их довольно непонятными во многих местах. Возможно, для работы над этим проектом требуется «особый» склад ума. : ухмылка:

Я не тратил много времени на изучение исходных текстов OpenSSL, но считаю их довольно непонятными во многих местах. Возможно, для работы над этим проектом требуется «особый» склад ума.

Я думаю, преуменьшение: wink:.

В любом случае, спасибо за обращение к ребятам из OpenSSL, рад, что здесь он будет решен там же. Между тем, кажется, что можно обойти это в b2d. Я не думаю, что здесь есть чем заняться compose, но подождите.

Как упоминалось здесь , для меня это исправляет:

pip install requests[security]

@iffy Это

К вашему сведению, PR с исправлением, представленным как boot2docker / boot2docker # 1029.

Исправление (спасибо @posita!) Есть в последней версии boot2docker. Усовершенствовать:

$ boot2docker upgrade
$ boot2docker delete
$ boot2docker init
$ boot2docker up

Это устранило проблему для меня. Пожалуйста, попробуйте и сообщите об этом.

Или переключитесь на Docker Machine , который теперь входит в стандартную комплектацию новой Docker Toolbox .

У меня все еще проблема ...

❯ openssl version && docker-compose --version && docker-machine --version && python --version
OpenSSL 1.0.2d 9 Jul 2015
docker-compose version: 1.4.0
docker-machine version 0.4.1 (HEAD)
Python 2.7.10

❯ docker-compose ps
/usr/local/Cellar/fig/1.4.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Name   Command   State   Ports
------------------------------

@chiefy Ваш выполняется успешно ; предупреждение, которое вы видите, безвредно. Вам следует перейти на OS X 10.10.5, если вы предпочитаете не видеть его.

@tdsmith не безобиден для меня, сводит с ума мое ОКР: smile: спасибо за подсказку, обновлюсь прямо сейчас.

Удаление версии python, установленной через brew, решило для меня эту проблему. brew remove --force python

Я удалил версию brew, но у меня все еще есть Python 2.7.10 и
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) ошибка.

У меня следующая установка:

OpenSSL 0.9.8zg 14 July 2015
docker-compose version: 1.4.0
docker-machine version 0.4.1 (e2c88d6)
Python 2.7.10

@chiefy
ты решил свою проблему?

Anybode знает, работают ли ребята из docker-compose, чтобы решить эту проблему, или это в основном не их проблема?

С Уважением,

@PavelPolyakov
нет. на обоих моих Mac (10.9.x и 10.10.x) я пробовал разные вещи без изменений. Я не думаю, что это docker-compose вещь и что-то еще от Python FWIW.

@chiefy
Согласен, но не нашел варианта, как заставить работать :(

Вроде все уже решили эту проблему, но не я :)

Я однажды установил python с помощью brew и, кажется, удалил системный, поэтому у меня нет возможности вернуться к старому.

Я пробовал установить докер несколькими вариантами:

1. из двоичного файла (загрузка панели инструментов докера)
2. из самого пива

однако у меня все еще есть:

есть ли у кого-нибудь подробное руководство о том, как преодолеть это поведение?

С Уважением,

@PavelPolyakov - Ошибка в том, что boot2docker (и в некоторых случаях, я думаю, docker-machine) создавал некоторые сертификаты, которые нельзя было использовать из-за поддержки SSL в Python. Если вы обновили все свое программное обеспечение, но у вас остались старые плохие сертификаты, все равно что-то сломается. Итак, на этом этапе я бы рекомендовал повторно подготовить любые виртуальные машины разработчиков, которые у вас есть, с текущей версией докер-машины, чтобы были подготовлены новые сертификаты SSL. Это может включать перемещение в сторону ~/.docker на вашем хосте.

@PavelPolyakov и @chiefy , в дополнение к совету @glyph , вы также можете попробовать это (если вы не хотите полностью переделывать среду boot2docker ):

% mv ~/.docker ~/.docker.bak
% ssh docker@[boot2dockerip]
docker@[boot2dockerip]'s password: [typically "tcuser"]
...
Boot2Docker version 1.8.1, build master : 7f12e95 - Thu Aug 13 03:24:56 UTC 2015
Docker version 1.8.1, build d12ea79
docker<strong i="10">@boot2docker</strong>:~$ rm -frv ~/.docker
...
docker<strong i="11">@boot2docker</strong>:~$ sudo -s
root<strong i="12">@boot2docker</strong>:/home/docker# rm -v /var/lib/boot2docker/tls/*
...
root<strong i="13">@boot2docker</strong>:/home/docker# shutdown -h now
...

[boot2dockerip] зависит от среды вашей виртуальной машины. Могут быть более простые методы (например, vagrant ssh , если вы используете Vagrant). Затем перезапустите свой экземпляр boot2docker и посмотрите, возникает ли ошибка SSL.

@glyph

Спасибо за совет, для меня не проблема переподготовить докер-машину. Однако это не помогает.

Когда я устанавливаю docker & co:
brew install docker docker-machine docker-compose

Тогда машина default не создается. И я понятия не имею, как его создать с помощью docker-machine create .

Когда я устанавливаю docker-toolbelt с помощью файла * .pkg, машина создается, но у меня есть ошибка SSL.
Я даже пробовал делать:

docker-machine regenerate-certs default

Но это не помогает.

@posita
Спасибо и за совет.
В своем руководстве вы предлагаете mv ~/.docker ~/.docker-bak - по какой причине? Как только мы это сделаем, мы не сможем снова запустить машину, потому что файлы перемещены.
Да, я могу войти в систему и удалить tls/* , а затем выключить его, но как запустить его снова?

Как его перепланировать с нуля?

@все
Как вы устанавливаете докер (с работающим docker-compose): через brew install или через toolbelt .pkg?
Как я могу быть уверен, что сертификаты, которые находятся на моей докер-машине, действительны и полезны для python, как я могу обновить python и openssl даже больше, чем brew can, и т. Д.?

Спасибо за помощь.

С Уважением,

@PavelPolyakov - docker-machine не имеет понятия "машина по умолчанию". Вы можете запустить docker-machine create --driver virtualbox my-docker-machine .

@PavelPolyakov Как только вы это сделаете, вам нужно сделать eval "$(docker-machine env my-docker-machine)" или что-то еще, что вы выбрали для вызова вашей локальной машины разработчика.

@glyph
Правильно, это была недостающая часть запуска всего с brew . Я успешно подготовил машину с именем default (то же самое, что делается при установке из * .pkg).

Однако, как обычно, я заканчиваю:

:(

В своем руководстве вы предлагаете mv ~ / .docker ~ / .docker-bak - по какой причине? Как только мы это сделаем, мы не сможем снова запустить машину, потому что файлы перемещены.

@PavelPolyakov , я не уверен. Я не использую docker-machine . Я предполагал, основываясь на других средах. Не обращайте внимания, если это не сработает.

Да, я могу войти в систему и удалить tls/* , а затем выключить его, но как запустить его снова?

docker-machine restart не работает?

Мой комментарий основан на моем собственном опыте запуска boot2docker с Vagrant. Это может не очень хорошо относиться к docker-machine . Похоже, у @glyph больше опыта в этой среде. Я бы попробовал его предложения.

Как вы устанавливаете докер (с работающим docker-compose): через brew install или через toolbelt .pkg?

Это несколько выходит за рамки данной проблемы (которая касается конкретно проблемы с сертификатом с boot2docker как показано в docker-compose ), но в OS X я использую двоичные сборки .

@PavelPolyakov , что произойдет, если вы сделаете следующее?

docker-machine create --driver virtualbox shiny-new-machine-74d5a19e
eval $( docker-machine env shiny-new-machine-74d5a19e )
docker-compose build

Какая версия для boot2docker отображается, когда вы делаете следующее?

docker-machine ssh shiny-new-machine-74d5a19e

Не стесняйтесь заменять shiny-new-machine-74d5a19e на то, что хотите, при условии, что он не ссылается на существующий экземпляр (то есть имя не должно отображаться, когда вы выполняете docker-machine ls перед выполнением вышеуказанных команд .).

@posita

Хммм ....: confused: @PavelPolyakov , а что это вам дает?

eval $( docker-machine env shiny-new-machine-74d5a19e ) # probably unnecessary if you're still in the same shell as above
which openssl
openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null

@posita
Спасибо, что продолжаете помогать.

openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
http://pastebin.com/Y9ZqfTVG

Пытался сделать то же самое на другой машине OSX.
Со всеми последними обновлениями (пакеты os и brew) и столкнулся с той же проблемой с SSL.

@PavelPolyakov , я вот это смотрю из твоего openssl s_client ... дампа:

...
Certificate chain
 0 s:/O=shiny-new-machine-74d5a19e
   i:/O=PavelPolyakov
...

Это не значения по умолчанию boot2docker , которые (сейчас) должны быть:

...
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
...

Не зная больше, я предполагаю, что docker-machine перезаписывает значения по умолчанию (каким-то образом), когда готовит виртуальную машину. Но вызов openssl похоже, сработал, поэтому я не уверен, что это проблема, и не понимаю, почему docker-compose сработает. : confounded:

Каковы ваши результаты?

(
set -x
eval $( docker-machine env shiny-new-machine-74d5a19e )
env | grep DOCKER
ls -al "${DOCKER_CERT_PATH}"
openssl x509 -in "${DOCKER_CERT_PATH}/cert.pem" -text
openssl x509 -in "${DOCKER_CERT_PATH}/ca.pem" -text
docker-compose --verbose version
docker-compose --verbose ps
DOCKER_TLS_VERIFY=0 docker-compose --verbose ps
) >"${HOME}/Desktop/docker-compose-890-outerr-$( date -u +%Y-%m-%dT%H:%M:%SZ ).txt" 2>&1

Это должно создать файл типа ~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txt подходящий для вставки / загрузки.

@posita
Вот:
http://pastebin.com/vWqZgVKi

Я почти уверен, что это не имеет ничего общего с вашей проблемой, но ваши версии docker-compose и docker-py отстают. Это последние выпуски:

...
 docker-compose version: 1.4.1
 docker-py version: 1.4.0
...

Кроме того (и я мог бы неправильно это понять), похоже, что ваши ca.pem и cert.pem используют один и тот же Subject (что было причиной исходного boot2docker вопрос, но идущий с другой стороны). Поскольку эти сертификаты создаются / поддерживаются docker-machine , я подозреваю, что проблема в этом? Я нашел docker / machine # 1335 и docker / machine # 1767, которые могут быть связаны, но ни один из них, похоже, не относится к делу.

FWIW, я использую docker-compose (установленный через pip в virtualenv ) с OpenSSL и Python 2.7, установленными с MacPorts. Эта версия OpenSSL подвержена проблеме, указанной в этой проблеме (и ее удалось решить путем обновления до boot2docker ). Для меня эта комбинация работает без проблем с boot2docker 1.8.1+ и Vagrant (мой Vagrantfile обрабатывает копирование сертификатов boot2docker обратно на хост с помощью некоторой магии подготовки):

% cat /.../Vagrantfile
...
         # See <http://tinyurl.com/nz4tgy6>
         boot2docker.vm.provision :shell, inline: "set -e ; while ! docker >/dev/null ps --quiet ; do echo 'Waiting for Docker to come alive so we can kill it...' ; sleep 1 ; done ; sudo /etc/init.d/docker stop ; sudo rm -f /var/lib/boot2docker/tls/*.pem ~docker/.docker/*.pem ; sudo /etc/init.d/docker restart ; while ! docker >/dev/null ps --quiet ; do echo 'Waiting for Docker to come alive again so we can steal its keys...' ; sleep 1 ; done ; echo 'It lives!' ; [ -z \"$( find ~docker/.docker -name '*.pem' 2>/dev/null )\" ] || cp -Rv ~docker/.docker/*.pem '/vagrant/certs" , privileged: true
...
% env | grep DOCKER
DOCKER_HOST=tcp://w.x.y.z:2376
DOCKER_TLS_VERIFY=1
DOCKER_CERT_PATH=/.../certs
% ls "${DOCKER_CERT_PATH}"
ca.pem
cert.pem
key.pem
% openssl x509 -in "${DOCKER_CERT_PATH}/cert.pem" -text
...
        Issuer: O=Boot2DockerCA
...
        Subject: O=Boot2Docker
...
% openssl x509 -in "${DOCKER_CERT_PATH}/ca.pem" -text
...
        Subject: O=Boot2DockerCA
...
% virtualenv --python=python2.7 .../venv
...
% .../venv/bin/pip install docker-compose
...
% .../venv/bin/docker-compose --verbose version
docker-compose version: 1.4.1
docker-py version: 1.4.0
CPython version: 2.7.10
OpenSSL version: OpenSSL 1.0.2d 9 Jul 2015
% .../venv/bin/docker-compose ps
Name   Command   State   Ports
------------------------------

Я понимаю, что у вас может не быть такой возможности. Я просто публикую его, чтобы осветить различия, которые могут помочь в диагностике вашей проблемы. Сравните вышеприведенное с вашими сертификатами, созданными docker-machine :

+-zsh:39> openssl x509 -in /.../.docker/machine/machines/shiny-new-machine-74d5a19e/cert.pem -text
...
        Issuer: O=PavelPolyakov
...
        Subject: O=PavelPolyakov
...
+-zsh:40> openssl x509 -in /.../.docker/machine/machines/shiny-new-machine-74d5a19e/ca.pem -text
...
        Subject: O=PavelPolyakov
...

Обратите внимание, что Subject из ca.pem совпадает с Subject из cert.pem .

Я не думаю, что ваша проблема связана с docker-compose . ( @aanand , возможно, вы можете прокомментировать?) новую проблему для docker / machine . Я бы сослался на это, начиная с вашего первоначального комментария .

Если вы решили зарегистрировать новую проблему для докера / машины , рассмотрите возможность добавления чего-либо интересного в /var/log/docker.log или /var/log/boot2docker.log на вашем экземпляре виртуальной машины. Например, попробуйте это:

ssh docker@[machine-instance] grep generate_cert /var/log/boot2docker.log

Или же:

docker-machine ssh grep generate_cert /var/log/boot2docker.log

Получив это на OSX el capitain,

docker-machine version 0.4.1 (HEAD)
Docker version 1.8.2, build 0a8c2e3
docker-compose version: 1.4.2

Привет @DaveBlooman!

просто любопытно, а у вас также установлен питон и прочее с помощью brew? Или наоборот.
А у вас точная ошибка при выполнении docker-compose build ?

Через доморощенный Python 2.7.10

Так что определенно что-то происходит из-за brew :(

@DaveBlooman , см. Также docker / machine # 1910. Если вы можете воспроизвести проблему @PavelPolyakov , то, может быть, вы двое сможете вместе

У меня была такая же проблема, и это было связано с тем, что у меня было открытое соединение vpn, установленное другим приложением (в моем случае Astrill), которое, вероятно, что-то испортило с конфигурацией сети. Надеюсь, это поможет кому-то еще, у кого такая же проблема.

Я получаю ошибки в OSX 10.9.5

/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Starting compose_maven_1
/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Starting compose_ssh_1
/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning

Python 2.7.10
докер-машина версии 0.5.0
версия docker-compose: 1.5.0

все установлено через Homebrew

@anthonygreen , похоже, это

Я не читал весь этот пост, но я видел ту же ошибку при недавней настройке OS X Yosemite с использованием Docker Toolbox 1.9.1a.

$ docker-machine --version
docker-machine version 0.5.1 (7e8e38e)
$ docker-compose --version
docker-compose version: 1.5.1
$ docker --version
Docker version 1.9.1, build a34a1d5

Оказывается, у меня была настраиваемая переменная среды CURL_CA_BUNDLE (с некоторыми настраиваемыми внутренними сертификатами), и отключение этой переменной env перед запуском docker-compose позволило ей пройти ошибку [SSL: CERTIFICATE_VERIFY_FAILED] .

$ (unset CURL_CA_BUNDLE; docker-compose up)
Starting ...

изменить: упс, я хотел прокомментировать здесь https://github.com/docker/machine/issues/1880

@pmahoney , спасибо, что

$ CURL_CA_BUNDLE= docker-compose up

@posita Установка env var на пустую строку приводит к предупреждению:

$TMPDIR/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html

Хотя я не получаю ошибки SSL.

@pmahoney , интересно. Таким образом, похоже, что установленный, но пустой CURL_CA_BUNDLE имеет другую семантику (т. Е. Нулевое переопределение), чем отсутствие установки вообще (что, вероятно, смотрит в какое-то местоположение по умолчанию). Я пытался найти это в поведении в документации, но безуспешно. Самое близкое, что я нашел, было это .

@neilsarkar, моя проблема заключалась также в запуске прокси Чарльза! Спасибо!

о боже, у меня также есть кастомный CURL_CA_BUNDLE на обеих машинах, где я тестировал.

благодаря

erf для меня ничего, нет переменной CURL_CA_BUNDLE :(
Поэтому я попытался установить для него значение, но безуспешно, но если я установил CURL_CA_BUNDLE на ничего (CURL_CA_BUNDLE =), то у меня есть предупреждение, как сказал @pmahoney, и он работает, но мой терминал il полностью заполнен предупреждающими сообщениями.
Надеюсь, для меня есть лучшее решение :)

Если вы знаете, какое хорошее значение для переменной CURL_CA_BUNDLE, я беру это :)

Спасибо

У меня была такая же проблема с webkit-patch. Глядя на документацию python по модулю SSL / TLS, можно увидеть , что ssl.get_default_verify_paths() показывает нам, где Python / OpenSSL ожидает файл сертификата CA. Итак, если вы запустите это в своем терминале:

python3 -c "import ssl; [print(i) for i in ssl.get_default_verify_paths()]"

мы должны увидеть, что без установки SSL_CERT_FILE модуль SSL Python ожидает файл сертификата CA по адресу /usr/local/ssl/cert.pem (для тех, кто установил OpenSSL на /usr/local/ssl ). Итак, вы либо устанавливаете SSL_CERT_FILE в файл сертификата с сертификатами корневого ЦС, либо помещаете файл с сертификатами корневого ЦС в /usr/local/ssl/cert.pem . Если вам нужны сертификаты корневого ЦС, загрузите curl и в исходном дереве запустите lib/mk-ca-bundle.pl и будет создан файл ca-bundle.crt. Я могу подтвердить, что установка SSL_CERT_FILE будет работать с OpenSSL 1.0.2d с Python 2.7.11 и Python 3.5.0.

@grahamc Удалось ли вам решить проблему? У меня аналогичная настройка, как у вас, которая отлично работает с удаленным демоном докеров, но не работает с docker-compose

Я получаю ошибку: ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Нет, мне просто пришлось отказаться от удаленных докер-хостов, к сожалению :(

У меня только что была эта проблема, когда CURL_CA_BUNDLE вызвала сбой docker-compose :

ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

в то время как docker работал нормально. Было бы хорошо, если docker-compose игнорирует переменную окружения или, по крайней мере, регистрирует предупреждение о том, что ожидаемые сертификаты не будут использоваться.

@buckett , подумайте о том, чтобы docker-py и попросить их ссылаться друг на друга. Я не уверен, какой слой подойдет лучше всего.

edit: Создан новый выпуск № 3114

Все это уже исправили? Я по-прежнему получаю ту же ошибку. Мой docker-compose version :

docker-compose version 1.6.2, build 4d72027
docker-py version: 1.7.2
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014

Вот что я получил от docker-compose --verbose build :

compose.config.config.find: Using configuration files: ./docker-compose.yml
docker.auth.auth.load_config: File doesn't exist
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "compose/cli/main.py", line 56, in main
  File "compose/cli/docopt_command.py", line 23, in sys_dispatch
  File "compose/cli/docopt_command.py", line 26, in dispatch
  File "compose/cli/main.py", line 189, in perform_command
  File "compose/cli/command.py", line 52, in project_from_options
  File "compose/cli/command.py", line 85, in get_project
  File "compose/cli/command.py", line 68, in get_client
  File "site-packages/docker/api/daemon.py", line 78, in version
  File "site-packages/docker/utils/decorators.py", line 47, in inner
  File "site-packages/docker/client.py", line 112, in _get
  File "site-packages/requests/sessions.py", line 477, in get
  File "site-packages/requests/sessions.py", line 465, in request
  File "site-packages/requests/sessions.py", line 573, in send
  File "site-packages/requests/adapters.py", line 431, in send
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Я установил docker, docker-mahine и docker-compose через панель инструментов Docker.

Я пробовал все предложения выше, но безуспешно. У меня нет опыта в docker поэтому я не мог понять это сам.

Есть ли у кого-нибудь первопричина или обходной путь? Я вижу это в compose 1.7.0 с более новой версией openssl.
Все это построено и запущено из Alpine, поэтому окружающая среда должна быть чистой:

/usr/src/app # env | sed 's/DOCKER_HOST=.*/DOCKER_HOST=#redacted/' && docker version && docker ps && docker-compose version && docker-compose pull
HOSTNAME=aebfe81b5938
SHLVL=1
PYTHON_PIP_VERSION=8.1.1
HOME=/root
GPG_KEY=97FC712E4C024BBEA48A61ED3A5CA953F73C700D
DOCKER_TLS_VERIFY=1
TERM=xterm
DOCKER_CERT_PATH=/certs
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C.UTF-8
PYTHON_VERSION=3.5.1
DOCKER_HOST=#redacted
PWD=/usr/src/app
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 21:49:11 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:39:25 2016
 OS/Arch:      linux/amd64
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
docker-compose version 1.7.0, build 0d7bf73
docker-py version: 1.8.0
CPython version: 3.5.1
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
Pulling registry (registry:2)...
ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)

@jmmills
в моем случае это было вызвано переопределенной переменной CURL_CA_BUNDLE env. Вы также должны проверить, есть ли у вас такой чехол.

@PavelPolyakov проверь мой дамп env ... нет CURL_CA_BUNDLE

@PavelPolyakov, ладно, это странно, я явно

@jmmills да… то же самое здесь. Может быть, python обрабатывает set-as-empty иначе, чем unset?

Mac OS, homebrew docker-compose и docker-machine, с использованием системного python. Недавно созданная машина с: docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURL ничего не возвращает
docker-compose ps возвращает

ОШИБКА: ошибка SSL: имя хоста 172.16.129.133 не соответствует localhost

CURL_CA_BUNDLE='' docker-compose ps возвращает:

/usr/local/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/usr/local/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
Name   Command   State   Ports 
------------------------------

У меня было то же самое - CURL_CA_BUNDLE не было установлено в моем env, и установка его на пустую строку дала мне тот же результат, что и @inanimatt.

Это определенно пахнет ошибкой апстрима, я предполагаю, что это какой-то код совместимости со средой для curl, в котором «определенные» и «пустые» обрабатываются по-разному.

Благодаря,
Джейсон Миллс

• отправлено с мобильного телефона.

24 апреля 2016 г. в 6:14 Алекс Уилсон [email protected] написал:

У меня было то же самое - CURL_CA_BUNDLE не был установлен в моем env, и установка его на пустую строку дала мне тот же результат, что и @inanimatt.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub

Кажется, это влияет только на версию homebrew - установка homebrew Python, а затем установка docker-compose через pip решает все ошибки.

24 апреля 2016 года в 14:14 Алекс Уилсон [email protected] написал:

У меня было то же самое - CURL_CA_BUNDLE не был установлен в моем env, и установка его на пустую строку дала мне тот же результат, что и @inanimatt.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub

Кажется, я ранее вставил репликацию проблемы в Linux. Я могу дважды проверить завтра, когда на рабочем месте

Благодаря,
Джейсон Миллс

• отправлено с мобильного телефона.

24 апреля 2016 г. в 12:22 Мэтт Робинсон [email protected] написал:

Кажется, это влияет только на версию homebrew - установка homebrew Python, а затем установка docker-compose через pip решает все ошибки.

24 апреля 2016 года в 14:14 Алекс Уилсон [email protected] написал:

У меня было то же самое - CURL_CA_BUNDLE не был установлен в моем env, и установка его на пустую строку дала мне тот же результат, что и @inanimatt.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub

Та же проблема, так как я обновил docker-compose до версии 1.7 с помощью brew.

$ docker-compose ps
ERROR: SSL error: hostname '192.168.99.100' doesn't match 'localhost'

$ docker-compose version
docker-compose version 1.7.0, build unknown
docker-py version: 1.8.0
CPython version: 2.7.10
OpenSSL version: OpenSSL 0.9.8zh 14 Jan 2016

Очистка CURL_CA_BUNDLE env var решает проблему:

CURL_CA_BUNDLE= docker-compose ps
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
   Name                 Command               State    Ports
------------------------------------------------------------

Переход на версию 1.6.2 также решает проблему.

$ brew switch docker-compose 1.6.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.4.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.5.1
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.5.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.6.0
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.6.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.7.0
3 links created for /opt/boxen/homebrew/Cellar/docker-compose/1.6.2

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

Вместо того, чтобы отключать CURL_CA_BUNDLE, вы можете запустить, используя:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

Я, наверное, не первый, кто поднял этот вопрос, но разве не противоречит интуиции, что переменная среды curl имеет какое-либо влияние на несвязанное приложение Python?

Благодаря,
Джейсон Миллс

• отправлено с мобильного телефона.

7 мая 2016 г. в 15:22 Лоренцо Сицилия [email protected] написал:

Вместо того, чтобы отключать CURL_CA_BUNDLE, вы можете запустить, используя:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub

Я столкнулся с этой проблемой, и проблема заключалась в том, что переменная среды REQUESTS_CA_BUNDLE указывала на настраиваемое расположение для самозаверяющих сертификатов. Encase это помогает кому угодно.

• Майкл Хауш

@aboutlo Это работает - не работало с другим файлом ca.pem , только с этим. Я тоже использую Windows, поэтому у меня больше конфигурации вуду, спасибо!

Удаление ndg-httpsclient (с pip - была версия 0.4.0) решило проблему для меня, см. Мой пост здесь: https://github.com/docker/compose/issues/3365

Я отлаживал docker-compose и docker-py и понял, что вы должны использовать либо переменные среды, либо параметры в команде. Не смешивайте их. Если вы даже укажете --tls в команде, тогда вам придется указать все параметры как объект TLSConfig, так как теперь объект TLSConfig создается полностью из параметров команды и управляет объектом TFSConfig, созданным из переменной среды.

@ m-housh OMG, спасибо за совет! Точно то же самое произошло и со мной! Удалено REQUESTS_CA_BUNDLE из моей среды, и это решило эту проблему для меня.

Я столкнулся с той же проблемой. Сначала я подумал, что это из-за различий в версиях OpenSSL (у Pyhton была 1.0.2, но у ОС была 0.9.8), я сделал их обе 1.0.2, но это все равно не сработало.
Я решил свою проблему, просто подключив ssh к докеру, а затем проверил свой сертификат в авторизованных ключах и обновил его. Интересно как-то там был неправильный сертификат.

Пожалуйста, выполните следующие действия:

boot2docker ssh
docker<strong i="10">@boot2docker</strong>:~$ cat .ssh/authorized_keys

Проверьте, действительно ли этот сертификат является сертификатом с вашего компьютера. Если нет, просто скопируйте свой в этот файл и сохраните его. Тогда просто запустите:

docker-compose up

Это сработало для меня, и надеюсь, что это поможет.

Устранение проблемы: здесь описывается множество различных режимов отказа и сценариев ошибок / неправильной конфигурации пользователя (все в основном исторические).

Я не вижу ничего, что указывало бы на активную текущую проблему в compose, поэтому закрываю ее. Если вы все еще видите связанную ошибку в современных версиях, пожалуйста, откройте новую проблему с полной информацией о вашем сценарии и т. Д.