Re: CSWS Connector : ServiceConstructionException: Failed to create service
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 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 : > > > 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 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 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 : >>> >>> >>> 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 : >>> >>> >>> Let me think about that option. >>> >>> Karl >>> >>> >>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke >>> 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 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
Re: CSWS Connector : ServiceConstructionException: Failed to create service
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 :
>
>
> 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 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 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 :
>
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 :
>>
>
> Let me think about that option.
>
> Karl
>
>
>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke 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 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
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
Re: CSWS Connector : ServiceConstructionException: Failed to create service
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 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 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 :
>>
>>
>> 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 :
>>
>>
>> Let me think about that option.
>>
>> Karl
>>
>>
>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke 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 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
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 :
>
>
> 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
>
Re: CSWS Connector : ServiceConstructionException: Failed to create service
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 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 :
>
>
> 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 :
>
>
> Let me think about that option.
>
> Karl
>
>
> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke 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 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
>>> 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 :
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 wrote:
> Yes I am doing that but I will need to
Re: CSWS Connector : ServiceConstructionException: Failed to create service
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 :
>
>
> 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 :
>>>
>>
>> Let me think about that option.
>>
>> Karl
>>
>>
>>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke 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 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 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 :
>>>
>>
>> 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 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
Re: CSWS Connector : ServiceConstructionException: Failed to create service
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 :
>
>
> Let me think about that option.
>
> Karl
>
>
>> On Wed, Jan 15, 2020 at 5:38 PM Jörn Franke 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 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 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 :
>>
>
> 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 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
