2017-01-31 5 views
0

Ich versuche, den GetTwitter-Prozessor für einen Nifi-Flow zu konfigurieren. Ich habe die erforderlichen Eigenschaften wie Zugriffstoken und Consumer Key festgelegt. Allerdings, wenn ich auf dem Prozessor drehen, bekomme ich folgende Fehlermeldung:Apache Nifi Twitter Connection Problem

Received error CONNECTION_ERROR: sun.security.validator.validatorexception pkix path building failed sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Will attempt to reconnect 

So ist es ziemlich klar, dass es irgendeine Art von Zertifikat/Sicherheitsproblem vor sich geht. Wie würde ich das beheben?

EDIT: Hinzufügen von OpenSSL Befehlsausgabe enter image description here

Antwort

1

Ja, zur Zeit Ihr Prozessor wird sagen, dass es ein Zertifikat erhält https://www.twitter.com identifizieren (oder was auch immer die tatsächliche URL ist), aber es kann keine vollständige Kette zwischen dem vorgelegten Zertifikat und einem bauen bekanntes CA/vertrauenswürdiges Zertifikat. Dies liegt daran, dass NiFi standardmäßig keine vertrauenswürdigen Zertifikate kennt.

Können Sie versuchen, festzustellen, dass Ihr Computer das Twitter-Zertifikat außerhalb von Java validieren kann? Sie können diesen OpenSSL-Befehl verwenden, dies zu tun:

$ openssl s_client -connect <host:port> -debug -state 

Sie sollten ein Ergebnis sehen, das ist ziemlich lang, aber enthält:

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA 
verify return:1 
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA 
verify return:1 
depth=0 C = US, ST = California, L = San Francisco, O = "Twitter, Inc.", OU = Twitter Security, CN = api.twitter.com 
verify return:1 
SSL_connect:SSLv3 read server certificate A 

und schließlich:

SSL-Session: 
    Protocol : TLSv1.2 
    Cipher : ECDHE-RSA-AES128-GCM-SHA256 
    Session-ID: 7FD9B2...F2A0CD 
    Session-ID-ctx: 
    Master-Key: 5847F71...0C2599 
    Key-Arg : None 
    PSK identity: None 
    PSK identity hint: None 
    SRP username: None 
    TLS session ticket lifetime hint: 129600 (seconds) 
    TLS session ticket: 
    0000 - 0a c4 e2 31 be 96 ac 47-87 a4 38 98 0f 39 cf 24 ...1...G..8..9.$ 
    ... 
    0090 - 14 c9 bd 6a d7 ca 01 6b-09 40 6a eb 5d e0 4e f5 [email protected]].N. 

    Start Time: 1485890791 
    Timeout : 300 (sec) 
    Verify return code: 0 (ok) 

Der wichtigste Teil ist Überprüfen Sie den Rückkehrcode: 0 (ok).

Wenn dies erfolgreich ist, können Sie überprüfen, ob Java die richtigen CA-Zertifikate im Truststore als vertrauenswürdig markiert hat. Abhängig von Ihrer Version von Java und OS müssen Sie möglicherweise die JRE und Ihr ca-certificates-Paket (on * nix) aktualisieren.

EDIT

Was ich unten gilt Prozessoren GetHTTP und InvokeHTTP schrieb, nicht GetTwitter.

Sie können ein StandardSSLContextService in Controller Diensten konfigurieren, die die Vertrauensspeicherdatei-$JRE_HOME/lib/security/cacerts Punkte (zum Beispiel auf meinem Mac, es ist /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/security/cacerts), und stellen Sie den -Vertrauen Typen zu JKS und das -Vertrauen Passwort bis changeit.

Es gibt an existing Jira Diskussion über das Hinzufügen dieser standardmäßig, aber es gibt Vor-und Nachteile zu dieser Entscheidung.

+0

Wenn das, was Sie geschrieben haben, nur für getHTTP und InvokeHTTP gilt, wissen Sie, wie Sie das GetTwitter-Problem lösen könnten? @Andy – Danzo

+0

Deshalb habe ich die obigen Debugging-Schritte hinzugefügt. Was waren die Ergebnisse des Befehls 's_client'? – Andy

+0

Ich habe den ursprünglichen Post editiert, um den Screenshot einzuschließen. @Andy – Danzo