Code for final

ふぁいなる向けのコード置き場です。すでにコードじゃないこともいっぱい。

VM(CentOS)からhttpsで接続をするとなぜかエラーになるとき。(ESETが入っている環境)

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' を使ってください。

調べて見ると同じように困っている人は多く、以下の2つの場合、エラーになる可能性があるようでした。

  • 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:  705 00:00:00 2018 GMT
*       expire date:  805 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:  828 18:23:00 2018 GMT
*       expire date: 1120 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になってます。
f:id:finalstream:20180916230813p:plain

試しに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のネットワーク設定をブリッジ接続にするという対応にしました。