DDEV项目在WSL2环境下SSL证书失效问题分析与解决

问题背景

在使用DDEV开发环境时，许多开发者选择在WSL2环境中运行项目。一个常见的问题是SSL证书在系统重启后突然失效，表现为浏览器提示"ERR_CERT_AUTHORITY_INVALID"错误。这种情况通常发生在WSL2与Docker Engine组合的环境中。

问题根源分析

通过诊断日志可以发现，问题的核心在于CAROOT环境变量被意外覆盖。在正常工作的系统中，CAROOT应该指向Windows系统中的mkcert证书存储路径（如/mnt/c/Users/用户名/AppData/Local/mkcert），并通过WSLENV环境变量保持同步。但在问题案例中，该变量被WARP相关配置覆盖，导致系统无法正确找到证书颁发机构。

技术细节

DDEV在WSL2环境下的证书工作机制：

1. mkcert证书安装在Windows系统侧
2. 通过CAROOT环境变量在WSL2侧引用这些证书
3. 证书信任需要同时在Windows和WSL2/Linux环境中建立

当CAROOT环境变量被错误设置时，系统无法找到正确的证书颁发机构，导致所有由该CA签发的证书都无法验证。

解决方案

方法一：修复现有环境

1. 删除WSL2环境中~/.ddev/global_config.yaml文件的mkcert_caroot配置项
2. 重新运行DDEV的WSL2安装脚本
3. 验证echo $CAROOT输出是否正确指向Windows侧的证书路径
4. 检查并修复可能覆盖环境变量的其他配置（如WARP相关设置）

方法二：改用Docker Desktop

对于持续遇到问题的用户，可以考虑：

1. 完全卸载现有的Docker Engine和DDEV环境
2. 安装Docker Desktop for Windows
3. 使用对应的DDEV安装脚本重新配置

虽然Docker Desktop和Docker Engine在技术实现上相似，但Docker Desktop提供了更完整的系统集成，可能避免一些环境变量冲突问题。

预防措施

1. 定期检查CAROOT环境变量设置
2. 避免安装可能修改关键环境变量的工具
3. 在系统更新后验证证书状态
4. 考虑将关键环境变量设置写入shell配置文件

总结

WSL2环境下DDEV的SSL证书问题通常源于环境变量配置冲突。通过理解DDEV与WSL2的交互机制，开发者可以更有针对性地解决问题。对于复杂环境，切换到Docker Desktop可能提供更稳定的开发体验。无论采用哪种方案，保持环境变量的一致性和正确性都是确保SSL证书正常工作的关键。