【问题标题】:Error checking TLS connection: Error checking and/or regenerating the certs错误检查 TLS 连接:错误检查和/或重新生成证书
【发布时间】:2016-04-11 00:12:03
【问题描述】:

重新启动 Windows 后,我无法连接到在 Oracle Virtual Box 中运行的 docker 机器。 当我启动 Docker QuickStart Terminal 时,一切看起来都很好,一切正常,它给了我这样的信息:

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

但是当我这样做时:

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL   SWARM   DOCKER   ERRORS
default   -        virtualbox   Timeout

和:

λ docker images
An error occurred trying to connect: Get http://localhost:2375/v1.21/images/json: dial tcp 127.0.0.1:2375: ConnectEx tcp: No connection could be made because the target machine actively refused it.

当我尝试重新初始化我的环境时,我得到:

λ docker-machine env default
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: i/o timeout
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

顺便说一句,重新生成证书也无济于事。 有什么想法吗?

谢谢。

【问题讨论】:

标签: docker docker-machine


【解决方案1】:

请尝试通过以下方式手动重新生成证书:

docker-machine --debug regenerate-certs -f default

并检查任何要修复的错误,然后重试:

docker-machine --debug env default

如果在 ssh 上失败,请将该命令复制并粘贴到终端中,通过添加额外的 -vv 来查看问题所在。

如果你有:

debug1:连接到地址 127.0.0.1 端口 64368:连接被拒绝

那么你的机器没有运行(检查docker-machine ls),所以试试:

docker-machine start

然后尝试通过 ssh 访问它:

docker-machine -D ssh default

【讨论】:

  • 谢谢,但这并不能解决我的问题。我的机器已启动,重新生成证书也无济于事。
  • @rmcshary 如果机器正在运行 (docker-machine ls),你可以通过docker-machine -D ssh default ssh 到它吗?如果你不能,你有什么错误?
  • 我不能再花时间了,所以我核对了默认容器并重新创建了它。下次它发生时(可能在大约 3-4 天内)我会试试这个并在这里发布。
  • docker-machine --debug regenerate-certs -f name_of_your_vm
【解决方案2】:

在做了一些研究后,我发现以下解决方法可以暂时解决问题:

  1. 打开网络和共享中心

  2. 点击更改适配器设置

  3. 查看您是否启用了任何适配器,例如 VPN 或 VM Ware 网络适配器。

  4. 尝试禁用它们并尝试再次连接到您的容器

  5. 如果在您禁用其他适配器时它不起作用,请重新启动您的 PC - 在我的情况下,这对我有用。

【讨论】:

  • 我尝试了 2 次,它确实有效。下次发生这种情况时,我会再试一次,看看是否可以重复。
  • 重启电脑后这对我也有效。当我禁用 VirtualBox 适配器时,重新启动后会创建新的适配器。
【解决方案3】:

我修复它这样做:

  • 从我的 VirtualBox 中删除了所有仅主机接口(VirtualBox → 首选项 → 网络 → 仅主机网络)。
  • rmdir.exe --ignore-fail-on-non-empty ~/.docker/
  • docker-machine start
  • docker-machine env
  • eval $("C:\Program Files\Docker Toolbox\docker-machine.exe" env default)(也添加在我的.bash_profile 末尾)。
  • docker run hello-world ← 正在工作

灵感来自this post

【讨论】:

    【解决方案4】:

    对我有用的是来自 docker-machine repo 的 this answer

    docker-machine regenerate-certs --client-certs [name]
    

    基本上,过期的是客户端证书。我从 docker-machine 收到的错误消息与您的类似(即,没有迹象表明它是需要重新生成的客户端证书)。

    【讨论】:

      【解决方案5】:

      这对我有用。第一步与 Hazhir 提出的类似,然后重新生成证书。

      1. 打开网络和共享中心。
      2. 点击更改适配器设置。
      3. 禁用所有活动的 VMWare 网络适配器。通常有“VirtualBox Host-Only Ethernet Adapter”的解释。
      4. 通过运行 docker-machine start 连接到您的容器。
      5. 运行docker-machine env。如果您像我一样,那么您会收到以下错误:

      错误检查 TLS 连接:错误检查和/或重新生成 certs:验证主机证书时出错 "192.168.99.100:2376": x509: 证书对 192.168.99.101 有效, 不是 192.168.99.100

      哪个好。现在我们需要做的就是运行

      docker-machine regenerate-certs -f default
      

      然后用docker-machine env 再次测试它。如果你得到:

      SET DOCKER_TLS_VERIFY=1
      SET DOCKER_HOST=tcp://192.168.99.100:2376
      SET DOCKER_CERT_PATH=C:\Users\Jay\.docker\machine\machines\default
      SET DOCKER_MACHINE_NAME=default
      REM Run this command to configure your shell:
      REM     FOR /f "tokens=*" %i IN ('docker-machine env') DO %i
      

      那么你就准备好了。在我的情况下,我需要通过运行 Docker Quickstart Terminal 来启动我的虚拟机。

      【讨论】:

        【解决方案6】:

        我也有这个问题。执行docker-machine regenerate-certs <vm-name> 不能解决问题。我在谷歌上搜索错误信息并在下面找到解决方案。

        • 在终端中执行sudo ifconfig vboxnet0 up
        • 显示 docker 机器状态:docker-machine ls
        • 现在STATEURL 可以了。

        但重启系统后问题依旧。

        GitHub issues我找到的链接在这里。

        VirtualBox 5.1.24 中似乎有一个bug

        【讨论】:

          【解决方案7】:

          这里的答案都没有帮助我。当我想使用 eval $(docker-machine env default) 激活我的虚拟机的 shell 时,出现了我的问题。

          当时它试图访问已关闭的 2376 端口,所以我不得不通过 ssh 进入 VM 的 shell 并激活以下 UFW 规则:

          sudo ufw allow 2376
          

          【讨论】:

            【解决方案8】:

            我确保能够连接到我的 docker 机器的方法是通过 assigning them a fixed IP(并且只重新生成一次证书)(无需重新启动)

            之后,docker-machine ls 始终有效。

            我当前的脚本:
            (将%PRGS%\dm\latest 替换为您机器上docker-machine.exe 所在的路径)
            (确保PATH 包含latest /path/to/git/usr/bin,以便ssh 等命令可用)

            > more dmvbf.bat
            @echo off
            setlocal enabledelayedexpansion
            set machine=%1
            if "%machine%" == "" (
                    echo dmvbf expects a machine name
                    exit /b 1
            )
            set ipx=%2
            if "%ipx%" == "" (
                    echo dmvbf x missing ^(for 192.168.x.y^)
                    exit /b 2
            )
            set ipy=%3
            if "%ipy%" == "" (
                    echo dmvbf y missing ^(for 192.168.x.y^)
                    exit /b 3
            )
            
            %PRGS%\dm\latest\docker-machine.exe ssh %machine% "sudo sh -c 'echo \"kill \$(more /var/run/udhcpc.eth1.pid)\" | sudo tee /var/lib/boot2docker/bootsync.sh >/dev/null'"
            %PRGS%\dm\latest\docker-machine ssh %machine% "sudo sh -c 'echo \"ifconfig eth1 192.168.%ipx%.%ipy% netmask 255.255.255.0 broadcast 192.168.%ipx%.255 up\" | sudo tee -a /var/lib/boot2docker/bootsync.sh >/dev/null'"
            
            %PRGS%\dm\latest\docker-machine ssh %machine% "sudo chmod 755 /var/lib/boot2docker/bootsync.sh"
            
            %PRGS%\dm\latest\docker-machine ssh %machine% "sudo cat /var/run/udhcpc.eth1.pid | xargs sudo kill"
            
            %PRGS%\dm\latest\docker-machine ssh %machine% "sudo ifconfig eth1 192.168.%ipx%.%ipy% netmask 255.255.255.0 broadcast 192.168.%ipx%.255 up"
            

            例如:

            dmvbf default 99 100
            docker-machine regenerate-certs -f default
            

            这会将192.168.99.100 分配给docker 机器'default',并重新生成一次证书。
            然后每次调用docker-machine ls,都会显示'default'的相同IP。

            【讨论】:

            • 嗨@VonC,我已经使用了你的脚本——我在你最初添加它的线程上发布了。但由于某种原因,我的默认 docker 机器仍然每隔几天就会“超时”。我认为这与主机要睡觉或被关闭有关,但不确定。我只是喜欢某种方法来解决超时发生时不涉及每次都从头开始重建我的 docker 容器。
            • @rmcshry 在这种情况下,打开 VirtualBox 以检查 VM 的状态。
            • @rmcshary 换句话说,你的虚拟机是否处于异常状态,例如“aborted”或“guru meditation”?
            • 不,VM 很好,我可以从 VirtualBox 启动/停止它没问题
            • @rmcshary 你能再试一次我在答案中提到的脚本吗:它与原始线程上发布的脚本不同。
            【解决方案9】:

            试试这种方式/解决方法:

            • 首先确定$yourhome/.docker/machine/certs/文件夹下有ca.pem, cert.pem, key.pem, ca-key.pem,对于丢失的这4个*.pem文件,可以复制他们来自其他地方,或者自己创建它们(这四个 pem 文件一开始肯定不正确)
            • 确保在 bash_profile 中正确设置了 env,例如: 导出 DOCKER_HOST=tcp://192.168.99.100:2376 导出 DOCKER_MACHINE_NAME=default 导出 DOCKER_TLS_VERIFY=1 export DOCKER_CERT_PATH=/Users/johnwang/.docker/machine/machines/default
            • 重新运行cmd:docker-machine regenerate-certs default(可能在运行之前,你需要重新打开docker终端) 在 mac 上的 docker toolbox 上试过,效果很好。
            • 最后是一些结果日志: 检查 TLS 连接时出错:检查和/或重新生成证书时出错:验证主机“192.168.99.100:2376”的证书时出错:x509:证书由未知机构签名 您可以尝试使用“docker-machine regenerate-certs [name]”重新生成它们。 请注意,这将触发 Docker 守护程序重新启动,这可能会停止运行容器。 ... ... johns-MacBook-Pro:certs johnwang$ docker-machine regenerate-certs default 重新生成 TLS 机器证书?警告:这是不可逆的。 (是/否):是 重新生成 TLS 证书 等待 SSH 可用... 正在检测供应商... 将证书复制到本地计算机目录... 将证书复制到远程计算机... 在远程守护进程上设置 Docker 配置... johns-MacBook-Pro:certs johnwang$ docker-machine ls 名称活动驱动程序状态 URL 群 Docker 错误 默认 - virtualbox 运行 tcp://192.168.99.100:2376 v17.03.1-ce

            希望对你有帮助 也可以在这里查看我的回复:https://github.com/docker/machine/issues/2808

            【讨论】:

              【解决方案10】:

              就我而言,是我的FortiClient 导致了问题。禁用它后docker-machine env default 再次正常工作。我建议你检查一下你的系统中是否有任何杀毒程序在运行。

              【讨论】:

                【解决方案11】:

                对我来说,跑步

                docker-machine --debug regenerate-certs -f name_of_your_vm
                

                工作得很好。

                docker-machine version 0.16.1
                virtualBox 6.0
                

                docker 也被配置为使用 IP 为 192.168.99.100 的默认机器

                【讨论】:

                  【解决方案12】:

                  只需启动 docker 机器,然后重新生成证书

                  docker-machine start <machine-name>
                  
                  docker-machine regenerate-certs <machine-name>
                  

                  它对我来说就像一个魅力。

                  【讨论】:

                    【解决方案13】:

                    我有同样的错误。我通过在网络防火墙中打开 tcp 端口 2376 来修复它。

                    【讨论】:

                    【解决方案14】:

                    我的问题的解决方案取自这里: https://github.com/docker/machine/issues/3845#issuecomment-271935924

                    引用:

                    如果你是第一次安装 docker-machine 那么你没有 托管将用于生成客户端的自签名 CA 证书和与您生成的机器一样多的服务器证书 稍后的。当您尝试创建机器时会生成该 CA,如果 该 CA 尚未创建。因此,如果您尝试生成多个服务器 并行(通过脚本),然后您将生成尽可能多的 自签名(根)CA 作为 docker createcommands,所有这些都是 写在同一个位置,似乎搞砸了 环境将不同的 ca.pem 分散到远程机器上 与最终版本匹配,导致 cert.pem (主机身份) 由不再存在的前 ca.pem 签名……或其他 其他异常情况。

                    要修复它,首先您需要删除现有的 自签名 CA。这可以通过删除文件夹来完成 ~/.docker/machine/certs(注意:注意这将强制创建一个 新的自签名 CA 供 docker-machine 使用,并将产生您的 现有机器无法连接到守护程序)。这将使 您的 docker-machine 再次生成有效证书。那么,对于我的 用例我正在前台创建第一台机器和所有 其余的都是并行完成的。这将导致创建一个 根自签名 CA 隔离,然后将用于进一步 docker-machine 创建命令。它就像一个魅力!

                    我能够 ssh 到主机的原因是因为有一个 每个主机生成不同的 sshing 密钥对 被这个咬了。

                    总而言之,这就是我最终要做的:

                    1. 找出 docker-machine 正在运行的命令是什么。我在 gitlab-runner 中使用它,所以我必须在调试模式下运行 gitlab-runner 才能查看它在 docker-machine 上运行的命令。

                    2. 然后停止 gitlab-runner:gitlab-runner stop

                    3. 然后删除证书:rm -rf ~/.docker/machine/certs

                    4. 然后运行单个命令(从第 1 步开始)以重新创建证书(请记住 - 这不起作用的原因是因为它试图多次创建它)

                    5. 然后重新运行 gitlab-runner:gitlab-runner start

                    为我工作!

                    【讨论】:

                      【解决方案15】:

                      对于 2021 年使用 brew 的读者,在您以某种方式升级 virtualbox cask
                      1. 系统偏好设置...>安全和隐私>(用手指解锁)允许。
                        >。
                      2. docker-machine restart default完成

                      【讨论】:

                        猜你喜欢
                        • 2016-07-13
                        • 1970-01-01
                        • 2023-01-28
                        • 2020-01-30
                        • 2016-07-03
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 2013-12-08
                        相关资源
                        最近更新 更多