Hi Walter,

I could be mistaken, but my interpretation of the Trusted Hostname 
configuration option is that it is designed to work with/in-addition-to the 
truststore, not instead of a truststore as an alternative trust mechanism. 

Basically, I think it is to be used in situations when the default hostname 
verifier (i.e., the remote hostname must match the hostname/SANs of the 
certificate) prevents the connection. IF you have a reason the hostname does 
not match the cert (for example, a dev/test environment) you could whitelist an 
alternative hostname while still making aan HTTPS connection.

Note that when using this option there are man-in-the-middle attack 
implications you should consider.

Hope this helps!

Cheers,
Kevin


On January 9, 2019 at 03:28:45, Vos, Walter (walter....@ns.nl) wrote:
> Hi,
>  
> I'm trying to use the invokeHttp processor to POST to an https site through a 
> proxy. The  
> proxy is http. Through some googling I found references that Java is rather 
> finicky with  
> SSL connections and wants the target server certificate in its truststore, 
> but InvokeHttp  
> also offers the trusted hostname parameter.
>  
> Because I don't have CLI access to the server that NiFi runs on, that seemed 
> like the way  
> to get what I want and I added the hostname to the Trusted Hostname. The 
> domain is in a form  
> of subsub.sub.domain.tld and I've tried it just like, as well as 
> *.sub.domain.tld and  
> *.domain.tld and domain.tld, but I keep getting this Java exception:
>  
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException:  
> unable to find valid certification path to requested target
>  
> Am I doing something wrong? Is truststore really the only way to go? We're 
> working with  
> HDF 3.1.0 / NiFi 1.5.0.*
>  
> Cheers, Walter
>  
> ________________________________
>  
> Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor 
> (gebruik door)  
> de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie 
> bevatten.  
> Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de 
> inhoud  
> van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet 
> toegestaan.  
> Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht 
> degene die  
> de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en 
> eventuele bijlagen)  
> te vernietigen.
>  
> Informatie vennootschap
>  

Reply via email to