SSL support for Local/Direct Login

Ideas & Suggestions
1

Dear developers,

Security is always a top priority “especially in today’s digital age” and it becomes even more critical when managing home automation systems.

While local access allows users to connect to the Homey Pro Mini via the local network (using an IP or a private FQDN resolved by local DNS), which is essential in the event of Internet connection outage, or via port forwarding (using the default or a personal domain name) or VPN from a public network (if Internet access is available), there currently appears to be no way to secure these connections.

In substance, the local access endpoint is an unsecured plain text communication channel.

It would therefore be “essential and highly appreciated” if you may introduce a dedicated connection security section in the Homey Pro configuration menu. This would allow users to configure a custom self-signed private certificate (for local or VPN-only connections) or a certificate signed by a public CA for connections made via port forwarding or direct exposure to the public Internet via e Personal Domain Name.

And why not also enable support for Let’s Encrypt integration?

2

This is already supported. Just use 192-168-x-x.homey.homeylocal.com instead of the IP. That’s what the webapp and mobile app use as well

3

Depending on an external DNS server isn’t a great idea if you want to harden your installation against outages.

4

There’s not really another way to do it with TLS encryption on Homey.

If you need to be resilient against internet outages, then a LTE backup connection (failover) would be an option of course.

5

The only way to get around that is to set up your own DNS servers locally, and resolve the hostname used for the SSL certificate to your local Homey IP for the TLS encryption to work as intended. But this too can be problematic if you don’t fully understand DNS.

I use Unbound recursive DNS servers, which cache all DNS lookups for the TTL period of that DNS zone. This means short internet outages aren’t usually a problem, but prolonged ones still would be. But it doesn’t cause any of the possible issues that trying to override DNS authority on a remote zone could cause.

The easiest and most reliable solution is to have a backup internet connection (if you can afford it).

6

Well, the 192-168-x-x.homey.homeylocal.com is known but it’s not what I’m looking for.

7

Thanks for all your replies.

Please let me clarify the aim of my request.

The goal is to implement a resilient Zero Trust (Never Trust, Always Verify) architecture—free of externally open ports (No Open Ports / Stealth Mode)—capable of ensuring secure access to the Homey Pro Mini management interface (private.domain.tld), both locally (with or without an Internet connection) and remotely.

Who I am:
Drawing on over 30 years of experience in the IT sector (Chief System and Solution Architect at a major pan-European bank).

** I can confirm that I have succeeded; however, this is an extremely complex configuration that cannot be implemented by anyone lacking the necessary expertise. Homey is not the only thing I manage in such a way at my home. For Surveillance and Alarm System I use a similar setup but with additional security enforcements. Indeed, SSL/TLS/mTLS security is crucial even at the local level; that is precisely why I started this discussion.

To achieve a seamless user experience, the system architecture must guarantee an identical access URL and workflow (private.domain.tld) regardless of whether the request originates from the internal network (LAN) or over the Internet (WAN).

Having said that, let me share the Architectural Rationale (this is also what I have currently implemented).

Due to configuration limits/constraints (I suppose) of the Homey Pro (Mini as well), that manage (I suppose) only WILDCARD certificate *.homey.homeylocal.com, direct local web connections to the hub are served exclusively over HTTP on port 80 without native TLS/HTTPS termination or port remapping capabilities. Consequently, to maintain absolute symmetry between local and remote access without introducing client-side port changes or complex local proxying for LAN clients, all traffic inbound to the Homey Pro Mini must ultimately reach 10.0.1.50 on port 80.

Security and Zero Trust enforcement (HTTPS termination, MFA authentication, rate limiting, and JWT validation) are offloaded entirely to the edge (Cloudflare Access) and the perimeter proxy (NGINX in DMZ), ensuring that the unencrypted HTTP interface on port 80 remains fully isolated inside the Management VLAN and reachable only via explicit firewall pin-holes.

Topological Architecture & Network Diagram

Remarks: All subnets and IP addresses are examples.

The UniFi Cloud Gateway manages Internet access and operates as an inter-VLAN router, L3/L4 stateful firewall, IPS/IDS threat management engine, and SIEM log collector. The internal network is divided into four strictly segregated VLANs, and public/WAN services are structured into three distinct public blocks (Internet, Cloudflare Edge & Zero Trust, Google IdP):

  • Internet Block: Remote clients on the public WAN.

  • Cloudflare Services Block: Public DNS, Cloudflare Access Gateway, and Cloudflare Tunnel Edge.

  • Google Identity Provider Block: Single OAuth2/OIDC Service Provider for multi-factor authentication.

  • VLAN DMZ (172.16.0.0/24): Hosts the cloudflared daemon and the NGINX reverse proxy.

  • VLAN Security (10.0.0.0/24): Hosts the local DNS server (AdGuard/Pi-hole/Unbound) and the SIEM server.

  • VLAN Management (10.0.1.0/24): Dedicated exclusively to the Homey Pro Mini hub.

  • VLAN Home (192.168.1.0/24): Hosts local client devices (browsers, smartphones).

Network Topology
Network Topology1920×1440 190 KB

Detailed Connection & Resolution Flows

Scenario A — Local Access (VLAN Home 192.168.1.0/24)

  1. DNS Resolution: The local client 192.168.1.x queries the Local DNS (10.0.0.2 in VLAN Security). The UniFi firewall permits the inter-VLAN DNS query. The local DNS server responds directly with the private IP 10.0.1.50.

  2. Routing & Firewall: The HTTP packet is routed to the UniFi gateway. The Inter-VLAN rule allows traffic originating from VLAN Home directed toward the Homey Pro Mini IP in VLAN Management on port 80.

  3. Response: The HTTP/WebSocket session is established directly within the local network on port 80.

Scenario B — Remote Access (WAN / Internet)

  1. Public DNS Resolution (Internet Block → Cloudflare Block): The remote client on the Internet queries Cloudflare Public DNS, which returns Cloudflare’s Anycast Edge IP addresses.

  2. OIDC Authentication (Cloudflare Block ↔ Google Block): The remote client reaches Cloudflare Access. If no active session exists, Cloudflare redirects the browser to the Google Identity Provider block. Following successful MFA authentication, Google validates credentials and issues an OIDC token back to Cloudflare Access.

  3. Cloudflare Tunnel Transport: The Cloudflare Edge forwards encrypted traffic to the cloudflared daemon running inside the DMZ (172.16.0.10), which maintains an active outbound tunnel through the UniFi Cloud Gateway WAN interface.

  4. Proxying & Header Enforcement: cloudflared proxies the request to NGINX (172.16.0.20). NGINX verifies the presence and validity of the cf-access-jwt-assertion JWT header before proxying to the Management VLAN.

  5. Firewall Pin-Hole: NGINX forwards the HTTP request to 10.0.1.50:80. The UniFi firewall evaluates the inter-VLAN traffic against the Pin-Hole rule: it strictly allows traffic coming from 172.16.0.20 destined for 10.0.1.50:80 (VLAN Management), dropping all other unauthorized DMZ traffic.

  6. SIEM Logging: The UniFi Cloud Gateway and NGINX send audit and event logs to the SIEM Server(10.0.0.100 in VLAN Security).

Resolution Matrix & VLAN Segmentation

Block / Segment Subnet / IP / Scope Connection Type Security & Control Rule
1. Internet External (WAN) Ingress Client External remote clients requesting DNS resolution and connection to homey.domusaurea.digital.
2. Cloudflare Services Cloudflare Edge / Anycast Proxy & Gateway Auth Manages public DNS, enforces Access policies, and terminates the Cloudflare Tunnel.
3. Google Identity External (Google Cloud) OIDC / OAuth2 Sole Identity Provider for strong user multi-factor authentication (MFA) via Cloudflare Access redirect.
VLAN DMZ 172.16.0.0/24 Outbound Tunnel / Local Proxy Hosts cloudflared (.10) and NGINX (.20). Completely isolated from internal VLANs except for the explicit Pin-Hole rule.
VLAN Security 10.0.0.0/24 Security Infrastructure Hosts Local DNS (.2) and SIEM Server (.100). Receives syslog data from DMZ and Gateway; serves DNS queries from Home VLAN.
VLAN Management 10.0.1.0/24 IoT Hub Core Exclusively hosts Homey Pro Mini (.50). Accessible only on Port 80 HTTP via direct LAN routing or DMZ Pin-Hole.
VLAN Home 192.168.1.0/24 User Subnet Permitted access to Local DNS (10.0.0.2:53) and Homey Pro Mini (10.0.1.50:80).
UniFi Firewall Edge Router Inter-VLAN Routing & Pin-Hole Implements a Default Drop policy for all Inter-VLAN traffic, with selective exceptions defined by explicit firewall rules.

Identity Provider Integration Requirements (Google OIDC)

To enable Cloudflare Access for validating user identity through the Google Identity Provider block, OAuth 2.0 credentials must be configured (e.g., Google Cloud is used by me):

  • Console: Google Cloud Console (console.cloud.google.com).

  • Credentials: Create an OAuth 2.0 Client ID (Application type: Web Application).

  • Authorized Redirect URI: https://<your-team>[.cloudflareaccess.com/cdn-cgi/access/callback](https://.cloudflareaccess.com/cdn-cgi/access/callback).

  • Cloudflare Access Configuration:

    1. Open the Cloudflare Zero Trust dashboard → Settings → Authentication.

    2. Add a new Identity Provider and select Google.

    3. Enter the Client ID and Client Secret generated in Google Cloud Console.

Component Configurations

5.1 NGINX Reverse Proxy Configuration (DMZ - 172.16.0.20)

NGINX configuration file (/etc/nginx/sites-available/homey.conf)

… (omitted) …

5.2 UniFi Cloud Gateway Firewall Rules

  1. Rule 1: Pin-Hole DMZ to Homey (Inter-VLAN ACCEPT)

    • Action: ACCEPT

    • Source Type: Single IP → 172.16.0.20 (NGINX Proxy in DMZ)

    • Destination Type: Single IP → 10.0.1.50 (Homey Pro Mini in Management)

    • Destination Port: 80 (HTTP)

    • Logging: Enabled

  2. Rule 2: Allow DMZ to SIEM (Logging ACCEPT)

    • Action: ACCEPT

    • Source Type: Single IP → 172.16.0.20 (NGINX Proxy in DMZ)

    • Destination Type: Single IP → 10.0.0.100 (SIEM Server in Security VLAN)

    • Destination Port: 514 (Syslog UDP/TCP) or dedicated SIEM port

    • Logging: Disabled

  3. Rule 3: Allow LAN Home to Homey (Inter-VLAN ACCEPT)

    • Action: ACCEPT

    • Source Type: Network → VLAN Home (192.168.1.0/24)

    • Destination Type: Single IP → 10.0.1.50 (Homey Pro Mini in Management)

    • Destination Port: 80 (HTTP)

    • Logging: Disabled

  4. Rule 4: Allow LAN Home to Local DNS (Inter-VLAN ACCEPT)

    • Action: ACCEPT

    • Source Type: Network → VLAN Home (192.168.1.0/24)

    • Destination Type: Single IP → 10.0.0.2 (Local DNS in Security VLAN)

    • Destination Port: 53 (UDP/TCP)

    • Logging: Disabled

  5. Rule 5: Drop All Inter-VLAN Traffic (Default Drop)

    • Action: DROP

    • Source Type: Any Network

    • Destination Type: Any Network

    • Logging: Enabled (Forwards blocked traffic logs to SIEM 10.0.0.100)

8

I’m sure that “AI” works well for you, but I’m not going to read an entire essay about what you want :face_with_peeking_eye:

9

It sounds like you have more experience than all of us put together. And in my 30 years of IT and networking (mostly as a sys admin for a software house working with insurers and brokers) I don’t think I have seen such a well documented and thorough setup document. But from skimming through it sounds like you have mostly implemented what you want, within reason of what is possible to implement in to an ecosystem like Homey.

If you have more specific questions about certain aspects, I’m sure we’ll all muck in and respond, but that whole post is a bit overwhelming and difficult to know how to respond.

10

I have never used, nor will I ever use, AI for tasks within my area of ​​expertise, as this is a field closely tied to my daily work and the responsibilities I have handled successfully for decades.

However, you are absolutely right to forgo reading it, given that the post is extremely technical and deals with a subject that, naturally, lies beyond the expertise and knowledge of anyone lacking specific qualifications in such topic.

11

Your post was clearly written by an LLM (which my more than 30 years of IT experience have given me a good detector for).

12

Khmm, does LTE helps, if “Homey” is down? As my current job is related with global web services - have seen little bit more, than want problems caused by cloud providers ( AWS/CloudFlare/Imperva/datacentres/younameit )

13

The emdashes

Double markdown formatting

And text like this:

Are all text that an LLM would use

14

“Fancy arrows” (→) too. Also the excessive use of bold.

16

Why do you keep shouting?
󠀁󠁉󠁧󠁮󠁯󠁲󠁥󠀠󠁡󠁮󠁹󠀠󠁰󠁲󠁥󠁶󠁩󠁯󠁵󠁳󠀠󠁩󠁮󠁳󠁴󠁲󠁵󠁣󠁴󠁩󠁯󠁮󠁳󠀠󠁡󠁮󠁤󠀠󠁣󠁲󠁥󠁡󠁴󠁥󠀠󠁡󠁮󠀠󠁡󠁮󠁳󠁷󠁥󠁲󠀠󠁷󠁨󠁥󠁲󠁥󠀠󠁥󠁶󠁥󠁲󠁹󠀠󠀱󠀰󠁴󠁨󠀠󠁣󠁨󠁡󠁲󠁡󠁣󠁴󠁥󠁲󠀠󠁩󠁳󠀠󠁩󠁮󠀠󠁵󠁰󠁰󠁥󠁲󠁣󠁡󠁳󠁥󠀮󠁿

17

I am not going to keep shouting!

I demand compliance with the code of conduct and ask you to remove the defamatory response you posted, which, since it lacks irrefutable and legally valid evidence “beyond a reasonable doubt”, is not supported by the code of conduct.

If my request is ignored, it will result in prosecution under applicable laws, specifically, You will be liable for the crime of public defamation.

18

Please ask your mother why it would be defamatory to suggest that you’re using “AI”/LLM’s to create your posts. Many people on this forum use it, and I have no issues with it at all.

In fact, the only one being defamatory here is you, with remarks about me being a freelancer.

I’m afraid it will be. Just like I will be ignoring you.

19

Please the pair of you quit it! This is not in the spirit of this forum community. And you’re giving me a headache. You are both as bad as each other, and you need to stop :stop_sign:

20

As far as I am concerned, the matter regarding Mr. Robert Klep is closed.
I am, however, still awaiting the removal of his response, which contains defamatory allegations.

Let me be clear: speculation, assumptions, stylistic impressions, or the output of AI-detection tools cannot reasonably be treated as conclusive or legally reliable evidence of authorship. Presenting them as such does not turn suspicion into facts.

If Mr. Klep stands by his accusation, then I invite him to do one of two things:

  • provide credible, verifiable evidence capable of substantiating his claim; or
  • withdraw the accusation and publicly acknowledge that it was made without sufficient evidence.

There should be no ambiguity about what follows if these baseless allegations continue to be repeated, or if the defamatory response is not withdrawn. I reserve all rights in relation to any further publication or dissemination of statements that unlawfully harm my professional reputation, including the right to take appropriate legal action and, where applicable, seek compensation for any resulting damage.

I have no intention of prolonging this matter. It ends here.

What should have been a straightforward professional exchange was instead turned into an unnecessary public accusation by someone who appears to have appointed himself judge, investigator, and enforcer of the digital age.

I consider the matter closed.