The Server I am connecting to requires TLS 1.1. My attempts fail. I am on a Windows Server 2008 R2 Standard SP1 64bit machine using Classic ASP.
Here is my code:
const WinHttpRequestOption_SecureProtocols = 9
const SecureProtocol_TLS1_1 = 512
dim objHTTP
set objHTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
No error:
objHTTP.Option(9) = 128
'No error:
objHTTP.Option(9) = &H80
'Errors right here:
objHTTP.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_1
'Errors right here:
objHTTP.Option(9) = 512
'Errors right here:
objHTTP.Option(9) = &H200
It does not matter where in the code I place this line, I still get this error as it tries to execute:
Microsoft VBScript runtime error '800a0005'
Invalid procedure call or argument: 'Option'
My Server's Browser was IE8, so I installed IE11 hoping for better results. Same error.
I have the Internet options of IE11 set to
(Unchecked) Use SSL 2.0
(Unchecked) Use SSL 3.0
(Unchecked) Use TLS 1.0
(Checked) Use TLS 1.1
(Checked) Use TLS 1.2
In the Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\
I have TLS 1.1 and 1.2 set at enabled=1 and DisabledByDefault=0
All the rest are set opposite.
I did the same at /ControlSet001/ and /ControlSet002/
Why can't I set objHTTP.Option(9) = 512?
Bonus question: Why is WinHttp insisting on TLS 1.0 regardless of my Server's settings?
This option means TLS 1.0:
objHTTP.Option(9) = 128
And winhttp.dll library on Windows 2008 R2 has reference only to this value.
That's why you don't have any error with it.
Next option means TLS 1.1:
objHTTP.Option(9) = 512
But only Windows 2012 and newer knows this value.
That's why you have errors on Windows 2008 R2
So you have to upgrade your Windows in order to use this setting.
Or there is another approach using registry fix exists.
Because Windows uses this value in case it is not specified in your code.
This approach works without changing any line of code.
In general:
Register protocol TLS 1.1 or even 1.2 is better (or both) in next section
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Tell winhttp.dll to use one of those protocols by default with value "DefaultSecureProtocols" in next sections
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
See more details in my answer here:
Classic ASP Outbound TLS 1.2
If you open the winhttp.dll in visual studio object browser, the version in Windows Server 2008 does not contain the constants for TLS1.1 and TLS1.2 under WinHttpRequestSecureProtocols enum.
If you do the same for Windows Server 2012, you'll find that the constants for TLS1.1 and TLS1.2 do appear.
I don't see an update available for Win 2008 to upgrade winhttp. If one exists I'd like to know. I haven't tried copying the Win 2012 version to Win 2008. I don't know if that would cause issues or not.
Related
Installed VS2019 on Windows 7.
Created ASP.NET web application from template.
Do nothing.
Run project "IIS Express + FireFox"
Get message about installing development certificate and running site under HTTPS
Accept certificate and IIS starts site on https://localhost:43315
Get error from browser Error code: SSL_ERROR_UNSUPPORTED_VERSION
Switching to Edge, I get NET::ERR_SSL_OBSOLETE_VERSION
Have tried :
https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-troubleshoot
https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client
https://support.microsoft.com/en-gb/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi
https://www.pluralsight.com/guides/visual-studio-2017-resolving-ssl-tls-connections-problems-with-iis-express
But have had no luck.
So as far as I can see:
I have a cert
The site is running on the right port range
Checking all the registry values (and many reboots) suggests TLS 1.2 is available.
so what's wrong ?
Thanks in advance all.
I am unable to connect to an HTTPS server (TLS 1.3) using WebRequest because of this error message:
The request was aborted: Could not create SSL/TLS secure channel.
The previous TLS version was 1.2 and with below code I could GET the page properly but as the page ssl upgraded to TLS 1.3 I got the error and also I cannot find any solution about it:
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
In fact, I think it should be something like below:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls13;
but there is not.
It looks like TLS13 is supported now as part of the 4.8 .Net Framework
https://learn.microsoft.com/en-us/dotnet/api/system.net.securityprotocoltype?view=netframework-4.8
However it is only supported on newer Window's OS versions (windows 11 and server 2022+), see here for full support details.
I have strange issue when i post to sage pay from my vb.net application
objHttpRequest = HttpWebRequest.Create(objUri)
objHttpRequest.KeepAlive = False
objHttpRequest.Method = "POST"
objHttpRequest.ProtocolVersion = HttpVersion.Version10
objHttpRequest.ContentType = "application/x-www-form-urlencoded"
arrRequest = objUTFEncode.GetBytes(postValues)
objHttpRequest.ContentLength = arrRequest.Length
objStreamReq = objHttpRequest.GetRequestStream()
objStreamReq.Write(arrRequest, 0, arrRequest.Length)
objStreamReq.Close()
objStreamReq = objHttpRequest.GetRequestStream()
At this line exception is thrown as "The underlying connection was closed: An unexpected error occurred on a send".
When i debug, the connection object is nothing. But i dont know whether it was there before.
It was successfully posted before and i didnt change anything.
I copied the inputs and posted to sage pay with POSTMAN and it succeeds.
Can somebody help me to find this please.
Are you using the test server? TLS 1.0 and 1.1 were disabled on it last month so any connections other than TLS 1.2 will fail in that way. The live servers still support 1.0/1.1 until March 31st 2018, so you will need to ensure the client supports TLS 1.2.
You can use TLS 1.2 on .NET 4.0 IF the OS has .NET 4.5+ installed and you manually set the protocol:
https://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/
I am calling a web page from a VB application to perform a validation, something like :
Set objXMLHTTP = CreateObject("MSXML2.ServerXMLHTTP")
...
objXMLHTTP.Open "GET", ls_address, False
objXMLHTTP.Send
The value of objXMLHTTP.Status is 0 in Windows7 and 200 in Windows10.
I have a lot of people that started to have this problem yesterday (2018-01-29) so I am thinking that a Windows 7 update might have caused this?
Also, my ls_address is https://... and I have the problem in Windows7, but when I change it to http://... it works again. Both work in Windows10.
Anybody has a clue where to look, Windows Defender, Microsoft Security Essentials, etc. ???
Try adding this line of code:
objXMLHTTP.setRequestHeader "Origin", ls_address
Also: is there any authentication needed?
The problem was not with a windows 7 update as I tought first, but rather a security update on the web server that caused trouble only with windows 7 clients.
As mentionned by Lankymart, it is related to SSL/TLS protocols or cyphers. I am not sure if I could code something different in VBA to make it work. I tried using Server.CreateObject ("MSXML2.XMLHTTP.6.0"), but it did not work in my vba environment.
As a temporary solution, the update on the web server was undone and everything went back to normal.
TLS version 1.2 update in Windows Server 2008 R2, 2012, and Windows 7
https://support.site24x7.com/portal/en/kb/articles/to-update-to-tls-version-1-2
We updated our SSL certificate to SHA2, but the intermediate certificate was SHA1. Chrome and other browsers have decided that the entire chain must be SHA2. Our customers were calling concerned about the yellow caution in the address bar. Rumor has it that in a few months Chrome and other browsers will replace the mildly unobtrusive caution with a stop screen. We certainly don't want that!
...
So we reissued the certificate and the new one is signed by the SHA2 intermediate. When we use that certificate to encrypt the traffic on our server, our applications that are using MSXML2.ServerXMLHTTP (running on Windows Server 2003) to access remote web services on that server can no longer connect.
After researching, we applied these two hotfixes that looked like they might could have addressed the issue:
https://support.microsoft.com/kb/938397/en-us
https://support.microsoft.com/kb/968730/en-us
But the problem persists. Switch the cert back to the SHA2 with SHA1 intermediate and we have no issues.
We have installed the intermediate SHA2 certificate in the trusted store but the problem persists.
We have tried specifying all versions of the MSXML2.ServerXMLHTTP and all fail.
ASP code :
function query(xml)
dim xmlhttp, xmlDoc, url
url = application("component_url")
set xmlhttp = server.createobject("MSXML2.ServerXMLHttp")
call xmlhttp.open ("POST", url, false)
call xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded")
on error resume next
err.clear
call xmlhttp.send(xml)
if err.number <> 0 then
call sendAlert("An error has occurred while trying to send your request", message)
else
dim rt
rt = ConvertUtf8BytesToString(xmlhttp.responseBody)
set xmlDoc = server.createobject("MSXML2.DomDocument")
xmlDoc.loadXml(rt)
end if
on error goto 0
set query = xmlDoc
set xmlHttp = nothing
set xmlDoc = nothing
end function
Your situation is very likely same as this post, specially the last answer as you mention the script has been running for 10+ years.
Quoting the last answer in full:
I know it is an old question. This issue could be because of
unsupported cipher suites. Try adding - TLS_RSA_WITH_AES_128_CBC_SHA
AES128-SHA - TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA
That means you have to follow this kb:
http://support.microsoft.com/kb/948963 This update is also interesting
if you are still using windows 2003. Which will allow connecting to
site using SHA2 - http://support.microsoft.com/kb/968730
Please note that Windows Server 2003 support is ending July 14, 2015
If the code is running on a Windows Server 2003, I suggest you try it on a newer machine, maybe a laptop with Windows 7 for a quick test.