We're using a VB6 application on Windows 7+ machines (we can't upgrade it just yet). We call several web services in the application like so:
Set objClient = CreateObject("MSSOAP.SoapClient30")
objClient.MSSoapInit gszEmailWebServiceURL
objClient.ConnectorProperty("Timeout") = 30000
strXMLResponse = objClient.GetEmails()
Soon, all of the web services we call are changing to only allow TLS 1.2 connections.
Is there any way to set the object to use TLS 1.2?
I know that in .NET, you can do this:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
Is there something similar for VB6?
Also, I know that you can force the entire system to use TLS 1.2 by default, as specified here: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in. I tested this on one of our VMs and it indeed works, but we'd have to do this on every one of our client workstations (100+) that use this application, and so I'm hoping there is a way to do it from within the app itself, as we already have auto-update functionality for the app.
Thanks in advance.
Related
With KB5018410 Windows update installed in Windows 10 recently, my Delphi REST applications have stopped working. It seems that TLS 1.2 is turned off. Insomnia, Firefox etc can access the URL below, but not a "default" set of TRESTClint/TRESTRequest/TRESTResponse components dropped on a form with the minimal required Properties modifications.
https://yams.ked.co.za/version
Checking boxes under TRESTClient.SecureProtocols also does not seem to make any difference.
How can I get my (very large) REST application going again!?
Check this conversation out on Reddit - Global Protect TLS issue after install of KB5018410
https://www.reddit.com/r/paloaltonetworks/comments/y21chi/some_of_our_users_are_having_issues_connecting_to/
Check your ssl cert and make sure your cert is not valid for more than 1 year 365 days. If it is issued to be longer than a year try switching your cert to one that is only good for 1 year and see if it solves it. That fixed my Palo Alto global protect vpn issue.
My final solution was to use another, 3rd party component (Chilkat) to carry out the REST functionality.
There is also the option of rolling back (and then blocking repeat upgrading) the Windows 10 KB5018410 upgrade.
The problem with the Embarcadero REST components was reported on the Issues site, and has now been elevated from "Reported" to "Open" status.
I am looking to use Cypress for end to end testing for some kubernetes applications. Typically, I access these applications via OIDC through kong, however cypress doesn't support this, but does support key-auth via an API key. Is there a way of setting up the service so that I can use both of these simultaneously?
I think you cannot use more than one authentication plugin in an XOR scenario. This would only work for AND as long as the plugins do not use the same headers.
I also faced this problem and I solved it by setting up one service (pointing to the backend) and multiple routes (one for normal traffic, one for test traffic). You then can activate different plugins on each route instead of sticking it to the service.
The only downside is the slightly different base path you use for testing, but I think this is less problematic than the downside of testing with a different way of authentication.
I tried opening a ticket with Docusign Support, but they sent me this way instead. I'm hoping someone will be able to assist with this.
Starting on Nov. 16th at about 12:30 Central, we started getting errors in our application logs in our non-production environment. Upon investigation, it appears that https://demo.docusign.net/restapi started responding to TLSv1 queries with the following:
{
"errorCode": "TLS_INVALID_VERSION",
"message": "TLS Version is invalid, please update to TLS1.2 TLSv1.2 is
required. Currently using TLSv1"
}
This came as a surprise to us considering that Docusign was supposed to disable TLSv1 in their non-production environment many months ago. Back then, we tested our application against the above URL (after the supposed switchover) and everything was working with our application, so we assumed that production would continue to work when that was supposed to switch over. And it did.
The issue is that it turns out that Docusign seems to have not disabled TLSv1 when they said they were supposed to, which invalidated any testing we did previously. And now, we're at risk of our production environment failing at some unknown point in the future.
So, does anyone know when Docusign will be switching over the production environment so that TLSv1 is disabled? We're investigating the option to update the libraries in the app so they support at least TLS 1.1, but that may take some time and this is a critical issue for us.
Hugh
p.s. On a side note, the site says that TLS v1.2 is required, but it still responds to TLS v1.1.
Note the publicly announced date for TLS 1.0 deprecation is 6/25/2018. However we had a grace period. Now the hard block dates are coming up. The hard block date in PROD is set at 1/31/2019. In Demo its 11/16, as you noticed.
Add this line before calling REST API
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
It will works fine.
I work for DocuSign.
As of this writing, DocuSign has no current plans to stop supporting TLS 1.1. We already support TLS 1.2 and encourage you to upgrade to it rather than TLS 1.1. But TLS 1.1 is fine if that is all your stack currently supports.
I am not a developer so please keep that in mind when reading the following message:
I need to be able to use Windows PowerShell to connect to a JMX RMI agent on a host, is this even possible ?
The example string from the java client I have been given is as below:
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:7979/jmxrmi");
The reason for this is that I am doing other work in my PowerShell script and would like to keep it all in one place.
Thanks !
This is an unusual mix of two technologies, but it is possible.
On the off-chance that you are attempting to connect to a JBoss server, the quickest way may be for you to call twiddle, a command tool that will dispatch JMX requests to the target JBoss server and return the results to standard out.
Another way is to implement the Jolokia agent on the target servers. This will allow you to issue JMX requests using REST. Responses will also be returned in REST format which you can process in PowerShell using one of these solutions.
Thirdly, you can also deploy the JMX-WS service on your target servers which will allow you to communicate with the JMX server using web-services. This document provides some VBScript examples of this.
None of the above actually uses the JMXServiceURL syntax you outlined, and I cannot think of a way you could actually cleanly integrate this RMI based protocol into PowerShell, but hopefully one of the above will work for you.
========== UPDATE ==========
There may be a way to use the RMI implementation. Take a look at IKVM. It is a Java Byte Code to .NET compiler. I have successfully compiled JMX/RMI java code into a .Net assembly and used it from C#. I think PowerShell will do the same thing.
I'm deploying an ASP.NET MVC 2 application using Apache / mod_mono / MONO (2.8.1) that uses the built in ASP.NET authentication framework.
When I restart Apache, or use the mod_mono control panel to restart the mono server process, users are logged out. I don't want this occurring.
I'm using custom Profile / Membership / Role providers (that are backed by a Redis database), and these currently have a bare minimum implementation. I can not see where my problem fits in here however, but am I missing something obvious?
I notice that the .MONOAUTH cookie changes value when a user logs back in, so I guess there is some persistence that needs to happen that is not happening.
Any solutions or pointers to the relevant documentation would be great!
NOTE: I'm not sure if the information below differs when you're using a Membership Provider -- it may be that session state is persisted by the Membership Provider itself.
It's likely that you're using "in-process" session state storage. This means that whenever you restart the web server process, you're clearing out all the session information stored in the web server process's memory space.
To avoid wiping out session information, you can move to using an out-of-process session state server, either running as an in-memory service (see below for the Mono version) or on SQL Server. Otherwise there are also a number of unofficial custom session store providers that use alternative storage mechanisms (e.g. MongoDB etc.)
I found what you may want, which is this Mono ASP.NET Session State Server: http://manpages.ubuntu.com/manpages/gutsy/man1/asp-state2.1.html
As a first step, take a look in your web.config at the system.web -> sessionState property. If it's set to mode="InProc" then there's your problem. It should look more like:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=server:port"
stateNetworkTimeout="number of seconds"/>
Solution: set the validationKey and decryptionKey manually:
<machineKey validationKey="blahblah" decryptionKey="blahblah" />
I think this is probably a bug in mono that these take on different values over server resets when auto-generated (which is the default).