Setting a Custom Domain with a wildcard certificate


Can somebody explain how setting the custom domain should actually work?
Following this guide: Interface tab - Documentation
I have 3 things to do:

  1. Set up a CNAME from my custom domain ( to
  2. Make sure the backend is accepting CORS requests from my custom domain via an environment variable
  3. A valid SSL certificate

The first 2 things are done:

Server: 2a02:1800:100::44:2
Address: 2a02:1800:100::44:2#53
Non-authoritative answer: canonical name = canonical name =

But still doesn’t work.

Also, I don’t get the point about having a valid SSL certificate.
Resolving eventually points to a machine displaying the frontend managed by ForestAdmin. So I should have an option to upload our certificate so that machine can provide that certificate to the browser? But I cannot find such an option.

Or, ForestAdmin could foresee a LetsEncrypt certificate on that machine. But then we don’t have to do anything so the warning about having a valid SSL certificate makes no sense?

Thanks for the help.

Hello @jorn_bonsai. Welcome to our community :tada: :confetti_ball:

Sorry for the delay. I just look at your site it seems that you didn’t configure the https access to your domain. You need to enforce https (https redirection) to configure the custom domain.

You need to have a valid certificate on to let Forest Admin make the trick.

I cannot provide you much help here since it depends on your infrastructure provider.

Nevertheless, Let me know if you encounter any troubles configuring it.

Kind regards,


https is not managed at domain level. A domain is nothing more like together with subdomains like

(http is a protocol. If it would have been managed on domain level, then you would need to configure everything on your domain like ftp, sftp, ssh, … which is not true. A domain is human readable name for an ip address. That ipaddress identifies a machine in the network)

So, going over the steps:
A computer asks for
The DNS resolver sees it is a cname to a different domain: points to the domain
That one is again a cname for
Eventually the DNS resolver gets to the ip address of which gives you the ipaddresses if the heroku machines hosting the content of

At that point in time your machine has the ipaddress if the machine it needs to connect to.
Then, your machine will try to reach that ip address via a certain protocol the client chooses. That can be any protocol. In order to make a connection possible, the host needs to be able to understand that protocol on the port you’re connecting on. Because a protocol often has a default port, you don’t need to provide the port in the url in your browser when you’re using http or https.

So if we go to
Your machine gets the ipaddress of the machine who is responsible for the DOMAIN (not the protocol https). As stated above, that ipaddress is a machine on heroku.
Your machine will make a connection to that ipaddress via the https protocol. The host will provide a ssl certificate back to the client.
The client (your browser) will check if that certificate matches the DOMAIN.
So, the host needs the certificate of
So I need to provide it to forestadmin so it can be installed on the machine.
But I don’t have such an option.
So ForestAdmin could also foresee a LetsEncrypt certificate. But then, I don’t have to do anything.

(sidenote: a letsencrypt certificate is used on the url from this thread: Production custom admin URL displays invalid SSL)

Hey @jorn_bonsai and welcome to our community :wave:

Having a SSL certificate is mandatory for the custom domain setup to work properly. AFAIK, and sadly, there is nothing much forestadmin can do to automate this process, since we don’t own the, we can’t automate a certificate generation for this domain.

The CNAME record seems indeed properly setup, nslookup returns indeed on my end as well.

This is especially important, since if is a CNAME to and the requests are made from , this machine must present a certificate valid for to the client, which is currently not the case in your setup.

1 Like

exactly …

This is especially important, since if is a CNAME to and the requests are made from , this machine must present a certificate valid for to the client, which is currently not the case in your setup.

Who is “this machine” in your scenario? It is, right?
Because if I go to, I get the CNAMEd to
So, if you agree with me, then as you say “this machine must present a certificate” it is the machine behind that must present a valid certificate for
How does our certificate get installed on that machine?! I have to provide it to you…

(And contrary to what you say: you can automatically generate a LetsEncrypt certificate. But that’s another discussion)

Hello @jorn_bonsai,

You just hit the nail on the head. After some investigation on our side we can confirm you that we have some issues here:

  • There an issue on our side. We found an unexpected error during your domain creation. We are investigating what cause the issue.
  • Our documentation is incorrect/outdated, you don’t need to provide the certificate…

The custom domain mechanism needs some love from our end. So from all the team kudos, you were right we can provide the certificate for you. :pray:

We will update the thread as soon as possible to solve your issues with the setup. Also, we will update the documentation and the settings panel to remove all the outdated informations.

Again, thank you so much for bringing to light this lacks.

Best regards,


Thanks for the explanation @morganperre. So indeed, no SSL is required on your domain.

However, we finally managed to locate the issue associated with your project.

As Heroku documentation states:

  • ACM does not support applications that have wildcard custom domains.

Manually adding your domain on our end seems to indicate that a wildcard * already exists on an heroku app, thus we are not able to generate a valid certificate via lets encrypt

Could you confirm that you have an app running with such a certificate?

Thanks in advance, sorry for the misleading informations, and thank you for the very details explanation & analysis of the issue @jorn_bonsai :pray:

That’s correct. We have applications running on heroku using our own wildcard certificate.
That’s indeed an important one to add to your documentation imo.

To solve this issue, it would be cool if ForestAdmin users would have an option to upload their own certificate to you, and ForestAdmin installs that certificate on heroku’s server via Automated Certificate Management | Heroku Dev Center

I understand that’s is not a feature that would be ready tomorrow.
So, what’s our next step? I think there are only 2 options:

  1. I remove my wildcard certificate from the other heroku applications
  2. A little bit of personal support: I send you our own certificate via another channel, and you install it manually on the heroku server…?

(sidenote: I don’t get why it’s a limitation on heroku… The correct application is probably reached on heroku via SNI, then that application should just provide the certificate it has installed… maybe I’ll reach out to heroku for this)

Indeed. We’ve created a ticket to fix the notice, write a better custom domain documentation & improve the error we received from our ACM to ease future investigation. I’ve pushed to productboard the fact that users may want to upload their own certificate for this “specific” wildcard certificate usage.

To me, 1. seems the best option, since our ACM will automatically renew the certificate 1 month before expiration. 2. would require you to provide us the wildcard certificate manually, way before it expires to avoid service interruption.

Let me know if that helps :pray:


Allright, we will just wait for this feature. I don’t think it will take a year to finish?

I’m switching the thread topic to feature suggestion, and marking it as resolved, since I already pushed this to our product board.

We can’t provide any ETA for such feature suggestion, but be sure you’ll be pinged once implemented :+1:

1 Like