Reply
Posts: 321
Topics: 5
Kudos: 36
Blog Posts: 5
Ideas: 0
Solutions: 26
Registered: ‎11-09-2011

Re: Request for Comments: API Best Practices - test url?

[ Edited ]

@skyetech That isn't surprising. Windows uses Secure Channel (AKA SChannel) for negotiating SSL/TLS with browsers and other services not going directly through IIS. The versions of SChannel used in Server 2003/XP cap at TLS 1.0, with older and weaker ciphers.

 

Chrome uses its own TLS negotiation setup, with its own cipher suites and certificate store. It also auto-updates, making it more resiliant to the sorts of issues legacy IE users face.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Member
Posts: 3
Registered: ‎05-28-2015

Re: Request for Comments: API Best Practices - test url?

So is sandbox currently RC4 disabled?  Just making sure it was not delayed again.

Posts: 2,527
Topics: 56
Kudos: 200
Blog Posts: 67
Registered: ‎12-05-2011

Re: Request for Comments: API Best Practices - test url?

@dlewis9

 

Yes, RC4 is disabled in the sandbox.

 

Richard


Build modern websites and mobile applications without increasing PCI burden using Authorize.Net Accept


DPM will be disabled in the sandbox on 7/1/2018. EOL 7/1/2019.
Member
Posts: 1
Registered: ‎05-12-2016

Re: Request for Comments: API Best Practices - test url?

Can you confirm that RC4 is even disabled in the sandbox for users of AIM, using this endpoint URL(?):

https://test.authorize.net/gateway/transact.dll

 

Many thanks.

Posts: 2,527
Topics: 56
Kudos: 200
Blog Posts: 67
Registered: ‎12-05-2011

Re: Request for Comments: API Best Practices - test url?

[ Edited ]

@gcgala2

 

All of our sandbox endpoints no longer support RC4.  You can confirm this using Qualys SSL Labs tool:

 

https://www.ssllabs.com/ssltest/analyze.html?d=test.authorize.net

 

Richard


Build modern websites and mobile applications without increasing PCI burden using Authorize.Net Accept


DPM will be disabled in the sandbox on 7/1/2018. EOL 7/1/2019.
Member
Posts: 1
Registered: ‎04-27-2017

Re: Request for Comments: API Best Practices

If our application server (Glassfish 4.0) is running on JDK 8, and we're using the Authorize.NET Java SDK, can we assume that TLS 1.2 is being used? I can't seem to find any object in the Authorize.NET library that explicitly sets the outbound TLS protocol version. Our application server is configured to use TLS 1.2 for inbound requests. Is that enough?

Highlighted
Member
Posts: 1
Registered: ‎05-25-2017

Re: Request for Comments: API Best Practices

We are using .net framework 4.0 in our project. How to do a workaround for this then ?

I suppose there are 2 ways:

1) Using existing project with .net framework(4.0). Installing .net framework 4.5 in my machine. Changing the code as ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

2) Upgrading project to .net framework 4.5.

 

Can we use the 1st option for time being ?

Kindly suggest.