Closed PhilM-IT closed 2 years ago
yes, this should not be too complicated. Once it is using https the actual port won't matter and probably best to not use 443, the default parts would still work fine.
yes, this should not be too complicated. Once it is using https the actual port won't matter and probably best to not use 443, the default parts would still work fine.
Sounds great, in my case I'm using the webhookrelay.com setup so I'd need the standard port (443) to be used. I just figured it's easier to leave your port options as is and add a flag to make it an https call instead of http.
I need a little more information on how your configuring webhook relay? I can send from rachio to webhook relay with a https prefer but I have not been able to test successfully. I can send https without webook relay in the mix but the self signed cert is an issue. are you just wanting to encrypt the traffic between rachio and webhook relay?
I take that back I can successfully test https from rachio to webhook relay if that is all you looking for
I take that back I can successfully test https from rachio to webhook relay if that is all you looking for
That is what I'm after. I'd expect the https connection directly to homebridge to fail unless a valid cert was loaded and enabled or you allowed https connections to continue with a self-signed cert. In my case I'm using the relay and they have a valid cert already in place for the endpoint rachio should be talking to.
try the beta version and let me know if it does what you expect. let me know if the readme is accurate.
try the beta version and let me know if it does what you expect. let me know if the readme is accurate.
Awesome, thanks for the quick turnaround. Sorry for the ignorance but how exactly do I install the "beta"?
"npm install -g homebridge-rachio-irrigation-beta"
are you using home bridge UI, you can use the install alternate version from the plugin UI. otherwise I think it would look like "npm install -g homebridge-rachio-irrigation@1.2.16-beta.0"
I'll try the UI option first and use the CLI if I can't get that to work. Thanks. I'll let you know once I have it in and tested.
I personally never used webhook relay, but installed it to test this release and realize I could make a few extra tweaks to make this easier. try beta2.
Sweet, will be trying it out this weekend.... I'll let you know what I find.
Sweet, will be trying it out this weekend.... I'll let you know what I find.
Installed, moved my config into the new section you setup for the relay and the test works. Leaving as is and will post back any issue I run across.
Some constructive feedback if you will. While this works, my main driver was not opening a port on my firewall for insecure traffic, so for now I use the relay. That said I'm working to get homebridge running with a valid cert and would prefer the non-webhook relay option but still want the webhook call under ssl.
The current implementation that would require more adjustments for this correct? If the option was available under the original section to make the webhook call https. Just a check box for example, I could forward any port needed (as I don't really want to expose the standard SSL port 443) but still forward that port to my internal homebridge instance using SSL.
This is ultimately what I'm after so I thought I'd share. I'm just still working on the homebridge ssl part right now ;-) as I run that in docker.
I have messed with that a bit and I had it working for me, I have the logic to move between the nodejs http and https libraries, assigning the key and cert in the options for the server used for listening when it is configured is the hard part. This may not be something I really want to support directly, but it may be possible to provide the option to use the https if you can point to you own key and cert. is you cert self signed?
I have messed with that a bit and I had it working for me, I have the logic to move between the nodejs http and https libraries, assigning the key and cert in the options for the server used for listening when it is configured is the hard part. This may not be something I really want to support directly, but it may be possible to provide the option to use the https if you can point to you own key and cert. is you cert self signed?
So I'm actually working on the cert part now. Ideally no, the cert would not be self-signed. I'm working on using certbot now to gen a valid cert from letsencrypt.org (free). If I can get this working (with the autorenew) the next part will be pointing my HB docker at it. The bot will handle the autorenews. In the end I was hoping to use a valid cert from a root CA. Not self-signed.
@valiquette, took me a while but I'm where I wanted. I have HB running with a valid cert (not self signed). Any chance I could convince you to add that https option for the normal webhook settings?
Plan to use a custom external port for the port forwarding not the standard 443 so the external port entry would still work, just need a way to tell the code to make a https call
So looks like I might be wrong on the effort. Maybe you need the same cert and private key for creating the webhook endpoint?
I have HB working with the cert but the webhook port still fails the test when using SSL. Standard http works fine.
I am not sure having HB is enough, since the plugin is acting as the server.
But I already put support for this in the current release, and I was able to test it as far as I could with a self signed cert.
add these 3 lines to this plugins config
"https":true,
"key":
"https":true, "key":path to key.pem, "cert":path to cert.pem
I think you can use the same ones you have for HB, just need to point to them
Sorry my previous instruction is wrong My test looked like this, "https": true, "key": "/Users/John/Downloads/key.pem", "cert": "/Users/John/Downloads/cert.pem",
Sorry my previous instruction is wrong My test looked like this, "https": true, "key": "/Users/John/Downloads/key.pem", "cert": "/Users/John/Downloads/cert.pem",
You got it, works like a charm. All set. Would be nice if you could UI those in a future release but this work (assuming valid CA cert is used)
Yea that would be my plan, I just did not want to put anything out there until I was sure it worked. As for now keep in mind they may disappear is you save the config from the UI
Yea that would be my plan, I just did not want to put anything out there until I was sure it worked. As for now keep in mind they may disappear is you save the config from the UI
Noted, thanks for the heads up...
Yea that would be my plan, I just did not want to put anything out there until I was sure it worked. As for now keep in mind they may disappear is you save the config from the UI
On that note, one other comment and I'll test a little more. I removed the relay config and setup the normal config specifying the same external and internal port (I have no need to translate the port). I left he SSL config in place.
This didn't seem to let the test url work at all, via ssl or none. I removed the ssl settings, put the external port back to 80 and it worked without ssl, I think added the SSL config back in and it worked. Lastly, I change the external port back to match the internal. All works. Maybe the webhook won't provision correctly with SSL from the start? Not sure what caused this...
Yea that would be my plan, I just did not want to put anything out there until I was sure it worked. As for now keep in mind they may disappear is you save the config from the UI
And one more issue, I think.... The test URL works both inside and outside my network but is the call the rachio service is making https with this change? the webhook receiver is and the test works but I'm not receiving webhooks when status changes occur.
Happy to test further or send debug logs, just let me know how to enable.
The incoming webhooks will not be able to reject un authorized requests like you could from your browser. You may need to check the domain used when you created the cert includes the webhook listener.
The incoming webhooks will not be able to reject un authorized requests like you could from your browser. You may need to check the domain used when you created the cert includes the webhook listener.
It all matches up and I have no warnings or issues hitting the test URL, here's the config. Feel free to hit the test url if you like, works for me from my office system. I don't think the inernal address is even used in this case.
"name": "MM Rachio",
"api_key": "[my key]",
"default_runtime": 3,
"runtime_source": 0,
"use_irrigation_display": true,
"show_standby": false,
"show_runall": false,
"show_schedules": false,
"external_IP_address": "mmhb.mymorrow.com",
"internal_IP_address": "127.0.0.1",
"external_webhook_port": 27546,
"internal_webhook_port": 27546,
"use_basic_auth": false,
"delete_webhooks": false,
"https": true,
"key": "/certs/live/mmhb.mymorrow.com/privkey.pem",
"cert": "/certs/live/mmhb.mymorrow.com/cert.pem",
"platform": "rachio"
I get different results based on different networks, when I test this from postman I get a good 200 response but there is a warning that seem like it may be the culprit. "unable to verify first certificate". I did find one note on this topic that when using certbot the file for the cert should be "fullchain.pem". Not sure if this could be a factor.
warning Network Local Address 172.20.10.2 Remote Address 47.197.74.245 TLS Protocol TLSv1.3 Cipher Name TLS_AES_256_GCM_SHA384 Certificate CN mmhb.mymorrow.com Issuer CN R3 Valid Until Jan 21 14:18:52 2023 GMT Unable to verify the first certificate
try changing the config to point to that fullchain.pem instead of cert.pem and I think that will solve this.
try changing the config to point to that fullchain.pem instead of cert.pem and I think that will solve this.
That was it, works like a charm now.
Makes sense too, the cert.pem file is only my certificate and not the intermediate certs. Normally a webserver should return all certificates in the chain. the fullchain.pem file contains them all.
Randome question, if I enable this and set the username and password that ensures the call to the webhook requires basic auth right?
"use_basic_auth": true,
Correct, except I disabled it for https regardless of the setting because Webhook relay would not accept that, but now in your use case it would work so I will correct that, now that this seem to work ok. If it is using it you will see it in the test url from the logs.
Correct, except I disabled it for https regardless of the setting because Webhook relay would not accept that, but now in your use case it would work so I will correct that, now that this seem to work ok. If it is using it you will see it in the test url from the logs.
I enabled and set the username and pass but to your point it doesn't look to be using it at the moment.
It will be fixed in the next release.
It will be fixed in the next release.
Sounds good, appreciate the quick responses. Glad this is working end-to-end now.
v1.2.17 has UI config for this and basic auth is enabled. If it looks ok you can close this out.
v1.2.17 has UI config for this and basic auth is enabled. If it looks ok you can close this out.
UI looks ok. the user and pass are now part of the webhook test URL but when I attempt to hit that it just logs this
"[10/25/2022, 7:13:24 AM] [MM Rachio] Expecting webhook authentication"
Disabled the auth and re-enabled but no go. (test URL still works without auth)
NOTE: It does still work properly when the Rachio operates so the testing URL just doesn't function pasting into a browser. Everything else looks good from what I see.
"[10/25/2022, 7:13:24 AM] [MM Rachio] Expecting webhook authentication" This is expected, because your browser will not have the correct header with the encrypted username and password. The fact that you saw that message indicates that the path and auth was working
Any chance you'd be able to add a config switch to use https instead of http. I was able to set the port to 443 but the calls fail for obvious reasons.