Reply
Highlighted
Member
Posts: 1
Registered: ‎03-01-2018

Re: TLS 1.2 Issue - in Classic ASP environment

Thank you for this! It was just what I needed to get everything up and running again after being down for over 24 hours.

 

Nice to know I'm not the only one running old code. I'm running Classic ASP that was originally written back in 2002 and I've never gotten around to porting it to something new.  I was running SQL Server Express 2008 on Windows Server 2008 R2 but after spending all day yesterday trying to get it to work with TLS 1.2, I ended up upgrading to SQL Server Express 2012. Actually, that upgrade was the easiest part of this whole process.

 

If any of you are still struggling with this feel free to hit me up. It's hard for me to recall everything I did in the past 24+ hours, but I can try to shed light on what worked for me. At least you know it can be done, which is something I doubted many times yesterday while working on this issue.

Highlighted
Contributor
Posts: 26
Registered: ‎02-28-2018

Re: TLS 1.2 Issue - in Classic ASP environment

This is from Microsoft:

 

Windows Server 2008 R2 ships with a 64-bit SKU only; no 32-bit SKU is available for the server version of the operating system. However, a 32-bit SKU continues to be available for the Windows 7 client.

 

https://msdn.microsoft.com/en-us/library/windows/desktop/dd371688(v=vs.85).aspx

Highlighted
Contributor
Posts: 11
Registered: ‎02-28-2018

Re: TLS 1.2 Issue - in Classic ASP environment

So bdf2723, from your most recent two posts, are you saying that I should have added that second key in the registry, even though I didn't find any of the sub-keys in it?  I used the "Easy Fix" tool from this MS article:  https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-s... which added the first key, but with an a00 value, which I then went in and edited to 800.

 

I'm not too experienced editing the Registry (okay, never until today), so I'm a bit hesitant to do it when I'm not sure what I'm doing.

Highlighted
Contributor
Posts: 26
Registered: ‎02-28-2018

Re: TLS 1.2 Issue - in Classic ASP environment

I just checked a couple of different 2008r2 servers that I have and they all have the Wow6432Node key.  It should be the last key under SOFTWARE. 

 

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\

Highlighted
Contributor
Posts: 11
Registered: ‎02-28-2018

Re: TLS 1.2 Issue - in Classic ASP environment

EIther I looked in the wrong place this afternoon, or the "Easy Fix" that I had downloaded went in and added the Wow6432Node key and the proper sub-keys, because after reading your earlier post and posting my response, I decided to go in and try to add in the key, and as you said most recently, this time I found it.  It was in there, set to a00 (which is why I think the Easy Fix probably added it).  So I changed it to 0800 and was pretty sure that would not make any difference, but it did.  I am now fixed.

 

Thank you everyone, especially you bdf2723, for your help.  I can't tell you how relieved I am. 

 

Tom

Highlighted
Contributor
Posts: 26
Registered: ‎02-28-2018

Re: TLS 1.2 Issue - in Classic ASP environment

Glad you got it.

 

I truely understand the pucker factor when your shopping cart is broke.

Highlighted
Member
Posts: 1
Registered: ‎03-02-2018

Re: TLS 1.2 Issue - in Classic ASP environment

I need some help too.

First of all, we form up a url, similar to this:


url_body =

x_login=validAPIKey&x_tran_key=validTranKey&x_version=3.1&x_type=AUTH_CAPTURE&x_card_num=4800430002324724&x_last_name=Joe Smith&x_type=AUTH_CAPTURE&x_exp_date=0622&x_card_code=211&x_delim_data=TRUE&x_delim_char=,&x_relay_response=FALSE&x_amount=1

We send the URL to https://secure.authorize.net/gateway/transact.dll? like this:

post_results = http_post(the_url,url_body)

 

Basically doing an http post.  This stopped working on 2/28/18.

 

However, we can post the url to sandbox: https://test.authorize.net/gateway/transact.dll?   and it works fine.

 

The error we're getting trying to go to the live url is this one:

Could not connect to server: Secure Sockets Layer OpenSSL Error¶OpenSSL Description: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure¶Error occurred in INET::SSLSocket::Connect

 

howsmyssl.com reports that we are "good"

I've applied the "easy fix" mentioned here: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-s...

 

and have confirmed that the registry entries are present and set to 800.

 

Baffled as to why this is not working and what to do next.  Any help would be appreciated.

Highlighted
Contributor
Posts: 26
Registered: ‎02-28-2018

Re: TLS 1.2 Issue - in Classic ASP environment

Test your SSL Certificate here:

https://www.ssllabs.com/ssltest/

 

And your browser here:

https://www.ssllabs.com/ssltest/viewMyClient.html

Highlighted
Member
Posts: 1
Registered: ‎03-02-2018

Re: TLS 1.2 Issue - in Classic ASP environment

cynshop - What fixed your issue? Down day 3 now, with 2 server techs, 2 IT's and 2 web developers trying to crack our issue! HELP!

Highlighted
Member
Posts: 1
Registered: ‎03-01-2018

Re: TLS 1.2 Issue - in Classic ASP environment

[ Edited ]

I am using Classic ASP on a Windows Server 2008 R2 Standard 64-bit with SQL Server 2012

 

I use the following code to post a transaction to Authorize.net (which quit working after 14 years on Feb 28!)

 

set oHttp = Server.CreateObject("MSXML2.ServerXMLHTTP.6.0")

oHttp.Open "POST", "https://secure2.authorize.net/gateway/transact.dll?" & sPostData, false

oHttp.Send ""

sPaymentStatus=oHttp.Status

sPaymentRetval = oHttp.ResponseText

 

It is now working finally. 

 

I don’t know if “secure2” (in https://secure2.authorize.net/gateway/transact.dll... it used to just be secure) makes a difference.  It was something an authorize.net rep suggested early in the process but it didn’t solve anything at the time.  I haven’t tried without it.

 

I also installed .NET 4.6.1 but I don’t know if that was part of the solution.

 

The following pages on my site show my current security settings after all the changes:

 

https://www.ssllabs.com/ssltest/analyze.html?d=www.real-estate-agent-lists.com

 

http://www.real-estate-agent-lists.com/testssl.asp

 

As best as I can recall with assistance from my host technical support these were the steps:

 

  1. Disable all security settings except TLS 1.2 in the Registry as described earlier in this thread.

There is a key for each protocol located here

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\

 

The process is described at https://tecadmin.net/enable-tls-on-windows-server-and-iis/

 

 2. This broke SQL Server connection for me because apparently SQL Server 2012 requires TLS 1.0 or SSL 3.0. This was going to be a big problem but I found a solution here:

https://blogs.sentryone.com/aaronbertrand/tls-1-2-support-read-first/

 

which has patches that gives SQL Server 2012 TLS 1.2 support.

 

This however required a change to my connection string in Classic ASP because SQLOLEDB has been deprecated and doesn’t support TLS 1.2!

 

To fix this problem required installation of SQL Net Client on the server (ODBC may work also) and the following code change to the connection string.  The key changes are “provider” is now SQLNCCLI11 and the end of the connection string is  “Trusted_Connection=No;DataTypeCompatibility=80”  No idea what that does but I saw it somewhere and it works!

 

sqlConn=”PROVIDER=SQLNCLI11;SERVER=server;DATABASE=dbname;UID=username;pwd=password;Trusted_Connection=No;DataTypeCompatibility=80"

 

 3. The TLS 1.2 registry change also broke my RDP connection from my Windows 7 (64-bit) computer at home.

 

I had to install

 

https://support.microsoft.com/en-us/help/3080079/update-to-add-rds-support-for-tls-1-1-and-tls-1-2-i...

 

which gave TLS 1.2 support to my RDP client I think.  It now works.

 

 4. Finally after all that, my authorize.net MSXML2.ServerXMLHTTP.6.0 post still didn’t work. The final change which was recommended earlier in this thread did the trick… Add a DWORD “DefaultSecureProtocols” value of 800 to the following Registry entries.  Actually I think you only have to do the first one for 32-bit and the second for 64-bit but I did both.

 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings