Trust custom root CA certificate for Home Assistant HTTPS/WSS connections

[Copilot]

Home Assistant instances secured by a locally-issued certificate were untrusted because there was no way to supply the root CA. This adds an optional CertificateAuthorityPath configuration field that, when set, validates both HTTP and WebSocket connections against the specified CA rather than bypassing validation entirely.

Changes

• HomeAssistantOptions — adds optional string? CertificateAuthorityPath
• Bootstrap.cs — registers a named HttpClient ("HomeAssistant") with a custom HttpClientHandler; when the CA path is set, uses X509ChainTrustMode.CustomRootTrust to validate against the provided cert instead of the system store
• HomeAssistantConnector — switches from injected HttpClient to IHttpClientFactory + named client (correct pattern for singletons)
• HomeAssistantMonitor — loads the CA cert once as a field at construction; sets ClientWebSocket.Options.RemoteCertificateValidationCallback for WSS connections
• TgHomeBot.SmartHome.HomeAssistant.csproj — adds Microsoft.Extensions.Http package reference

Configuration

"HomeAssistant": {
  "BaseUrl": "https://homeassistant.local",
  "Token": "<token>",
  "CertificateAuthorityPath": "/certs/local-ca.crt"
}

Leave CertificateAuthorityPath empty or omit it to retain existing behaviour. Certificate is loaded via X509CertificateLoader.LoadCertificateFromFile (non-deprecated .NET 9+ API).

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Trust custom root certificate</issue_title>
<issue_description>I have a local Certificate authority that issued the SSL certificate of home assistant. Add a awy to add the root certificate so that the home assistant certificate is trusted.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Trust custom root certificate #51

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Copilot]

Pull request overview

This PR adds support for trusting a user-supplied custom root CA certificate for Home Assistant HTTPS and WebSocket connections, enabling secure connections to locally-issued TLS endpoints without disabling certificate validation.

Changes:

• Add CertificateAuthorityPath to HomeAssistantOptions and expose it in API configuration.
• Register a named HttpClient with a custom HttpClientHandler to validate server certs against a custom root CA when configured.
• Update Home Assistant HTTP connector to use IHttpClientFactory and add WebSocket remote certificate validation support.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
TgHomeBot.SmartHome.HomeAssistant/TgHomeBot.SmartHome.HomeAssistant.csproj	Adds Microsoft.Extensions.Http dependency needed for AddHttpClient/IHttpClientFactory.
TgHomeBot.SmartHome.HomeAssistant/HomeAssistantOptions.cs	Introduces optional CertificateAuthorityPath configuration.
TgHomeBot.SmartHome.HomeAssistant/Bootstrap.cs	Configures named HttpClient with custom server certificate validation using a custom root CA.
TgHomeBot.SmartHome.HomeAssistant/HomeAssistantConnector.cs	Switches from injected HttpClient to IHttpClientFactory + named client.
TgHomeBot.SmartHome.HomeAssistant/HomeAssistantMonitor.cs	Loads custom CA once and sets RemoteCertificateValidationCallback for WebSocket connections.
TgHomeBot.Api/appsettings.json	Adds CertificateAuthorityPath setting to default configuration.

Comments suppressed due to low confidence (1)

TgHomeBot.SmartHome.HomeAssistant/HomeAssistantConnector.cs:76

• HttpRequestMessage/HttpResponseMessage are IDisposable, but neither is disposed here. In a long-running service this can contribute to resource pressure (especially if exceptions occur before content is fully read). Consider using using/await using (or using var) around the request/response objects.

        var message = new HttpRequestMessage(method, url);
        message.Headers.Authorization = new AuthenticationHeaderValue("Bearer", options.Value.Token);

        var httpClient = httpClientFactory.CreateClient(HttpClientName);
        var response = await httpClient.SendAsync(message);

        response.EnsureSuccessStatusCode();

        return await response.Content.ReadAsStringAsync();

[Copilot]

_caCertificate is loaded once and stored on the monitor, but it is never disposed in Dispose(). Since X509Certificate2 holds unmanaged resources, consider disposing _caCertificate when the monitor is disposed to avoid leaking handles in long-running processes.

[Copilot]

The custom certificate validation callback accepts the certificate whenever chain.Build(cert) succeeds, even if SslPolicyErrors includes RemoteCertificateNameMismatch (hostname mismatch). This can disable hostname verification when a custom CA is configured. Consider only overriding validation when the only error is RemoteCertificateChainErrors, and explicitly rejecting name-mismatch / not-available cases.

[Copilot]

LoadCertificateFromFile creates an X509Certificate2 that holds unmanaged resources, but the instance is captured by the validation callback and never disposed. Also, because this runs per-handler creation, the CA cert can be reloaded repeatedly (file IO + allocations). Consider loading/caching the CA certificate once (e.g., as a singleton) and reusing it for both HTTP and WebSocket validation, with a clear ownership/disposal strategy.

[Copilot]

The WebSocket certificate validation callback has the same issue as the HTTP one: when errors != None it returns chain.Build(...) without preserving hostname verification. If SslPolicyErrors includes RemoteCertificateNameMismatch, this would still return true as long as the chain builds. Only override chain validation when the only failure is RemoteCertificateChainErrors, and fail closed for other SSL policy errors.

Also note that the current URI construction in this method always prefixes with ws (not wss), so when BaseUrl is https://... this callback may never run because the connection would be attempted over plain WS.

[Copilot]

RemoteCertificateValidationCallback provides cert as X509Certificate, so the direct cast to X509Certificate2 can throw at runtime on platforms where the runtime doesn’t pass an X509Certificate2 instance. Consider converting safely (e.g., creating a new X509Certificate2(cert) or using as with a fallback) before calling chain.Build(...).

Suggested change

	return chain.Build((X509Certificate2)cert);
	var certificate = cert as X509Certificate2 ?? new X509Certificate2(cert);
	return chain.Build(certificate);