Обновление (2019-02-07): проблема теперь исправлен, поэтому, если вы все еще сталкиваетесь с этим, попробуйте 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)
Я пробовал следующее:
sudo gcloud components update
(версия 221.0.0).sudo pacman -Syu
(обновление системы), чтобы получить последний набор сертификатов SSL. Это Arch Linux, так что почти всегда на переднем крае.sudo gcloud components reinstall
.google-cloud-sdk
, удаление оставшегося /opt/google-cloud-sdk
и полная переустановка из AUR.--httplib2_debuglevel=3
(допустимые значения не задокументированы, найдено значение 3
здесь). Это не дает никаких дополнительных результатов.--ca_certificates_file=/etc/ca-certificates/extracted/tls-ca-bundle.pem
, --ca_certificates_file=/etc/ca-certificates/extracted/ca-bundle.trust.crt
и --ca_certificates_file=/etc/ssl/certs/ca-certificates.crt
, один из которых обязательно должен быть комплектом корневых сертификатов в моей системе. Последний из них используется curl, который может нормально взаимодействовать с www.googleapis.com
./opt/google-cloud-sdk/platform/bq/third_party/httplib2/cacerts.txt
- это пакет сертификатов, используемый по умолчанию. Если я попробую это с curl --cacert ...
, он все равно будет работать.GOOGLE_APPLICATION_CREDENTIALS
в этой оболочке. Как и ожидалось, это тоже не имеет значения; ошибка SSL возникает до того, как bq
даже успел начать квитирование OAuth.--disable_ssl_validation
. Это «работает», но явно небезопасно.Кто-нибудь еще видит это или есть идеи, как отлаживать / решать?
У меня такая же ошибка сегодня, после обновления до Ubuntu 18.10, временно используя --disable_ssl_validation, хотя это не рекомендуется
Возможно, это как-то связано с новым Ubuntu 18.10? Так как он у меня тоже установлен.
Я вижу точно такую же проблему и с Arch Linux.
Однако, когда вы вводите команду bq
в командной строке, я почти уверен, что файл сертификата на /opt/google-cloud-sdk/platform/bq/third_party/httplib2/cacerts.txt
используется нет, потому что флаг --ca_certificates_file=/etc/ssl/certs/ca-certificates.crt
будет автоматически вставлен во флаги в процессе начальной загрузки приложения. В Arch Linux этот файл является символической ссылкой на /etc/ca-certificates/extracted/tls-ca-bundle.pem
.
Я пробовал использовать curl
и openssl s_client
с этим пакетом CA против вызываемого URL-адреса API, который
https://www.googleapis.com/discovery/v1/apis/bigquery/v2/rest
и он отлично работает.
Я предполагаю, что это не проблема отсутствующих сертификатов или сертификатов с истекшим сроком действия. Мой пакет pyopenssl
имеет версию 18.0.0
, поэтому я использую самую последнюю версию. Однако я думаю, что эта проблема вызвана неподдерживаемыми шифрами или алгоритмами в процессе установления связи TLS.
Спасибо, что подтвердили, что я не сумасшедший. Тогда должно быть что-то связанное с Arch ... каким-то образом. Вы также установили google-cloud-sdk
из AUR?
Ничего страшного, я пробовал из официального архива, но тоже не удалось. Я отправил сообщение о проблеме с gcloud: Issuesetracker.google.com/issues/117948931
Есть система отслеживания проблем с похожим поведением, что и у вас. Я предлагаю в главной роли быть в курсе этого, а также предоставить свой сценарий.
Если вы находитесь за корпоративным прокси-сервером, в комментарии # 8 есть сценарий, при котором корпоративный прокси заменяет сертификат, а обходной путь предоставляется в комментарии # 16
Надеюсь, это поможет.
Спасибо, но похоже на другую ошибку. И я не за прокси. Issuesetracker.google.com/issues/115556782 выглядит ближе к отметке, но в конечном итоге также относится к прокси.
Интересно, связано ли это с самим Python OpenSSL. Если вы попытаетесь установить SSL-соединения с помощью
requests
на любой защищенный URL-адрес, это сработает? Возможно, обновление pyopenssl и http2 тоже может что-то изменить.