SSL Support for Twingate Alias Without Public DNS Records

Support / Troubleshooting
1

Hello Twingate team,

We’re currently utilizing Twingate connectors for our internal applications, and we have a specific requirement related to SSL/TLS.

In the past, we had public-facing A records for our domains, which were used mainly for testing purposes. These domains were secured using SSL certificates. However, to enhance our security posture, we’ve now decided to remove these public DNS records to ensure our endpoints aren’t exposed to the public.

Given this change, we have a few questions:

  1. SSL for Twingate Alias: With the public DNS records removed, is it possible to still use SSL for the Twingate alias? Specifically, can we prepend https:// to the alias and have it be recognized securely? Is it possible to have the browser recognise the certificate if we are using an alias?
  2. Certificate Validation: Given that we already have SSL certificates using DNS-01 challenge with LetsEncrypt for our previous DNS records, can they still be used in conjunction with Twingate aliases, even without the public DNS A records?
  3. Alternative Methods: If the above isn’t possible, are there any recommended methods or best practices to achieve SSL security for our Twingate aliases without making the domains publicly resolvable?

Our goal is to ensure a secure connection for our internal users via Twingate, without exposing any of our endpoints or domain information to the public internet.

Thank you for your assistance!

2

Hey David,

I put your question in front of my colleagues to see if anyone has some alternative answers, but as I understand things:

We don’t have anything specific surrounding SSL and aliases. It’s not something that’s really come up for us previously.

That being said, for the duration of the validity of your current LE certs, as long as your Twingate alias matches the domain the SSL cert(s) was/were issued for, the browser should be none the wiser, because you’ll be accessing server.example.com in the browser, and the SSL cert is going to say Hi I'm server.example.com and everybody should be happy.

The issue with this (I think) will come when your LetsEncrypt certificates expire, as I don’t think LE will let you generate SSL certs for FQDNs that don’t have public A records, which means you’d have to recreate those A records every 90 days or whatever the expiry period is.

You could also generate self-signed certs for the applicable aliases on the appropriate servers and then roll them out to the user endpoints so that everyone agrees they’re good.

I’ll report back if my colleagues have any additional context or suggestions for achieving what you’re looking for.

Thanks!

-arthur