Some URL show down after updated to v1.23.4

[aciducen1995]

⚠️ Please verify that this bug has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

📝 Describe your problem

After updating my uptime-kuma to the latest v1.23.4, some URLs are showing down. Refer to Error based on log. After i revert back to v1.23.3, the uptime are ok.

📝 Error Message(s) or Log

Error in Dashboard
write EPROTO C0577B433D7F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:

Error in container log
| Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0
2023-11-14T19:13:46+08:00 [MONITOR] WARN: Monitor #5 'https://xxxxxx.com.my': Failing: write EPROTO C0A7EDAA937F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:

Keep in mind i have changed the URL to xxxxx

🐻 Uptime-Kuma Version

1.23.4

💻 Operating System and Arch

Oracle Linux 8.5

🌐 Browser

Google Chrome

🐋 Docker Version

20.10.17

🟩 NodeJS Version

No response

[chakflying]

This is a security fix in node.js v17+. Is the server running behind a corporate VPN/firewall?

(Related: nodejs/node#45378, blog post)

[aciducen1995]

This is a security fix in node.js v17+. Is the server running behind a corporate VPN/firewall?

(Related: nodejs/node#45378, blog post)

yes its behind corporate firewall.

[desquinn]

Wea re having the same issue following the upgrade. The commonality between two checks are that they are testing Lets Encrypt Certificates on Draytek routers using DDNS supplied by Draytek. The two urls are in the form https://xxxhostxxxx.drayddns.com:9443/ and the URLs work in firefox etc without any issue. These are the external firewalls for a couple of Small businesses.

[chakflying]

• So you have other HTTP monitors, but they are working fine, except these 2?
• What is the behavior of the monitor? Does it go into retry (pending)? Does it change status to up occasionally?
• The timeout parameter for a monitor was recently introduced. Does changing its value result in different behavior for the monitor?

1.23.5-beta.0 is also out so you may try it to see if it improves the situation.

[desquinn]

• Have reverted to previous version but other https checks with https / Letsencrypt were behaving okay. Just checked and we have another equivalent router with a draytek ddns record that did not fail.
• When it fails it goes to retry generating fails and same error messages. Did not see it ever come back with a positive result
• Also tried to pause the two failing checks and it seemed to reactivate them and "pull down" the parent.
• I did not vary the timeout but will upgrade a bit later and retry with varying the timeout.

I may try the beta as well.

[louislam]

• So you have other HTTP monitors, but they are working fine, except these 2?

  • What is the behavior of the monitor? Does it go into retry (pending)? Does it change status to up occasionally?

  • The timeout parameter for a monitor was recently introduced. Does changing its value result in different behavior for the monitor?

1.23.5-beta.0 is also out so you may try it to see if it improves the situation.

1.23.5-beta.0 do not include #4044 yet.

[CommanderStorm]

@desquinn
b383392 was merged and is avaliable since the v1.23.5 release.
=> I am assuming this issue is fixed.

If it is not, could you please comment, so we can debug this further? ^^