Automatic License Activation Not Working

KB#1758: Last Updated September 15, 2020


To jump straight to the simple workaround, click here: Simple Workaround

Recently we’ve had an increase in support tickets related to automatic license key activation failing across all our products. This post provides a solution to the issue and some background on the problem.


On September 28, 2019, we migrated the website from self-managed servers (hosted by HiVelocity) and onto WordPress (hosted by Pressable). This also meant that the vast amount of services rooted on had to be redirected to a different domain than because, as a result of moving to WordPress) the site was also transitioned from a dynamic ASP.NET site to static HTML. One of these former services was, naturally, product license activation.

Normally, simple HTTP redirection isn’t a problem. However (and obviously, considering the existence of this post), the scenario was a bit more complex.

First, it meant that TLS v1.2+ was now required to connect, which is not support by default in the framework the products were built with. This caused many “connection dropped” errors in the Diagnostic Center.

Second, Pressable’s integrated SSL support is limited to “Let’s Encrypt” certificates, so we could not upload the wildcard * certificate that we were using previously. This caused a different problem: some organizations don’t trust the “Let’s Encrypt” certificate authority.


We solved this by using Pressable support with Cloudflare as a façade; using their SSL certificate resolves the trust issues. Cloudflare also handles HTTP to HTTPS redirection, which means that requests from HTTP to HTTPS occur before they reach Pressable, which supports the necessary redirection defined to handle the change in the activation URL. Unfortunately, the Cloudflare redirect is specified as an HTTP 301 Permanent Redirect, as opposed to a 308, so the original HTTP request method is lost. Since the method is a POST for the activation endpoint, the following request becomes a GET, and the activation data is lost, which results in a response failure.

At the moment there seems to be no known method to override this behavior, i.e., ignoring SSL for very specific URLs or forcing a 308 redirect.


To resolve this issue, set the System.IntegrationUrl (BuildMaster) or .IntegrationUrl (ProGet and Otter) Advanced Setting to the following value based on the product:

  • ProGet – – (not required in v5.2.14+)
  • BuildMaster – – (not required in v6.1.17+)
  • Otter – – (not required in v2.2.8+)

Once the website or application pool is restarted, automatic activation should work again. In the upcoming maintenance releases for each product, we will update the integration URLs to be specific to individual services (instead of being built via relative URLs in the software itself) and to use HTTPS by default, avoiding the need for this workaround.