Ignore TLS/SSL error option

[gorkem-bwl]

Add "ignore TLS/SSL error option" for self-signed certificates for uptime monitors. Otherwise they will return "down" on Checkmate.

[karins28]

@gorkem-bwl can i take this?

[gorkem-bwl]

Go ahead please. You can suggest a placement in the settings area or I can let you know where to add it. You decide :)

[jnovack]

I suggest this to be a per-monitor setting.

[gorkem-bwl]

I suggest this to be a per-monitor setting.

Yes, that will be an option for each monitor.

Default would be enabled unless anyone comes up with a reason to make it disabled by default.

[karins28]

@gorkem-bwl That sounds like an Interesting task!
so if it would be an option for each monitor and enabled by default
1.Should i also store in the monitor object or a "whitelist " on the settings?
2.Also, should those monitors have a list of ips that can self-signed certificates, or given that a monitor has it enabled all ip addresses can access this domain?

[gorkem-bwl]

@ajhollid can you check @karins28's questions please?

[jnovack]

Disclaimer: IANAM (I am not a maintainer.)

1. Whatever object is storing the URL (and other details of the object being checked) to check also store the setting to InsecureSkipVerify, and just pass it right to the check code.

2. I feel that either are unnecessary, given the answer of "store with the url". It solves itself.

[ajhollid]

Hi @karins28 and @jnovack ,

Apologies for the late response, it's been a busy couple days!

I agree the best approach here is to simply add a flag to the Monitor object that holds all the other monitor details.

Also agreed there is no need for a whitelist, this can be handled on a monitor by monitor basis.

We can then use the status of that flag to ignore ssl errors when performing the check.

Sounds good to me!

[karins28]

@ajhollid @jnovack thank you for the help!
I opened a small draft pr, it'd be great if you can let me know if I'm on the right path
https://github.com/bluewave-labs/checkmate-backend/pull/95

I added:
1.flag to monitor object
2.handled certificate related errors in the monitors check using 1
3.Also Checked the ssl-checker usage (that we use in the /certificate api) -
in that case it returns invalid but doesn't fail but returns valid:false
https://codesandbox.io/p/devbox/interesting-napier-3qx85x?file=%2Ftest.js%3A10%2C14&workspaceId=ws_P6XRqxcbNyrKQyWGZJ7TvF

should I also the update option be added the ui, or any other apis as well?

[gorkem-bwl]

@karins28 for the option on the UI, yes, please. You can place it here:

On the left hand side we can have: "Ignore TLS/SSL error for HTTPS websites" as the first line, and "Ignore TLS/SSL errors and continue checking the website's availability. This is especially useful for monitoring internal, staging, or development sites with self-signed or expired certificates."

On the right hand side we can have this button type (default disabled):

Just fyi, @ajhollid may also write this in your PR, but we have merged two repos, and everything is now in one repo. Hence we have made the checkmate-backend repo private.

Can you please re-send your PR to this repo (https://github.com/bluewave-labs/Checkmate/) directly?

[jnovack]

Why as it's own box and not part of advanced settings? Are the advanced settings somehow different than the page's other settings?

By "hiding" it in advanced settings, you give the impression it's "not meant to be touched by default".

[gorkem-bwl]

That's a good point. Do you think it's not meant to be touched by default (as per your previous experience, and maybe how other similar tools do/work)? If that's the case, yes, we can move it to the advanced settings. Let me know so I can modify my previous response about how it will be placed.

[jnovack]

Do you think it's not meant to be touched by default

I'm mildly exaggerating, maybe that's a language barrier. It is not "hidden" in such a way that's it's forbidden to change it, like trying to add an internal/ package from one repository to another? No.

I'm suggesting insecure certificates being "valid" by default is meant to be "discouraged". Yes, of course you can use it, they gave you a method to use it.

But it's discouraged from being turned on. Look at the hoops you have to go through to use it. Google makes it off by default (I guess that's proof?), you can't just start a &http.client object, you have to call the client object with a config object with the TLSClientConfig setting changed. They provide some "barrier of entry".

I'm suggesting that it's available, but not highlighted like it's an option you should always have on and easily clickable. "Hide" it a little among the other advanced settings. Those extra clicks give feedback to the user it's allowed, but discouraged.

[gorkem-bwl]

@karins28 let me know the latest status here please as we are nearing the release.

[karins28]

I discussed it on the ticket,
the solution should be an addition to the axios configuration,
unfortunately I won't be able be able to reach it till Friday, you can reassign it if it's urgent

#2156

[gorkem-bwl]

LGTM!