Before investigating complicated application behavior, verify three basic dependencies:
DNS
certificate trust
system time
Failures in these areas can make a healthy application appear completely unreachable.
DNS
The endpoint must be able to resolve the remFREE hostname.
The primary service hostname is:
rmm.remfree.com
On Windows PowerShell:
Resolve-DnsName rmm.remfree.com
On Linux:
getent hosts rmm.remfree.com
or:
dig rmm.remfree.com
If name resolution fails, HTTPS and WSS cannot reliably reach the intended service.
Test the resolved destination
If DNS resolves, verify that the endpoint can establish HTTPS communication.
Linux example:
curl -I https://rmm.remfree.com
PowerShell example:
Invoke-WebRequest https://rmm.remfree.com -Method Head
This helps distinguish name-resolution failure from higher-layer connectivity problems.
Certificate trust
TLS depends on certificate validation.
A client must be able to build a trusted certificate chain for the service it is contacting.
Failures can be caused by:
- missing trusted root certificates
- TLS inspection
- incorrectly configured inspection certificates
- expired certificates
- certificate name mismatch
- incorrect system time
TLS inspection
When an organization performs TLS inspection, the endpoint may see a certificate issued by the organization's internal inspection authority.
The machine must trust that authority.
A browser working successfully does not always prove that the service account or agent runtime uses exactly the same certificate environment.
System time
Certificate validation depends heavily on time.
If an endpoint's clock is far from reality, a valid certificate can appear to be:
- not yet valid
- expired
Authentication systems can also behave incorrectly when clocks differ significantly.
Check the operating-system time before spending hours debugging higher layers.
Windows time check
Useful PowerShell commands include:
Get-Date
and:
w32tm /query /status
Linux time check
Useful commands include:
date
and on systemd-based systems:
timedatectl
Look at the entire trust path
A remFREE connection depends on more than the destination server.
Conceptually:
Agent
|
v
Local DNS
|
v
Network path
|
v
Proxy / inspection if present
|
v
TLS validation
|
v
remFREE
A failure at any layer can appear to the application simply as:
connection failed
Start simple
When diagnosing an endpoint that suddenly cannot connect:
- Verify the clock.
- Verify DNS.
- Verify HTTPS.
- Verify certificate trust.
- Verify WSS behavior.
- Then investigate remFREE-specific application state.
Starting with fundamentals prevents application troubleshooting from becoming a search for problems that do not actually exist.