Выпуск сертификата с Curl - PullRequest
0 голосов
/ 08 октября 2018

Мой сервер CentOS 7, находящийся в частном облаке AWS (сеть компании), не может подключиться к некоторым сайтам.После некоторой работы мне удалось сузить проблему до следующей проблемы.

(1) Следующий внутренний сайт недоступен (SSL через общедоступный ЦС):

curl -v https://git.example.com

, который возвращает:

About to connect() to git.example.com port 443 (#0)
Trying 10.62.124.6...
Connected to git.example.com (10.62.124.6) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none

(2) Но работает следующий внутренний сайт (SSL через общедоступный ЦС):

curl -v https://alm.example.com

, который возвращает:

About to connect() to alm.example.com port 443 (#0)
Trying 10.64.167.137...
Connected to alm.example.com (10.64.167.137) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
...
...
...
Accept: */*

Любая идея, почему число (1) не работает?Оба эти сайта являются внутренними, которым доверяет один и тот же общедоступный центр сертификации.

Спасибо за помощь.

1 Ответ

0 голосов
/ 18 октября 2018

Оказалось, что это следующий случай в нашей компании.git.example.com размещался в частном Azure, а alm.example.com - в частном AWS.И мой рабочий сервер тоже работает в AWS, поэтому у Azure возникли проблемы в сети.По рекомендации сетевой команды я установил размер MTU в linux kernal на 1350, и это было решено.

Кроме того, наша компания также начала перехватывать трафик SSL, для которого они установили промежуточный сертификат в прокси-сервере, и ожидают, что все внутренние серверы будут доверять этому сертификату.Моя проблема, о которой говорилось выше, была вызвана сочетанием обеих этих проблем, когда проблему с сертификатом можно было решить, доверяя ей или игнорируя проверку SSL.

Надеюсь, это кому-нибудь поможет.

...