HFF Custom HTTPS (TLS/SSL) Certificates and Customer Domains Not Supported

Author: Eric Vasbinder

Overview

When customers use Trimble Viewpoint's HR Portal on-premise, they often utilize a friendly name, tied to their own HTTPS certificate for convenience. For example, "Company A" might use https://hrportal.companya.com as their URL to access their employee portal. They would then purchase an HTTPS certificate, tied to that specific name. When moving to Viewpoint's ERP cloud, however, this method is not supported due to security and compliance reasons. As such, we cannot load third party, including customer, HTTPS certificates into our cloud, nor can we use the customer's domain name to refer to their employee portal.

Let's delve into the specifics as to why this is the case.

Managing HFF Sites in Viewpoint's ERP Cloud

In our cloud, HFF only supports connectivity through encrypted HTTPS communications. In order to have this connectivity function, a digital certificate is necessary for the HFF port to securely identify itself to the end user. This certificate is tied to the domain name of the HFF instance for each specific customer, usually in the format of https://companycode-hff.viewpointforcloud.com. From time to time, customers will ask us to change the DNS name of the HFF portal to match their old, on-premise instance, to make things easier for end users.

Unfortunately, this will not work in our cloud.

The root of the problem is in order for us to support the use of the customer's domain for the HFF portal, Viewpoint would need to not only coordinate DNS settings with the customer, but more critically we would need to host the customer's own digital certificate in our infrastructure to enable the HTTPS connection to function.

The security and management ramifications of hosting a customer's own digital certificate in our cloud are profound and could increase risks for all concerned. Additionally, this action would run up against the requirements of multiple compliance standards, including our SOC 2/2 certification.

"But wait!" I hear you say, "I thought SOC doesn't touch specifically on certificates?". This is true.

However, though SOC does not necessarily prohibit the hosting of third-party certificates, it does have very stringent requirements around what we would need to do from a control and monitoring perspective in order to host them. Adding in the proper additional technical, procedural, and personnel controls that would be necessary to effectively mitigate the added risks entailed by doing so would increase our costs by a significant amount. This would then need to be passed on to our customers as a substantial price increase. Doing this for just one customer would cause a major ramp in prices charged to all of our customers due to the baseline additional controls we would need to add as table stakes. This is not something we are willing to do.

As such, Viewpoint does NOT support the use of a customer's own domain name or HTTPS certificates in our cloud hosted servers.

However, there are ways to accomplish nearly the same ends that will work given architectural constraints.

Solutions

Temporary Placeholder Page

As the first step in your move, you may wish to create a simple HTML page that could be used on your old, on-premise HFF server in place of HFF. You would update the IIS site to point to a new "INDEX_REDIRECT.HTML" page that would have the text reminding your end users that the URL of HFF's portal had changed to the Viewpoint cloud domain URL. Users would click on that URL to pull up the new, cloud HFF.

HTTP 301 Permanent Redirects

This is the preferred longer term method to point end users to the new cloud location. Since the key item for end users is to allow for a simple transition period where the use of the original, internal, on-premise HFF URL can be used, we can instead use an HTTP 301, Permanent Redirect from the old, on-premise HFF IIS server to the new URL for HFF in Viewpoint's cloud. Here are the steps that you might use to set this up on Windows Server 2012/2016: https://howto.hyonix.com/article/how-to-set-up-website-redirection-from-iis-7-in-windows/

Simplified HFF URLs

Though it is not possible to host certificates for a customer's own domain in our cloud, to allow URLs such as https://keystyle.companydomain.com to work, we can simplify and shorten the issued name for the cloud-hosted HFF box to a certain extent.

For example, let's say that John Masterson's Heating and Plumbing Supply, LLP was initially assigned an HFF URL of https://johnmastersonheatingandplumbingsupplyllp-hff.viewpointforcloud.com as the URL for their HFF / Keystyle portal. This is long and would be confusing to end users, since the portal on-premise might have a name like https://keystyle.jmhps.com (EXAMPLE NAME ONLY). However, our friends at this customer would need to merely create a support case to request that their URL for HFF be renamed to https://jmhps-hff.viewpointforcloud.com.

In other words, as long as the URL for an HFF portal in our cloud has the suffix, "-hff.viewpointforcloud.com", at the end of it, we can support nearly any prefix the customer would request to keep things simple, rather than always being restricted to using the customer's legal entity name.