🔐 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.

slampton · February 22, 2026, 1:26am

I ran into this issue. I updated the remote software and was able to complete the HA connection using a domain name and SSL. It threw an error when I didn’t specify :443 as the port, but it still connected.

Unfortunately, the voice assistant is not working when connected via SSL. I disabled SSL in my HA environment temporarily to confirm that this was the cause.

Charles · February 25, 2026, 1:40am

Hi slampton — welcome, and thank you for sharing your findings and testing results. This is very helpful.

First, it’s great to hear that you were able to successfully connect using a domain + SSL after the update, and thank you for noting the port requirement. Your observation about needing to explicitly specify :443 is especially valuable and will help other users who may run into the same behavior.

Regarding the voice assistant not working over SSL:
What you’re seeing is very likely related to how secure connections are currently handled in certain subsystems. While the main Home Assistant connection can now establish successfully over HTTPS, some auxiliary services (such as voice-related communication modules) may still rely on slightly different connection handling or validation logic. That can lead to cases where core control works but voice features fail when SSL is enabled.

The fact that voice works normally when SSL is disabled is actually very useful diagnostic confirmation — thank you for verifying that. We’ll pass this along to engineering as a reproducible scenario tied specifically to secure connections.

Current recommendation (temporary workaround)
Until this is fully addressed, users who rely heavily on voice features may need to:

use a local/internal endpoint for HA voice communication, or
temporarily use a configuration where SSL termination is handled upstream (for example via reverse proxy) while keeping a compatible internal endpoint for the device.

Next steps on our side
We are actively improving:

TLS handling consistency across modules
Domain + certificate validation logic
Error transparency for secure connection failures

Your report directly helps us narrow down edge cases, especially in real HTTPS environments, which are essential for production deployments.

If you’re open to it, once we have a test build addressing SSL-related voice behavior, we’d really appreciate your help validating it.

Thanks again for contributing such clear and practical feedback — this kind of real-world testing is incredibly valuable for improving reliability across different network setups.

slampton · February 27, 2026, 9:24pm

I’m not as confident that I can reproduce the error relating to port 443 being defined or not, but it certainly deserves more testing, but the voice Assistant issue is easy to reproduce. I’m happy to help test a new build that addresses that. Thanks!

Charles · February 28, 2026, 1:31am

Hi @slampton,

Thank you for the quick follow-up — we really appreciate your willingness to help test, that’s extremely valuable.

Reproducibility Notes

No worries at all about the port 443 behavior. Intermittent connection quirks like that can sometimes depend on factors such as:

reverse proxy configuration
certificate chain structure
DNS resolution timing
or even caching at the TLS layer

So it’s completely understandable if it isn’t consistently reproducible yet. We’ll continue investigating that internally as we gather more data points.

Voice Assistant Issue — Confirmed Test Case

Great news (from a debugging perspective):

The voice assistant failing when SSL is enabled but working when SSL is disabled is a clean and reliable test scenario.

That gives engineering a very clear signal path to trace, which significantly speeds up troubleshooting. Issues that are deterministic like this are exactly what help us pinpoint subsystem differences in secure connection handling.

Beta Testing

We’ve noted your interest in testing — thank you again for volunteering. When we have a test build that targets SSL-related voice behavior improvements, we’ll reach out so you can validate it in your environment. Real-world HTTPS setups like yours are especially helpful for verifying fixes before wider release.

Current Status Summary

Domain + SSL HA connection → working
Port requirement behavior → under investigation
Voice assistant over SSL → reproducible issue
Fix → being evaluated by engineering

Thanks again for your patience and for contributing such clear feedback. Reports like yours genuinely help improve reliability for everyone using secure Home Assistant deployments.