Native TLS for the gRPC endpoint (REST gated) (#2144)

[exzile]

Summary

Implements native TLS/HTTPS for the API endpoints (#2144), so traffic can be encrypted without relying on an external reverse proxy (the NGINX sidecar leaves the NGINX↔OVMS hop in plaintext, which is the gap this issue raised).

gRPC TLS — functional

• New per-protocol CLI params (optional, empty = disabled): --grpc_certificate_path, --grpc_key_path, --grpc_ca_path.
• cert + key → server TLS. Adding --grpc_ca_path → mutual TLS: client certificates are required and verified (GRPC_SSL_REQUEST_AND_REQUIRE_CLIENT_CERTIFICATE_AND_VERIFY).
• grpcservermodule builds grpc::SslServerCredentials from the cert/key/CA. No insecure fallback — a missing/unreadable/empty cert or key aborts startup rather than serving plaintext.

REST TLS — gated (fail-closed) in this build

The same --rest_certificate_path/--rest_key_path/--rest_ca_path params and the Drogon addListener SSL wiring are implemented, but the bundled Drogon is built without OpenSSL and cannot serve HTTPS. To avoid silently serving plaintext on a port an operator believes is encrypted, Config::validate() rejects any REST TLS parameter at startup with a clear error. The wiring is retained so REST HTTPS activates once Drogon is built with OpenSSL (a build-system follow-up). Use gRPC TLS or terminate REST TLS with a proxy in the meantime.

Also

• ServerSettings fields, Config accessors, and C-API setters (OVMS_ServerSettingsSet{Grpc,Rest}{Cert,Key,Ca}Path) in ovms.h.
• Validation (runs on both CLI and C-API start paths): cert/key must be set together; files must exist and be non-empty; CA requires cert+key.
• Private key contents are never logged — only paths appear in logs/errors.
• Docs: parameters.md (new params) and security_considerations.md (gRPC TLS now native; REST via proxy).

Testing

• Unit: config-validation death tests for every cert/key/ca combination, missing/empty files, and the REST-gated rejection; C-API setter coverage; a positive gRPC-TLS config test.

• Server-only TLS handshake (CPU): started a server with gRPC TLS and verified a real handshake with openssl s_client — TLS 1.2, server certificate presented.

• Live mTLS + real inference over TLS (CPU): with an mTLS-configured server (src/test/dummy model), generated a CA, a CA-signed server cert (CN=localhost + SAN), a CA-signed client cert, and an untrusted client cert (different CA), then ran real gRPC/KFS inference for three cases:

  Case	Expected	Result
  Client presents CA-signed cert	inference succeeds	✅ correct output returned over the encrypted channel
  Client presents no cert	rejected at handshake	✅ rejected
  Client presents untrusted cert (different CA)	rejected at handshake	✅ rejected

  Server-side handshake logs confirm the rejection reasons, i.e. that REQUIRE_AND_VERIFY enforces both the require and the verify:

  Handshake failed ... SSL_ERROR_SSL: ...PEER_DID_NOT_RETURN_A_CERTIFICATE   # no client cert -> required
  Handshake failed ... SSL_ERROR_SSL: ...CERTIFICATE_VERIFY_FAILED          # untrusted cert -> verified against CA
  

  This proves mTLS genuinely enforces at runtime and that a real inference request completes end-to-end over the TLS channel — not just the handshake.

• Security review: no plaintext fallback when TLS is requested; mTLS genuinely enforces; no key material in logs; validate() not bypassable.

• REST TLS is intentionally untested beyond the startup-rejection unit test, since it is gated/fail-closed in this build pending a Drogon-with-OpenSSL build.

Notes

• This delivers the gRPC half of Enabling HTTPS end points on OpenVINO Model server #2144 now; REST HTTPS is gated behind enabling OpenSSL in the Drogon build (kept fail-closed so there's no false sense of encryption). Happy to follow up with the Drogon-OpenSSL build change if maintainers want native REST HTTPS.
• No automated CI on fork branches here; verified via local Windows/MSVC build + tests.