Outbound HTTPS requests fail on Linux because Aspire replaces SSL_CERT_DIR with temporary certificate directory

[axies20]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

On Linux, Aspire appears to replace the SSL_CERT_DIR environment variable for hosted projects with an Aspire-generated temporary directory.

Example value observed inside the hosted application:

SSL_CERT_FILE=
SSL_CERT_DIR=/tmp/aspire-*//certs

As a result, outbound HTTPS requests may fail with certificate validation errors even though the same requests work correctly outside Aspire.

Environment

• Fedora Linux
• .NET 10
• Aspire CLI 13.4.3

Related issue

This issue appears closely related to:

• SSL_CERT_DIR is overwritten and not propagated from AppHost #13219 - "SSL_CERT_DIR is overwritten and not propagated from AppHost"

However, that issue is closed and the behavior can still be reproduced.

Expected Behavior

Aspire should preserve access to the system OpenSSL trust store when configuring development certificates.

Possible approaches:

• Append Aspire certificates to the existing trust directories.
• Preserve the system SSL_CERT_DIR.
• Merge Aspire-generated certificates with the system trust configuration.

Hosted applications should be able to use Aspire development certificates without breaking outbound HTTPS requests to external services.

Steps To Reproduce

1. Create a simple Aspire application on Linux.
2. Print SSL_CERT_FILE and SSL_CERT_DIR from the hosted project.
3. Observe that SSL_CERT_DIR points to an Aspire-generated temporary directory.
4. Make an outbound HTTPS request to an external service.
5. Certificate validation fails while the same request succeeds outside Aspire.

Exceptions (if any)

System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: NotSignatureValid, UntrustedRoot

Aspire doctor output

Aspire Environment Check

Aspire
✅ Aspire CLI version 13.4.3 (channel: stable)

.NET SDK
✅ .NET 10.0.300 installed (x64)

Container Runtime
⚠️ Docker: installed but not running
Start Docker daemon
✅ Podman v5.8.2: running (auto-detected (only runtime running)) ← active

Environment
⚠️ HTTPS development certificate is only partially trusted
Set SSL_CERT_DIR in your shell profile: export
SSL_CERT_DIR="$SSL_CERT_DIR:/etc/pki/tls/certs:/home/axi/.aspnet/dev-certs/trust"
See: https://aka.ms/aspire-prerequisites#dev-certs
Details:
The certificate is in the trusted store, but SSL_CERT_DIR is not configured to
include '/home/axi/.aspnet/dev-certs/trust'. Some applications may not trust the
certificate. 'aspire run' will configure this automatically.

Summary: 3 passed, 2 warnings, 0 failed
For detailed prerequisites: https://aka.ms/aspire-prerequisites

Aspire CLI Installations

Path	Version	Channel	Route	PATH status
/home/axi/.aspire/bin/aspire (current)	13.4.3+4f218933552e18ff2874d 1b6d5dc3fe671e3b6d9	stable	script	active

Anything else?

Running:

aspire certs trust

returns:

Developer certificates may not be fully trusted (trust exit code was:
PartiallyFailedToTrustTheCertificate).
❌ Failed to trust HTTPS development certificate. Certificate trust operation returned:
PartiallyFailedToTrustTheCertificate

and logs contain:

The certificate is not trusted by OpenSSL.
Ensure that the SSL_CERT_DIR environment variable is set correctly.

[joperezr]

🤖 Aspire triage pass — 2026-06-09 22:57 UTC

Area: area-app-model
Kind: regression
Repro: yes-minimal — see "Steps To Reproduce" in issue body
Affected version(s): 13.4.3 (per aspire doctor output; latest stable is 13.4.x)
Severity: S2 — outbound HTTPS calls fail in hosted projects on Linux; workaround exists (manually set SSL_CERT_DIR in shell profile, as the doctor output suggests).

Urgency: 🟡 vNext — recommend milestone 13.5
Reason: The original issue (#13219) was fixed and shipped in 13.1, but the reporter observes the same behavior on 13.4.3. This looks like a regression that returned somewhere between 13.1 and 13.4.x — but the issue does not establish that the bug worked on 13.2 / 13.3.x and was broken specifically by a 13.4 change, so it does not clearly meet the 13.4.x servicing bar. Defaulting to 13.5 with human escalation if a regression baseline can be confirmed.

Suggested owner(s): @danegsta (primary), backup @davidfowl
Evidence:

• @danegsta has been the principal author of dev-cert / SSL_CERT_DIR work: Standardize the SSL_CERT_DIR checks #15281 ("Standardize the SSL_CERT_DIR checks"), Add 'aspire certs' command for certificate management #15117 ("Add 'aspire certs' command"), Pre-export dev certificate to Aspire cache to avoid macOS keychain prompts #16282 ("Pre-export dev certificate to Aspire cache"), and Rework certificate environment and argument config to be more idiomatic #12358 ("Rework certificate environment and argument config") — which is the most likely original fix for SSL_CERT_DIR is overwritten and not propagated from AppHost #13219.
• @davidfowl recently merged partial-Linux-trust work: Handle partial Linux certificate trust in CI #17447 ("Handle partial Linux certificate trust in CI") and related cert-trust test fixes in May 2026.
• CODEOWNERS for /src/Aspire.Hosting lists @JamesNK @karolz-ms @danegsta @mitchdenny @davidfowl. The affected code path is src/Aspire.Hosting/ApplicationModel/CertificateTrustExecutionConfigurationGatherer.cs.

Confidence: medium
Needs human?: yes — please confirm whether this reproduces on 13.2 / 13.3.x. If it works on 13.3.x and is broken only on 13.4.x, this should be re-escalated to the 13.4.x servicing milestone (regression vs. the prior 13.x).

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[danegsta]

@axies20 based on what you're describing, I'm assuming you're using dotnet to run your AppHost? Can you try running it via aspire run or aspire start to see if that gives the SSL_CERT_DIR behavior you expect (we do some SSL_CERT_DIR override when using the CLI to run). I'll also look at handling the case when the CLI isn't setting SSL_CERT_DIR.

[axies20]

@axies20 based on what you're describing, I'm assuming you're using dotnet to run your AppHost? Can you try running it via aspire run or aspire start to see if that gives the SSL_CERT_DIR behavior you expect (we do some SSL_CERT_DIR override when using the CLI to run). I'll also look at handling the case when the CLI isn't setting SSL_CERT_DIR.

I tried running the AppHost via aspire run.

The AppHost starts successfully, but the effective environment variables are empty:

SSL_CERT_DIR =
DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER =

I still get the ASP.NET Core dev certificate warning:

The ASP.NET Core developer certificate is only trusted by some clients

So in my case, the Aspire CLI does not appear to set SSL_CERT_DIR for the AppHost process.

[danegsta]

@axies20 odd, aspire run specifically overrides the SSL_CERT_DIR environment if the .aspnet trust folder is missing and we definitely append an existing SSL_CERT_DIR value when building the executable environment. Can you share an example AppHost so I can see the type of resource you're running?

Certain resources use different trust settings which can change our environment variable behavior. For example, we support several different trust modes (None, Append, Override, and System) where only Append explicitly includes the default certificate folders in the SSL_CERT_DIR value (while None doesn't apply any custom SSL_CERT_DIR or SSL_CERT_FILE environment). Both Override and System act by explicitly owning the full trust set. So in both of those cases you would only get the Aspire managed certificate paths in the environment, with Override only adding certificates explicitly added to the Aspire trust API and System automatically including trusted system certificates but using an Aspire managed bundle.

[axies20]

Thanks, that helps explain the behavior.

In my test, running via aspire run resulted in:

SSL_CERT_DIR =
DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER =

so it looks like no custom trust environment was applied to the process I inspected.

The issue originally appeared when my ASP.NET application made outbound HTTPS requests and failed with certificate validation errors (AuthenticationException, UntrustedRoot).

My AppHost is fairly simple. The relevant resources are:

var postgres = builder.AddPostgres("PostgresBtr");
var redis = builder.AddRedis("RedisBtr");

builder.AddProject<Projects.BTR_Web>("BTR-Web")
    .WithReference(postgres)
    .WithReference(redis);

builder.AddProject<Projects.BTR_Auth>("BTR-Auth")
    .WithReference(postgres);

I don't believe I'm explicitly configuring any trust mode, but I can share the full AppHost if that would help identify which resource type or trust mode is being used.

[danegsta]

Hmm, AddProject should be using the default Append trust mode and we're definitely picking up the expected Fedora Linux system certificate path in aspire doctor (/etc/pki/tls/certs). We would do the wrong thing if invoked directly via dotnet run (as we only handle the case where there's an existing SSL_CERT_DIR, not the implicit default), but aspire run definitely sets an SSL_CERT_DIR environment variable for the AppHost that includes the system folder when SSL_CERT_DIR is unset. Can you try both .WithCertificateTrustScope(CertificateTrustScope.None) and .WithCertificateTrustScope(CertificateTrustScope.System) to see if either resolves the trust issue? In the first case we don't set any custom SSL_CERT_DIR environment on the process and in the second we manually apply the system trusted certificates.

[axies20]

@danegsta I also tested the two trust scopes you suggested:

.WithCertificateTrustScope(CertificateTrustScope.None)

and

.WithCertificateTrustScope(CertificateTrustScope.System)

In my environment there was no observable difference between them.

For both configurations:

• the application started successfully
• the startup warning remained:

The ASP.NET Core developer certificate is only trusted by some clients.

• the process logged:

SSL_CERT_DIR =
DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER =

Additionally, after reviewing my command history I noticed that some of my later tests were performed after manually exporting:

export SSL_CERT_DIR="$HOME/.aspnet/dev-certs/trust:/etc/pki/tls/certs"

and Aspire CLI logs contain:

The certificate is not trusted by OpenSSL.
Ensure that the SSL_CERT_DIR environment variable is set correctly.

which suggests the issue may be related to the OpenSSL trust configuration on my Fedora machine rather than the selected CertificateTrustScope.

[danegsta]

@axies20 can you check what OpenSSL version you have locally? We saw another report where a user had updated their OpenSSL version and started running into issues. May be unrelated, but wanted to see if there's any possible correlation here.