cannot verify 192.168.40.250's certificate, issued by 'emailAddress=admin@ma

Question

在内网环境中，设备通过自签名证书实现HTTPS通信时，常出现“cannot verify 192.168.40.250's certificate, issued by 'emailAddress=admin@ma’”的警告。该问题源于客户端无法验证由私有CA签发的证书，尤其是当证书颁发者为内部管理员（如admin@ma）且未被系统信任时。典型场景包括访问IP地址形式的管理界面（如路由器、监控系统），而证书未正确配置SAN（Subject Alternative Name）或未将根CA导入客户端信任库。此错误虽不影响通信加密，但存在中间人攻击风险。解决方法包括：将自签名证书添加至受信根证书 Authorities，使用带正确SAN的本地CA签发证书，或在确认安全的前提下临时忽略警告。建议生产环境部署可信证书以保障安全性。

Answer 1

一、问题背景与现象分析

在企业内网环境中，设备（如路由器、交换机、摄像头管理平台）常使用自签名证书实现HTTPS加密通信。然而，当用户通过浏览器或命令行工具访问这些设备时，常出现如下警告信息：

cannot verify 192.168.40.250's certificate, issued by 'emailAddress=admin@ma'

该错误表明客户端无法验证服务器证书的合法性，核心原因在于证书由私有CA签发，且未被操作系统或应用的信任库所接受。尤其当颁发者为内部邮箱地址（如 admin@ma），系统默认不信任此类非公共CA。

典型场景包括：

• 访问基于IP地址的Web管理界面（如 192.168.40.250）
• 设备出厂自带自签名证书，未配置SAN扩展
• 自动化脚本调用HTTPS接口时因证书校验失败中断
• 跨平台客户端（Windows/Linux/macOS）信任链不一致

二、技术原理深度剖析

SSL/TLS握手过程中，客户端会执行以下验证步骤：

1. 检查证书是否过期
2. 验证证书签名链是否可追溯至受信根CA
3. 确认域名/IP是否匹配证书中的Common Name（CN）或Subject Alternative Name（SAN）
4. 检查证书吊销状态（CRL/OCSP）

在自签名场景下，第2步失败是主因。此外，若证书未包含IP地址在SAN字段中，即使CN为IP也会被现代浏览器拒绝，违反RFC 2818规范。

示例证书缺失SAN的OpenSSL配置片段：

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn

[ dn ]
CN = 192.168.40.250
emailAddress = admin@ma

三、解决方案全景图

方案	适用场景	安全性	维护成本	推荐级别
导入根CA至信任库	统一管理的内网环境	高	中	★★★★☆
使用本地私有CA签发带SAN证书	中大型网络架构	高	高	★★★★★
临时忽略警告（curl -k / wget --no-check-certificate）	调试阶段	低	低	★☆☆☆☆
部署企业级PKI体系	金融、医疗等合规要求高行业	极高	极高	★★★★★

四、实施路径与最佳实践

构建内部CA并签发合规证书的标准流程如下：

# 生成私钥
openssl genrsa -out ca.key 4096

# 创建自签名根证书
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=Internal CA/emailAddress=admin@ma"

# 生成设备CSR（含SAN）
cat > openssl.cnf << EOF
[ SAN ]
subjectAltName = IP:192.168.40.250
EOF

openssl req -new -key device.key -out device.csr -config openssl.cnf

# 签发证书
openssl x509 -req -in device.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out device.crt -days 730 -sha256 -extfile openssl.cnf -extensions SAN

五、可视化流程：内网HTTPS信任链建立

graph TD
            A[客户端发起HTTPS请求] --> B{证书有效？}
            B -- 否 --> C[检查是否信任CA]
            C -- CA未信任 --> D[提示证书错误]
            C -- CA已信任 --> E[验证SAN/IP匹配]
            E -- 匹配 --> F[建立安全连接]
            E -- 不匹配 --> D
            B -- 是 --> F
            G[管理员导入ca.crt至信任库] --> C

六、长期运维建议

对于拥有5年以上经验的IT从业者，应推动以下改进：

• 建立标准化的内部PKI管理体系，替代零散的自签名证书
• 采用自动化工具（如CFSSL、Smallstep CLI）批量签发和轮换证书
• 集成LDAP/AD实现证书绑定身份认证
• 监控证书有效期，避免突发中断
• 在DevOps流水线中嵌入证书健康检查
• 对关键系统启用双向TLS（mTLS）增强安全性
• 记录所有证书签发日志，满足审计需求
• 定期演练证书吊销与应急恢复流程
• 培训团队理解X.509证书结构与TLS握手细节
• 评估使用Let's Encrypt私有ACME服务的可能性