So… (long pause)…

NetSuite has been telling us this for some time that they are forcing TLS 1.2 compliance. The question then becomes what does that mean to me? And probably an even bigger question is what changes do I need to make on my end to keep my stuff running?

Here’s an overview of where TLS is used in our NetSuite implementation.

What changes did we make?

First, my SuiteTalk app (at my location) had to be told to use the TLS 1.2 protocol. If your app uses the Microsoft .NET Framework 4.6 or higher, you don’t need to do anything. My app used 4.5.2, so I needed to add this statement somewhere ahead of opening the connection to NetSuite.

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Second, the site that hosts my APIs (at my location) had to be TLS 1.2 compliant. Apparently, when NetSuite said they were forcing TLS 1.2, that meant in both directions. To test your website, use the following URL:

https://www.ssllabs.com/ssltest/analyze.html?d=%5BYour domain here]

Here are some notes about how we got our website TLS 1.2 compliant.

First, we installed all the latest Microsoft security patches on our server which hosts our APIs. Then we tested, using a URL other than the SSL Labs one shown above, and we passed!

However, on the day of reconning, when NetSuite turned on TLS 1.2 our APIs were not reachable. They were getting an SSS_INVALID_HOST_CERT error. Confusing! The problem had nothing to do with our cert (which we purchased from GoDaddy).

To diagnose the problem, our NetSuite support rep ran the SSL Labs checker shown above and our site got an F! So we made the following registry changes to our server and rebooted.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
“DisabledByDefault”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
“DisabledByDefault”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
“ServerMinKeyBitLength”=dword:00000800

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
“Enabled”=dword:00000000

That did the trick. Our APIs site went from an F to an A in the SSL Labs checker, and all of our user event scripts in NetSuite began working again!