This is a public Forum  publicRSS


    Ruhul Amin
    TLS 1.0 Deprecation for Soap API Calls
    Topic posted October 5, 2016 by Ruhul AminExplorer 
    727 Views, 27 Comments
    TLS 1.0 Deprecation for Soap API Calls

    Hi Everyone,
                       According to the Oracle recommendation, we canned our production environment with TLS 1.0 Log Scanner found that it use TLS 1.0 for Soap API Calls.

    I was looking for the solution how to change the TLS version in Soap API call.

    I have searched a lot for that  but unfortunately could not find any solution for that.

    Any idea or Tutorial will be appreciated.



    TLS 1.0, Soap API call, Log Scanner


    • Chris van Es

      The same problem. Looking forward for a idea or tutorial.

    • Scott Harwell

      It depends on the source of the SOAP call; where are you calling the SOAP UI from?

      Add-ins, in most cases, should pick the most secure version of TLS to establish a connection with the host server.  However, you can programmatically "force" those to use a specific version (bad idea, but you can) which might be something done on your site.  If you're not setting the TLS version in your code, then it's highly likely that you don't need to do anything here.

      If you're using scripting languages to hit the SOAP API via cURL, then you may have to set the TLS version in your cURL call.  Again, if you're not doing that today, then the most secure version should be selected for you by curl.  

      For a tool like SOAP UI, you may need to force TLS 1.2 by entering the following entries in your vmoptions.txt file.

    • Cole Spolaric

      What about those of us that are accessing through a .net program (C#) using the wsdl?

    • Scott Harwell

      Same deal with external apps.  If your client binding auto negotiates TLS, then it should use the newest (available) version by default.  That's not guaranteed, but likely unless you have programmed your app to use a specific version of TLS.  You could use a tool like wireshark or fiddler to capture the communication between your app and the server and review the ServerHello message which will identify the version being negotiated with the server.

    • Mohana Gopal Selvam

      Hi Scott ,

      What about those of us that are accessing through  java (JDK 7) using the wsdl?

      Thanks in advance,


    • Scott Harwell

      The same principals apply to any connection to the APIs, regardless of language used to write your integration.  Unless you are specifying the version of TLS to use in your code, then it's highly likely that you won't have to do anything; the communications libraries will pick the most secure version of TLS available on the server.  However, this is not guaranteed whatsoever, so you still need to confirm that your application is connecting to OSvC with TLS 1.1 or higher.  Wireshark or Fidler can help (among other tools, and non of these are Oracle supported -- they are widely used for similar requirements as network security changes) determine what version of TLS is used during the server handshake.  There are other approaches as well for discovery of the TLS version used, and those approaches will vary depending on your source of integration, where it is deployed (server side, client side), and other factors.

      In Rahul's case, originating the question, he sees logs that use TLS 1.0, so his application is either specifying the TLS version, or the libraries that he has used to bind his app(s) to the OSvC API are using 1.0 instead of the newer version (they default to the lowest version or don't support newer versions).  Depending on the circumstance, he may need to rewrite his code not to specify TLS 1.0 and allow auto-negotiation, he may actually need to specify it (though this is likely a rare case) if the library(ies) are defaulting to the oldest version, may need to update the libraries used to versions that support newer versions of TLS, or may need to find a new approach for the integration.  But, without an idea of the source of his SOAP calls, the possibilities of what integration is causing the issue and how to fix it are too numerous to list in a thread like this.

    • Cole Spolaric

      In my case, I don't see anywhere that the TLS version is being specified, the SOAP API is version 1.2, and my code is using .net 4.0.  Yet the scan came back showing that SOAP calls are being made using TLS 1.0.  Do I simply need to upgrade to v1.3?

    • Scott Harwell

      No, the API version is completely unrelated to the TLS version used in communication between the client and the server.  The version of .NET that you are using might impact the request though.  Take a look at this article...

    • Cole Spolaric

      Thank you Scott.  Sounds like I will have to work on upgrading the .net version being used.

    • Karuna Gudipati

      Have the same issue, we will try to get more details from TAM and update if we find anything.

    • Jobins Kuriakose

      Hi Scott,

      I have same issue. Oracle mentioned that our SOAP API call (Java client) is hitting with TLS1.0. Below are the jars in  my project.  Do I need to upgrade these all jars or there is a way to specify the TLS version in the Java code itself?

      This is the code snippet to create the client.

         ServiceClient serviceClient = ((org.apache.axis2.client.Stub) _service)



    • Jobins Kuriakose

      When I turned on the debugger, I am seeing this in the log. Please note that My Java version is 1.7. On 1.8 I don't have this issue. But unfortunately I can't upgrade the Java on the server.

      2016-10-12 13:23:28 DEBUG HttpClient.<clinit>()    SunJSSE 1.7: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)

    • Mohana Gopal Selvam

      Java guys needs to upgrade from Java 1.7 to Java 1.8 and needs to disable SSLv3,TLSv1 in \Java\jre1.8.0_51\lib\security\ . Search for jdk.tls.disabledAlgorithms  in and replace the entire line(keep a backup FYR) with

      jdk.tls.disabledAlgorithms=SSLv2Hello, SSLv3, TLSv1, DH keySize < 768

      But i have a query, my Oracle right now addin code is contacting an java webservice which is http webservice not https should i need to change it to https ? Or hosting in server which supports java8 will be fine without changing it to https? Could you pls help?

    • Scott Harwell

      @mohana you would not need to change your add-in if the other web service is using http.  That web service is independent of OSvC, so the TLS change on the OSvC end does not affect it.  However, unless your web services is all behind a local firewall, this is bad practice as your add-in's communication to that web service is completely exposed.  You should switch to HTTPS for best practice.

    • Ruhul Amin


      Thanks guys for your comments and opinions.
      In my case, .Net as well as Java are used to develop two different client application.
      As per the above discussion and google search, I am concluding my understanding:

      1. DotNet App: Need to upgrade the .net framework version >= 4.6.2 and recompile the source code with the new .net framework version. Additionally, need to check the source code whether the TLS version specifically mentioned in anywhere.

      2. For Java: In the server where my Java application hosted is using java 6. in my source code, TLS version is not hard coded explicitly.
      Due to the other applications(on premise ) dependency, we can't upgrade the java version.

      According to Mohana, I have to upgrade the Java version.
      But from Scott's first answer, it is not clear.

      Current Java version running running server  is 6. So is there any way to overcome TLS problem keeping the java version 1.6?