Vinay, If the hostname of the machine is “ambari-srv-dev” and all NiFi hostname properties are configured to be “ambari-srv-dev” and the certificate is issued to “CN=ambari-srv-dev, …” and the machine is resolvable (i.e. ‘ping ambari-srv-dev’ from another machine on the network works), then this should work.
You can verify this by running “openssl s_client -connect ambari-srv-dev:8686 -state -debug” from the command line and ensuring that the output is “Verify return code: 0 (ok)” (see below for example). If it is a non-zero value, the server is not successfully negotiating the SSL handshake on incoming connections. To answer your other question, if the subject (“Issued To”) value is the same as the issuer (“Issued By”), that is referred to as a self-signed certificate. This is acceptable in a development environment but not in production. You will want the endpoint certificate to be signed by a certificate authority (CA) — either a publicly known CA or an internal CA from your organization. — Example result from “openssl s_client -connect google.com <http://google.com/>:443” New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: EF6D82...63D0F3 Session-ID-ctx: Master-Key: B47C7E...14BC641 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - b9 5b 06 f0 18 d3 78 d6-bb 0d b6 97 12 0c ad 2d .[....x........- ... 0090 - e1 90 5f 1b f0 c3 01 6d-f4 86 45 5d 1f bf 17 90 .._....m..E].... 00a0 - b5 63 b6 40 .c.@ Start Time: 1468603095 Timeout : 300 (sec) Verify return code: 0 (ok) --- Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 14, 2016, at 8:45 PM, Vinay <[email protected]> wrote: > > Guys i re-created new user certificate to match the hostname and made changes > as well in nifi properties giving the same hostname as in CN but still jam > struck with same :( > > Please check below the nifi log > > Client -hdp-dev-n3 > 2016-07-15 01:36:02,798 ERROR [Site-to-Site Worker Thread-40] > o.a.n.r.io.socket.ssl.SSLSocketChannel > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel@1e236c9c Failed to > connect due to {} > java.io.IOException: Connection reset by peer > at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.8.0_91] > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) > ~[na:1.8.0_91] > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) > ~[na:1.8.0_91] > at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.8.0_91] > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) > ~[na:1.8.0_91] > at > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.readData(SSLSocketChannel.java:305) > ~[nifi-utils-0.6.1.jar:0.6.1] > at > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.performHandshake(SSLSocketChannel.java:239) > ~[nifi-utils-0.6.1.jar:0.6.1] > at > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.connect(SSLSocketChannel.java:160) > ~[nifi-utils-0.6.1.jar:0.6.1] > at > org.apache.nifi.remote.SocketRemoteSiteListener$1$1.run(SocketRemoteSiteListener.java:155) > [nifi-site-to-site-0.6.1.jar:0.6.1] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91] > 2016-07-15 01:36:02,798 ERROR [Site-to-Site Worker Thread-40] > o.a.nifi.remote.SocketRemoteSiteListener RemoteSiteListener Unable to accept > connection from Socket[unconnected] due to javax.net.ssl.SSLException: > Inbound closed before receiving peer's close_notify: possible truncation > attack? > 2016-07-15 01:36:14,316 WARN [Remote Process Group > 30bf2378-fff5-4154-9484-67042e723dce: https://ambari-srv-dev:8686/nifi > Thread-1] o.a.n.remote.StandardRemoteProcessGroup Unable to connect to > RemoteProcessGroup[https://ambari-srv-dev:8686/nifi] due to > com.sun.jersey.api.client.ClientHandlerException: java.io.IOException: HTTPS > hostname wrong: should be <ambari-srv-dev> > > > > Server - ambari-srv-dev > 2016-07-15 01:34:27,403 ERROR [Site-to-Site Worker Thread-17] > o.a.nifi.remote.SocketRemoteSiteListener RemoteSiteListener Unable to accept > connection from Socket[unconnected] due to javax.net.ssl.SSLException: > Inbound closed before receiving peer's close_notify: possible truncation > attack? > 2016-07-15 01:34:52,736 ERROR [Site-to-Site Worker Thread-18] > o.a.n.r.io.socket.ssl.SSLSocketChannel > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel@4ff98d27 Failed to > connect due to {} > java.io.IOException: Connection reset by peer > at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.8.0_91] > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) > ~[na:1.8.0_91] > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) > ~[na:1.8.0_91] > at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.8.0_91] > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) > ~[na:1.8.0_91] > at > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.readData(SSLSocketChannel.java:305) > ~[nifi-utils-0.6.1.jar:0.6.1] > at > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.performHandshake(SSLSocketChannel.java:239) > ~[nifi-utils-0.6.1.jar:0.6.1] > at > org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.connect(SSLSocketChannel.java:160) > ~[nifi-utils-0.6.1.jar:0.6.1] > at > org.apache.nifi.remote.SocketRemoteSiteListener$1$1.run(SocketRemoteSiteListener.java:155) > [nifi-site-to-site-0.6.1.jar:0.6.1] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91] > 2016-07-15 01:34:52,736 ERROR [Site-to-Site Worker Thread-18] > o.a.nifi.remote.SocketRemoteSiteListener RemoteSiteListener Unable to accept > connection from Socket[unconnected] due to javax.net.ssl.SSLException: > Inbound closed before receiving peer's close_notify: possible truncation > attack? > > > > My question further > > 1. Should the CN of the "Issued By" be the same as that of "Issued To" ? > 2. I assume "nifi.remote.input.socket.host" should hold the hostname of the > remote server NIFI tries to connect , in my case 'ambari-srv-dev'. > > > Regards, > Vinay > > > > > -- > View this message in context: > http://apache-nifi-developer-list.39713.n7.nabble.com/NIFI-Secure-Access-Site-to-Site-tp12735p12815.html > Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.
signature.asc
Description: Message signed with OpenPGP using GPGMail
