Agent测试

Name: Agent测试
Author: Aaronontheweb

工程开发社区

作者仓库星标 1,012
叉子 98
作者更新于 2026年4月16日 02:05
作者仓库 dotnet-skills

流狐档案事实层信息：领域、Agent、信任分、运行环境、权限与网络

领域: 工程开发
兼容 Agent: Claude Code
Cursor
Cline
Codex
Windsurf
Gemini CLI

+20
信任分: 83 / 100 · 社区维护
作者 / 版本 / 许可: @Aaronontheweb · 未声明 license
Token 消耗评级: 低消耗
接入复杂程度: 需手动接入
是否需要外部 API Key: 不需要
兼容的系统: macOS · Linux · Windows · Docker
底层运行要求: Docker
文件与系统权限: 只读
允许写入 / 修改
Shell 执行
读取环境变量
网络行为: 允许外网请求
安装命令数: 26 条

档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。

需要注意： 未限定 allowed-tools，默认拥有全部工具权限。；检出高风险片段：rm_rf_root

输出预览 dotnet-devcert-trust.preview

---
name: dotnet-devcert-trust
description: Diagnose and fix .NET HTTPS dev certificate trust issues on Linux. Covers the full certificate l…
category: 工程开发
runtime: Docker
---

# dotnet-devcert-trust 输出预览

## PART A: 任务判断
- 适用问题：代码实现、重构、调试或代码审查。
- 输入要求：目标材料、限制条件、期望输出和验收方式。
- 证据边界：围绕“When to Use This Skill / The Problem / Why This Surfaces with Aspire 13.1.0+”读取原文规则，不把推断写成作者承诺。

## PART B: 执行结果
- **01** 任务判断：确认你的需求是否属于代码实现、重构、调试或代码审查，并标出输入、限制和预期结果。
- **02** 执行计划：优先按“When to Use This Skill / The Problem / Why This Surfaces with Aspire 13.1.0+”拆成步骤，说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果：给出可复制的命令、文件改动、检查清单或内容草稿，并说明如何继续迭代。
- **04** 风险边界：结合 读取文件、写入/修改文件、执行终端命令、读取环境变量、会按任务需要访问外部网络、通常不需要额外 API Key 给出执行前确认项。

## Running Rules
- 读取文件、写入/修改文件、执行终端命令、读取环境变量；会按任务需要访问外部网络；通常不需要额外 API Key。
- 先小样例验证，再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。

SKILL.md SKILL.md

---
name: dotnet-devcert-trust
description: Diagnose and fix .NET HTTPS dev certificate trust issues on Linux. Covers the full certificate l…
category: 工程开发
source: Aaronontheweb/dotnet-skills
---

# dotnet-devcert-trust

## 什么时候使用
- dotnet-devcert-trust 是一个工程开发方向的技能，扩展 Agent 在写代码、做 review、跑测试这类场景下的能力 适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查，核心价值是把输入、判断、执行、验证和…
- 面向代码实现、重构、调试或代码审查，优先处理能明确输入、步骤和验收标准的工作。

## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。

## 执行规则
- 围绕「When to Use This Skill / The Problem / Why This Surfaces with Aspire 13.1.0+」组织步骤，不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令、读取环境变量；会按任务需要访问外部网络；通常不需要额外 API Key。
- 先跑小样例，确认结果可检查后再扩大任务范围。

## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown，不编造命令、平台或依赖。

证据边界与执行链路

作者原文负责流程事实；仓库文件负责来源和命令；流狐只补充适用场景、限制和质量判断。

skill "dotnet-devcert-trust" {
  输入层     -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
  上下文层   -> When to Use This Skill / The Problem / Why This Surfaces with Aspire 13.1.0+
  规则层     -> SKILL.md 触发条件 / 执行顺序 / 输出格式
  运行层     -> Docker | 读取文件、写入/修改文件、执行终端命令、读取环境变量 | 会按任务需要访问外部网络
  安全层     -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
  输出层     -> 可复制结果 + 检查清单 + 下一步迭代
}

解读按原文结构重写，命令、链接、术语均保留；右侧可核对作者原始 SKILL.md

先判断是否适合

核心用途：dotnet-devcert-trust 是一个工程开发方向的技能，扩展 Agent 在写代码、做 review、跑测试这类场景下的能力适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查，核心价值是把输入、判断、执行、验证和交付边界固定下来，避…
适用任务：更适合工程开发场景下的代码实现、调试、重构、测试或代码审查，尤其是输入、步骤、验收口径可以反复复用的场景。
不宜硬套：如果任务只有一次性问答、来源材料很少，或需要作者没有说明的命令和外部服务，应先降级为普通对话。

作者设计意图

触发依据：使用时机、上下文收集、输出格式和失败处理共同决定它是否适合当前任务。
来源边界：作者原文负责事实，仓库文件负责命令和文件证据；Fluxly 只补充用途、限制和使用判断。

作者的方法与取舍

执行主线：任务围绕「When to Use This Skill / The Problem / Why This Surfaces with Aspire 13.1.0+」组织，把触发条件、必要上下文、执行规则和交付标准连成一条可复核的链路。
设计重点：重点不在重复教程，而在解释作者为什么规定这些步骤、哪些条件不可省略，以及结果偏离时应回到哪一层检查。
使用判断：先确认任务与原文边界一致，再决定是否启用；来源没有说明的命令、平台和依赖保持未知，不由 Fluxly 补写。

边界和复核

依赖条件：通常不需要额外 API Key，适合先用小任务验证触发是否稳定。
权限提醒：会涉及 read / write / shell-exec / env-read 权限，执行前要说明可读写范围、命令边界和回退方式。
质量标准：结果应包含明确产物、必要证据和下一步动作；如果只是泛泛解释，需要补充输入和验收条件后重跑。

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

It does not export the certificate to the system CA directory
It does not run update-ca-certificates to rebuild the CA bundle
It does not add the cert to browser trust stores (NSS/NSSDB)
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:

┌─────────────────────────────────────────────────────┐
│ Application (.NET, curl, OpenSSL)                   │
│   reads: /etc/ssl/certs/ca-certificates.crt         │
│          (consolidated CA bundle)                    │
└──────────────────────┬──────────────────────────────┘
                       │ built by
┌──────────────────────▼──────────────────────────────┐
│ update-ca-certificates                              │
│   reads from:                                        │
│     /usr/share/ca-certificates/      (distro CAs)   │
│     /usr/local/share/ca-certificates/ (local CAs)   │
│   writes to:                                         │
│     /etc/ssl/certs/ca-certificates.crt (bundle)     │
│     /etc/ssl/certs/*.pem (individual symlinks)      │
└─────────────────────────────────────────────────────┘

Key insight: Placing a .crt file in /usr/local/share/ca-certificates/ is necessary but not sufficient. The consolidated bundle at /etc/ssl/certs/ca-certificates.crt must be rebuilt by running update-ca-certificates. Applications read the bundle, not the individual files.

5-Point Diagnostic Procedure

Run these checks in order. Stop at the first FAIL and apply its fix before continuing.

Check 1: Dev Cert Existence

dotnet dev-certs https --check
echo "Exit code: $?"

Exit Code	Meaning	Action
0	Cert exists in user store	PASS — continue
Non-zero	No valid dev cert	Run `dotnet dev-certs https`

Check 2: System Trust Store — Single Cert, Correct Permissions

ls -la /usr/local/share/ca-certificates/ | grep -iE 'dotnet|aspnet'

Result	Meaning
Only `dotnet-dev-cert.crt` with `-rw-r--r--` (644)	PASS
Multiple cert files, wrong permissions, or stale `aspnet*` files	FAIL

Common stale files from previous sessions:

File	Problem
`aspnetcore-dev.crt`	Often created with `0600` permissions (unreadable by `update-ca-certificates`)
`aspnet/https.crt`	Old convention, may have a different fingerprint than current dev cert
`dotnet-dev-cert.crt` with `0600`	Correct name but wrong permissions

Fix:

# Remove ALL stale cert files
sudo rm -f /usr/local/share/ca-certificates/aspnetcore-dev.crt
sudo rm -rf /usr/local/share/ca-certificates/aspnet/

# Ensure correct permissions on the dev cert (if it exists)
sudo chmod 644 /usr/local/share/ca-certificates/dotnet-dev-cert.crt

Check 3: CA Bundle Inclusion

This is the most commonly failed check. The cert file exists but was never added to the bundle.

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
  /usr/local/share/ca-certificates/dotnet-dev-cert.crt

Result	Meaning
`dotnet-dev-cert.crt: OK`	PASS — cert is in the consolidated bundle
`error 20 at 0 depth lookup: unable to get local issuer certificate`	FAIL — bundle was never rebuilt
`error 2 at 0 depth lookup: unable to get issuer certificate`	FAIL — same issue, different OpenSSL version

Fix:

sudo update-ca-certificates
# Expected output includes "1 added" or similar

# Re-verify
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
  /usr/local/share/ca-certificates/dotnet-dev-cert.crt

Check 4: Environment Variable Overrides

SSL environment variables can redirect certificate lookups away from the system bundle:

echo "SSL_CERT_DIR=${SSL_CERT_DIR:-<unset>}"
echo "SSL_CERT_FILE=${SSL_CERT_FILE:-<unset>}"
echo "DOTNET_SSL_CERT_DIR=${DOTNET_SSL_CERT_DIR:-<unset>}"
echo "DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=${DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER:-<unset>}"

Result	Meaning
All `<unset>`	PASS
Any variable set	FAIL — may redirect cert lookups

Fix: Remove the offending variables from your shell profile (~/.bashrc, ~/.zshrc, ~/.profile) and start a new shell.

Check 5: Symlink Integrity

Stale symlinks from previously removed certificates can confuse OpenSSL:

find /etc/ssl/certs/ -xtype l 2>/dev/null | head -5

Result	Meaning
No output	PASS
Broken symlinks listed	FAIL

Fix:

sudo update-ca-certificates --fresh
# Rebuilds ALL symlinks from scratch

Full Recovery Procedure

When multiple checks fail or you want a clean slate, run this complete sequence:

#!/usr/bin/env bash
set -euo pipefail

echo "=== .NET Dev Certificate Trust Recovery ==="

# Step 1: Remove ALL stale certificate files
echo "--- Removing stale certificate files ---"
sudo rm -f /usr/local/share/ca-certificates/aspnetcore-dev.crt
sudo rm -rf /usr/local/share/ca-certificates/aspnet/
sudo rm -f /usr/local/share/ca-certificates/dotnet-dev-cert.crt

# Step 2: Clean and regenerate dev cert
echo "--- Regenerating dev certificate ---"
dotnet dev-certs https --clean
dotnet dev-certs https

# Step 3: Export as PEM and install to system trust store
echo "--- Installing to system trust store ---"
dotnet dev-certs https --export-path /tmp/dotnet-dev-cert.crt --format PEM --no-password
sudo cp /tmp/dotnet-dev-cert.crt /usr/local/share/ca-certificates/dotnet-dev-cert.crt
sudo chmod 644 /usr/local/share/ca-certificates/dotnet-dev-cert.crt
rm /tmp/dotnet-dev-cert.crt

# Step 4: Rebuild CA bundle (CRITICAL — most commonly missed step)
echo "--- Rebuilding CA bundle ---"
sudo update-ca-certificates

# Step 5: Verify
echo "--- Verifying ---"
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
  /usr/local/share/ca-certificates/dotnet-dev-cert.crt

echo "=== Done! Restart your .NET application. ==="

Save this as ~/fix-devcert.sh and run with bash ~/fix-devcert.sh when needed.

Distro-Specific Notes

Ubuntu / Debian

The procedure above is written for Ubuntu/Debian and works as-is.

CA directory: /usr/local/share/ca-certificates/
Bundle command: sudo update-ca-certificates
Bundle output: /etc/ssl/certs/ca-certificates.crt
Cert format: PEM with .crt extension required

Fedora / RHEL / CentOS

Fedora uses update-ca-trust instead of update-ca-certificates:

# Export cert
dotnet dev-certs https --export-path /tmp/dotnet-dev-cert.pem --format PEM --no-password

# Install to Fedora trust store (different directory!)
sudo cp /tmp/dotnet-dev-cert.pem /etc/pki/ca-trust/source/anchors/dotnet-dev-cert.pem
sudo chmod 644 /etc/pki/ca-trust/source/anchors/dotnet-dev-cert.pem
rm /tmp/dotnet-dev-cert.pem

# Rebuild trust bundle
sudo update-ca-trust

# Verify
openssl verify /etc/pki/ca-trust/source/anchors/dotnet-dev-cert.pem

Key differences:

	Ubuntu/Debian	Fedora/RHEL
CA directory	`/usr/local/share/ca-certificates/`	`/etc/pki/ca-trust/source/anchors/`
Rebuild command	`update-ca-certificates`	`update-ca-trust`
Bundle path	`/etc/ssl/certs/ca-certificates.crt`	`/etc/pki/tls/certs/ca-bundle.crt`
Extension	`.crt`	`.pem` (any extension works)

Arch Linux

Arch uses the same update-ca-trust approach as Fedora:

sudo cp /tmp/dotnet-dev-cert.pem /etc/ca-certificates/trust-source/anchors/dotnet-dev-cert.pem
sudo chmod 644 /etc/ca-certificates/trust-source/anchors/dotnet-dev-cert.pem
sudo update-ca-trust

WSL2

WSL2 runs a real Linux kernel with its own certificate store — separate from the Windows host. The standard Ubuntu/Debian procedure works, but watch for:

Shared filesystem (/mnt/c/) — cert files on the Windows filesystem have Windows permissions that may not be 644. Always copy to a native Linux path first.
systemd not running — some older WSL2 setups don't have systemd, which update-ca-certificates hooks may depend on. If the command hangs, try sudo dpkg-reconfigure ca-certificates instead.
Docker Desktop integration — If using Docker Desktop's WSL2 backend, containers inherit the WSL2 distro's CA bundle. Fixing trust in WSL2 fixes it for containers too.

Aspire-Specific Considerations

Redis TLS (Aspire 13.1.0+)

Aspire 13.1.0 enables TLS on Redis by default. If you see:

UntrustedRoot

in Redis connection errors, the dev cert isn't trusted at the system level. Run the full recovery procedure above.

Aspire Dashboard HTTPS

The Aspire dashboard uses the dev cert for HTTPS. If the dashboard shows certificate warnings in the browser, the cert isn't in the browser's trust store. For development, clicking through the warning is acceptable — the system-level trust (needed for Redis, gRPC, etc.) is the priority.

ASPIRE_ALLOW_UNSECURED_TRANSPORT

Setting ASPIRE_ALLOW_UNSECURED_TRANSPORT=true is a workaround, not a fix. It disables TLS for inter-service communication, which:

Masks the underlying trust issue
Doesn't match production behavior
May cause different bugs than what you'd see in production

Fix the cert trust instead.

Certificate Lifecycle

The dev cert is valid for 1 year from creation. When it expires:

dotnet dev-certs https --check will report no valid cert
Run the full recovery procedure to generate a new cert
The old cert file in /usr/local/share/ca-certificates/ will be replaced
update-ca-certificates will swap the old cert for the new one in the bundle

No system reboot is required. Applications pick up the new bundle on next TLS handshake (restart your app).

Automation: CI/CD Pipelines

In CI/CD on Linux runners, dev certs are rarely needed (you typically test against real certificates or disable TLS validation in test harnesses). However, if your integration tests require trusted dev certs:

GitHub Actions

- name: Trust .NET Dev Certificate
  run: |
    dotnet dev-certs https
    dotnet dev-certs https --export-path /tmp/dotnet-dev-cert.crt --format PEM --no-password
    sudo cp /tmp/dotnet-dev-cert.crt /usr/local/share/ca-certificates/dotnet-dev-cert.crt
    sudo chmod 644 /usr/local/share/ca-certificates/dotnet-dev-cert.crt
    rm /tmp/dotnet-dev-cert.crt
    sudo update-ca-certificates

Azure DevOps

- script: |
    dotnet dev-certs https
    dotnet dev-certs https --export-path /tmp/dotnet-dev-cert.crt --format PEM --no-password
    sudo cp /tmp/dotnet-dev-cert.crt /usr/local/share/ca-certificates/dotnet-dev-cert.crt
    sudo chmod 644 /usr/local/share/ca-certificates/dotnet-dev-cert.crt
    rm /tmp/dotnet-dev-cert.crt
    sudo update-ca-certificates
  displayName: 'Trust .NET Dev Certificate'

Common Pitfalls

1. Cert placed but bundle never rebuilt

Symptom: Cert file exists in /usr/local/share/ca-certificates/ but openssl verify fails.

Cause: update-ca-certificates was never run after placing the file.

Fix: sudo update-ca-certificates

This is the single most common mistake. The CA directory is an input to the bundle generation process, not the bundle itself.

2. Stale cert files with wrong permissions

Symptom: update-ca-certificates runs but reports 0 added.

Cause: Cert files with 0600 permissions are unreadable by update-ca-certificates (which runs as root but reads files through a process that may check world-readability). Files must be 644.

Fix: sudo chmod 644 /usr/local/share/ca-certificates/*.crt

3. Multiple cert files from different sessions

Symptom: update-ca-certificates adds multiple certs, but applications still fail.

Cause: Old cert files from previous dotnet dev-certs https --clean / regenerate cycles remain in the CA directory. The old cert's fingerprint doesn't match the current dev cert.

Fix: Remove all dotnet* and aspnet* files, then re-export the current cert.

4. Fingerprint mismatch after clean/regenerate

Symptom: openssl verify passes but .NET still reports UntrustedRoot.

Cause: The cert in /usr/local/share/ca-certificates/ was exported from a previous dev cert. After dotnet dev-certs https --clean && dotnet dev-certs https, a new cert with a different fingerprint was generated. The system trusts the old cert, not the new one.

Fix: Re-export and reinstall:

dotnet dev-certs https --export-path /tmp/dotnet-dev-cert.crt --format PEM --no-password
sudo cp /tmp/dotnet-dev-cert.crt /usr/local/share/ca-certificates/dotnet-dev-cert.crt
sudo update-ca-certificates

5. Using --trust and assuming it worked

Symptom: dotnet dev-certs https --trust returns exit code 0 but nothing is actually trusted.

Cause: On Linux, --trust attempts to add the cert to the OpenSSL trust store but does not call update-ca-certificates. The operation "succeeds" from dotnet's perspective but the bundle remains unchanged.

Fix: Don't rely on --trust on Linux. Follow the manual procedure in this skill.

Quick Reference

# Generate dev cert (if missing)
dotnet dev-certs https

# Export as PEM
dotnet dev-certs https --export-path /tmp/dotnet-dev-cert.crt --format PEM --no-password

# Install to system trust (Ubuntu/Debian)
sudo cp /tmp/dotnet-dev-cert.crt /usr/local/share/ca-certificates/dotnet-dev-cert.crt
sudo chmod 644 /usr/local/share/ca-certificates/dotnet-dev-cert.crt
sudo update-ca-certificates

# Verify trust
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
  /usr/local/share/ca-certificates/dotnet-dev-cert.crt

# Check cert details
openssl x509 -in /usr/local/share/ca-certificates/dotnet-dev-cert.crt -noout -subject -dates -fingerprint

# Nuclear option: full clean + rebuild
dotnet dev-certs https --clean && dotnet dev-certs https

dotnet-skills:aspire-configuration — Aspire AppHost configuration including TLS settings
dotnet-skills:aspire-service-defaults — Service defaults including HTTPS configuration

安装命令

一键复制安装选择包管理器,点击右侧复制,粘贴到终端回车即可

npx skills add Aaronontheweb/dotnet-skills/skills/dotnet-devcert-trust -y

查看通用安装教程

查看 Skill 原文

兼容工具

Claude Code
Cursor
Cline
Codex
Windsurf
Gemini
OpenCode
Roo Code
AAide
+Augment
GitHub Copilot
OpenClaw
KKiro
Junie
WWarp
Goose
Trae
Kilo Code
OpenHands
Amp
Zencoder
CContinue
AIAider
CodeBuddy
CodeGeeX
Replit Agent

安全审计

83 / 100

社区

未声明 license/许可。
未声明 version。
未限定 allowed-tools，默认拥有全部工具权限。
检出高风险片段：rm_rf_root

元信息

来源: local
Aaronontheweb/dotnet-skills
English

@Aaronontheweb 的其他技能

分类与标签

分类工程开发

先判断是否适合

作者设计意图

作者的方法与取舍

边界和复核

.NET Dev Certificate Trust on Linux

When to Use This Skill

The Problem

Why This Surfaces with Aspire 13.1.0+

How Linux Certificate Trust Works

5-Point Diagnostic Procedure

Check 1: Dev Cert Existence

Check 2: System Trust Store — Single Cert, Correct Permissions

Check 3: CA Bundle Inclusion

Check 4: Environment Variable Overrides

Check 5: Symlink Integrity

Full Recovery Procedure

Distro-Specific Notes

Ubuntu / Debian

Fedora / RHEL / CentOS

Arch Linux

WSL2

Aspire-Specific Considerations

Redis TLS (Aspire 13.1.0+)

Aspire Dashboard HTTPS

ASPIRE_ALLOW_UNSECURED_TRANSPORT

Certificate Lifecycle

Automation: CI/CD Pipelines

GitHub Actions

Azure DevOps

Common Pitfalls

1. Cert placed but bundle never rebuilt

2. Stale cert files with wrong permissions

3. Multiple cert files from different sessions

4. Fingerprint mismatch after clean/regenerate

5. Using --trust and assuming it worked

Quick Reference

Related Skills

讨论