Erro de certificado SSL ao conectar-se ao github.com

2

A partir de hoje (ou nos últimos dias), acertei um erro SSL ao tentar se conectar ao github.com (por exemplo, para clonar um repositório).

Este é um servidor legado que executa o Red Hat 4.1.2-33.

Veja o que parece quando tento me conectar:

$ curl https://www.github.com --verbose
* About to connect() to www.github.com port 443 (#0)
*   Trying 192.30.252.130... connected
* Connected to www.github.com (192.30.252.130) port 443 (#0)
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

Eu posso ver em esta página que o NSS código de erro é:

"Cannot communicate securely with peer: no common encryption algorithm(s)."

The local and remote systems share no cipher suites in common. This can be due to a misconfiguration at either end. It can be due to a server being misconfigured to use a non-RSA certificate with the RSA key exchange algorithm.

Se eu estou colocando isso completamente correto, parece que o github.com tem um certificado SSL atualizado recentemente e meu servidor não tem um conjunto de cifras compatível com ele. Este é um servidor legado, então não estou tão surpreso.

Eu tentei yum update nss (desde que o que o curl parece estar usando), bem como yum update openssl , mas nenhum desses pacotes foi atualizado.

Eu também tentei seguir o esquema de procedimentos aqui mas sem sucesso.

Estou meio que batendo na parede com o meu conhecimento de como os handshakes TLS funcionam para solucionar problemas ainda mais profundos. Alguém tem alguma boa idéia sobre como começar a cavar mais fundo e descobrir o que está errado e onde eu preciso atualizar as coisas? A atualização do sistema operacional não é, por enquanto, uma opção.

Atualizar

Continuando, parece ser um problema com o libcurl e com a cifra que ele está usando ao se conectar ao github.com via git. Eu posso fazer o curl funcionar se eu especificar explicitamente uma cifra compatível:

$ curl https://github.com --cipher rsa_aes_128_sha

E posso até adicionar o parâmetro --cipher rsa_aes_128_sha a um arquivo .curlrc e usar o curl que usa cifra por padrão. Infelizmente, isso não parece ser captado pelo comando git, então não me levou a lugar nenhum ... nem poderia encontrar uma maneira alternativa de especificar a cifra. É assim que o resultado de um git pull detalhado se parece em um repositório github.com:

$ GIT_CURL_VERBOSE=1 git pull
* Couldn't find host github.com in the .netrc file, using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.129... * Connected to github.com (192.30.252.129) port 443 (#0)
*   CAfile: /root/certs/cacert.pem
  CApath: none
* NSS error -12286
* Expire cleared
* Closing connection #0
* Couldn't find host github.com in the .netrc file, using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.129... * Connected to github.com (192.30.252.129) port 443 (#0)
*   CAfile: /root/certs/cacert.pem
  CApath: none
* NSS error -12286
* Expire cleared
* Closing connection #0
error: SSL connect error while accessing https://github.com/twbs/bootstrap.git/info/refs
fatal: HTTP request failed

Isso pode ser um beco sem saída ... parece que esse cara no StackOverflow correu para o exatamente o mesmo problema .

    
por Jim D 02.01.2014 / 22:14

3 respostas

4

A configuração SSL / TLS hoje é guiada por considerações de segurança que surgiram nos últimos dois anos, como os ataques BEAST e CRIME, e a fraqueza do RC4, e que - em alguns casos - resultarão em alguns problemas antigos. clientes sendo incapazes de se comunicar, pois eles não suportam protocolos mais modernos, pacotes de criptografia, etc. Mesmo os clientes RHEL 5 ocasionalmente têm problemas comunicando-se com os servidores RHEL 6 via SSL / TLS. Com algum trabalho, você pode ser capaz de especificar manualmente um conjunto de criptografia para usar, mas é altamente improvável com algo tão antigo quanto o RHEL4. Esse estado de coisas faz com que você atualize sua opção real somente .

    
por 02.01.2014 / 22:29
1

... antes de passar o tempo batendo na parede e tudo mais) marque sua data / hora:

[alexus@wcmisdlin02 ~]$ sudo ntpdate time.apple.com
 2 Jan 16:33:44 ntpdate[6883]: adjust time server 17.171.4.35 offset 0.000416 sec
[alexus@wcmisdlin02 ~]$ 

isso pode não ser o seu problema, mas eu tive problemas quando o tempo não estava certo, o SSL não funcionou para mim.

    
por 02.01.2014 / 22:34
-1

Acho que isso pode ser o que você está procurando:

link

Ele tem explicações para as configurações que eu acho que você vai precisar para fazê-lo funcionar por padrão (sem especificar na linha de comando).

O nome do arquivo no meu sistema centOS 6.8 é /etc/pki/nssdb/pkcs11.txt

    
por 06.10.2016 / 15:39

Tags