find it here:
https://issues.apache.org/jira/browse/CONNECTORS-1635
On Thu, Jan 30, 2020 at 1:48 PM Jörn Franke <jornfra...@gmail.com> wrote:
> Sorry yes i was busy - will do it tonight
>
> Am 30.01.2020 um 13:00 schrieb Karl Wright <daddy...@gmail.com>:
>
>
> Hi,
>
> I've been waiting for a ticket to appear that summarizes what's been
> happening for this issue but I haven't seen one. Can you bring us up to
> date? Thanks in advance,
> Karl
>
> On Wed, Jan 22, 2020 at 12:06 PM Jörn Franke <jornfra...@gmail.com> wrote:
>
>> i try to help. I will create a Jira if you do not mind where I also
>> explain how I make the WSDL thing working for https, which could not have
>> worked before.
>> Reason is that for fetching the WSDL it uses a completely different
>> approach (WSDL4Java), where in the connector code no truststore was defined
>> (only for doing actually SOAP requests). This was fixed and it can create
>> the service. But then after service creation in the following lines of
>> codes it fetches the xsd which does not work (it says it cannot find them),
>> which is strange as the Url is correct and reachable. Hence, I suspect it
>> does not understand it is a http URL but instead it tries to open it on the
>> file system.
>> I am pretty busy at the moment, but I try to support and give feedback as
>> soon as possible.
>>
>> I don’t know what is different to your 2 installations - maybe they are
>> http or partly http or there is some patch to the code that did not make it
>> into the git.
>> I can tell that I can test with Content Server 10 as well as 16.
>> SOAP UI has no problem and in the end it does exactly the same (starting
>> from the https WSDL etc.)
>>
>> Am 22.01.2020 um 13:17 schrieb Karl Wright <daddy...@gmail.com>:
>>
>>
>> The whole web services java + cxf architecture is pretty mysterious. The
>> only way I've made progress is by finding code snippets in stackoverflow;
>> the documentation is not adequate. BUT there are configuration files that
>> determine how the WSDL parser resolves references. I don't know how we
>> would force that configuration to be in effect but something like that
>> would need to be done. I'm just surprised that you're having this problem
>> when two other installations didn't. There must be a difference somewhere.
>>
>> Karl
>>
>>
>> On Wed, Jan 22, 2020 at 5:11 AM Jörn Franke <jornfra...@gmail.com> wrote:
>>
>>> Sorry I did not have much time, my next action plan is to try to modify
>>> the catalogue xml to fetch it directly from the https. For some reasons it
>>> can fetch the WSDL (after my fix), but not the included xsds despite that
>>> in the error message it has the correct url of them.
>>> Are you aware of any configuration that tries to force file based access
>>> of those? In the Code i did not find anything suspicious.
>>>
>>> Am 22.01.2020 um 10:28 schrieb Karl Wright <daddy...@gmail.com>:
>>>
>>>
>>> Has there been any news?
>>> I'd love to get this tied up so that you're able to proceed.
>>> Karl
>>>
>>> On Thu, Jan 16, 2020 at 12:08 PM Jörn Franke <jornfra...@gmail.com>
>>> wrote:
>>>
>>>> Ok I understand. I will try and let you know. Thanks again very much
>>>> for your fast and detailed answer. Really appreciated. I hope I can give
>>>> back with the solution to fetch WSDLs from https and maybe a solution to
>>>> this problem (maybe other will face this as well).
>>>>
>>>> About the connector: the WSDL is successfully fetched via https (not
>>>> file - no clue why) - after the modification I made. The only problem I see
>>>> now is that the xsd to which the WSDL is referring are not fetched. The
>>>> bizarre thing is that the https url that it mention for the xsd is
>>>> absolutely correct. So I assume it does not understand an http url, maybe
>>>> that is related to configuration.
>>>>
>>>> Am 16.01.2020 um 14:53 schrieb Karl Wright <daddy...@gmail.com>:
>>>>
>>>>
>>>> The WSDLS are bundled with the jar. We intended this to be the ONLY
>>>> way the wsdls were accessed, and made lots of changes to the wsdls
>>>> accordingly, so that they referenced other wsdls via the "file system".
>>>> The wsdls are the fixed up ones that are used to build the java stubs
>>>> locally, plus a config file that's supposed to tell CXF how to resolve
>>>> referenced wsdls. That config file may or may not be correct, because we
>>>> never were able to get CXF to use the local resource wsdls during actual
>>>> connection.
>>>>
>>>> Except now they seem to be both fetched via https AND locally sourced.
>>>> I have no idea how that can be. I had assumed it was done one way or the
>>>> other but not both.
>>>>
>>>> Perhaps the problem is that the configuration file is being read but
>>>> the resource wsdls are not being found? Removing the meta-inf from the jar
>>>> would then force everything to go through https. Ideally I'd love it if
>>>> that wasn't needed and we could get the resource fetch working everywhere.
>>>>
>>>>
>>>> Karl
>>>>
>>>>
>>>> On Thu, Jan 16, 2020 at 8:20 AM Jörn Franke <jornfra...@gmail.com>
>>>> wrote:
>>>>
>>>>> Well i am not sure how they solved it - I will share a tested solution
>>>>> in Jira and everyone can check. Maybe their wsdl is accessible through
>>>>> http?
>>>>>
>>>>> What works is doing call through https, but thee fetching of WSDL did
>>>>> not - as this is through another mechanism.
>>>>>
>>>>> I don’t think that the open text is different, the WSDL look very
>>>>> similar to the repository.
>>>>>
>>>>> The strange thing is that for this error message it tries to access
>>>>> the xsd through a https url (which is perfectly accessible for the
>>>>> server).
>>>>> Could it be that the connector restrict itself somehow to local file
>>>>> system only or similar?
>>>>> Have you faced this issue before?
>>>>>
>>>>>
>>>>>
>>>>> Am 16.01.2020 um 12:56 schrieb Karl Wright <daddy...@gmail.com>:
>>>>>
>>>>>
>>>>> I should say that we have (AFAICT) at least two independent
>>>>> installations of the csws connector working in the field, at least one of
>>>>> them using secure connections.
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>> On Thu, Jan 16, 2020 at 6:54 AM Karl Wright <daddy...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We solved the WSDL fetching through HTTPS, or thought we had, by
>>>>>> restructuring the code according to a number of articles we found. This
>>>>>> was supposedly tested and worked in one installation. Nobody has ever
>>>>>> reported issues with the wsdls being fetched however; I worry that you
>>>>>> may
>>>>>> have a different version of OpenText that is incompatible with the one we
>>>>>> developed against. That's the problem with this kind of architecture;
>>>>>> unless the wsdls are included in the jar there can be issues. We tried
>>>>>> to
>>>>>> do that too but were unable to get it to work.
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 16, 2020 at 5:34 AM Jörn Franke <jornfra...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok i fixed the source to fetch WSDL from https (it is not perfect
>>>>>>> yet as it does not use the truststore yet but this I can fix) - I will
>>>>>>> share later in a Jira.
>>>>>>> It is however now unable to locate the imported document
>>>>>>> /Authentication?xsd=2 relative to Authenticaton?wsdl#types1
>>>>>>>
>>>>>>> I will look into this, but if someone has come cross it then please
>>>>>>> let me know.
>>>>>>>
>>>>>>> Am 16.01.2020 um 10:22 schrieb Jörn Franke <jornfra...@gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>> Coming back to the original topic. I believe SSL was never fully
>>>>>>> solved from what i read in the corresponding issue. Apparently, the
>>>>>>> fetching of the WSDL itself through https was not possible. Do you
>>>>>>> remember
>>>>>>> still some insights beyond what is written in the issue ?
>>>>>>>
>>>>>>> Am 16.01.2020 um 00:37 schrieb Karl Wright <daddy...@gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>> Let me think about that option.
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke <jornfra...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We could make it configurable, e.g. in properties.xml. Here people
>>>>>>>> could set it to SSL, TLS, TLSv1.2 (to restrict it to TLS1.2 => some
>>>>>>>> companies may want that!). Is this a viable option? That would be also
>>>>>>>> future proof. We can leave it by default to SSL, but we should put in
>>>>>>>> the
>>>>>>>> example config files TLS by default (so new starters do not get even
>>>>>>>> the
>>>>>>>> idea to use an outdated protocol) AND put a comment with
>>>>>>>> recommendation to
>>>>>>>> use/enforce always newest protocols for security reasons. Of course,
>>>>>>>> the
>>>>>>>> choice is then with the people using the software.
>>>>>>>> Could that be something sensible from your point of view?
>>>>>>>>
>>>>>>>> On Wed, Jan 15, 2020 at 11:14 PM Karl Wright <daddy...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> It's rather immaterial what browsers do here. What's important is
>>>>>>>>> what *existing servers* support, since that is what we're connecting
>>>>>>>>> with.
>>>>>>>>>
>>>>>>>>> I tend to agree that *most* people have probably upgraded to web
>>>>>>>>> servers that support TLS. But we can't guarantee it, nor can we
>>>>>>>>> assume
>>>>>>>>> that people have upgraded to the most modern version of TLS
>>>>>>>>> exclusively.
>>>>>>>>> In fact I think we can assume they have *not*. When the SSL issues
>>>>>>>>> were
>>>>>>>>> discovered a couple of years back, the standard recommendation was
>>>>>>>>> simply
>>>>>>>>> to *disable* SSLv1 and SSLv2, not to upgrade to Java 11 or some such.
>>>>>>>>> We
>>>>>>>>> still support (and have people using!!) early forms of NTLM (v1 to be
>>>>>>>>> specific), for instance. We're not going to be able to wag the dog
>>>>>>>>> here.
>>>>>>>>> Breaking changes of this kind usually mean we go to a whole new major
>>>>>>>>> version of MCF.
>>>>>>>>>
>>>>>>>>> However, if you can show that SSLContext.getSSLFactory("TLS")
>>>>>>>>> produces a SSLSocketFactory that works with all versions of TLS and
>>>>>>>>> SSL
>>>>>>>>> that do not have known security holes, I would support changing over
>>>>>>>>> to
>>>>>>>>> that. If it turns out we need much more specificity about the kind of
>>>>>>>>> SSLSocketFactory we produce, then we need a better solution anyhow for
>>>>>>>>> handling multiple protocols in one socket factory.
>>>>>>>>>
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jan 15, 2020 at 5:17 AM Jörn Franke <jornfra...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Karl,
>>>>>>>>>>
>>>>>>>>>> No it does not. I can look into that further, but Current
>>>>>>>>>> browsers stop supporting anything below TLSv1.2 in March 2020.
>>>>>>>>>> Then TLS exists since more than ten years. I expect any server
>>>>>>>>>> running nowadays will always have tls support.
>>>>>>>>>> SSL itself is not supported since some time now. From a security
>>>>>>>>>> perspective it should even break servers that run only SSL as they
>>>>>>>>>> are
>>>>>>>>>> inherently insecure and also clients that only support SSL are
>>>>>>>>>> adding to
>>>>>>>>>> this.
>>>>>>>>>> However if you have an idea how this should be made configurable
>>>>>>>>>> then I can look into this.
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>>
>>>>>>>>>> Am 15.01.2020 um 10:52 schrieb Karl Wright <daddy...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Mcf currently requires jdk8. Jdk11 is non trivial to support
>>>>>>>>>> because of the removal of many jdk classes connectors need. It will
>>>>>>>>>> be
>>>>>>>>>> ported at some point but not lightly.
>>>>>>>>>>
>>>>>>>>>> Similarly, disabling SSL would certainly break many installations
>>>>>>>>>> upon upgrade and we do not do that lightly.
>>>>>>>>>>
>>>>>>>>>> The core methods that mcf supplies its connectors should
>>>>>>>>>> therefore be updated to support but not mandate tls. The protocol
>>>>>>>>>> specification one gives to sslcontext is not a detailed one but
>>>>>>>>>> rather a
>>>>>>>>>> major version. What I don't know is whether"tlsv1" also allows for
>>>>>>>>>> older
>>>>>>>>>> protocols etc.
>>>>>>>>>>
>>>>>>>>>> Karl
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 15, 2020, 1:19 AM Jörn Franke <jornfra...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Yes I am doing that but I will need to rebuild.
>>>>>>>>>>> I don’t recommend TLSv1 - this is already outphased and will
>>>>>>>>>>> lock out TLSv1.2. I try TLS only as it includes all TLS protocols
>>>>>>>>>>> (depends
>>>>>>>>>>> on JDK).
>>>>>>>>>>>
>>>>>>>>>>> SSL will not be supported by this (however as I said there are
>>>>>>>>>>> other parts of the code where there is a getInstance(TLS). And some
>>>>>>>>>>> caveats: On JDK6+7 TLS only means TLSv1 (and newer TLS Protocols are
>>>>>>>>>>> deactivated) on JDK8 it means also that newer TLS protocols are
>>>>>>>>>>> enabled.
>>>>>>>>>>> To be honest in my opinion - a SSL only one is a significant
>>>>>>>>>>> security hole and given how old TLS support is JDK i would be
>>>>>>>>>>> surprised if
>>>>>>>>>>> there is someone using such a server (most Organisations should
>>>>>>>>>>> switch to
>>>>>>>>>>> TLSv1.2 in any case as all protocols below have been broken).
>>>>>>>>>>> While it works for all JDKs - probably JDK8 should be
>>>>>>>>>>> recommended as it seems to have all TLS protocols activated when
>>>>>>>>>>> using
>>>>>>>>>>> „TLS“. Older JDKs seem to deactivate TLSv1.1 and TLSv1.2 when using
>>>>>>>>>>> TLS. I
>>>>>>>>>>> will write more about this in the JIRA, once I verified that this
>>>>>>>>>>> solves
>>>>>>>>>>> the problem.
>>>>>>>>>>> Then TLSv1.3 is JDK11 only - I will investigate what that
>>>>>>>>>>> implies.
>>>>>>>>>>> Does ManifoldCf supports JDK11?
>>>>>>>>>>>
>>>>>>>>>>> Am 15.01.2020 um 00:08 schrieb Karl Wright <daddy...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think you can just change the code to read as follows when it
>>>>>>>>>>> creates the SSLContext:
>>>>>>>>>>>
>>>>>>>>>>> SSLContext ctx = SSLContext.getInstance("TLSv1");
>>>>>>>>>>> I don't know if TLS will downgrade to SSL if that's all that's
>>>>>>>>>>> available.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 14, 2020 at 6:02 PM Jörn Franke <
>>>>>>>>>>> jornfra...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yes it you do not change this setting as what I suspect happens
>>>>>>>>>>>> here. See my previous mail for details.
>>>>>>>>>>>>
>>>>>>>>>>>> Am 14.01.2020 um 23:51 schrieb Karl Wright <daddy...@gmail.com
>>>>>>>>>>>> >:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It looks looks TLS is actually enabled in the SSLSocketFactory
>>>>>>>>>>>> framework based on how you create the SSLSocketContext. See:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://docs.oracle.com/cd/E19698-01/816-7609/security-83/index.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Karl
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jan 14, 2020 at 5:48 PM Karl Wright <daddy...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> The design of ManifoldCF deliberately manages keystores on a
>>>>>>>>>>>>> connection by connection basis, not globally. If you think the
>>>>>>>>>>>>> only way to
>>>>>>>>>>>>> implement TLS is via global keystore I very much doubt it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am on the road until late tomorrow but somewhere along the
>>>>>>>>>>>>> line I can do some research into why TLS won't work as we are
>>>>>>>>>>>>> currently
>>>>>>>>>>>>> doing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jan 14, 2020 at 12:56 PM Jörn Franke <
>>>>>>>>>>>>> jornfra...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> These are TLS only. So maybe you have other servers where tls
>>>>>>>>>>>>>> and ssl are possible and it downgrades to ssl.however, this is
>>>>>>>>>>>>>> speculation
>>>>>>>>>>>>>> and I need to verify it. I have to rebuilt manifold for that.
>>>>>>>>>>>>>> Probably I
>>>>>>>>>>>>>> have to reinstall everything as the keystorefactory is a
>>>>>>>>>>>>>> dependency in the
>>>>>>>>>>>>>> connector.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 14.01.2020 um 18:34 schrieb Karl Wright <
>>>>>>>>>>>>>> daddy...@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you can recommend changes to support TLS, that would be
>>>>>>>>>>>>>> great. The basic infrastructure should still work; it is just a
>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>> keystone and associated SSLSocketFactory, which I think also is
>>>>>>>>>>>>>> used for
>>>>>>>>>>>>>> TLS connections, unless I am missing something.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Jan 14, 2020, 9:38 AM Jörn Franke <
>>>>>>>>>>>>>> jornfra...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes this works fine. I believe the error comes from the fact
>>>>>>>>>>>>>>> that TLS connections are not supported.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 14.01.2020 um 15:31 schrieb Michael Cizmar <
>>>>>>>>>>>>>>> michael.ciz...@mcplusa.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you want to test the url and the ssl, I would recommend
>>>>>>>>>>>>>>> attempting using SSLPoke to confirm that they keystore is setup
>>>>>>>>>>>>>>> properly:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://github.com/MichalHecko/SSLPoke
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Michael
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *From: *Karl Wright <daddy...@gmail.com>
>>>>>>>>>>>>>>> *Reply-To: *"user@manifoldcf.apache.org" <
>>>>>>>>>>>>>>> user@manifoldcf.apache.org>
>>>>>>>>>>>>>>> *Date: *Tuesday, January 14, 2020 at 7:21 AM
>>>>>>>>>>>>>>> *To: *"user@manifoldcf.apache.org" <
>>>>>>>>>>>>>>> user@manifoldcf.apache.org>
>>>>>>>>>>>>>>> *Subject: *Re: CSWS Connector :
>>>>>>>>>>>>>>> ServiceConstructionException: Failed to create service
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hmm, others have succeeded setting up SSL connections with
>>>>>>>>>>>>>>> the current code. Hoping they chime in here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Jan 14, 2020, 8:19 AM Jörn Franke <
>>>>>>>>>>>>>>> jornfra...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems that it has indeed a certificate issue as it cannot
>>>>>>>>>>>>>>> find a valid certification path to the target. The thing is: I
>>>>>>>>>>>>>>> added those
>>>>>>>>>>>>>>> certificates in the UI should it should not happen.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 10.01.2020 um 20:51 schrieb Jörn Franke <
>>>>>>>>>>>>>>> jornfra...@gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2.15 ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will try on the weekend to see if I can get some logs out
>>>>>>>>>>>>>>> of it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 10.01.2020 um 19:02 schrieb Karl Wright <
>>>>>>>>>>>>>>> daddy...@gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can I ask what version of MCF you are using? There were
>>>>>>>>>>>>>>> issues with SSL in the first release of the csws connector if I
>>>>>>>>>>>>>>> recall
>>>>>>>>>>>>>>> correctly, that were fixed for the second release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jan 10, 2020 at 11:42 AM Jörn Franke <
>>>>>>>>>>>>>>> jornfra...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added root, intermediate and server certificate (in base64
>>>>>>>>>>>>>>> cer, it seems to be recognized by manifoldcf), but I still get
>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>> message. I will try to get somehow the full stacktrace
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 10.01.2020 um 17:21 schrieb Karl Wright <
>>>>>>>>>>>>>>> daddy...@gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you are using SSL you need to have the proper certificate
>>>>>>>>>>>>>>> saved in the connection's keystore.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jan 10, 2020 at 11:20 AM Jörn Franke <
>>>>>>>>>>>>>>> jornfra...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is actually a server using configuration of the command -
>>>>>>>>>>>>>>> driven multi-process model (but the agents executed as a
>>>>>>>>>>>>>>> service and the
>>>>>>>>>>>>>>> war on a tomcat executed as a service) under Linux.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I thought as well that it cannot reach the webservices, the
>>>>>>>>>>>>>>> question is why. On the same server I can reach the webservices
>>>>>>>>>>>>>>> and fetch
>>>>>>>>>>>>>>> the WSDL without issues.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe sth related to ssl ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 10.01.2020 um 14:59 schrieb Karl Wright <
>>>>>>>>>>>>>>> daddy...@gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How are you running manifoldcf? Single process example, or
>>>>>>>>>>>>>>> a custom setup of some kind?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This exception is a "catch all" exception generated far
>>>>>>>>>>>>>>> below anything in ManifoldCF, but usually means it cannot
>>>>>>>>>>>>>>> download the
>>>>>>>>>>>>>>> WSDLs from the service. Getting the full exception dumped in
>>>>>>>>>>>>>>> the log
>>>>>>>>>>>>>>> requires a "hack" to the check() method of the connector, but
>>>>>>>>>>>>>>> I'm pretty
>>>>>>>>>>>>>>> sure that's what's happening anyway.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Karl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jan 10, 2020 at 8:50 AM Jörn Franke <
>>>>>>>>>>>>>>> jornfra...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tried to use the CSWS connector, but already for the
>>>>>>>>>>>>>>> Authority connection I receive a
>>>>>>>>>>>>>>> org.apache.cxf.service.factory.ServiceConstructionException:
>>>>>>>>>>>>>>> Failed to
>>>>>>>>>>>>>>> create service.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Unfortunately I don’t see more details , also not in the log
>>>>>>>>>>>>>>> (debug is activated). I try to get a little bit more output by
>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>> the connector, but maybe someone has already an idea why this
>>>>>>>>>>>>>>> can happen?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are there some special instructions to use it? The pointers
>>>>>>>>>>>>>>> to the webservices are correct, I tested via Curl and SOAPUI.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
