"bq" 命令行工具抛出 CERTIFICATE_VERIFY_FAILED

"bq" command line tool throws CERTIFICATE_VERIFY_FAILED

更新(2019-02-07):issue 现已修复,所以如果您仍然 运行 喜欢这个,请尝试 gcloud components update .


在过去几个月的某个时候,我的 bq 工具停止工作了。即使是一个简单的事情也会显示此错误:

$ bq show
BigQuery error in show operation: Cannot contact server. Please try again.
Traceback: Traceback (most recent call last):
File "/opt/google-cloud-sdk/platform/bq/bigquery_client.py", line 685, in BuildApiClient
response_metadata, discovery_document = http.request(discovery_url)
File "/opt/google-cloud-sdk/platform/bq/third_party/oauth2client_4_0/transport.py", line 176, in new_request
redirections, connection_type)
File "/opt/google-cloud-sdk/platform/bq/third_party/oauth2client_4_0/transport.py", line 283, in request
connection_type=connection_type)
File "/opt/google-cloud-sdk/platform/bq/third_party/httplib2/__init__.py", line 1626, in request
(response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File "/opt/google-cloud-sdk/platform/bq/third_party/httplib2/__init__.py", line 1368, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, headers)
File "/opt/google-cloud-sdk/platform/bq/third_party/httplib2/__init__.py", line 1288, in _conn_request
conn.connect()
File "/opt/google-cloud-sdk/platform/bq/third_party/httplib2/__init__.py", line 1082, in connect
raise SSLHandshakeError(e)
SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:726)

我试过以下方法:

其他人看到这个,或者有想法如何debug/solve?

我在使用 Arch Linux 时也遇到了完全相同的问题。

但是,当您在命令行上发出 bq 命令时,我很确定 /opt/google-cloud-sdk/platform/bq/third_party/httplib2/cacerts.txt 处的证书文件 使用,因为标志 --ca_certificates_file=/etc/ssl/certs/ca-certificates.crt 将在应用程序 bootstrap 过程中自动放入标志中。在 Arch Linux 上,此文件是 /etc/ca-certificates/extracted/tls-ca-bundle.pem.

的符号链接

我已经尝试将 curlopenssl s_client 与此 CA 捆绑包一起使用,以对抗被调用的 API URL,即

https://www.googleapis.com/discovery/v1/apis/bigquery/v2/rest

而且效果很好。

我的假设是,这不是证书丢失或过期的问题。我的 pyopenssl 包的版本是 18.0.0,所以我这里是最新版本。但是,我认为这个问题是由于TLS握手过程中不支持的密码或算法引起的。

有一个 public issue tracker with a similar behavior that you're having. I suggest starring it 可以随时更新它并提供您的场景。

如果您支持公司代理,请发表评论 #8 there's a scenario which the corporate proxy replaces the certificate, and the workaround is provided on comment #16

希望对您有所帮助。