Не удалось установить соединение Subversion SSL и код ошибки 408

Версии

Subversion: версия 1.6.11 (r934486)

Операционная система : CentOS версии 6.8 (окончательная версия).

Фон

У меня есть множество сценариев оболочки, которые выполняются как задания cron на компьютере с CentOS. Скрипты оболочки фиксируют файлы и извлекают файлы из Subversion. Сегодня все мои скрипты начали давать сбой со следующей ошибкой

svn: ОПЦИИ «https://svn.int.mydomain.edu/eas»: не удалось установить соединение SSL: получено предупреждение SSL: ошибка в версии протокола ( )

В качестве шага устранения неполадок я выполнил следующую команду

      openssl s_client -connect svn.int.mydomain.edu:443

И получил следующий вывод (слегка отредактированный)

      CONNECTED(00000003)
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.int.mydomain.edu
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.int.mydomain.edu
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5545 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: REDACTED
    Session-ID-ctx: 
    Master-Key: REDACTED
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1618275549
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
HTTP/1.1 408 Request Time-out
content-length: 110
cache-control: no-cache
content-type: text/html
connection: close

<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>
closed

Как вы можете видеть, я получаюHTTP/1.1 408 Request Time-outв конце стандартного вывода. Я могу убедиться, что у меня есть доступ к https://svn.int.mydomain.eduhttps://svn.int.mydomain.edu в этом ящике, потому что отдельная установка svn работает нормально из этого ящика (установка SVN, поставляемая с плагином Jenkins).

Вопрос

Есть ли у кого-нибудь мысли о дополнительных методах устранения неполадок? Я пытался найти эту проблему, но плодотворных ответов нет.

Источник

1 ответ

Ответ 408 вызван просто тем, что openssl никогда не отправлял HTTP-запрос. Он установил TCP-соединение и SSL-подтверждение, но это все.

Важными частями ответа являются:

      Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES256-GCM-SHA384
Verify return code: 0 (ok)

Эта часть означает, что что касается openssl, с SSL-соединением все в порядке. Сертификат действителен и поддерживается как минимум один шифр и протокол.

Но сообщение об ошибке в вашем сценарии bash предполагает, что SSL-соединение не в порядке. Я думаю, что причина в том, что сервер был обновлен и больше не поддерживает TLS 1.0 и TLS 1.1, а какой бы сценарий bash ни использовал для HTTPS-запросов, он не поддерживает TLS 1.2. Вы можете запустить тест, добавив-tls1опция для вашей команды openssl.

Если это приводит к чему-то другому, то, скорее всего, проблема в несовместимости версий TLS.

Также возможно, что проблема заключается в несовпадении доступных шифров. Если вы все еще получаете0 (ok)для TLS 1.0, возможно, стоит изучить шифры, доступные на сервере и клиенте.

Возможно, также стоит посмотреть последние изменения, внесенные на сервер, или просто попытаться обновить клиент. (Это выстрел в темноте, но иногда он срабатывает...)

Источник
Другие вопросы по тегам