Problem installing server certs on the RIO

Has anyone else seen net::ERR_ACCESS_DENIED errors while installing SSL certs on the RIO? I’m really wanting to crack the code and not have my browser say the site is a security risk.

The attached image has the full story. Some items about it:

Any ideas why I’m unable to upload that certificate? I get no error response, just that the certificate hasn’t been uploaded.

Thank you

I have been able to upload a test certificate without issue. I haven’t tried a LetsEncrypt one, since I don’t want to have to do that manually every 90 days - I would want an acme client for that.

Since you are getting a lower level access denied, by any chance do you have a password on the key file?

I’m not sure if the key file has a password, but will look into it. This seems to be happening at the network level during certificate upload, long before the certificate is in place at the network level.

If the server had an issue with the certificate I’d predict an HTTP response vs. a network level error. It seems like the request never made it to the server.

I’ll try with a self-generated certificate per the docs.

I’m with you on not wanting LetsEncrypt frequent refresh, but I don’t want my customers to install anything in their browser or O/S keychain to add a trusted authority. If you know of a way around this, I’m all ears!

FYI - I tried a LetsEncrypt cert that was for one of my servers on the RIO and it took it without issue as well.

As far as managing certs: (tldr - I don’t have a good answer)

  1. You could get a paid cert from a public CA, but that will cost money, and will expire in 1 year.
  2. You could get an internal certificate from IT that is signed by a CA that is trusted by the clients.
  3. You could run a reverse proxy that handles LetsEncrypt duties with an ACME client.

It is certainly possible for Opto to add the ability to obtain and renew LetsEncrypt certificates, but in your case (and most others too) you don’t have public access to the device, so the HTTP challenge verification step would fail. DNS challenge could work, as long as IT gives the RIO / EPIC access (probably unlikely) to the DNS API, if available.

Definitely a thorny issue. Our clients aren’t sophisticated, and we need a solution that works for all network infrastructure. We’re building the certificate on our server so LetsEncrypt can certify our domain ownership, then installing it on the RIO.

DNS is another story all together. We’re adding DNS entries for our customers’ opto22 controllers as subdomains of our domain, and pointing to their internal IP address. This will only work if the client is in their network or VPN.

All of this is done via outbound calls from the Opto22 controller, so we’re not blocked by inbound security. Really a mess, but worth it so our communications are secure and our customers don’t get that scary browser security warning.

Won’t help on the RIO without shell access, but may be worth trying on a PR1 to install certbot and seeing if you can get it to use DNS challenge with your DNS server (if your DNS host has an API for it). If that works, then petition Opto for shell access to the RIO or to include certbot as part of the firmware.

RESOLVED: Turns out, generating the certificate wasn’t the problem. It was a stupid mistake where net::ERR_ACCESS_DENIED was the browser telling me it didn’t have permission to read the root owned certificate created by LetsEncrypt. Once I changed permissions on the cert files I was able to upload.

Thank you for your input on this.

postscript: Certbot is only one piece of the puzzle, and running it on the groov is doomed because it relies on inbound connections. Inbound connections are the biggest issue with varying network infrastructure. Some customers are home users with a comcast router, others are businesses with who knows what ISP, and very few have an IT department capable of, or willing to configure inbound connections for critical OT infrastructure.

Yet… They all want secure communications to their RIO/EPIC without configuring certificates or seeing scary warnings that they don’t understand.

That’s the issue that we’re working to resolve. Once we get it working I’ll share what we had to do, because I have to think this is a thorn in your side more often than not. I would think it’s valuable for Opto22 to resolve this vs. Opto22 resellers. It’s a fairly complex issue that not all resellers could tackle.

This resolves the HTTPS issue as well as the issue of finding the IP address on your internal network. Wouldn’t it be nice to tell your customers to plug in the RIO, wait a minute or two, then put the following into their browser (or QR code from a sticker on the EPIC/RIO):

https://04-91-ee.opto22.com

No finding the local IP, no certificate management, no browser security messages, just clean https connections. Requires an internet connection for DNS, and only works on the internal network because the registered IP address is internal.

Certbot does support DNS challenge, which should avoid needing an inbound connection to the RIO/PR1. The only inbound connection for verification would be to the DNS server. However the RIO/PR1 would need to be able to update a TXT record on the DNS server during the certificate issuance and renewal. Common DNS hosting services have an API for this.

Yes, you’re right about DNS challenge. Wouldn’t it be sweet if the controller called a service on the opto22 domain that did this whenever the IP address changed or the certificate is in need of renewal, installing the cert from the service?

By the way, it’s working like a charm. Typed the url into my phone, and it found the RIO and went straight to the login screen. Smooth as silk!