The JVM manages its own key store and certificate chains separately from those managed by your browser(s) and/or OS
Thus you may need to obtain the root certificates for your CA (which should be readily available) and add them to the JVM key store Digicert's appear to be available at https://www.digicert.com/digicert-root-certificates.htm Rob On 14/09/2015 16:04, "Jason Levitt" <[email protected]> wrote: >It's a Digicert wildcard certificate that's paid for, valid, and >actively used for several >domains (e.g. xxxx.mysite.com, yyyy.mysite,com, etc..). As I pointed >out, the latest >versions of Chrome and Firefox show the certificate as perfectly valid >when I >browse to the fuseki admin app at https://fuseki.mysite.com:8443 > >So, maybe the question is: what's the difference between a web browser >client and >a Java 8 client trying to connect over SSL? Does a Java 8 client >require some special >configuration to connect over SSL? > >J > >---------- Forwarded message ---------- >From: Rob Vesse <[email protected]> >Date: Mon, Sep 14, 2015 at 3:47 AM >Subject: Re: Fuseki over HTTPS? >To: [email protected] > > >Basically the certificate is not trusted, most likely because you created >a self signed certificate > >I have a repo at https://bitbucket.org/rvesse/java-ssl-helper/overview >which has some useful scripts for configuring the JVM keystore on *nix/OS >X based systems > >Rob > >On 13/09/2015 17:19, "Andy Seaborne" <[email protected]> wrote: > >> >>On 12/09/15 05:23, Jason Levitt wrote: >>> As I mentioned, I have Fuseki running using SSL with a valid >>>certificate. >>> >>> However, when I try to access the site remotely, using the Jena libs, >>> I get the exception below. >> >>http://stackoverflow.com/questions/6908948/java-sun-security-provider-cer >>t >>path-suncertpathbuilderexception-unable-to-find >> >>https://blogs.oracle.com/gc/entry/unable_to_find_valid_certification >> >>? >> >> Andy >>> >>> Firefox shows that the endpoint (via the admin app) is a valid >>> Digicert certificate. >>> >>> Is there something missing in the Jena API handshake? >>> >>> org.apache.jena.atlas.web.HttpException: >>> javax.net.ssl.SSLHandshakeException: >>> sun.security.validator.ValidatorException: PKIX path building failed: >>> sun.security.provider.certpath.SunCertPathBuilderException: unable to >>> find valid certification path to requested target >>> at org.apache.jena.riot.web.HttpOp.exec(HttpOp.java:1125) >>> at org.apache.jena.riot.web.HttpOp.execHttpHead(HttpOp.java:1039) >>> at >>>org.apache.jena.web.DatasetGraphAccessorHTTP.doHead(DatasetGraphAccessor >>>H >>>TTP.java:156) >>> at >>>org.apache.jena.web.DatasetGraphAccessorHTTP.httpHead(DatasetGraphAccess >>>o >>>rHTTP.java:150) >>> at >>>org.apache.jena.web.DatasetAdapter.containsModel(DatasetAdapter.java:56) >>> ... >>> ... >>> .... >>> ... >>> ... >>> >>> >>> On Fri, Sep 11, 2015 at 10:54 PM, Jason Levitt <[email protected]> >>>wrote: >>>> Andy, >>>> >>>> When do you officially plan to release Fuseki 2.3.1 with Netty >>>>updated? >>>> >>>> Cheers, >>>> >>>> J >>>> >>>> On Sat, Sep 5, 2015 at 3:12 PM, Andy Seaborne <[email protected]> wrote: >>>>> After exchanging intact XML files offlist, Jason and I managed to get >>>>>a >>>>> working Jetty configuration for HTTP+HTTPS to work with Fuseki after >>>>>the >>>>> updates to Jetty 9.3.3: >>>>> >>>>> This should be taken as an example, not the definitive setup. >>>>> >>>>> https://gist.github.com/afs/63a80512cdc55caf77d0 >>>>> >>>>> Improvements and verification very welcome. >>>>> >>>>> Andy >>
