Rob, just as a folowup. I added all the properties to the command line and everything works as expected. Not sure what was going on. Thanks for your help.
On Thu, Feb 5, 2015 at 2:13 PM, Trevor Donaldson <[email protected]> wrote: > Rob, so even if I setup all of the javax.net.ssl.keystore etc... > properties, they don't apply to the Http call? > > On Wed, Feb 4, 2015 at 1:54 PM, Trevor Donaldson <[email protected]> > wrote: > >> I imported the certificate plus I loaded all the system properties. I am >> not sure if it has something to do with how >> DatasetAccessorFactory.createHttp works, specifically how, the Http >> connection is made. >> >> On Wed, Feb 4, 2015 at 1:33 PM, Trevor Donaldson <[email protected]> >> wrote: >> >>> no the keystore approach did not work for me. I am not sure why it >>> didn't work. It is only causing a problem with Java App->Fuseki (inside >>> tomcat ssl container) >>> >>> On Wed, Feb 4, 2015 at 12:57 PM, Rob Vesse <[email protected]> wrote: >>> >>>> Trevor >>>> >>>> Did the key store approach not work for you? >>>> >>>> That is the preferred approach as the code approach you've used >>>> essentially removes any SSL security from your application and makes it >>>> vulnerable to man in the middle attacks >>>> >>>> Rob >>>> >>>> On 04/02/2015 08:10, "Trevor Donaldson" <[email protected]> wrote: >>>> >>>> >In case anyone else is struggling with this. I had to go with the >>>> method >>>> >that Rob described here >>>> > >>>> > >>>> https://github.com/rvesse/sparql-query-bm/blob/master/cmd/src/main/java/ne >>>> >t/sf/sparql/benchmarking/commands/AbstractCommand.java#L444 >>>> > >>>> >More specifically trusting all certificates. >>>> > >>>> >On Tue, Feb 3, 2015 at 8:19 PM, Rob Vesse <[email protected]> >>>> wrote: >>>> > >>>> >> As I suggested based on your original description this error does >>>> indeed >>>> >> mean that the certificate is not trusted. Either it is a self-signed >>>> >> certificate OR there is an untrusted certificate/certificate >>>> authority >>>> >>in >>>> >> the certificate chain >>>> >> >>>> >> You should not need to pass a SSLContext to anything in order to >>>> resolve >>>> >> this. >>>> >> >>>> >> Configuring the key store on your machine to trust the relevant >>>> >> certificate(s) is a JVM level feature and will be sufficient in most >>>> >> cases. The key store is automatically discovered by the JVM and >>>> used by >>>> >> higher level libraries like Apache HTTP Client (which underpins all >>>> HTTP >>>> >> functionality in ARQ). >>>> >> >>>> >> Rob >>>> >> >>>> >> On 03/02/2015 16:25, "Trevor Donaldson" <[email protected]> wrote: >>>> >> >>>> >> >Thanks Rob. Apologies for not adding some of the stacktrace. Here is >>>> >>the >>>> >> >error. >>>> >> > PKIX path building failed: >>>> >> >sun.security.provider.certpath.SunCertPathBuilderException: unable >>>> to >>>> >>find >>>> >> >valid certification path to requested target >>>> >> > >>>> >> >DatasetAccessor datasetAccessor = >>>> DatasetAccessorFactory.createHTTP(" >>>> >> >https://localhost:8443/ds";); >>>> >> > >>>> >> >I believe I may have to pass the HttpAuthenticator with an >>>> SSLContext. >>>> >>Not >>>> >> >sure how the DatasetAccessorFactory "knows" about my keystore and >>>> >> >truststore. >>>> >> > >>>> >> >On Tue, Feb 3, 2015 at 6:38 PM, Rob Vesse <[email protected]> >>>> wrote: >>>> >> > >>>> >> >> Trevor >>>> >> >> >>>> >> >> An invalid certificate exception generally means that the >>>> >>certificate is >>>> >> >> not trusted (often because it is self-signed) but without seeing a >>>> >> >> specific error condition and stack trace we can only guess what >>>> the >>>> >> >>actual >>>> >> >> problem is. >>>> >> >> >>>> >> >> Generally I would not expect it to be a HttpAuthenticator specific >>>> >> >>problem >>>> >> >> but again without a stack trace we can only speculate. You can >>>> use >>>> >>the >>>> >> >> debugging support (basically appropriately configuring logging) if >>>> >>you >>>> >> >> want to see exactly what Apache HTTP Client is doing under the >>>> hood: >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >>>> >> >>>> https://jena.apache.org/documentation/query/http-auth.html#debugging-auth >>>> >> >>en >>>> >> >> tication >>>> >> >> >>>> >> >> Trusting a certificate that would otherwise not be trusted is >>>> >>generally >>>> >> >>a >>>> >> >> JVM specific task and requires you to either configure the JVM key >>>> >>store >>>> >> >> on each machine your client runs on appropriately OR do some nasty >>>> >>code >>>> >> >> hacks that essentially disables SSL certificate verification in >>>> your >>>> >> >>JVM. >>>> >> >> For example the following SO question shows both approaches: >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >>>> >> >>>> http://stackoverflow.com/questions/2893819/telling-java-to-accept-self-si >>>> >> >>gn >>>> >> >> ed-ssl-certificate >>>> >> >> >>>> >> >> I have some helper scripts that I've used in the past up on >>>> BitBucket >>>> >> >>that >>>> >> >> can help automate the key store management because it is a little >>>> >> >>esoteric >>>> >> >> if you've never had to do it before: >>>> >> >> >>>> >> >> https://bitbucket.org/rvesse/java-ssl-helper/overview >>>> >> >> >>>> >> >> Note that under some JVMs using this approach may not help (IBM V9 >>>> >>was >>>> >> >> problematic if memory serves) and you may need to use the code >>>> >>approach >>>> >> >> instead. See the following code where I've done this in a tool >>>> that >>>> >> >>uses >>>> >> >> ARQ and HttpAuthenticator's in the past: >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >>>> >> >>>> https://github.com/rvesse/sparql-query-bm/blob/master/cmd/src/main/java/n >>>> >> >>et >>>> >> >> /sf/sparql/benchmarking/commands/AbstractCommand.java#L444 >>>> >> >> >>>> >> >> Rob >>>> >> >> >>>> >> >> >>>> >> >> On 03/02/2015 12:49, "Trevor Donaldson" <[email protected]> >>>> wrote: >>>> >> >> >>>> >> >> >Is it possible to setup an ssl context using HttpAuthenticator? >>>> I am >>>> >> >> >getting an invalid certificate exception when I try to use >>>> >> >>DataSetFactory. >>>> >> >> >I believe this is because the actual call is not using SSL. >>>> >> >> > >>>> >> >> >Thanks >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >>>> >>>> >>>> >>>> >>> >> >
