Did KEAP just disable TLS1.2 causing API Failures

On 9/20/23 (yesterday I started getting errors on all my API calls. We have 2 separate KEAP accounts with their own credentials and I use REST and XML-RPC in both one using the static app code that does not need updating and the other needing the daily refresh. All code worked for past 2 years with little issues.

I did not see any announcements from KEAP but was told by support: “Today we enforced some SSL policies the forced TLS 1.2+ and disable some insecure ciphers. This was actually a very similar SSL policy we had earlier this year. When we migrated our API Proxy earlier this year we accidentally allowed the older TLS and ciphers. The issue was identified during our PCI Audit earlier this week. Sorry for the inconvenience”

Nobody at KEAP has been able to advise what TLS1.2+ means. Does that include TLS1.2 or only TLS1.3. I was just told this was done for PCI compliance but PCI Compliance still accepts TLS1.2 and higher. I have been advised they are working on it but does not seem like there is any urgency.

We use ASP/net and windows servers and the only OS that supports TLS1.3 is Server 2022. We knew the migration to TLS1.3 is on the horizon and had scheduled a server upgrade in January 2024 ahead of any anticipated deprecation.

Hi @Roger_Nemeth, it looks like it was either a blip or your side, or it was related to the recent blip that’s been reported.

TLS 1.2 has been the minimum for the past 5+ years. No mention has been made about going to TLS 1.3.

The Keap-authored software application product offerings provide end-to-end encryption using the Transport Layer Security (TLS) protocol version 1.2 or higher with a minimum of 128 bit encryption for personal data in transit.


Systems are now back online

We experienced a service outage for most of our features at 6:21 PM PST on September 21, 2023, which caused multiple pages in Pro, Max, and Max Classic to be inaccessible.

Systems are now back online and functioning. Our team will be actively monitoring performance throughout the day as normal customer traffic increases to ensure no loss in performance.

What happened was during the migration of our API Proxy earlier this year we inadvertently loosened our TLS restrictions. This was found during our PCI audit last week. We applied a more restrictive policy on the load balancer that returned it to the previous restrictions with the addition of disabling a few additional ciphers that are considered to be weak according to modern standards.

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

We received a few reports that those ciphers were being used by a few developers, and their http clients didn’t support the more modern ciphers. We checked with our security people if we could re-enable these 4 ciphers and still be compliant. Once we got the go ahead we re-enabled these 4. It is highly likely we turn them off again once we give some additional time for the few clients that reported issues to update their http clients. The TLS version has been 1.2+ for some time like @Pav mentioned minus the last few months due to the accidental regression.