starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

mTLS montoring through the tcp probe fails when extracting TLS alerts on TLS1.3 connections #4621

New issue

Open

opened 2026-02-28 04:09:34 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-28 04:09:34 -05:00

Owner

Originally created by @tchinchow on GitHub (Jan 19, 2026).

This is a continuation of #5837 which was closed as "implemented by #6587"

Many thanks for this patch that opened the way.

🛡️ Security Policy

I have read and agree to Uptime Kuma's Security Policy.

📝 Description

I'm still facing issues on some of my sites when expecting a certificate_requested alert (116) from the server.

The tcp probe pretends like the server accepted the connection when it really did not (and curl confirms that the server is requiring a client certificate).
(see #5837 for details and screenshots)

👟 Reproduction steps

Probe a TLSv1.3 server that requires a client certificate.

Set the Expected TLS Alert field to certificate_requested (116)`.

👀 Expected behavior

The probe should indicate that the server indeed responded with the expected TLS alert (116).

😓 Actual Behavior

The probe pretends like the server accepted the connection and fails to recognize that it actually refused the connection with the expected TLS alert (116).

This is confirmed this with curl. You can run it from inside the docker container to make sure that the network configuration is similar.

🐻 Uptime-Kuma Version

2.1.0-beta2

💻 Operating System and Arch

fedora

🌐 Browser

firefox

🖥️ Deployment Environment

you can do this in the official docker container.

📝 Relevant log output

Originally created by @tchinchow on GitHub (Jan 19, 2026). ### 📑 I have found these related issues/pull requests This is a continuation of #5837 which was closed as "implemented by #6587" _Many thanks for this patch that opened the way._ ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description I'm still facing issues on some of my sites when expecting a `certificate_requested` alert (116) from the server. The tcp probe pretends like the server accepted the connection when it really did not _(and `curl` confirms that the server is requiring a client certificate)_. _(see #5837 for details and screenshots)_ ### 👟 Reproduction steps Probe a TLSv1.3 server that requires a client certificate. Set the `Expected TLS Alert` field to certificate_requested (116)`. ### 👀 Expected behavior The probe should indicate that the server indeed responded with the expected TLS alert (116). ### 😓 Actual Behavior The probe pretends like the server accepted the connection and fails to recognize that it actually refused the connection with the expected TLS alert (116). This is confirmed this with `curl`. You can run it from inside the docker container to make sure that the network configuration is similar. ### 🐻 Uptime-Kuma Version 2.1.0-beta2 ### 💻 Operating System and Arch fedora ### 🌐 Browser firefox ### 🖥️ Deployment Environment you can do this in the official docker container. ### 📝 Relevant log output ```bash session ```

deekerman added the

bug

label

2026-02-28 04:09:34 -05:00

deekerman commented

2026-02-28 04:09:39 -05:00

Author

Owner

@tchinchow commented on GitHub (Jan 19, 2026):

I think I know what happens but I'm not confident enough with Javascript/node to fix it.

TLSv1.3 seems to enter a secureConnect state/event before reaching the error state/event because ciphering happens much before what is done in TLSv1.2.

The connection eventually reaches the error state but this event happens when the Promise has already been resolved.

In comparison, TLSv1.2 fails during the handshake and the error state is reached first.
This explains why current code works with this version of TLS (at least with fairly recent versions of node).

Documentation of the NodeJS TLS, session event seems better suited than secureConnect for what we want to achieve here.
However in case of TLSv1.2 it lloks like we never get to the session state/event.
I don't know why and this is where Javascript leaves me hanging...

I tried to modify the code _(#6772)_but then most tests fail because the session event does not seem to come for TLSv1.2 servers.

...and then I'm stuck for now.

@tchinchow commented on GitHub (Jan 19, 2026): I think I know what happens but I'm not confident enough with Javascript/node to fix it. TLSv1.3 seems to enter a `secureConnect` state/event before reaching the `error` state/event because ciphering happens much before what is done in TLSv1.2. The connection eventually reaches the `error` state but this event happens when the Promise has already been resolved. In comparison, TLSv1.2 fails during the handshake and the `error` state is reached first. This explains why current code works with this version of TLS _(at least with fairly recent versions of node)_. Documentation of the [NodeJS TLS, session event](https://nodejs.org/api/tls.html#event-session) seems better suited than `secureConnect` for what we want to achieve here. However in case of TLSv1.2 it lloks like we never get to the `session` state/event. I don't know why and this is where Javascript leaves me hanging... I tried to modify the code _(#6772)_but then most tests fail because the `session` event does not seem to come for TLSv1.2 servers. ...and then I'm stuck for now.

deekerman commented

2026-02-28 04:09:40 -05:00

Author

Owner

@tchinchow commented on GitHub (Jan 19, 2026):

All I can tell is that the fix seems to work for me with node version 25.3.0.

It clearly fails with node version 20

I don't know about other versions but the automated tests suggests that multiple versions (including old node versions 20) must be supported by uptime kuma on systems such like ubuntu...

I will close the pull requests where I was only trying to figure out how the test system works and what it validates.
I don't know what I'm doing and I don't know how I can try things out on my own without polluting this repo.

@tchinchow commented on GitHub (Jan 19, 2026): All I can tell is that the fix seems to work for me with node version 25.3.0. It clearly fails with node version 20 I don't know about other versions but the automated tests suggests that multiple versions _(including old node versions 20)_ must be supported by uptime kuma on systems such like ubuntu... I will close the pull requests where I was only trying to figure out how the test system works and what it validates. I don't know what I'm doing and I don't know how I can try things out on my own without polluting this repo.