Well done Minh. I had a suspicion it was being blocked in the network.
Steve Hindmarch From: e-soci...@gmx.fr <e-soci...@gmx.fr> Sent: Thursday, November 30, 2023 2:19 PM To: users@nifi.apache.org Subject: Re: RE: invokeHTTP SSL error NIFI : 1.23.2 Hi Steve, I found the error :) It seems block by the security team... "This category is not allowed by the company IS security policies." Regards Minh Envoyé: lundi 27 novembre 2023 à 16:47 De: e-soci...@gmx.fr<mailto:e-soci...@gmx.fr> À: users@nifi.apache.org<mailto:users@nifi.apache.org>, stephen.hindma...@bt.com<mailto:stephen.hindma...@bt.com> Cc: users@nifi.apache.org<mailto:users@nifi.apache.org> Objet: Re: RE: invokeHTTP SSL error NIFI : 1.23.2 Thanks, for the informations, I will recheck from my side Minh Envoyé: lundi 27 novembre 2023 à 16:38 De: "stephen.hindmarch.bt.com via users" <users@nifi.apache.org<mailto:users@nifi.apache.org>> À: users@nifi.apache.org<mailto:users@nifi.apache.org> Objet: RE: invokeHTTP SSL error NIFI : 1.23.2 Minh, I would be reluctant to simply trust an external web site's certificate directly unless I personally knew the operators and could vouch for their reputation, and knew the reason they did not have a signed certificate. The point about Root CAs is that are supposed to perform the required diligence to ensure the site is trustworthy, at least ensuring the site is operated by the legal owners of the domain they are using. The easiest tool to use to check the certificate and its trust chain is your own browser. Using Edge for example I can click to check that the site is secure and there is a simple tool for viewing the trust chain. I can see this web site uses a certificate that was issued on Tuesday, 3 October 2023 at 12:46:54 BST. Did your problems with connecting start about then? The certificate has a wildcard subject (CN = *.reputation.com) and signed by a Let's Encrypt signing certificate: Subject: CN = R3, O = Let's Encrypt, C = US Serial: 00:91:2B:08:4A:CF:0C:18:A7:53:F6:D6:2E:25:A7:5F:5A Validity: 04/09/2020, 01:00:00 BST to 15/09/2025, 17:00:00 BST This in turn is signed by a root certificate Subject: CN = ISRG Root X1, O = Internet Security Research Group, C = US Serial: 00:82:10:CF:B0:D2:40:E3:59:44:63:E0:BB:63:82:8B:00 Validity: 04/06/2015, 12:04:38 BST to 04/06/2035, 12:04:38 BST It is this last certificate that you probably have in your CA certs file as "letsencryptisrgx1" (Let's Encrypt ISRG X1 !?!). If the subject, serial and validity dates for your copy match these details here (or better yet, the details you discover yourself through your own investigation - why trust me eh?) then you indeed have the right root cert. The question then is why the HTTP processor cannot form the trust chain from the web site to the root cert just like my Edge browser has managed to do. Are there any security patches for the JVM which might update the cacerts? Are you sure you are referencing the right cacerts file from NiFi? Does NiFi have read permission on the file? What happens if you GET a page from a different HTTPS site, like https://www.microsoft.com/ do you have any trust issues then? Can you run some commands with openssl on the command line of your NiFi server host to check the trust of the site and output the process verbosely? Sorry if I cannot be more help, I just had to step in before you went away with the belief that the solution to external certificate issues is to blindly trust individual certificates. Steve Hindmarch From: Etienne Jouvin <lapinoujou...@gmail.com<mailto:lapinoujou...@gmail.com>> Sent: Monday, November 27, 2023 2:28 PM To: users@nifi.apache.org<mailto:users@nifi.apache.org> Subject: Re: invokeHTTP SSL error NIFI : 1.23.2 What do you mean by : "Let Encrypt CA" is already setup ? If this is only the root certificate for Let Encrypt, then you do not have the certificate for api-eu.reputation.com<http://api-eu.reputation.com/> in your truststore. I may say something wrong, but if I had to do it, I will create a new truststore and not use the one from JDK, use the SSL Context service to configure the truststore location and password. Le lun. 27 nov. 2023 à 13:58, <e-soci...@gmx.fr<mailto:e-soci...@gmx.fr>> a écrit : Hello, It is not working I have used : # true | openssl s_client -showcerts -connect api-eu.reputation.com:443<http://api-eu.reputation.com:443/> I saw it is manage by Let Encrypt And the let Encrypt CA is already setup in the file 11.0.17/lib/security/cacerts => alias name: letsencryptisrgx1 [jdk] so I configure SSL controler base on filename "11.0.17/lib/security/cacerts" in the truststore But always failed .. Envoyé: lundi 27 novembre 2023 à 11:00 De: "Etienne Jouvin" <lapinoujou...@gmail.com<mailto:lapinoujou...@gmail.com>> À: users@nifi.apache.org<mailto:users@nifi.apache.org> Objet: Re: invokeHTTP SSL error NIFI : 1.23.2 Oh I did not get this is an external api. Yes because it is https, you should import the certificate. There was an update of OKHttpClient, which is more restrictive regarding certificate. Le lun. 27 nov. 2023 à 10:52, <e-soci...@gmx.fr<mailto:e-soci...@gmx.fr>> a écrit : Hello Thank for reply, the weird thing it is until now, I don't use SSL context and it is working. Good anyway, I will get the server certificate and add it in the truststore and configure invokeHTTP to user SSL context also Thanks Minh Envoyé: lundi 27 novembre 2023 à 10:48 De: "Etienne Jouvin" <lapinoujou...@gmail.com<mailto:lapinoujou...@gmail.com>> À: users@nifi.apache.org<mailto:users@nifi.apache.org> Objet: Re: invokeHTTP SSL error NIFI : 1.23.2 Hello; For sure, the certificate for the target server is not valid. We had this issue also, because in the certificate the alias was missing. Check your certificate, and I guess you will have to generate it again, import it in the truststore. Regards Le lun. 27 nov. 2023 à 10:28, <e-soci...@gmx.fr<mailto:e-soci...@gmx.fr>> a écrit : Hello all, Since I've upgraded the nifi version from 1.18 to 1.23.2 - Java Version 11.0.17 I got the error concerning the invokeHTTP (GET https://api-eu.reputation.com/v3/ ..) even if I setup SSL Context or not Do you have informations about what has changed between the 2 nifi version ? In 1.18.0 this url (GET https://api-eu.reputation.com/v3/ ..) working with no issue Thanks for Helps Minh 2023-11-27 09:21:09,710 ERROR [Timer-Driven Process Thread-6] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=da03ad8a-5a88-344c-a9b6-b88efb2e871b] Request Processing failed: StandardFlowFileRecord[uuid=2d75e8bc-1d2c-4d7d-938f-23c10bd5128d,claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1701076362668-643397, container=repo0, section=325], offset=9405, length=165],offset=120,name=b8de3009-45e3-48e7-855d-8b252275f259,size=45] javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:369) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:312) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:478) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:456) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:199) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1382) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1295) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:416) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:388) at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:379) at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337) at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209) at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226) at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106) at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74) at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255) at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201) at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154) at org.apache.nifi.processors.standard.InvokeHTTP.onTrigger(InvokeHTTP.java:951) at org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27) at org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1361) at org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:247) at org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:102) at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439) at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306) at java.base/sun.security.validator.Validator.validate(Validator.java:264) at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313) at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222) at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)
