[BUG] Healthcheck fails due to incorrect detection of SSL status

[nwh3365]

Environment

Self-Hosted (Docker)

System

24.0.7

Version

2.1.1

Describe the problem

This is similar to #768, #840, and #843, however none of those issues resolve this specific issue.

Healthcheck is failing under docker when SSL certificate files are passed to the container as described in the documentation (snippet below): https://github.com/Lissy93/dashy/blob/master/docs/management.md#passing-a-self-signed-certificate-to-dashy

Passing a Self-Signed Certificate to Dashy
Once you've generated your SSL cert, you'll need to pass it to Dashy. This can be done by specifying the paths to your public and private keys using the SSL_PRIV_KEY_PATH and SSL_PUB_KEY_PATH environmental variables. Or if you're using Docker, then just pass public + private SSL keys in under /etc/ssl/certs/dashy-pub.pem and /etc/ssl/certs/dashy-priv.key respectively

I think the issue is with the isSsl test at the beginning of healthcheck.js. It is determining if SSL is applicable strictly based on the SSL-related environment variables (SSL_PRIV_KEY_PATH and SSL_PUB_KEY_PATH) that are mentioned in the docs.

The docs indicate that with Docker you just need to pass the key files to the container (without specifying the environment variables), and indeed Dashy will run in SSL mode by doing so. However, because healthcheck.js is only using the environment variables to determine the SSL status, if you don't set them it assumes non-SSL and ultimately fails because it gets a "302 Found" instead of a "200 OK".

Ideally, the isSsl check should probably include whatever mechanism Dashy is using to put itself in SSL mode based on the presence of the key files in the container, however you can work around this issue simply by specifying the environment variables with docker run / docker compose:

--env SSL_PUB_KEY_PATH="/etc/ssl/certs/dashy-pub.pem"
--env SSL_PRIV_KEY_PATH="/etc/ssl/certs/dashy-priv.key" \

By specifying the environment variables (in addition to passing the key files), the isSsl check determines the correct SSL status and the rest of the healthcheck proceeds as it should.

Additional info

No response

Please tick the boxes

• You have explained the issue clearly, and included all relevant info
• You are using a supported version of Dashy
• You've checked that this issue hasn't already been raised
• You've checked the docs and troubleshooting guide
• You agree to the code of conduct

[liss-bot]

If you're enjoying Dashy, consider dropping us a ⭐
_{🤖 I'm a bot, and this message was automated}

[clsty]

Same issue here.

--env SSL_PUB_KEY_PATH ... --env SSL_PRIV_KEY_PATH ... does not change anything for my problem.

As for statusCheckAllow Insecure: true, it seems to require a http endpoint for detection, but this one usually being 302 redirect when setting up nginx reverse proxy.

I'm using mkcert as the root CA to self-sign ssl certs.

On the same machine, the homepage's Site Monitor feature just works. I'm NOT saying that homepage is better than dashy: Actually, homepage is kinda lightweight and much less powerful than dashy. If this issue could be truly resolved, I'd be very glad to migrate from homepage to dashy.

Oh, and another thing (but actually the same thing I guess), I specified
icon: https://mymachine.lan/img/icon.png for an item. This img url can be opened on my browser normally, and can be downloaded by curl, but the log of dashy says The path to 'https://mymachine.lan/img/icon.png' could not be resolved.

For adding the same url as icon, homepage works again.

I mean, it seems really weird how dashy process those url links.
Does "could not be resolved" means that dashy even choose the different DNS as the machine it is running on?
Or at least it seems that dashy does not refer to the system's (nor the browser's) CA root trust store.

[RamonAbudAlcala]

This #1025 (possibly related) feature request about adding a custom SSL CA might solve the problem.

[RamonAbudAlcala]

Ok I think I definitely missunderstood what the problem was in my previous comment.

But I was having this problem. I added the environment variables as @nwh3365 original comment suggests and I have the problem no more! Thanks!

I think this should be fairly simple to solve [technically], but unfortunately I don't know any javascript... Is it difficult to check for the existence of a file with javascript? If not, this should be enough. A possible fix to the boolean isSsl could include the following check.

[pseudocode] pretend that fileExists is a function or method to check if a file exists or not. It takes the path of the file as a parameter, returns a boolean.

const isSsl = ( !!process.env.SSL_PRIV_KEY_PATH && !!process.env.SSL_PUB_KEY_PATH ) || ( fileExists("/etc/ssl/certs/dashy-priv.key") && fileExists("/etc/ssl/certs/dashy-pub.pem") );

or perhaps another suitable solution is to simply ask the user directly if they want to use ssl or not, i.e., have an environment variable for that.
Something like USE_SSL = False added to the dockerfile. Then isSsl = process.env.USE_SSL

[CrazyWolf13]

Once 2.1.2 is avaiable on docker, can you test and see if the issue persists? There was one PR (#1076) related to this topic, but I cannot really test, as I do not have any SSL set up yet.