🔐 Security discussion: tokens, access control & remote access

Charles · December 22, 2025, 8:31am

Let’s discuss security best practices:

Long-lived access tokens
Token rotation
Multi-remote setups
Remote access risks

This is a technical discussion, not general usage.

troy · February 4, 2026, 7:05am

Environment

Sanytron Remote: Astrion
Sanytron Firmware: 1.0.38 / 2025111416
Home Assistant: Running with HTTPS enabled (via reverse proxy)
Network: Enterprise network with security policies

Issue Summary

I’m unable to configure the Sanytron remote to connect to my Home Assistant instance. The remote appears to have two separate issues with URL handling.

What I’ve Tried

1. Using Domain Name URL

URL entered: https://homeassistant.example.com/api/
Result: INVALID_URL_FORMAT error

The remote rejects any URL containing a domain name. Only IP addresses appear to be accepted.

2. Using IP Address with HTTPS

URL entered: https://[REDACTED_INTERNAL_IP]/api/
Result: Connection fails (TLS certificate error)

This fails because the SSL certificate is issued for the domain name, not the IP address. This is expected behaviour for properly configured HTTPS.

3. Using IP Address with HTTP

Not possible - Home Assistant server only accepts HTTPS connections (as it should for security).

The Problem

The remote creates an impossible situation:

URL Type	Protocol	Result
Domain name	HTTPS	`INVALID_URL_FORMAT`
IP address	HTTPS	TLS certificate mismatch
IP address	HTTP	Server doesn’t support HTTP

Note on redacted information: Internal IP addresses and domain names have been redacted for security. These are valid, correctly formatted addresses - the redaction is not masking malformed input.

Network Context

Our network implements standard enterprise security practices, including:

Blocking outbound connections to known telemetry/tracking services (“phone home” blocking)
DNS filtering for IoT devices
HTTPS-only internal services

The remote can reach internal services (we’ve verified network connectivity), but the URL parsing/TLS handling prevents successful connection to Home Assistant.

Questions

Is there a firmware update that adds support for domain names in URLs?
Are there alternative integration methods (local API, different URL format)?

Device Information

The remote broadcasts itself as an Android device via mDNS. If helpful for diagnostics, I can provide additional network-level information about what the device is attempting to connect to.

Charles · February 6, 2026, 6:22am

“Cannot Connect to Home Assistant via HTTPS – TLS / URL Issues”

Replying as Sanytron team

Hi Troy, welcome to the community — and thank you for such a clear, well-structured report. This is very helpful for diagnosis.

First, we want to acknowledge that your analysis is correct. The situation you described does indeed create a dead-end configuration when Home Assistant is deployed using HTTPS with a domain-based certificate, which is a very common and correct security setup.

Let me respond point by point.

Current behavior (confirmed)

At the moment, Astrion’s HA connection logic has the following limitations:

Domain names in the HA URL

Currently, the URL parser only accepts IP-based formats
Domain-based URLs (even when valid) may trigger INVALID_URL_FORMAT
This is a known limitation in the current implementation

HTTPS with IP address

As you correctly noted, TLS certificates issued for a domain will fail validation when accessed via raw IP
The TLS failure you observed is expected and standards-compliant behavior

HTTP fallback

Astrion does not downgrade HTTPS to HTTP
If HA is HTTPS-only (as it should be), HTTP is not a viable workaround

So yes — in enterprise or security-focused environments, this combination currently makes it impossible to complete the connection. Your summary table accurately reflects the problem.

Why this exists (context, not an excuse)

Some of these constraints originate from:

Early-stage assumptions around local-network HA deployments
Simplified URL validation logic
Conservative TLS handling choices made before broader enterprise use cases emerged

Your report clearly shows that these assumptions no longer hold for many advanced users.

What we are doing next

Your feedback has been recorded and escalated internally, and we are actively discussing improvements in the following areas:

Support for domain-based HA URLs
Improved HTTPS / TLS handling
Clearer validation and error reporting during connection setup

At this stage, we can’t yet commit to a specific release version or timeline, but this issue is now formally tracked and recognized as a real limitation, not a configuration mistake on your side.

Alternative integration paths (short term)

At present:

There is no separate local API or alternative URL format that bypasses this limitation
mDNS visibility alone is not sufficient to complete authenticated HA pairing

If you’re willing to share additional diagnostics (for example, TLS handshake behavior or connection attempts observed at the network level), that information would be genuinely useful and welcome.

Thanks again for the professional and responsible way you raised this. Reports like yours directly influence how we evolve Astrion beyond simple home networks and into more secure, real-world deployments.

We’ll update the forum once we have concrete progress on this topic.

ajguerre · February 8, 2026, 4:15pm

Hi Sanytron team,

I have the same setup with a domain-based HA URL using HTTPS with a valid SSL certificate. This isssue is preventing me to consider the Astrion remote for all my HA projects. I really think this remote is the best implementation of HA remote control in the market right now, but this issue will prevent professional smart home projects from using the Astrion. Please give this issue a higher priority in order to enable the connection between HA and Astrion via HTTPS using a domain-based HA URL with a valid SSL certificate.

Best regards,

Alvaro

jcholewa · February 8, 2026, 9:24pm

I’m also affected by this. Not a business, just a regular customer, but using https and a dynamic dns is the only easy(-ish) way to access my smart home from my phone when I’m away from home.

It’s been way too long since I did any proper programming (so apologies for the backseat driving), but I know that libcurl has options to ignore SSL security checks. For example, the curl command to my https://192.168.1.175:8123 HA box gives an SSL error (“no alternative certificate subject name matches target ipv4 address”), but running «curl --insecure https://192.168.1.175:8123» pulls the page. I think maybe that the documentation at “https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html” could be relevant.

But even if you’re using a different library, there’s likely a similar means to do the same thing. And obviously it’s a terrible idea to make this a default on an in-production product, but I’d really like it if there were a switch somewhere I could use to make this a voluntary insecure option, even with lots of “Are You Sure” dialogs to click past. Until this, my Astrion is just a useless slab laying on a coffee table.

Anyway, don’t know if there’s anything I can do to really help. I could paste outputs from curl on my laptop (–verbose does give some TLS handshake details), but no clue if that’s actually useful.

Charles · February 9, 2026, 2:44am

@jcholewa @ajguerre
Hi Alvaro, jcholewa, and everyone following this thread,

Thank you very much for taking the time to explain your setups and concerns so clearly. We want to be very direct here: this is an important issue, and we fully understand why it blocks both professional projects and advanced Home Assistant users.

Acknowledgement & priority

You are absolutely right that:

Domain-based Home Assistant URLs
HTTPS-only setups
Valid SSL certificates
are standard practice today — especially in enterprise networks, professional smart home deployments, and remote-access scenarios.

This limitation is not acceptable long-term, and we have already elevated this internally as a high-priority item.

Current status (what’s happening today)

At the moment, Astrion:

Performs strict URL format validation
Enforces TLS certificate verification
Does not yet accept domain-based URLs in the HA endpoint configuration

This combination unfortunately creates exactly the “impossible triangle” that Troy and others described earlier:

Domain + HTTPS → rejected at URL validation
IP + HTTPS → certificate mismatch
HTTP → not allowed (and correctly so)

So yes — you’re seeing a real limitation, not a misconfiguration on your side.

About the “insecure / ignore TLS errors” suggestion

jcholewa, thank you for the concrete example and for referencing libcurl options — that’s helpful context.

From a product and security standpoint:

We cannot enable “ignore SSL verification” as a default behavior
We do understand the request for an explicit, opt-in, advanced setting, clearly marked as insecure, for controlled environments

This approach is currently under discussion internally, including:

Whether it should be hidden behind an advanced / developer toggle
How to ensure users fully understand the security implications
How this interacts with future OTA updates and platform compliance

No promises on the final form yet — but the idea itself is reasonable and noted.

What we are actively working on

The engineering team is currently evaluating:

Proper domain name support in HA endpoint configuration
Improved TLS handling, including correct hostname validation
Clearer error reporting, so failures are easier to diagnose
How to support professional / enterprise HA deployments without compromising baseline security

Once an implementation plan is finalized, we will:

Post an official update in the forum
Clearly document supported configurations
Explain any limitations or required setup steps

Thank you (genuinely)

We also want to say this clearly:
The level of feedback in this thread is exactly what helps us mature Astrion from an enthusiast product into something that can be confidently used in professional smart home projects.

Your points are well-argued, technically sound, and taken seriously — this is not being brushed aside.

If anyone is willing to:

Test beta firmware later
Share anonymized TLS handshake logs
Or validate fixes in real HTTPS/domain environments

…that will be extremely helpful, and we’ll reach out when we’re ready.

Thank you again for your patience and for holding us to a high standard.