bug: Generated CA certificate is missing keyUsage extension (rejected by Python 3.14 / OpenSSL strict mode)

[a-erta]

Pre-flight checks

• I updated to the latest add-on version and restarted it.
• I checked the docs/troubleshooting section first.

What happened?

The self-signed CA certificate generated by the addon in lan_https mode (/addon_configs/<slug>/openclaw-ca.crt) is missing the X.509 keyUsage extension. This violates RFC 5280 §4.2.1.3 for CA certificates and causes Python 3.14 with OpenSSL strict-mode (default in current HA Core) to reject the CA outright, regardless of whether it's been added to the trust store.

Inspecting the generated CA:
openssl x509 -in /addon_configs//openclaw-ca.crt -noout -text

shows no X509v3 Key Usage extension. A valid CA should include at least Key Usage: Certificate Sign, CRL Sign with the critical flag set, per RFC 5280.

The practical impact is that lan_https mode is unusable with any HTTP client that uses Python 3.10+ default strict X.509 validation — most notably the companion HACS integration (OpenClawHomeAssistantIntegration) when Verify SSL certificate is enabled. Adding the CA to both /usr/local/share/ca-certificates/ (via update-ca-certificates) and Python's certifi bundle inside the HA Core container does not help, because the CA itself is malformed.

What did you expect to happen?

The CA certificate generated by the addon should include the X.509 extensions required for CA certificates by RFC 5280, at minimum:

• basicConstraints = critical, CA:TRUE
• keyUsage = critical, keyCertSign, cRLSign
• subjectKeyIdentifier = hash
• authorityKeyIdentifier = keyid:always, issuer

Similarly, the server certificate signed by this CA should declare extendedKeyUsage = serverAuth.

With proper extensions, the CA could be trusted by HA Core's Python TLS stack after being added to the trust store, allowing lan_https mode to work end-to-end with the HACS integration.

Steps to reproduce

1. Install the OpenClaw Home Assistant add-on (latest version)
2. Set access_mode: lan_https and gateway_bind_mode: lan in the addon configuration
3. Restart the add-on — it generates /addon_configs/<slug>/openclaw-ca.crt
4. Inspect the generated CA:
   openssl x509 -in /addon_configs/<slug>/openclaw-ca.crt -noout -text
   Observe that no X509v3 Key Usage extension is present
5. Copy the CA into the HA Core container trust store:
   docker exec homeassistant cp /config/openclaw-ca.crt /usr/local/share/ca-certificates/
docker exec homeassistant update-ca-certificates
docker exec homeassistant sh -c 'cat /config/openclaw-ca.crt >> /usr/local/lib/python3.14/site-packages/certifi/cacert.pem'
ha core restart
6. From the HA Core container, attempt a TLS handshake against the gateway:
   docker exec homeassistant python3 -c "import ssl, socket, certifi; ctx=ssl.create_default_context(cafile=certifi.where()); s=socket.create_connection(('',18789),timeout=5); ss=ctx.wrap_socket(s,server_hostname=''); print(ss.getpeercert())"
7. Observe the failure:
   ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: CA cert does not include key usage extension (_ssl.c:1081)

Add-on version

0.5.27

OpenClaw version (if known)

2026.5.28 (e932160)

Access mode

lan_https

Relevant add-on configuration (redacted)

timezone: Europe/Rome
enable_terminal: true
terminal_port: 7681
gateway_public_url: ""
homeassistant_token: "<redacted>"
http_proxy: ""
clean_session_locks_on_start: true
clean_session_locks_on_exit: true
persist_node_global: false
persist_brew_tools: false
gateway_mode: local
gateway_remote_url: ""
gateway_bind_mode: lan
gateway_port: 18789
access_mode: lan_https
gateway_auth_mode: token
gateway_trusted_proxies: ""
gateway_additional_allowed_origins: ""
controlui_disable_device_auth: true
enable_openai_api: true
force_ipv4_dns: true
nginx_log_level: minimal
gateway_env_vars: []
auto_configure_mcp: false

Add-on logs

2026-06-01T10:52:35.252+02:00 [gateway] loading configuration…
2026-06-01T10:52:35.397+02:00 [gateway] resolving authentication…
2026-06-01T10:52:35.518+02:00 [gateway] starting...
2026-06-01T10:52:46.056+02:00 [gateway] starting HTTP server...
2026-06-01T10:52:46.433+02:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-06-01T10:52:52.314+02:00 [gateway] agent model: anthropic/claude-sonnet-4-6 (thinking=adaptive, fast=off)
2026-06-01T10:52:52.329+02:00 [gateway] http server listening (9 plugins: browser, canvas, device-pair, duckduckgo, file-transfer, memory-core, phone-control, talk-voice, whatsapp; 16.8s)
2026-06-01T10:53:02.033+02:00 [gateway] ready

(Add-on starts cleanly. The issue is in the certificate generation logic, not the runtime. Inspecting the generated CA shows the missing keyUsage extension.)

Python 3.14 verification error from HA Core container:
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] 
  certificate verify failed: CA cert does not include key usage extension (_ssl.c:1081)

Additional context

Related issue filed against OpenClawHomeAssistantIntegration: techartdev/OpenClawHomeAssistantIntegration#32

A related bug in the HACS integration (the Verify SSL certificate: false flag is ignored in the manual config flow) means users currently cannot work around this CA bug by simply disabling verification. The combination of these two bugs makes lan_https mode unusable with the HACS integration.

Workaround currently in use: access_mode: custom + gateway_bind_mode: lan to expose plain HTTP on the Supervisor bridge network.