Alias domain for devices on resindevice.io


#1

We’d like the ability to alias our devices on the public resindevice.io to our own subdomain, eg. so we can use a wildcard ssl cert - when we did this we ended up with a 404 error, any ideas why this would be?


#2

Hi, can you tell a bit more about what you were doing, how are you setting things up, so we can understand/replicate the issues better?


#3

Hey,

If you look at it, you’ll see that the subdomain on device urls is the device UUID. We use this to locate the device on the VPN. If you send a request using a different domain, we won’t be able to locate the device. Even if we identified the device in some other way, you’d still get a TLS error because we wouldn’t have your cert and be capable of terminating the traffic.

To do what you want, you need to set up a reverse proxy where you terminate your own TLS (wildcard or otherwise) and the proxy the request to the device URL as an HTTPS request as normal. This would put the burden on you to somehow extract/translate the UUID out of whatever request your proxy receives and convert it to the subdomain we expect.

I hope that’s helpful. If you need more details or examples let us know, and we could extend our docs to support this use case.

Jack


#4

hey Jack (good Name FYI)

we had spotted that and had Just tried to CNAME a domain we have to resindevice.io and passing the Device UUID intact. we had a Public DNS CNAME record for .example.com to .resindevice.io and no joy not even an invalid Common Name error from the Cert. I’ll retest as i need to get the CNAME reinstated as we have replaced that device now.

Ideally we would do this in production with a DNAME record.

i can see the reasoning behind using a reverse proxy but i would really like to see at least TLS Client Auth on the inside of the reverse proxy to resindevice.io TLS Server. sadly though that wouldn’t answer my concerns on Open https via public URL

The ability to do that and use a DNAME would be a graceful solution to accessing devices’s web interface as an end/nontech user. all without having to worry about things like inward permissions and NAT Traversal that are the standard on most networks today.

Jack