Ability to monitor individual SSL sites on single server via SNI

[MikeWdotorg]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

New Monitor

🔖 Feature description

Multiple sites being served securely from a single server behind a load balancer using SNI cannot be individual monitored using the host headers in HTTPS. This type of monitoring requires SNI, specifically the host name to be passed as part of the TLS negotiation.

✔️ Solution

The existing URL field of the HTTPS monitor would specify an IP address of the shared server, and a separate host name field would be required to specify the site to check. The contents of the host name field would be passed to the server as part of the TLS negotiation, allowing the server to properly route the request to the correct site.

A potential solution to this would be to not perform a DNS lookup for the host name on the HTTPS monitor and use the IP address specified in the monitor in conjunction with the user specified hostname.

❓ Alternatives

I'm aware of no alternatives, but I'm very open to suggestions.

📝 Additional Context

No response

[CommanderStorm]

I am confused:
Isn't this the standard how the http(s) monitor works?

-> enter host: https://google.com
-> uptime-kuma will resolve the ip of the host (using the dns-cache if enabled)
-> request the page
-> checks the status code (and cert, if specified)

[MikeWdotorg]

You're correct in how it works, but that method fails if the server is behind a load balancer.

In your example, google.com resolves to an ip, lets say 8.8.8.8. With my issue, 8.8.8.8 is not an actual web server but a load balancer, which is a device that distributes the requests among 4 different back end servers: 8.8.4.4, 1.1.1.1, and 1.1.1.2. If 1.1.1.2 is down, you only have a 25% chance of kuma knowing that.

I need to know that google.com site running on 1.1.1.2 is down, so that I can be alerted and remediate the situation.

Using 1.1.1.2 as the host name also does not work, because multiple sites can be hosted on that IP address thanks to SNI protocol.

[CommanderStorm]

A load balancer should not be routing traffic to a node which is down. Health checks are one of the core things a LB does…

Either:

• your LB is down ⇒ the heath check fails
• your LB is up, and all nodes are down ⇒ the heath check fails
• your LB is up, and at least one node is up ⇒ the heath check succeeds

I don't think a cloud vendor ships LBs without health checks nowadays.
=> I don't think the argument why individual SNI is a good feature for all users is solid.

[damaddin]

What @MikeWdotorg is saying I think is that he wants to monitor a different IP then the one the DNS resolves to or be able to add custom HOST header to the HTTP monitor so you can build 4 monitors for the backend servers instead of just monitoring the loadbalancer where you are not sure which server you hit from external.

I was looking to use your supercool software to assist in a migration, where I would want to check all the SSL configurations on the target server without actually moving the DNS entry or the virtual IP.

Being able to add custom headers to the HTTP check would do the trick (at least for me).

[CommanderStorm]

@MikeWdotorg
You can already add custom headers to http checks

See #3564 for related issues concerning ipv6.

If you agree that this issue is resoved/a duplicate, could you please close this Issue, as duplicates only create immortal zombies and are really hard to issue-manage?

[damaddin]

Hi @CommanderStorm,

I totally missed that you can add custom headers there. I have tried it out and it works for me for this case. Thank you!

@MikeWdotorg You can configure the IP address for the node instead of the Domain as https check and add a HOST header to match the correct SNI / Virtual host and it should do the trick. Eg. check https://8.8.4.4 and have this config in the Header field:

{ "HOST": "domain-to-check.test" }

Works for me.

[MikeWdotorg]

I believe this method will work, thank you all. I had pretty much given up on it.

I just got back from Blackhat/Defcon and don't have time to test, but I'm going to close the issue on faith! It looks good. Thank you all!