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 >> >> >> >> >>
