Go starter: pre-start go mod tidy fails TLS validation on macOS with Go 1.27 #22221

Is there an existing issue for this?

• I have searched the existing issues

Related to #21198, which is closed. The Go application already uses the platform-specific trust default, but its pre-start module resource does not.

Describe the bug

Dogfooding the Go starter template with the latest Aspire 17.0 staging build on macOS, the pre-start go mod tidy -e command fails to download dependencies from proxy.golang.org with x509: certificate signed by unknown authority.

The generated AppHost uses:

app := builder.AddGoApp("app", "./api").
    WithModTidy().
    WithHttpEndpoint(aspire.HttpEndpointEnv("PORT")).
    WithHttpHealthCheck(aspire.HttpHealthCheckPath("/health")).
    WithExternalHttpEndpoints().
    WithOtlpExporter()

The failure affects starter startup and is not specific to one dependency: Redis and OpenTelemetry downloads fail in the same way.

Expected Behavior

Pre-start Go commands should preserve trust in system/public certificate authorities while using Aspire's certificate configuration. The starter should restore its dependencies and start without disabling TLS verification.

Steps To Reproduce

1. On macOS, use Go 1.27.4 and the Aspire 17.0 staging build.
2. Create a project from the Go starter template, which configures AddGoApp(...).WithModTidy().
3. Start the AppHost with dependencies that require downloading.
4. Inspect the app-mod-tidy resource's logs and certificate environment.

Observed process:

Cmd = /opt/homebrew/bin/go
Args = ["mod", "tidy", "-e"]
WorkingDirectory = <starter>/api

Exceptions (if any)

go: aspire-go-starter/api imports
    github.com/redis/go-redis/v9: github.com/redis/go-redis/v9@v9.19.0:
    Get "https://proxy.golang.org/github.com/redis/go-redis/v9/@v/v9.19.0.zip":
    tls: failed to verify certificate: x509: certificate signed by unknown authority

The same error occurs for redisotel, otelslog, and OTLP log/metric exporter packages.

Aspire doctor output

Not collected. The running AppHost and its resource environments were inspected with aspire describe --include-hidden --format Json, and the failing restore logs were confirmed with aspire logs.

Anything else?

Environment:

• Aspire CLI: 17.0.0+4084327635a16237ab8d0babc07701493525f12b (staging installation).
• Go: go1.27.4 darwin/arm64, installed at /opt/homebrew/bin/go.
• Starter API module declares go 1.26; the failing command is the Go 1.27.4 tool itself.

Confirmed trust mismatch: the running app-mod-tidy resource has only SSL_CERT_DIR=<resource>/certs. The main Go resource has both SSL_CERT_DIR=<resource>/certs and SSL_CERT_FILE=<resource>/cert.pem.

In src/Aspire.Hosting.Go/GoHostingExtensions.cs, AddGoApp configures:

.WithCertificateTrustScope(OperatingSystem.IsMacOS() || OperatingSystem.IsWindows()
    ? CertificateTrustScope.System
    : CertificateTrustScope.Append)

But WithModTidy creates a plain executable without that configuration:

var tidy = builder.ApplicationBuilder
    .AddResource(tidyResource)
    .WithArgs("mod", "tidy", "-e")
    .WithParentRelationship(builder.Resource)
    .ExcludeFromManifest();

That executable falls back to the generic Append scope. Since Go 1.27, setting SSL_CERT_DIR on macOS/Windows switches certificate verification to roots loaded from disk instead of the platform verifier. Without the system-root bundle, the restore process loses public CA trust.

Isolated verification: using separate temporary module caches, go list -m -json github.com/redis/go-redis/v9@v9.19.0 fails with the tidy resource's certificate environment and succeeds with the main resource's certificate environment. TLS verification stayed enabled in both cases; the sample project and running AppHost were not modified or restarted.

WithModVendor, WithModDownload, and WithVetTool also create plain Go executable resources without the Go-specific trust configuration. They should be checked for the same omission; only the tidy failure was reproduced here. Windows has the same trust-default rationale but was not tested.

Requested triage: High priority, targeting 17.0, assigned to David Negstad (@danegsta).