Provide custom SSL Certificate
Is it possible for RM to provide a mechanism for users to upload their own trusted SSL/TLS certificate for use by API clients? I'm really not comfortable turning off certificate validation just to use the API.
If there's already a mechanism in place, can you point me to the documentation? I wasn't able to find it.
For local LAN RainMachine uses a self signed certificate since it's not really possible to have a authority signed certificate for private local lan IPs. This doesn't mean the SSL is not encrypted, just that the certificate can't be verified with a CA (which is expected).
If you have a certificate for your domain and you actually do a FQDN for the RainMachine private IP it's possible to add that certificate by ssh (you need to enable SSH from Settings) in /rainmachine-app/RMNetworkFramework/resources/sslCert.pem using for example something like:
scp mycert.pem root@<rainmachine ip>:/rainmachine-app/RMNetworkFramework/resources/sslCert.pem
and restart the device.
If you have configured Remote Access feature it's possible to access the API though our server instead of direct local connection. In this way you won't have certificate warnings.
on the device did not work for me. What did work was copying to
This is on a RainMachine Touch HD-16 running firmware version 4.0.925, though I found this to be true several months ago, too.
A: Agree with Dean. Don't bother with the /rainmachine...resources/ directory, that certificate doesn't seem to be used. But copying it to /system/etc/lighttpd/ works great. EDIT: See comment from Nicholas below: the Mini-8 uses the former location, the HD12/16 uses the latter. Probably good idea to update both in either case.
B: Here are the steps. First, you need to get an SSL certificate, which has to match the host name of the sprinkler controller. In my case, that's sprinkler1.int.example.com (replace example.com with my real domain name), and "int" stands for internal network. I like to use LetsEncrypt for my SSL certificates, because they are easy and free; and I use the "certbot" script to get and renew certificates, because that can be done with a single command. The problem with that is: this only works because certbot is able to modify files in the web server directory to implement the authentication challenge, and certbot is running on the machine for which the certificate is intended. This won't work on a RainMachine.
So the alternative I used is: I got a wildcard certificate for *.int.example.com, which I will apply to all my RainMachines (in the future, there will be more than one). And I use the DNS challenge technique for authentication; unfortunately, that can't be automated with my DNS service, but it is just a handful commands, every three months. Once that's done, you get your certificates, for example in /etc/letsencrypt/live/*.pem. Now copy them to the RainMachine directory shown above, and reboot.
BUT WARNING: The pem file on the RainMachine needs to contain both the private key and the certificate! This is different from an apache server, which wants those two ingredients in two separate files. No problem, concatenate privkey.pem and fullchain.pem (from the letsencrypt directory shown above), and copy them to sslCert.pem on the RainMachine.
Victory! No more web browser warnings.
Thank you for the correction; I edited my post to clarify.
How hard would it be to add the logic into the RainMachine to get a real SSL certificate itself? In some cases, it would be pretty easy: The device already contains a web server (duh, obviously), and it has a normal full-function OS which can run programs, so it could run certbot to get a real certificate from LetsEncrypt. The easiest way to implement the ACME challenge would be to use the web server challenge, with certbot depositing a file on the RainMachine's web server, and LetsEncrypt's authentication machine checking it. The problem with this idea is: it only works if the RainMachine is accessible via IP from the outside world (from LetsEncrypt servers) on a long-term stable DNS name, which requires it to have a semi-permanent IP address, no NAT (or a tunnel) and DNS. That's probably not true in the majority of the households. Another problem is that certbot doesn't support Android. So even implementing this for the easy case would be quite a bit of work; and generalizing it for all manner of network setups and handling edge cases would be really difficult. Therefore, I will not request this feature, and continue to do it by hand.
I fail to see how all of these gyrations are an improvement over instructing your browser/local machine to trust a given self-signed certificate. This security warning only occurs via direct access to the device. If you're accessing remotely via RainMachine.com proxy you don't get a security warning. If not, and you have done all the steps in this thread, then you are deciding to put your RainMachine IoT device running Android 4.3/"Jelly Bean" out on the public internet ("it only works if the RainMachine is accessible via IP from the outside world")... and all this is supposed to be an *improvement* in security?!
My suggestion: don't turn off certificate validation. Add the self-signed cert to your trusted exceptions (install your own self-signed cert on the device if you really prefer), and if it ever changes then you'll get a fresh security warning and know something is wrong. Remember, there is nothing magical about the CA's, except their license to print money by virtue of their public keys being included in your OS/browser trust store. Take control of your own trust store and add your certificate, or use the RainMachine.com proxy.
Regardless of whether or not your model runs a version of Android released 4 years ago (as the RainMachine Touch HD models do), the point remains that it's better to trust a self-signed certificate or use the Rainmachine.com proxy service than to put your IoT device on the public internet... and all in order to avoid using a self-signed certificate that you can trivially "pin" to your trust store.
Besides, all this setup involving publicly-accessible RainMachine devices, DNS to provide a fixed public target, NAT considerations, firewalls, obtaining certs with a CA-signed cert in the trust chain, etc, has already been performed by the RainMachine team when they created their free proxy service.
I just put a CA signed cert on my RainMachine Pro 16. Could I have done the Let's Encrypt hack, sure but for $6 I'll just install a cert that is good for a year. Next year I'll need to worry about it.
There are a few CA's that do offer either pretty cheap certs or they are having a sale.
Do I have a domain name? Yes
Do I have Internet reachable DNS servers? Yes, Amazon Route 53
Do I have a firewall? Yes, enterprise grade
Do I have access restrictions in place? Yes
Will mainly local devices hit it? Yes and they won't need to deal with a self-signed cert
Just because mine has a CA signed cert doesn't mean it will be fully accessible on the Internet. I can put it behind a reverse proxy as well.
...but you didn't get a CA-signed cert for your LAN IP, so if you directly access your RainMachine device via LAN you will still get a security error. Conversely, if you're willing to route the traffic to your device via the public internet, you could have accessed it for free – via TLS on a CA-signed cert with no security warning — using the RainMachine.com proxy.
"Just because mine has a CA signed cert doesn't mean it will be fully accessible on the Internet. I can put it behind a reverse proxy as well."
...so, that's like using the Rainmachine.com proxy, but with more steps.
"Will mainly local devices hit it? Yes and they won't need to deal with a self-signed cert"
If you're accessing it via local IP and not getting a cert error, then that means you have *also* overridden DNS for your LAN via one mechanism or another. And if your LAN local devices are routing your traffic out to the public internet IP in order to hit your RainMachine on your LAN, well, now we're back to the same effect as using the Rainmachine.com proxy (but with more steps).
From your statement, I don't think you understand certs at all. I can access the device from my LAN and there is no cert error. I can access it from the Internet and there is no cert error. I have a DNS zone on the inside of the network with an IP address. I have a DNS zone on the Internet with a different IP address. When connecting to the server using the DNS name, it works, That is what the browser is checking; that the entered name is the name on the cert.
From a security standpoint, you are trusting RainMachine is properly secured. Your RainMachine makes an outbound connection so that the your controller can be accessed remotely. That is a persistent connection that is always open. Companies far bigger than RainMachine have had breaches.
I have enterprise network hardware at home. Switches, routers, firewalls, IPS, load-balancers, etc. Everything is also logged. I can easily block traffic from certain sources; IP's ranges or subnets. I can also only allow it from certain IP's, ranges or subnets.
On the contrary, *you* seem to misunderstand cert issuance. It seems that you are unaware that certs can be issued to IP addresses (though not IANA reserved addresses, as I pointed out). You override DNS locally, as I indicated was requisite if you're going to avoid cert validation errors for hostname-based certs you want to resolve to a LAN local IP.
"When connecting to the server using the DNS name, it works"
...and, as I pointed out, it won't if you access it by the LAN local IP.
We can sit around and play "let's compare our enterprise-grade home network configuration", but that's just going to degenerate into even more eye rolling. I disagree with your assertion that your approach is more secure; you have elected to expose your IoT device to inbound-initiated traffic from the internet and hope your IPS/blacklisting approach works.
All this work to avoid pinning a self-signed cert to your trust store, and your approach *still* doesn't allow error-free direct access to your LAN IP.
You can have the DN or SAN to anything that you want. Any competent person would always only use names and not an address in a cert. If the addresses ever changes, then the cert is useless. Any IT person that would use an IP address in a CA signed cert should be fired.
Why would I want to access it via the IP address? That is what DNS is for...it is a wonderful thing, you should try it sometime. It doesn't matter if I'm at home or away, the same name works and no cert error.
Any device that connects to the RainMachine will not get an error if it uses the name. I will never tell it to use the IP address. That is stupid, dumb, asinine and something a fool would do.
I could give the IP address and anything packet that you send would never even make it to the RainMachine. You can't try to access a device you can't even talk too. Is that a hard or complicated concept?
Once again, I don't use the IP to access devices, I use a DNS name. That is how a real network is setup.
if I wanted, I could even give the RainMachine a real IP address. I have a block.;)
Haha, I see your retorts have degenerated to name-calling rather than admitting your error regarding CA-cert issuance and the fact that I am correct regarding the IP address scenario. Does it really bother you that you were ironically wrong in asserting I didn't "understand certs" while you were operating under incorrect assumptions regarding cert issuance?
Don't worry about it — I enjoy educating people. ;)
And what name were you called?
What error? Go to https://18.104.22.168
Guess what happens, cert on on the RainMachine main page. What a surprise. Since I use DNS and not IP's (which is the entire point of DNS) to access sites, what is your point exactly? I use technology the way it was designed; use it correctly and you don't have issues. I can access my RainMachine internally or externally and have no cert errors. Adding the cert to a keychain or cert store while can be done, doesn't mean that is the answer either. With multiple machines, that means I have to do the same thing multiple times. The alternative is a cert that cost me less than $6 for the year, was already purchased and took me all of four minutes to generate the private key, the CSR, the cert issued and installed.
You haven't educated anyone about anything.
Let's look at your posts in this thread:
"but you didn't get a CA-signed cert for your LAN IP, so if you directly access your RainMachine device via LAN you will still get a security error."
I access my RainMachine from the LAN and don't get a security error. So that statement is wrong because DNS is used and used correctly.
"RainMachine IoT device running Android 4.3/"Jelly Bean"
Not all of them run Android. So that statement is also wrong.
"point remains that it's better to trust a self-signed certificate"
Why is it better? Sure both are essentially trusted, one is trusted in a more secure method than the other. I can revoke a CA signed cert.
"Besides, all this setup involving publicly-accessible RainMachine devices, DNS to provide a fixed public target, NAT considerations, firewalls, obtaining certs with a CA-signed cert in the trust chain, etc, has already been performed by the RainMachine team when they created their free proxy service."
That also means that the cloud is required. I will have less downtime handling it myself than using the proxy service of RainMachine. If they have an outage, it impacts my access but my home network can be fully operational. Don't forget that not long ago, they had an outage.
"If you're accessing it via local IP and not getting a cert error, then that means you have *also* overridden DNS for your LAN via one mechanism or another. And if your LAN local devices are routing your traffic out to the public internet IP in order to hit your RainMachine on your LAN, well, now we're back to the same effect as using the Rainmachine.com proxy (but with more steps)."
I'm accessing it via the DNS name. The local LAN is not sending anything out the Internet. It is painfully obvious that either you don't understand the technology or that you have such a narrow view of it that you don't realize what it can really do.
You can have rainmachine.blah.example.com resolve to say 192.168.128.200 internally. So if you put that in the address bar, you will connect and not have an issue with a cert error. The name on the cert will match the name which is DNS and that you typed in the address bar. Using Amazon Route 53, example.com is hosted, was already hosted for other purposes to begin with. So no cost being added by using what is already there. Since rainmachine.blah.example.com is a FQDN but only example.com is domain being hosted, I can just create that entry as a FQDN and guess what, I can assign it a different IP address that is accessible on the Internet, say 22.214.171.124 as an example. So when the rainmachine.blah.example.com is typed into the address bar, you can still access it with a cert error.
The actual IP address of the device is irrelevant in regards to the cert.
Your scenario is flawed and as shown above, even RainMachine.com suffers from it. Use DNS and you don't have an issue. I was not operating under any incorrect assumptions.
How about your last incorrect statement:
"We can sit around and play "let's compare our enterprise-grade home network configuration", but that's just going to degenerate into even more eye rolling. I disagree with your assertion that your approach is more secure; you have elected to expose your IoT device to inbound-initiated traffic from the internet and hope your IPS/blacklisting approach works."
Blocking inbound (I can do outbound as well) traffic from the Internet using an IPS/blacklisting approach is used by companies big and small. That is the entire point of a firewall. Once again, use technology like it was designed and things work. How many large companies have their sites on the Internet that is not behind a firewall of some sorts?
There is an enormous amount of nonsense and chest-pounding in this thread.
To begin with: In this day and age, any server that exposes web services (meaning any http* protocol, meaning in particular http on port 80 and https on port 443) should be able to do so via https. For very obvious security and trust reasons, one should use encryption and authentication everywhere. That also implies that as much as possible, any https server should have a certificate for authentication. Now, I completely understand that in the case of the RainMachine, the good people at RainMachine are not capable of shipping one, since they don't know the IP address, domain name and network setup into which their product will be set up. So the end user will have to take care of it. And as we have seen above, this is perfectly doable, but not super easy. It could be made easier, if the good people at RainMachine put extra work into (example is above); whether that's an important project or not, I can not judge.
RK wrote: " This security warning only occurs via direct access to the device. If you're accessing remotely via RainMachine.com proxy you don't get a security warning." True, but I don't have to always go through the proxy server. I have a very fast, reliable and (imho) well managed internal network. The external network is neither fast nor reliable, and not particularly secure. If I can get to the RainMachine directly using only local traffic (with my external network disconnected), that is far preferable. It works even when my local (crappy) phone company has problems with their DSL. And it would work in the unpleasant case that the RainMachine corporations goes under (which I hope doesn't happen, but better be ready) and the proxy vanishes. So forget relying on the proxy: when it works, great, but it also has to work without.
And then RK wrote: "If not, and you have done all the steps in this thread, then you are deciding to put your RainMachine IoT device running Android 4.3/"Jelly Bean" out on the public internet ... and all this is supposed to be an *improvement* in security?!". Nonsense. The RainMachine does NOT have to be on the public internet. In my case, it is on a well shielded internal network, which is firewalled in both directions (and explicitly allows the RainMachine to talk to its proxy). One can choose to take the https port of the RainMachine and make it externally visible (not necessarily at port 443, for a little bit extra shielding); one doesn't have to. One can also choose to simply expose the RainMachine openly to the network, and hope that the good people are RainMachine have done a good job at securing the machine. About that:
You point to a list of vulnerabilities, which are mostly irrelevant, since nearly no server ports on the RainMachine are accessible, if on a well-managed network. Matter-of-fact, nearly all the vulnerabilities you list are probably irrelevant, since most of them are for internal users (who have logged in or are developing software, like privilege escalation problems), or for ports that RainMachine has already turned off. What you are doing is fear-mongering, and I haven't see any facts to back your claim up.
RK also wrote: "I fail to see how all of these gyrations are an improvement over instructing your browser/local machine to trust a given self-signed certificate. ... My suggestion: don't turn off certificate validation. Add the self-signed cert to your trusted exceptions (install your own self-signed cert on the device if you really prefer), and if it ever changes then you'll get a fresh security warning and know something is wrong." Sure, one could do that. If one has only one web client, it is less work than getting a certificate. But the math doesn't work out: in a typical environment, there are way more clients than there are RainMachine. In our household, there is roughly a dozen laptops/desktops/tablets/phones, with about 4 or 5 operating systems, and I would have to add the self-signed certificate to all of them. I already have a certificate for internal machines (that's the wildcard certificate for *.int.example.com), and to use it on the RainMachine all I need to do is to copy it to the RainMachine whenever it gets updated. That is even scriptable and automatable (haven't gotten around to automating it yet, 5 minutes ever 3 months hasn't annoyed me enough yet).
In general, teaching all users to blindly trust certain certificates is dangerous: Once in a while, they will get spoofed. You are better of using the automated trust system, which follows certificate chains back to an authenticated source. Speaking of authentication:
RK also wrote: "Remember, there is nothing magical about the CA's, except their license to print money by virtue of their public keys being included in your OS/browser trust store." That's even more nonsense, although it sometimes contains a grain of truth. Some CAs do charge outrageous fees, and some CAs are very sloppy about authentication. But today there are free CAs (LetsEncrypt is the gold standard there). And they do indeed perform a useful function: They authenticate that the party obtaining the certificate is really in control of the server and/or its DNS (depending on the challenge). While this is not magic, it is the single biggest step in authentication. Sure, I would love it if they did a better job authenticating (check the birth certificate of the person responsible), but that's just not practical.
In summary: Dear RainMachine people, please continue to allow users to upload their own certificates for the https port, don't listen to this buffoon, and consider whether in the future you want to help users automate getting certificates.
I had a few problems like that along the way. First advice: Hopefully, you didn't overwrite the existing files, but saved them, and can just put them back, and then everything should start working again.
There is one funny thing though: the RainMachine needs a certificate file that contains both the private key and the full certificate chain. Here is a cut and paste from my old instructions (notes that I wrote to myself):
Upgrading the certificate on the RainMachine. It needs both the
private key and the full chain certificate:
# cd /usr/local/etc/letsencrypt/live/int.example.com/
# cat privkey.pem fulchain.pem > /tmp/sslCert.pem
# chmod 600 /tmp/sslCert.pem
Then copy it to the two places (only the second is used) on the sprinkler:
# scp /tmp/sslCert.pem $sprinkler:/rainmachine-app/RMNetworkFramework/resources/
# scp /tmp/sslCert.pem $sprinkler:/system/etc/lighttpd/
# rm -f /tmp/sslCert.pem
Note added 20181001: It's important to use fullchain, not just cert, otherwise
the web server on the sprinkler silently fails.
EDIT: I replaced my domain name with "example.com"; the internal house network is int.example.com, and the RainMachine is sprinkler1.int.example.com. Also, the location of the LetsEncrypt certificates in the notes above is for FreeBSD; it is probably different on Linux.
Just discovered something funny. My RainMachine (a HD16) got a firmware upgrade sometime this week. Didn't pay any attention to it, since the darn thing works so well and is so reliable. Sprinkling continued to work just great (did I say it works well?).
This evening I want to log into it quickly, to adjust some sprinkler times. Discover that the certificate I downloaded a while ago has vanished, back to the default self-signed certificate that comes from RainMachine. Not a big deal, just log into my server, and load the correct certificate back in, takes all of 2 minutes.
What do we learn from this? Some RainMachine firmware upgrades will overwrite the certificate! I'm not complaining (it is a reasonable thing to do as part of an upgrade, in particular if the factory-shipped self-signed certificate has changed). But it surprised me. If this happens to you: you have been warned.
The beta updates I've received always removed the cert I put on it. So I would say that Rain Machine needs to make a change. Nothing wrong with them updating the cert, but they should make it available to change the config file(s) to point to the cert you want. This way firmware updates don't modify the cert that is used. There wouldn't be a need to change the file that says what certificate and key to use when they update their own cert, but also stops their cert from being used by those of us who use our own certificate and keys.
Please sign in to leave a comment.