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