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