访问etcd的https服务一直报"certificate host mismatch"错误

tang43

Hi，大家好，向大家求助一个问题，在使用lua_resty_etcd组件访问启用了https的etcd服务时，在指定信任证书后，访问etcd服务一直报“host mismatch”错误，使用curl工具使用指定的证书访问etcd正常，而且使用upstream反向代理目标etcd服务，信任指定的证书后，通过openresty访问代理后的etcd服务却也是正常的。
google之后也没有找到类似的问题，有人知道这个问题怎么解决吗？我现在的临时方案是让lua_resty_etcd访问openresty代理之后的etcd服务(使用http),暂时可用。

tang43

再补充几点我已经分析的点：

这个错误信息确认是openresty里面的ssl握手那个c函数报的；
打开socket error记录日志的选项后，能够观测到大量ssl握手的错误，大意是host不匹配(抱歉日志、截图及函数名等信息都在公司办公用机上发不出来，只能在家里凭记忆来写真 )，没有其他错误，报该错误的函数是nginx的host检验函数；

whuizzzzzz

可以尝试抓包分析下，里面包含比较多的信息。

tang43

whuizzzzzz 谢谢你的回复，已经抓过包了，且走读过相关C代码，没看出来问题在哪儿，因为不会gdb跟踪调试，看来只能修改C代码加日志自己编译看看了。

doujiang24

看起来 “host mismatch” 是 client 端(openresty) 报出来的，通常这种时候，意味着服务端返回的证书域名，跟请求的域名不匹配
用 curl 来请求又是正常的，这个说明跟 1 是矛盾的

抓包分析的话，你可以主要对比用 openresty 和 curl 这两种方式，网络包上的区别，关注两个点：

client 发送的 SNI server name
server 端返回的证书包含的域名

tang43

多谢大家的答复，问题已经解决，根源在于启用了SAN证书；
我们在测试验证环境基于IP来生成了自签名证书（使用了cfssl工具，在生成server证书时，hosts中配置了IP地址、主机名及127.0.0.1），由于指定了hosts，实际上生成了SAN证书，Openresty/Nginx严格遵从了RFC的定义，因此使用IP地址来访问使用该证书的etcd时，会在验证主机名时失败，而curl看起来没有严格遵从相关RFC，故而能够访问成功。、
解决办法很简单，在基于IP地址生成server端证书时，将hosts列表清空，重新生成证书，访问即是OK的。

Jinxin231

tang43 你好，清空hosts列表的意思是清空域名只保留ip吗？