GetSSL项目中DNS-01验证对非通配符域名支持问题的技术分析

问题背景

GetSSL是一个用于自动化获取和管理SSL/TLS证书的Shell脚本工具。近期在使用该工具与Sectigo的ACME服务进行DNS-01验证时，发现了一个关于非通配符域名验证的问题。

问题现象

当用户尝试通过GetSSL获取非通配符域名的证书时，DNS验证会失败。具体表现为：

1. 对于通配符域名（如*.example.com），验证能够正常完成
2. 对于普通域名（如example.com），验证过程会错误地尝试创建DNS TXT记录
3. 调试信息显示，虽然ACME服务返回了有效的验证状态，但GetSSL未能正确识别

技术分析

ACME协议规范

根据RFC 8555第7.1.4节关于通配符域名的规定：

• 对于通配符域名的授权，必须包含值为"true"的"wildcard"字段
• 对于非通配符域名的授权，该字段应当被省略或设置为"false"

GetSSL的实现问题

GetSSL在处理ACME服务响应时存在以下问题：

1. 代码中仅检查wildcard字段是否为空字符串（使用-z测试）
2. 当Sectigo的ACME服务返回"wildcard":false时，该检查会失败
3. 导致非通配符域名的验证状态被错误地忽略

解决方案比较

社区提出了几种不同的修复方案：

1. 空字符串转换方案： 将false值显式转换为空字符串，保持原有逻辑不变

   if [[ "$wildcard" == "false" ]]; then
     wildcard=""
   fi
   

2. 布尔值明确检查方案： 显式检查wildcard字段的值是否为"true"或"false"

   if [[ ( "$lower_d" == "$authdomain" && "$wildcard" == "false" ) || 
         ( "$lower_d" == "*.${authdomain}" && "$wildcard" == "true" ) ]]; then
   

3. 严格协议合规方案： 根据RFC 8555规范，仅当字段存在且为"true"时才视为通配符

   if [[ "$wildcard" == "true" ]]; then
     # 处理通配符情况
   else
     # 处理非通配符情况
   fi
   

最佳实践建议

1. 协议兼容性：

   • 应该同时支持省略wildcard字段和"wildcard":false的情况
   • 这是最符合RFC 8555规范的做法

2. 代码健壮性：

   • 避免使用简单的空值检查，改为明确的布尔值比较
   • 可以增加对意外值的容错处理

3. 未来维护：

   • 在代码中添加注释说明处理逻辑的依据
   • 考虑添加对ACME服务响应格式的兼容性测试

总结

GetSSL在处理DNS-01验证时对非通配符域名的支持问题，源于对ACME协议响应中wildcard字段处理的不足。通过明确区分"true"、"false"和字段缺失三种情况，可以更好地兼容不同ACME服务的实现方式，同时保持与RFC 8555规范的一致性。这个问题也提醒我们在处理协议实现时，需要仔细阅读规范文档并考虑各种边界情况。