Getting "Gio.TlsError: Unacceptable TLS certificate"
Closed this issue · 17 comments
I am using my local IP to connect to HA, as far as I am concerned there are no such things as certificates for local IP's, therefore HAE should be able to ignore the certificate.
I am sorry if I misunderstand something here, my knowledge about that stuff is pretty limited.
Hmm, are you sure this error is related to this extension? Have you added a valid HASS token? And is the URL in the correct format (e.g. http://0.0.0.0:8123 in your case)?
Yupp, I am sure. As soon as I use the domain-name, it is working fine. But I want it to work without internet, so that's not an option for me.
Oh just noticed you used http, HA is refusing unencrypted connections if TLS is turned on, unless there is a way to change that that I am not aware of.
In all honesty, I am not equipped to help you with that since I am not familiar with how HA encryption works in the background. I don't have my HA instance connected to the Internet either and I never had an issue.
In any case, I doubt that this is an issue with this extension. The error seems to originate in HA itself so I would guess the root of the issue is somewhere in your configuration.
The certificate is supposed to be invalid, that is expected behavior. Since it is registered to my domain, not to my local IP. All other clients ignore (or only warn) about the invalid certificate. But this extension doesn't let me ignore it. The only way to make it work would be to create a certificate for a local IP and as far as I am concerned that is not possible. So I am out of options here.
I did some research on certificates for local networks and the only way seems to setup my own DNS-Server, create a local domain-name and issue self-signed certificates. This seems kinda overkill since I would only need it for this extensions alone. @geoph9 Do you use a specific library or something for the http-access? (Sorry if the question is dumb) Maybe there is a way to make it force the connection even if considered insecure. Thank you for the answers/help.
Definitely not a dumb question. I recently migrated to Soup 3 (see #44) with which I am not very familiar. libsoup is the one that handles the certificate verification.
This post from 8 years ago (and Soup2) asks a similar question. Could you try out the proposed solution and see if it works for you?
Oh dear, I assume I would have to modify and compile the source-code for this? I am very inexperienced in that regard, when I find some spare-time I will look what I can do.
No, you would only have to change the utils.js file (the send_request and _constructMessage functions). The file should already be located under ~/.local/share/gnome-shell/extensions/hass-gshell@geoph9-on-github/utils.js. You should configure the message's properties.
I tried to figure out how to do this, I tried some things but the error remained. However, in search of a soluton I found this page, it says "ssl-strict has been removed in favor of using the SoupMessage::accept-certificate signal."
Maybe that's why it is not working?
Did you try adding a handler that returns true (maybe also log/print a warning)?
I think this is out of my league, I struggle hard to understand any of what the code does tbh. What I did was right after:
let session = Soup.Session.new();
I added this line:
session.ssl_strict = false;
I also asked ChatGPT to adjust the code to ignore certificates, he did the exact same thing I did, lol.
Okay, I just asked ChatGPT to use SoupMessage::accept-certificate instead, he added some lines of code and it worked. 🤯
function _constructMessage(type, url, data=null) {
// Initialize message and set the required headers
// let message = Soup.Message.new_from_encoded_form(
log(`hass-gshell: Constructing Message for ${url}`);
let message = Soup.Message.new(type, url);
message.request_headers.append(
'Authorization',
`Bearer ${Secret.password_lookup_sync(getTokenSchema(), {"token_string": "user_token"}, null)}`
)
if (data !== null){
// Set body data: Should be in json format, e.g. '{"entity_id": "switch.some_relay"}'
// TODO: Maybe perform a check here
let bytes2 = GLib.Bytes.new(JSON.stringify(data));
message.set_request_body_from_bytes('application/json', bytes2);
}
message.request_headers.set_content_type("application/json", null);
// Accept invalid certificates
message.connect('accept-certificate', (message, cert, errors) => {
return true;
});
return message
}
Yeah, seems about right. Did you try it out?
I am not completely sure that's something we want to have by default. Maybe there could be a switch that users toggle if they want to accept invalid certificates. Otherwise, this could be a security flaw.
Maybe there could be a switch that users toggle if they want to accept invalid certificates. Otherwise, this could be a security flaw.
I agree 100%!
I tried it just as is and it worked right away. I didn't interact with entities yet but the connection is clearly established.
I have this other problem that I need to restart the OS to make it show the togggleables but I have aaru dumping a CD right now, so I can't restart yet and try it.
Great! Thanks for looking into this!