Which versions of Sage 300 support TLS 1.2 (i.e. for Avalara plugin)

We have Sage 300 2020 update 2 and our Avalara plugin won't connect to the sandbox envionmnet (but it does connect to production). It appears to be because the Avalara Sandbox requires TLS 1.2 (but production doesn't until the end of this month).  

My question is whether Sage 300 2020 update 2 "supports TLS 1.2" for outgoing connections from plugins that presumably use their SDK.  And if not, what version do we need?  

We have the latest Avalara developed integration installed, on Windows Server 2016, and have verified that TLS 1.2 works from other applications.

  • You need to update Sage to PU7.

  • I believe Avalara are working on making the Sage 300 plugin TLS 1.2 compatible.  

  • in reply to Team Equation

    That makes sense because I would have through that it would be totally up to Avalara to support TLS 1.2 within the plugin that they write, and not dependent on which version of Sage it is used with.   But I don't know if perhaps the plugin has to go through some Sage SDK code in order to make an outgoing connection to the AvaTax service API.  

    However, if Avalara has already depreciated incoming REST API calls using TLS 1.0 and TLS 1.1 (in sandbox now and production at the end of the month), then how could it be possible their own Sage 300 plugin doesn't support it yet?  And when we pointed out the issue to their representative, he pointed to their blog post stating we had to talk to Sage to find out if it "supports TLS 1.2".

  • in reply to Jay Converse Acumen

    Our Sage reseller is saying "TLS 1.2 and 1.3" will be supported in an upcoming April update for supported versions.  That seems to imply it isn't supported in the current latest patch of any version, but that contradicts what Sage posted that said "Sage 300 currently supports TLS 1.2".   

    I think there may be some confusion about what kind of support we're talking about.  They might be talking about their own connection to Office 365 from wiithin thier code (MS also requires TLS 1.2 now for that).   Whereas I'm trying to find out if Sage's SDK somehow limits plugins from using TLS 1.2 to communicate with 3rd party services like AvaTax.

  • We were in a similar situation with Sage 300 2020 Build 0 and AvaTax on Windows Server 2012 R2 but think we solved it (no thanks to a lack of direction on Avalara's part). When performing the test with the AvaTax connector in Sage we would get a bad username or password error.

    Here's what we did:

    Followed this document to disable older TLS versions and enable 1.2 in the registry: docs.microsoft.com/.../tls. You could also use www.nartac.com/.../ but I felt more comfortable doing it manually. Changes require a reboot. Our AvaTax connector test now gave us an error that it could not find the companies. At this point we knew we were on the right track as the changes we made to force TLS 1.2 actually did something even if it was break things. Had to set system to use older TLS version so it would work again for users (apparently it uses TLS 1.0) while we research.

    Thought we needed to upgrade the connector so we upgraded the AvaTax connector from version 9.00.002.02 to version 9.00.003.00 (the newest). Changing the Avalara credentials to test using the sandbox still gave us bad username or password error. Forcing to use TLS 1.2 still gave us the "can't find companies" error.

    Thought the "can't find companies" error in the AvaTax connector was because it was trying to access our SQL server which is on another box. Went through a completely separate ordeal of enabling TLS 1.2 on the SQL server. Sage connection from the Sage application server still worked but now Windows desktop clients could not connect to the Sage database. Found workstations were using "Microsoft SQL Server 2012 Native Client" version 11.2.5058.0 which does not support TLS 1.2. This is the version of the client included in the Sage workstation install prerequisites folder. Was able to find the version of the client that does work with TLS 1.2, version 11.4.7001.0 and installed it on workstations and now they could work in Sage again (www.microsoft.com/.../details.aspx sqlncli.msi). The AvaTax connector still gave the "can't find companies" error when TLS 1.0 was disabled in the registry.

    Turns out the AvaTax connector uses .NET (who knew? thanks for letting us know Avalara). Made registry changes on our Sage application server found here under the "Configure for strong cryptogprahy" section: docs.microsoft.com/.../enable-tls-1-2-client. Once making those changes and rebooting the AvaTax connector did not give the "can't find companies" error when the system was forced to use TLS 1.2 only. So, we are on track now right? Test still fails with the bad username or password error.

    Next we contact Sage support. This URL says our version works with TLS 1.2: support.na.sage.com/.../viewdocument.do. At this point we're wondering if the test credentials that Avalara gave us are bad. We contact Avalara support and they have us test the sandbox credentials at this URL: developer.avalara.com/.../ The username and password work but they show a different account number than the one for our sandbox account. Support creates a new sandbox account for us and we use it to generate a new license key. The email received when generating a new license key also includes the "Web service URL" which is not something we had with the previous sandbox credentials. Entering the new test credentials, new account ID, new license with the sandbox "Web service URL", clicking "Test Connection" and it works! I'm all for better security but a little more instruction from the SOFTWARE VENDOR that is requiring this change would have been nice.

    TLDR: Check schannel registry settings, check "Configure for strong cryptography" registry settings for .Net apps, update your AvaTax connector and verify the sandbox credentials. It works with our Sage 2020 Build 0.