How to have own HTTPS domain on password recovery URL?

After successfully setting up the email config so that my users can set their passwords (despite the scant email documentation for this, I had to follow this video https://www.youtube.com/watch?v=U69YYWV7BW0), I get the following recovery email:

Hi,

Please click the following link to reset your password within 2 hours .

http://grafana.staged-by-discourse.com/user/password/reset?code=[SOME-CODE]

Not working? Try copying and pasting it to your browser.

The link works well but only (obviously) if I change community.grafana.com to my own domain.

How can I have the community.grafana.com string in the password recovery email be my domain?

How can I make sure the URL is also https? (My server should redirect it to https, but I’d like users to see https since many would like that safety signal.)

For context, I followed this tutorial for setting up the grafana server with a reverse proxy: How To Install and Secure Grafana on Ubuntu 20.04 | DigitalOcean

Hello,

The requited configuration is documented here: https://grafana.com/docs/grafana/latest/administration/configuration/#domain

Update the “domain” in the full public facing URL:
root_url = %(protocol)s://%(domain)s:%(http_port)s/

So, if you update it to, for example, “mygrafana”, your URL will be http://mygrafana:3000. If you change the “http_ports”, then you will have to provide the correct port number.

Thank you.

Changing that in /etc/grafana/grafana.ini isn’t enough given my context. It prevents the page from loading. In /var/log/grafana/grafana.log the error is logged as

t=2020-12-08T02:09:41+0000 lvl=eror msg="Stopped HTTPServer" logger=server reason="cert_file cannot be empty when using HTTPS"
t=2020-12-08T02:09:41+0000 lvl=eror msg="A service failed" logger=server err="cert_file cannot be empty when using HTTPS"
t=2020-12-08T02:09:41+0000 lvl=eror msg="Server shutdown" logger=server reason="cert_file cannot be empty when using HTTPS"

At the very least it requires also including where the certificate file and key are in the cert_file and cert_key parameters. When those are set to the right pem files, this error happens:

t=2020-12-08T02:17:13+0000 lvl=eror msg="A service failed" logger=server err="open /etc/letsencrypt/live/[domain]/fullchain.pem: permission denied"
t=2020-12-08T02:17:13+0000 lvl=eror msg="Server shutdown" logger=server reason="open /etc/letsencrypt/live/[domain]/fullchain.pem: permission denied"

Changing group permissions as described here and in no other places I could find: https://www.jorgedelacruz.es/2019/06/04/grafana-securizando-nuestros-dashboards-en-grafana-usando-https-con-lets-encrypt-de-manera-gratuita-y-renovacion-automatizada/

After that, you finally get the server to respond but with an error saying:

Client sent an HTTP request to an HTTPS server.

which then, I suspect, goes into more complicated reverse proxy settings…

Also to clarify, @aparajitachatterjee’s works if I leave protocol as http - but for digital hygiene and user trust purposes I’d really need it to be set to https.

Looking at some other posts, there is an orphan answer from some months ago that helped: Question about forcing HTTPS traffic with Grafana - #9 by kevinbertho

In the partially-certbot-managed /etc/nginx/sites-available/[site-domain] I changed

proxy_pass http://grafana.staged-by-discourse.com;

to

proxy_pass https://community.grafana.com;

and that did the trick but then I reverted everything since I was not sure if making https calls to localhost is recommended or not. It did seem to be interfering with http-to-https redirection on the site, but I’m not positive it was.

In any case, it shouldn’t be this complicated to have a https password recovery URL with my domain.

What ended up working - taken from this answer - was editing /etc/grafana/grafana.ini:

domain = [my domain]

root_url = https://%(domain)s/

That way, you have an https URL without changing the protocol parameter, and thus you avoid running into messy paths, permissions or groups. There’s also no changing nginx config files.

Thank you for the feedback. We are glad you got the issue resolved.