Dotnet Devcert Trust

If you've ever run `dotnet dev-certs https --trust` on Linux and wondered why your Aspire Redis connections still fail with certificate errors, this is why: the command does basically nothing. It generates the cert but doesn't export it to the system CA directory or run `update-ca-certificates` to rebuild the bundle that applications actually read. This skill walks through the five-point diagnostic (cert existence, trust store files, CA bundle inclusion, environment variables, symlink integrity) and provides a complete recovery script. Especially relevant if you upgraded to Aspire 13.1.0+ where Redis suddenly uses TLS by default. The explanation of how Linux certificate trust actually works is worth reading even if you're not debugging right now.

skills.sh installs: 457
GitHub stars: 1.3K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add aaronontheweb/dotnet-skills --skill dotnet-devcert-trust --agent claude-code

Installs into .claude/skills of the current project.

Files

.NET Dev Certificate Trust on Linux

When to Use This Skill

Use this skill when:

Redis TLS connections fail with UntrustedRoot or RemoteCertificateNameMismatch in Aspire
dotnet dev-certs https --check --trust returns exit code 7
HTTPS localhost connections fail with certificate validation errors
After running dotnet dev-certs https --clean and needing to restore trust
Setting up a new Linux dev machine for .NET HTTPS development
Aspire dashboard or inter-service gRPC calls fail with TLS errors
Upgrading from Aspire < 13.1.0 (which didn't use TLS on Redis by default)

The Problem

On Windows and macOS, dotnet dev-certs https --trust handles everything automatically — it generates the certificate, installs it in the user store, and adds it to the system trust store. On Linux, it does almost nothing useful. The command generates the cert and places it in the user store, but:

SKILL.md on GitHub