RE: Truststore/Trusted hostname
Hi, I’ve spoken to the admins in the meantime and their suspicion is that the proxy changes the certificate which causes issues. They’re investigating, but it’ll probably be a misconfiguration of the truststore. Thanks for the suggestions! -Walter Van: Andrew Grande [mailto:apere...@gmail.com] Verzonden: woensdag 9 januari 2019 20:25 Aan: users@nifi.apache.org CC: Vos, Walter Onderwerp: Re: Truststore/Trusted hostname Walter, you could point to the default JRE truststore file, maybe. Andrew On Wed, Jan 9, 2019, 7:12 AM Kevin Doran mailto:kdo...@apache.org>> wrote: 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<mailto: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 > 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<http://www.ns.nl/emaildisclaimer>
Re: Truststore/Trusted hostname
Walter, you could point to the default JRE truststore file, maybe. Andrew On Wed, Jan 9, 2019, 7:12 AM Kevin Doran wrote: > 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 > > > >
Re: Truststore/Trusted hostname
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 >
