# Dotnet Devcert Trust

Diagnose and fix .NET HTTPS dev certificate trust issues on Linux.

- Repository: https://github.com/Aaronontheweb/dotnet-skills (1244 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-28
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add Aaronontheweb/dotnet-skills --skill dotnet-devcert-trust -g -a claude-code -y`
Codex: `npx skills add Aaronontheweb/dotnet-skills --skill dotnet-devcert-trust -g -a codex -y`
Cursor: `npx skills add Aaronontheweb/dotnet-skills --skill dotnet-devcert-trust -g -a cursor -y`
Gemini CLI: `npx skills add Aaronontheweb/dotnet-skills --skill dotnet-devcert-trust -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add Aaronontheweb/dotnet-skills`

## Description

Diagnose and fix .NET HTTPS dev certificate trust issues on Linux. Covers the full certificate lifecycle from generation to system CA bundle inclusion, with distro-specific guidance for Ubuntu, Fedora, Arch, and WSL2.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# .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:

1. It does **not** export the certificate to the system CA directory
2. It does **not** run `update-ca-certificates` to rebuild the CA bundle
3. It does **not** add the cert to browser trust stores (NSS/NSSDB)
4. The `--trust` flag silently succeeds but the cert remains untrusted

This means .NET applications, OpenSSL, curl, and browsers all reject the dev certificate, even though `dotnet dev-certs https --check` reports it exists.

### Why This Surfaces with Aspire 13.1.0+

Prior to Aspire 13.1.0, Redis connections used plaintext. Starting with 13.1.0, Aspire enables TLS on Redis by default. If your dev cert isn't trusted at the system level, Redis connections fail immediately with:

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

## How Linux Certificate Trust Works

Understanding the architecture prevents cargo-cult debugging:

The rest: https://github.com/Aaronontheweb/dotnet-skills/blob/HEAD/skills/dotnet-devcert-trust/SKILL.md