Não consigo fazer o download do https://www.sicdm.caixa.gov.br/cadmut/login_internet_form.do em um servidor CentOS 6.2.
O comando curl -v -k -3 https://www.sicdm.caixa.gov.br/cadmut/login_internet_form.do produz:
* About to connect() to www.sicdm.caixa.gov.br port 443 (#0)
* Trying 200.201.173.93... connected
* Connected to www.sicdm.caixa.gov.br (200.201.173.93) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* NSS error -5938
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
O que eu tentei até agora:
1) Emita o mesmo comando curl em servidores hospedados com outros provedores, na minha máquina do linux dev e nas máquinas dos meus colegas de equipe: a página baixa muito bem;
2) google NSS error -5938 , que não forneceu uma única dica útil.
3) Ditch curl e use wget: não funciona, já que o servidor remoto usa Transfer-Encoding: chunked, com o qual wget não brinca.
4) Atualize / faça o downgrade / compile a versão mais recente do Curl, NSS e OpenSSL: o problema persiste.
5) Relate o problema ao provedor do servidor. Primeiro eles alegaram que era um problema com o certificado do servidor remoto; Estou duvidoso que é o caso, desde que eu disse a onda de ignorar a validação do certificado (sinalizador -k).
6) Extraia um tcpdump da conexão, onde as coisas "engraçadas" foram encontradas (captura superior):
Existem muitos erros de transmissão, e a resposta do servidor à fase "Client Key Exchange" nunca chega ao nosso servidor - mesmo que o pacote ACK o faça! - observe o intervalo de 30 segundos entre os pacotes 46 e 47. (isso acontece mesmo se o firewall estiver desativado)
Para comparação, curling paypal (captura inferior) é bom.
7) Entre em contato com o provedor do servidor, mostrando as descobertas do tcpdump. Eles não comentaram nada sobre o despejo, mas disseram que tentaram o comando em outros servidores em sua rede, e o comando falhou da mesma maneira. Apesar disso, eles ainda afirmam que o problema é o certificado de má qualidade do servidor remoto e a maneira como eu lidei com ele.
Então, o que estou perdendo?
PS: aqui estão alguns números de versão:
curl -v
onda 7.19.7 (x86_64-redhat-linux-gnu) libcurl / 7.19.7 NSS / 3.16.2.3 ECC básico zlib / 1.2.3 libidn / 1.18 libssh2 / 1.4.2 Protocolos: tftp ftp telnet ditar ldap ldaps arquivo http https ftps scp sftp Características: GSS-Negociar com IDN IPv6 Largefile NTLM SSL libz
uname -a
Linux [nome do host redigido] 2.6.32-220.23.1.el6.x86_64 # 1 SMP seg Jun 18 18:58:52 BST 2012 x86_64 x86_64 x86_64 GNU / Linux