uptime-kuma: x.509 SSL Client Certificate Authentication

@bdsoha Yes, these variables will allow you to accept a custom CA and / or ignore TLS related errors, and yes, that does solve the server certificate issue which is great.

However, the remaining (and most significant) part of this issue is referring to client TLS authentication - i.e. allowing the client to authenticate themselves using a certificate. That is not possible with those (or other) environment variables.

I have a need for this too. I habe several services running with a x.509 client certificate.

+1 for adding this feature. It would be very beneficial for enterprise environments.

Similar feature “Ignore TLS Error” will be available in the next release.

Hello, actually mTLS is added but is there a way to consider a monitor online whitout the need of adding the client cert?

so to consider the monitor online with just the HTTPS handshake completed (chrome i.e. shows ERR_BAD_SSL_CLIENT_AUTH_CERT) i’ve tried the “Ignore TLS/SSL error for HTTPS websites” options but seems to not ignore this case, actually the only workaround i’ve found is to switch to a TCP-Port monitor but is not really the same

ps. the popup error says SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1586:SSL alert number 42

I encounter almost he same issue. The strange thing is that the error only occurs on some domains, and not all…

Pending: 0088F8F5797F0000:error:0A0003FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1586:SSL alert number 20

so to consider the monitor online with just the HTTPS handshake completed

I can’t help with how UptimeKuma handles this but, from an SSL point of view, the client certificate verification is part of the handshake so, if the server is set to require a client certificate, the handshake will fail if an appropriate certificate isn’t sent.

The client doesn’t get a HTML response, just an error. I suppose if you wanted to treat this as confirmation that the server was up you’d need logic along the lines of “if I get this type of failure to connect, treat it as success”, seems like a can of worms that really shouldn’t be opened?

Two caveats to the statement above. Firstly servers can be configured with client certificate optional and do the certificate checking logic later in the exchange (but you are unlikely to be seeing the error above if that was the case) .

Secondly, TLS v1.3 has introduced the concept of post-handshake client certificate authentication. However, in my experience this is quite erratically (to be polite) implemented with a lot of browser and server vendors pointing in all directions at each other and accusing everyone else of implementing it incorrectly.

Final caveat, I’m no SSL expert, just lots of bitter experience 😃 If any of the above is incorrect I’ll happily stand corrected.

+1’d above - been looking for a maintained statping alternative and one of the features many don’t have is mTLS authentication for both HTTPS and TCP/TLS (e.g. Kafka Brokers in my case). I can open a new issue for TCP if that’s out of scope for this one.

Yeah, I saw that feature and that’ll be great for allowing custom CAs but doesn’t address the mTLS angle to this. In node this would be a case of using a custom https.Agent and providing the cert and key parameters.