Re: InvokeHttp -- StandardSSLContextService Validator Exception

[Andy LoPresto]

Pat,

Curl’s -k option skips certificate validity checking [1], and we don’t allow 
that. However, you can go through the process to explicitly add that public 
certificate into your local truststore, which should then work.

I’m going to outline the process here (I’m doing this from memory so you may 
encounter an issue; write back and I’ll try to reproduce)

* Using your browser or s_client, download the public certificate presented by 
the remote server. You can do this by using the “Security” panel of “Developer 
Tools” in Chrome, for example. There are ways to do it in any major browser. 
For s_client (probably the fastest way), use:

$ openssl s_client -connect host:port -showcerts

and you should get some output with

Certificate chain
 0 s:/DN of your host
   i:/DN of CA (or same as above if self-signed)
-BEGIN CERTIFICATE-
Lots of Base64…
-END CERTIFICATE-
 1 (repeats for as many certs as are in chain)

That’s the Base64-encoded representation of the certificate, or what we call 
“PEM” format.

Find the last block of that text (the one corresponding to the highest number), 
and copy it (including the -BEGIN… and -END… lines entirely) into a 
file and save it as ca.pem.

To examine it (for sanity), you can run the following command to parse it and 
display it:

$ openssl x509 -in ca.pem -text -noout

To import it as a trusted certificate into your truststore, you need one more 
step:

$ keytool -import -v -trustcacerts -alias my-ca -file ca.pem -keystore 
truststore.ks

You can put whatever you want (machine-parseable string) for “my-ca”, that’s 
just the alias that will be used for this entry and it doesn’t matter to NiFi.

You can verify that the CA has been successfully imported to the truststore by 
using:

$ keytool -list -v -alias my-ca -keystore truststore.jks

Now you should have a Java truststore which knows the remote endpoint(’s 
signing) certificate and can verify it on connection.

To check to see if curl now works “securely”, try your curl command without the 
-k and provide --cacert ca.pem to inform curl of the expected remote 
certificate.

[1] https://curl.haxx.se/docs/sslcerts.html 
<https://curl.haxx.se/docs/sslcerts.html>

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Mar 14, 2018, at 1:43 PM, Jones, Patrick L. <p...@mitre.org> wrote:
> 
> Thank you so much for your help.  I looked at all of my certs and my 
> keystore/trustore.  Everything is as I thought it would be.  The openssl 
> s_client -connect … also worked.
> I think the problem is with my CA cert.  I said I use curl with the certs.  I 
> do but it only works with the –insecure (-k) flag.
> So my conclusion is that unless there is some way to tell NiFi to work in 
> insecure mode, I will have to convince someone to give me certs that work 
> without an insecure mode.  Then hopefully all of this will work
> 
> Thanx again,
> 
> Pat
> 
> 
> From: Andy LoPresto [mailto:alopre...@apache.org]
> Sent: Tuesday, March 13, 2018 4:36 PM
> To: users@nifi.apache.org
> Subject: Re: InvokeHttp -- StandardSSLContextService Validator Exception
> 
> Pat,
> 
> That error means that NiFi could not find a valid trusted certificate for the 
> hostname in question within the provided truststore. Understanding that the 
> system in question may be on a limited network, can you please document what 
> “the certs work when I use curl” means? Sometimes people include flags in 
> curl that sidestep certain verification steps. You can also use the s_client 
> tool provided within OpenSSL to verify the hostname and certificate exchange.
> 
> In general, you should be able to use a browser tool or s_client to show the 
> certificate(s) being presented by the endpoint, and verify that the Subject 
> Public Key Identifier of one or more of those certificates matches one listed 
> in your truststore ($ keytool -list -v -keystore my_truststore.jks). Some 
> other good things to verify:
> 
> * the certificate has validity dates that are currently active
> * the certificate presents the proper hostname/IP address that the remote 
> service is running on. Ensure any alternates you want to resolve are in the 
> Subject Alternative Names entry
> * you only need the private key in a keystore (and the keystore at all) if 
> you are using TLS mutual authentication (i.e. NiFi presents a client 
> certificate for authentication to be verified by the remote service)
> 
> Let us know if these steps help and you have further information.
> 
> $ openssl s_client -connect  -debug -state -cert 
>  -key  -CAfile 
> 
> 
> 
> Andy LoPresto
> alopre...@apache.org <mailto:alopre...@apache.org>
> alopresto.apa...@gmail.com <mailto:alopresto.apa...@gmail.com>
> PGP Fingerpri

RE: InvokeHttp -- StandardSSLContextService Validator Exception

[Jones, Patrick L.]

Thank you so much for your help.  I looked at all of my certs and my 
keystore/trustore.  Everything is as I thought it would be.  The openssl 
s_client -connect … also worked.
I think the problem is with my CA cert.  I said I use curl with the certs.  I 
do but it only works with the –insecure (-k) flag.
So my conclusion is that unless there is some way to tell NiFi to work in 
insecure mode, I will have to convince someone to give me certs that work 
without an insecure mode.  Then hopefully all of this will work

Thanx again,

Pat


From: Andy LoPresto [mailto:alopre...@apache.org]
Sent: Tuesday, March 13, 2018 4:36 PM
To: users@nifi.apache.org
Subject: Re: InvokeHttp -- StandardSSLContextService Validator Exception

Pat,

That error means that NiFi could not find a valid trusted certificate for the 
hostname in question within the provided truststore. Understanding that the 
system in question may be on a limited network, can you please document what 
“the certs work when I use curl” means? Sometimes people include flags in curl 
that sidestep certain verification steps. You can also use the s_client tool 
provided within OpenSSL to verify the hostname and certificate exchange.

In general, you should be able to use a browser tool or s_client to show the 
certificate(s) being presented by the endpoint, and verify that the Subject 
Public Key Identifier of one or more of those certificates matches one listed 
in your truststore ($ keytool -list -v -keystore my_truststore.jks). Some other 
good things to verify:

* the certificate has validity dates that are currently active
* the certificate presents the proper hostname/IP address that the remote 
service is running on. Ensure any alternates you want to resolve are in the 
Subject Alternative Names entry
* you only need the private key in a keystore (and the keystore at all) if you 
are using TLS mutual authentication (i.e. NiFi presents a client certificate 
for authentication to be verified by the remote service)

Let us know if these steps help and you have further information.

$ openssl s_client -connect  -debug -state -cert 
 -key  -CAfile 



Andy LoPresto
alopre...@apache.org<mailto:alopre...@apache.org>
alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Mar 13, 2018, at 12:16 PM, Jones, Patrick L. 
<p...@mitre.org<mailto:p...@mitre.org>> wrote:

The best I could do right now is:

invokehttp.java.exception.class
javax.net.ssl.SSLHandshakeException

invokehttp.java.exception.message
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target

Any thoughts?

Pat

From: Jorge Machado [mailto:jom...@me.com]
Sent: Tuesday, March 13, 2018 9:48 AM
To: users@nifi.apache.org<mailto:users@nifi.apache.org>
Subject: Re: InvokeHttp -- StandardSSLContextService Validator Exception

Any trace for us ?
Working Example:


Jorge Machado








On 13 Mar 2018, at 13:11, Jones, Patrick L. 
<p...@mitre.org<mailto:p...@mitre.org>> wrote:

Howdy,

I’m using a StandardSSLContextService with InvokeHttp and I get a 
ValidatorException ‘unable to find valid certification path to requested 
target.’  The certs work when I use curl.  I put the CA cert and the public key 
cert in the StandardSSLContextService truststore and the private key in the 
keystore.  Any thoughts on how to make this work?

Thank you,

Pat

Re: InvokeHttp -- StandardSSLContextService Validator Exception

[Andy LoPresto]

Pat,

That error means that NiFi could not find a valid trusted certificate for the 
hostname in question within the provided truststore. Understanding that the 
system in question may be on a limited network, can you please document what 
“the certs work when I use curl” means? Sometimes people include flags in curl 
that sidestep certain verification steps. You can also use the s_client tool 
provided within OpenSSL to verify the hostname and certificate exchange.

In general, you should be able to use a browser tool or s_client to show the 
certificate(s) being presented by the endpoint, and verify that the Subject 
Public Key Identifier of one or more of those certificates matches one listed 
in your truststore ($ keytool -list -v -keystore my_truststore.jks). Some other 
good things to verify:

* the certificate has validity dates that are currently active
* the certificate presents the proper hostname/IP address that the remote 
service is running on. Ensure any alternates you want to resolve are in the 
Subject Alternative Names entry
* you only need the private key in a keystore (and the keystore at all) if you 
are using TLS mutual authentication (i.e. NiFi presents a client certificate 
for authentication to be verified by the remote service)

Let us know if these steps help and you have further information.

$ openssl s_client -connect  -debug -state -cert 
 -key  -CAfile 



Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Mar 13, 2018, at 12:16 PM, Jones, Patrick L. <p...@mitre.org> wrote:
> 
> The best I could do right now is:
> 
> invokehttp.java.exception.class
> javax.net.ssl.SSLHandshakeException
> 
> invokehttp.java.exception.message
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
> 
> Any thoughts?
> 
> Pat
> 
> From: Jorge Machado [mailto:jom...@me.com <mailto:jom...@me.com>]
> Sent: Tuesday, March 13, 2018 9:48 AM
> To: users@nifi.apache.org <mailto:users@nifi.apache.org>
> Subject: Re: InvokeHttp -- StandardSSLContextService Validator Exception
> 
> Any trace for us ?
> Working Example:
> 
> 
> Jorge Machado
> 
> 
> 
> 
> 
> 
> On 13 Mar 2018, at 13:11, Jones, Patrick L. <p...@mitre.org 
> <mailto:p...@mitre.org>> wrote:
> 
> Howdy,
> 
> I’m using a StandardSSLContextService with InvokeHttp and I get a 
> ValidatorException ‘unable to find valid certification path to requested 
> target.’  The certs work when I use curl.  I put the CA cert and the public 
> key cert in the StandardSSLContextService truststore and the private key in 
> the keystore.  Any thoughts on how to make this work?
> 
> Thank you,
> 
> Pat



signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: InvokeHttp -- StandardSSLContextService Validator Exception

[Jones, Patrick L.]

The best I could do right now is:

invokehttp.java.exception.class
javax.net.ssl.SSLHandshakeException

invokehttp.java.exception.message
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target

Any thoughts?

Pat

From: Jorge Machado [mailto:jom...@me.com]
Sent: Tuesday, March 13, 2018 9:48 AM
To: users@nifi.apache.org
Subject: Re: InvokeHttp -- StandardSSLContextService Validator Exception

Any trace for us ?
Working Example:
[cid:image001.png@01D3BADE.2D9BAF00]

Jorge Machado






On 13 Mar 2018, at 13:11, Jones, Patrick L. 
<p...@mitre.org<mailto:p...@mitre.org>> wrote:

Howdy,

I’m using a StandardSSLContextService with InvokeHttp and I get a 
ValidatorException ‘unable to find valid certification path to requested 
target.’  The certs work when I use curl.  I put the CA cert and the public key 
cert in the StandardSSLContextService truststore and the private key in the 
keystore.  Any thoughts on how to make this work?

Thank you,

Pat

RE: InvokeHttp -- StandardSSLContextService Validator Exception

[Jones, Patrick L.]

The working example looks the same as mine.  I’ll post a trace when I get to 
that computer.


Pat

From: Jorge Machado [mailto:jom...@me.com]
Sent: Tuesday, March 13, 2018 9:48 AM
To: users@nifi.apache.org
Subject: Re: InvokeHttp -- StandardSSLContextService Validator Exception

Any trace for us ?
Working Example:
[cid:image001.png@01D3BAB2.353B4C60]

Jorge Machado






On 13 Mar 2018, at 13:11, Jones, Patrick L. 
<p...@mitre.org<mailto:p...@mitre.org>> wrote:

Howdy,

I’m using a StandardSSLContextService with InvokeHttp and I get a 
ValidatorException ‘unable to find valid certification path to requested 
target.’  The certs work when I use curl.  I put the CA cert and the public key 
cert in the StandardSSLContextService truststore and the private key in the 
keystore.  Any thoughts on how to make this work?

Thank you,

Pat

Re: InvokeHttp -- StandardSSLContextService Validator Exception

[Jorge Machado]

Any trace for us ? 
Working Example: 


Jorge Machado





> On 13 Mar 2018, at 13:11, Jones, Patrick L.  wrote:
> 
> Howdy,
>  
> I’m using a StandardSSLContextService with InvokeHttp and I get a 
> ValidatorException ‘unable to find valid certification path to requested 
> target.’  The certs work when I use curl.  I put the CA cert and the public 
> key cert in the StandardSSLContextService truststore and the private key in 
> the keystore.  Any thoughts on how to make this work?
>  
> Thank you,
>  
> Pat
>  

InvokeHttp -- StandardSSLContextService Validator Exception

[Jones, Patrick L.]

Howdy,

I'm using a StandardSSLContextService with InvokeHttp and I get a 
ValidatorException 'unable to find valid certification path to requested 
target.'  The certs work when I use curl.  I put the CA cert and the public key 
cert in the StandardSSLContextService truststore and the private key in the 
keystore.  Any thoughts on how to make this work?

Thank you,

Pat