使用自签名证书的HTTPS环境下出现CORS失败问题

这个CORS失败的核心原因不是CORS配置问题，而是浏览器对未信任的自签名证书的安全限制：当设备B的证书未被浏览器加入信任列表时，浏览器会直接阻止任何向B发起的跨域请求（甚至不会发送OPTIONS预检请求），最终表现为CORS错误。

1. 使用受信任的CA签发证书（最优生产方案） #

如果有条件，给设备B部署由内网根CA签发的证书，并将该根CA证书预装到用户的浏览器或操作系统信任存储中。这样浏览器会自动信任设备B的证书，不会弹出风险警告，跨域请求也能正常发起。

2. 优化用户证书信任引导 #

如果必须用自签名证书，可以在设备A的页面上添加明确的操作指引：

• 在A的页面顶部显示提示，告知用户需要先访问设备B的页面并接受证书风险，提供一键跳转至B页面的按钮；
• 尝试在A的页面中嵌入隐藏iframe加载设备B的静态资源（如https://设备B地址/favicon.ico），触发浏览器的证书信任提示，但部分浏览器可能会阻止iframe的证书弹窗，需要用户手动允许。

3. 在设备A上配置反向代理（推荐折中方案） #

通过设备A的web服务器（你用的是lighttpd）做反向代理，将A页面脚本的请求转发到设备B的API。这样脚本请求的是同域（设备A的域名）的接口，彻底避免跨域问题，且用户只需要信任设备A的证书即可。

添加以下lighttpd配置（和你的CORS配置放在一起）：

# 反向代理设备B的API到A的/api/b路径
$HTTP["url"] =~ "^/api/b/" {
    # 替换为设备B的实际IP/域名
    proxy.server = ( "" => ((
        "host" => "192.168.x.x",
        "port" => 443,
        "ssl" => "enable"
    )))
    # 配置lighttpd信任设备B的自签名证书（替换为B证书的本地路径）
    proxy.ssl.ca-file = "/etc/lighttpd/certs/b-device.crt"
    # 保留CORS头部（兼容其他场景）
    setenv.add-response-header = (
        "Access-Control-Allow-Origin" => "*"
    )
}

之后设备A的脚本只需请求/api/b/xxx（比如/api/b/temperature），而不是直接请求设备B的地址。

4. 浏览器端临时绕过（仅测试用） #

仅用于开发测试场景，不适合生产：

• Chrome/Edge：启动时添加参数--ignore-certificate-errors，全局忽略证书错误；
• Firefox：在about:config中设置security.enterprise_roots.enabled = true（适配内网CA场景），或临时手动添加证书例外。

内容的提问来源于stack exchange，提问作者Bruce Hsu