Reverse-Proxy-as-a-Service (RPaaS) supports using a custom domain name. There are multiple considerations when selecting a domain to use for proxying applications, which are outlined below.
Technical Requirements #
RPaaS uses The ACME protocol to generate certificates, using Let’s Encrypt for the certificate authority. Wildcard certificates are used for optimal security, which requires DNS validation to prove that the RPaaS instance is associated with the domain.
The process is 100% automated, but it requires using a DNS provider with a supported API and configuring the RPaaS instance with the required API tokens/keys. A full list of supported DNS providers can be found here: https://github.com/acmesh-official/acme.sh/wiki/dnsapi
Choosing a domain #
There are three options for domains:
- Using the randomly generated FQDN
- Registering a new domain
- Using the existing domain (not recommended for RMMs)
These options can also be mixed and matched as required by business needs. Our usual suggestion would be to use the random FQDN or a new domain with RMMs, documentation systems, and credential managers while using the existing domain for PSA tools.
Another consideration would be authentication; ConnectWise SSO is domain-aware and requires various reconfigurations when the domain changes (with steps varying per application).
Randomly generated domain #
Each proxy instance receives a randomly generated FQDN upon provisioning. These FQDNs are designed to be anonymous and resistant to enumeration. It is impossible for an outside party to determine the application or MSP based on the FQDN alone, making it the most secure of all the options.
However, this security comes with a usability tradeoff. The long and random names are not pronounceable or easy to use from memory. They require the use of browser bookmarks or documentation systems for daily use. Some of these concerns can be addressed by using a URL-shortening service that supports custom domains.
Registering a new domain #
Another secure option is to register a new domain. The idea here is to keep the MSP tools separate from the public domains used for marketing and email (so attackers using tools like HackerTarget won’t see the MSP toolstack when enumerating the MSP). This also provides the option to use user-friendly and memorable FQDNs, making implementation easier.
Registering a new domain is also a convenient way to resolve any technical API access requirements or limit the scope of the API tokens for MSPs using DNS providers that don’t offer granular access controls.
The only drawbacks to registering a new domain are the purchase/renewal costs for the additional name.
Using the existing domain #
For RMM tool security purposes, we do not recommend using the existing domain the application was using (especially if it is in the toolname.mspdomain.tld format)! Many MSPs have had their existing subdomains enumerated through DNS leaks and certificate transparency logs over the years, and bad actors have lists of these historic names. RPaaS provides excellent go-forward enumeration prevention, but overall protection diminishes if RPaaS is used with an already enumerated FQDN.
For PSA systems, the threat and defense scenarios are different, and there is less security concern with using the existing FQDN.
Typically, using the existing FQDN is the fastest method to proxy applications, and it is the least intrusive. MSPs with clients logging into their applications might make the tradeoff of less robust security controls for the transparent implementation method. While this isn’t recommended for RMM tools, it is an available configuration option if changing FQDNs isn’t a plausible scenario.
