Client activation ports and SOLO Server IP address

Quick reference: allow outbound access to your SOLO Server host name (secure.softwarekey.com for SOLO Server Shared URL) on TCP port 443. Prefer the DNS name over an IP address in firewall and proxy rules, because the IP address can change.

Which address should we allow?

When an IT department has to configure rules to allow connection to SOLO Server, it is recommended to use the DNS name if allowed, because the IP address can potentially change.

• SOLO Server Shared URL: secure.softwarekey.com
• SOLO Server Custom URL: [your brand].softwarekey.com
• SOLO Server Dedicated URL or SOLO Server Self Hosted: [your SOLO Server domain name] (for example: secure.mysoloserver.com)

Allowing the name in a firewall rule is not sufficient on its own if the workstation cannot resolve that name. A protected application reporting that the remote name could not be resolved has hit a DNS problem rather than a blocked port, and the fix is different. See Troubleshooting general licensing client connectivity.

What if we have to use an IP address?

If an IP address is needed, the IP address of SOLO Server depends on your SOLO Server Automation Package. You can ping your SOLO Server host name to retrieve it.

1. Click the Start button, type "cmd" (without the quotes) in the search bar, and press enter to open the Command Prompt.
2. Type the command that matches your package:

• Shared URL: ping secure.softwarekey.com
• Custom URL: ping [your brand].softwarekey.com
• Dedicated URL or Self-Hosted: ping [your SOLO Server domain name]

The IP address will be displayed in the command prompt window and will look similar to this output:

<code>Pinging secure.softwarekey.com [13.89.224.215] with 32 bytes of data:
Reply from 13.89.224.215: bytes=32 time=12ms TTL=242
Reply from 13.89.224.215: bytes=32 time=12ms TTL=242

In the above output, the current IP address is 13.89.224.215. Always confirm the real address from your own ping output rather than copying one from documentation in case it has changed.

Will the IP address ever change?

It is always recommended to use the DNS name rather than the IP address, but we recognize not everyone can use DNS for their proxy rules. If your customer must use an IP address, use the steps above to identify the address to provide them.

We know it is important to try and avoid IP address changes, but there may be certain circumstances that require it. In the unlikely event a circumstance requires us to fail-over to a geographically-distant disaster recovery site, this IP address will likely change.

We invite customers to visit our SoftwareKey System Status page, which has the ability to subscribe to receive updates on issues affecting the service.

Which ports does activation use?

Protected applications built with our licensing clients communicate with SOLO Server using the same underlying HTTP technology as a web browser, so activation uses standard web ports:

• Port 443 for HTTPS, encrypted in transit.
• Port 80 for HTTP, unencrypted.

Which of the two a given protected application uses is decided by the licensing client and how the software developer implemented it, not by SOLO Server. The shared SOLO Server does answer on port 80, and the web service endpoints are reachable over plain HTTP, which is what makes the client-side fallback described below possible. Browsing to the site root over HTTP redirects to HTTPS, but that redirect is not a protection: a redirect is only received after the request has already been sent, so anything in a request body has already crossed the network by that point.

If you are writing firewall or proxy rules and you know the application activates over HTTPS, allowing port 443 alone is sufficient.

Can activation traffic be restricted to HTTPS only?

With Protection PLUS 5 SDK, yes, and the two editions do it differently:

In neither edition is it the default. Configuring an https:// URL is not sufficient on its own, because both editions will retry over plain HTTP if the first attempt fails. Requiring HTTPS is an explicit setting the developer has to make:

• PLUSManaged requires setting the RequireSsl property to true on the web service call object, in addition to using an https:// URL. RequireSsl defaults to false. It is available on every licensing call, including ActivateInstallation, CheckInstallationStatus, DeactivateInstallation, InfoCheck, and ValidateRegistration. With RequireSsl left at its default, a failed HTTPS attempt is retried against the same address over http://.
• PLUSNative requires the SK_FLAGS_REQUIRE_SSL flag, set either on the API Context or on the individual call. With SK_FLAGS_USE_SSL alone, PLUSNative attempts SSL and falls back to plain HTTP if that attempt fails. SK_FLAGS_REQUIRE_SSL removes the fallback: if the secure connection fails, no HTTP attempt is made.

So Protection PLUS 5 SDK is the case where an application can be guaranteed to never send an activation request over HTTP, but only where the developer has explicitly required SSL. If you are answering a security review, confirm which setting the application actually uses rather than assuming it from the URL.

With our wizard-based clients, no. Instant Protection PLUS 3 and AutoCrypt SL are configured with a SOLO Server instance or host name rather than a full web service URL, and neither wizard exposes a protocol, port, or TLS setting. Those clients default to HTTPS, but if an HTTPS attempt fails they fall back to unencrypted HTTP, and there is no setting to prevent that fallback, not in the wizard, not in the generated configuration, and not on the API call. So an application built with a wizard client cannot be guaranteed to never send an activation request over HTTP.

Quick reference: Protection PLUS 5 SDK can be restricted to HTTPS only, but not by default; the developer must require SSL explicitly. Instant Protection PLUS 3 and AutoCrypt SL cannot be restricted at all.

If HTTPS-only communication is a hard requirement and you are currently using a wizard client, migrating to Protection PLUS 5 SDK is the supported path. Note that Protection PLUS 5 SDK is a separate licensing implementation, so a new license and a new activation are required; it is a development project rather than a configuration change.

If a security team needs written confirmation of how a specific application communicates, contact us with the licensing client and version you are using and we will confirm for your implementation.

If a request does fall back to HTTP, is license data exposed?

Usually not, because the core licensing calls carry their own encryption inside the message, independently of TLS.

Activation, the periodic license status check, and deactivation can each be encrypted and digitally signed at the application layer using per-product keys issued through your SOLO Server account. The sensitive contents of those requests and responses, including the License ID, password, and machine identifiers, sit inside the encrypted portion of the message, and both the client and the server verify the signature on what they receive. Where that protection is in use, an observer on the network cannot read the license credentials even if the request traveled over plain HTTP, and cannot forge or alter a response without the receiving side detecting it.

Two important limits on that:

• It is always on for the core licensing calls in Instant Protection PLUS 3, but it is not universal. The optional version/update check and the optional built-in online registration do not use this layer. If you rely on those features, confirm what they transmit before treating HTTP fallback as harmless.
• In Protection PLUS 5 SDK it is the developer's choice. Message encryption and signing are enabled per call or per API Context. If a Protection PLUS 5 SDK integration does not enable them, then a fallback to HTTP does transmit the request in the clear.

This is a defense in depth argument, not a substitute for TLS.

Can a fallback to HTTP be prevented at the network level?

The fallback happens on the computer where your protected application is installed. For most vendors that is an end user's workstation inside their own organization's network, administered by that organization's IT team. It is not your network and it is not ours, so any network-level control here is a change that only that organization can make, and the question normally arrives via a security review their IT team is carrying out.

Where that organization already prohibits unencrypted outbound traffic, there is nothing further to do. Their existing egress policy blocks the fallback attempt, the application reports a connection failure rather than communicating over HTTP, and normal activation over HTTPS on port 443 is unaffected.

Where it does not, the equivalent control is a rule on their egress firewall or proxy blocking outbound TCP port 80 to the SOLO Server address, while continuing to allow port 443. Whether that is something they are able or willing to add is theirs to judge, and it is worth confirming with them rather than assuming. Of the network-level options this is the one that holds regardless of conditions, because the decision to attempt a fallback is made by the licensing client on each machine.

For software distributed to the general public, rather than into managed environments, no network-level control is available to you at all. In that case the client-side options in the table above are the only ones that apply.

On the server side, the shared SOLO Server does not offer this. Port 80 is open on the shared service and the web service endpoints answer over plain HTTP. If you use SOLO Server Dedicated URL or SOLO Server Self-Hosted, disabling plain HTTP on your own instance may be an option, and you can contact us to ask about your instance. Note that it is a weaker guarantee than a block on the end user's network: it stops the legitimate server from answering an HTTP request, but the client still emits that request onto its local network, where a transparent proxy or an attacker in the path could accept it.

If your security team needs the specific algorithms, key sizes, and message structure for a formal security review, contact us and we will provide that documentation for your product directly.

Does the licensing client fall back to unencrypted HTTP if HTTPS fails?

See the table above for the per-client answer. Unless SSL has been explicitly required, the answer is yes for every client.

The fallback is triggered when the first attempt fails for any reason, not only when TLS specifically fails. A DNS failure, a refused connection, a timeout, or a certificate problem will each cause the retry. The retry goes to the same host and path with the scheme changed to http://.

In practice a machine that can reach the internet normally and supports TLS 1.2 completes the first attempt over HTTPS, so the HTTP path is not exercised. It becomes relevant on machines where something is interfering with the connection, which is exactly the situation a security review is usually asking about. One documented case is Mono older than version 5.0.0, whose SSL/TLS support was unreliable enough that the fallback fired routinely; Mono 5.0.0 or later is required for SSL/TLS support.

Which TLS versions does the hosted SOLO Server support?

The hosted SOLO Server accepts TLS 1.2 and TLS 1.3 only, and HTTP Strict Transport Security is enabled. TLS 1.0 and TLS 1.1 are both disabled and a connection attempt using either is refused.

This matters for older protected applications. If an application only offers TLS 1.0 or TLS 1.1, it will not be able to connect to SOLO Server at all, and the failure will look like a general connectivity or activation error rather than anything mentioning TLS. Two common causes:

• An application targeting an older version of the Microsoft .NET Framework, where the default protocol selection is obsolete. These usually need to opt into TLS 1.2 explicitly in application code or configuration.
• An operating system too old to support TLS 1.2. See the TLS 1.0 disablement announcement for the minimum operating system versions.

If you are troubleshooting an application that used to activate and now cannot, and it is an older build, check which TLS versions it offers before looking at firewall rules.

Related articles

• Web proxy support, proxy authentication, and troubleshooting
• Troubleshooting general licensing client connectivity