2016-04-19 20 views
0

Ich versuche, von meinem Red Hat (Jenkins) -Server eine REST-API auf einem anderen Server (IBM Security Access Manager) mit CuRL aufzurufen.CuRL SSL-Handshake-Problem bei Red Hat

Die Sache ist, dass ich von meinem Windows-Rechner kann CuRL und rufen Sie die REST-API erfolgreich, aber nicht von meinem Server (Jenkins und normale Befehlszeile). Es scheint, dass der Handshake nicht abgeschlossen ist ...

Es gibt eine Verbindung zwischen den beiden am richtigen Port. Getestet habe ich diese mit dem Telnet-Befehl (telnet my.full.ip.adress 443) und sogar curl scheint zu verbinden, wenn an der ausführlichen Ausgabe suchen:

15:05:31.930998 * About to connect() to my.full.ip.adress port 443 
15:05:31.931062 * Trying my.full.ip.adress... connected 
15:05:31.931651 * Connected to my.full.ip.adress (my.full.ip.adress) port 443 
15:05:31.937510 * successfully set certificate verify locations: 
15:05:31.937531 * CAfile: /etc/pki/tls/certs/ca-bundle.crt 
    CApath: none 
15:05:31.937629 * SSLv2, Client hello (1): 
SSL connection timeout 
15:06:31.987734 * Closing connection #0 

Die im Befehl ausgeführt ist jetzt:

-bash-3.2$ curl -k -v -H 'Content-type:application/json' -H 'Accept:application/json' --user xxx:xxx -X POST -d '{"my_key":"my_value","another_key":"another_value"}' https://my.full.ip.adress/wga/reverseproxy/ 

(und jetzt auch einschließlich '--trace Zeit --alle-error-timeout --connect 60' für Testzwecke)

die Firewall-Protokolle folgendes zeigen: Firewall log (Quelle und Ziel sind die obigen erwähnt ser vers)

So scheint es, dass irgendwo der Handshake-Prozess schief geht.

Ich versuchte getan folgenden:

  • Bestätigte Verbindung zwischen den beiden Servern auf dem richtig Port (SSL/443)
  • die -1, -2 verwenden, -3 Argumente andere SSL zu erzwingen Versionen
  • Verifizierte den Befehl durch Ausführen von meinem Windows-Rechner.

Falls Sie sich fragen:

-bash-3.2$ curl -V 
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

Wie ist es möglich, das Handshake nicht erfolgreich ist?

Antwort

0

Ok das Problem gelöst. Als Referenz für andere:

Wie sich herausstellte, war es ein Routing-Problem. Der Zielserver (ISAM) hatte eine falsche Routingkonfiguration, die dazu führte, dass die Antworten auf ein anderes (Teil-) Netz ungültig wurden. Wenn Sie das gleiche Problem haben, überprüfen Sie Ihre Routing-Tabelle :)