Dockerを勉強のために構築していたのですが、https系の接続がことごとくエラーとなってドハマリしたので記録しておきます。
Dockerで普通にpullをしました。
[root@localhost ~]# docker pull httpd Using default tag: latest Trying to pull repository docker.io/library/httpd ... Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority
wgetでもだめです。
[root@localhost ~]# wget https://registry-1.docker.io/v2/ --2018-09-16 23:21:05-- https://registry-1.docker.io/v2/ registry-1.docker.io (registry-1.docker.io) をDNSに問いあわせています... 52.54.155.177, 34.233.151.211, 34.206.236.31, ... registry-1.docker.io (registry-1.docker.io)|52.54.155.177|:443 に接続しています... 接続しました。 エラー: registry-1.docker.io の証明書(発行者: `/CN=ESET SSL Filter CA/O=ESET, spol. s r. o./C=SK')の検証に失敗しました: 発行者の権限を検証できませんでした。 registry-1.docker.io に安全の確認をしないで接続するには、`--no-check-certificate' を使ってください。
調べて見ると同じように困っている人は多く、以下の２つの場合、エラーになる可能性があるようでした。
- OSにバンドルされている証明証が古い。
# 以下のコマンドを流して最新化する [root@localhost ~]# yum update openssl
- 時刻がずれている。
# 以下のコマンドを流して同期をとる [root@localhost ~]# ntpdate -bv ntp.nict.jp
OSを入れたばかりなのでどちらも問題ないはずと思いつつ、だめもとで試しましたが、だめでした。
次にSSLの動作を確認するコマンド(curl)で確認しました。
[root@localhost ~]# curl -v https://registry-1.docker.io/v2/ * About to connect() to registry-1.docker.io port 443 (#0) * Trying 34.201.236.93... * Connected to registry-1.docker.io (34.201.236.93) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Server certificate: * subject: CN=*.docker.io * start date: 7月 05 00:00:00 2018 GMT * expire date: 8月 05 12:00:00 2019 GMT * common name: *.docker.io * issuer: C=SK,O="ESET, spol. s r. o.",CN=ESET SSL Filter CA * NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER) * Peer's Certificate issuer is not recognized. * Closing connection 0 curl: (60) Peer's Certificate issuer is not recognized. More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
ではほかのサイトもどうなのかとgoogleで確認してみました。
[root@localhost ~]# curl -v https://google.com/ * About to connect() to google.com port 443 (#0) * Trying 216.58.197.174... * Connected to google.com (216.58.197.174) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Server certificate: * subject: CN=*.google.com,O=Google LLC,L=Mountain View,ST=California,C=US * start date: 8月 28 18:23:00 2018 GMT * expire date: 11月 20 18:23:00 2018 GMT * common name: *.google.com * issuer: C=SK,O="ESET, spol. s r. o.",CN=ESET SSL Filter CA * NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER) * Peer's Certificate issuer is not recognized. * Closing connection 0 curl: (60) Peer's Certificate issuer is not recognized. More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
ん？よくよく見比べて見ると気になるものが。。
どっちも発行者(issuer)がESETではありませんか！
ESETが認証局サービスを始めたにしても偶然すぎるし、Filterってのが怪しすぎる。
で、さっそくESETの設定を確認。
ありました。怪しそうな設定が…"SSL/TLSプロトコルフィルタリング"がONになってます。
試しにOFFにするとすんなり通りました。
[root@localhost ~]# docker pull httpd Using default tag: latest Trying to pull repository docker.io/library/httpd ... latest: Pulling from docker.io/library/httpd Digest: sha256:8631904c6e92918b6c7dd82b72512714e7fbc3f1a1ace2de17cb2746c401b8fb Status: Image is up to date for docker.io/httpd:latest
みなさんもESET入れている方で、SSL/TLS系の通信がおかしいときとは"SSL/TLSプロトコルフィルタリング"の設定を確認しましょう。
ちなみになぜゲスト(CentOS 7)でホスト(Windows10)にインストールされているESETの影響を受けているか気になったので調べると 案の定、VMのネットワーク設定がNAT接続になっていました。ブリッジにすると影響をうけなくなったので、 最終的には"SSL/TLSプロトコルフィルタリング"をOFFにするのではなく、VMのネットワーク設定をブリッジ接続にするという対応にしました。
