Add TLS Support to integrations

[afscrome]

Related to an existing integration?

Yes

Existing integration

Community Toolkit hosting integrations that expose TLS-capable server endpoints, particularly RavenDB, SeaweedFS, RustFS, SurrealDB, KurrentDB, LavinMQ, Posta, Meilisearch, Solr, and Redpanda.

Overview

The toolkit should make use of Aspire's recently added certificate APIs for configuring resources to use TLS via the development certificate. Aspire now provides WithHttpsCertificateConfiguration, WithHttpsDeveloperCertificate, WithHttpsCertificate, and related certificate trust APIs so integrations can consume Aspire-provisioned certificate and key material rather than requiring integration-specific file paths or remaining HTTP-only.

An audit of the current hosting integrations identified the following candidates:

Priority	Integration	Current state	Recommended direction
High	RavenDB	Secured mode accepts a certificate path/password manually and maps them to RAVEN_Security_Certificate_Path, but is not connected to Aspire certificate annotations.	Add WithHttpsCertificateConfiguration support so WithHttpsDeveloperCertificate() and WithHttpsCertificate(...) supply the server certificate. Preserve the existing secured settings API for custom or Raven-managed certificates.
High	SeaweedFS	Master, Volume, Filer, and S3 APIs are exposed as HTTP endpoints with no Aspire certificate mapping.	Map Aspire certificate/key paths to SeaweedFS TLS configuration and consistently update the affected endpoint schemes.
High	RustFS	The S3 API and console are exposed over HTTP without certificate plumbing.	Map Aspire-provisioned certificate material to supported RustFS settings and update both endpoint schemes, health checks, and client behavior.
Medium	SurrealDB	The server endpoint and startup initialization assume the default non-TLS scheme.	Map certificate/key paths to native SurrealDB TLS flags and update connection strings and initialization to use HTTPS/WSS.
Medium	KurrentDB	The endpoint is HTTP and the container explicitly sets KURRENTDB_INSECURE=true.	Add an opt-in secure configuration, updating the health check and generated kurrentdb:// connection string together.
Medium	LavinMQ	AMQP and management endpoints have fixed non-TLS schemes.	Treat AMQPS and HTTPS management independently and map Aspire certificate material to both where supported.
Medium	Posta	Inbound SMTP already accepts PEM certificate/key paths, but callers must provide paths manually.	Allow Aspire-provisioned certificate material to configure inbound STARTTLS. This is protocol TLS and should not be represented as an HTTPS endpoint.
Investigate	Meilisearch, Solr, Redpanda	These integrations expose HTTP endpoints without Aspire certificate configuration.	Verify the supported image/version-specific server TLS settings. Redpanda requires separate handling for Kafka TLS and Admin API HTTPS.

Zitadel, OpenTelemetry Collector, and Floci already use WithHttpsCertificateConfiguration and provide useful implementation patterns. K3s should continue using its Kubernetes-generated CA and server certificates. Existing JavaScript, Perl, and MCP Inspector certificate integration is primarily outbound certificate trust rather than server TLS.

Implementation should distinguish:

• Server authentication for HTTP endpoints through Aspire's HTTPS certificate APIs.
• Protocol-specific TLS such as AMQPS, MQTT TLS, Kafka TLS, and SMTP STARTTLS.
• Outbound certificate trust through WithDeveloperCertificateTrust, WithCertificateAuthorityCollection, and related trust APIs.

Reference: https://aspire.dev/app-host/certificate-configuration/

Usage example

var builder = DistributedApplication.CreateBuilder(args);

var database = builder.AddRavenDB("database")
    .WithHttpsDeveloperCertificate();

var storage = builder.AddSeaweedFS("storage")
    .WithS3()
    .WithHttpsDeveloperCertificate();

builder.AddProject<Projects.Api>("api")
    .WithReference(database)
    .WithReference(storage)
    .WithDeveloperCertificateTrust(true);

builder.Build().Run();

The same integrations should also work with a caller-provided certificate:

var certificate = new X509Certificate2("server.pfx", "password");

builder.AddRustFs("storage")
    .WithHttpsCertificate(certificate);

Breaking change?

No

Alternatives

Users can currently bind-mount certificate files and configure integration-specific environment variables, command-line options, or settings objects. Some integrations, such as RavenDB and Posta, expose manual certificate path properties. This duplicates certificate provisioning logic, does not integrate naturally with the Aspire development certificate, and makes cross-resource trust harder to configure consistently.

Additional context

The work can be delivered incrementally per integration. RavenDB, SeaweedFS, and RustFS are the clearest first candidates because they already expose server endpoints and either have existing certificate settings or well-defined HTTP API surfaces. Each implementation should include resource model tests that verify certificate annotations, generated environment variables or arguments, endpoint schemes, and behavior when no certificate is selected.

Help us help you

No, just wanted to propose this