【玩转腾讯云】排障coscli下载文件报net/http: TLS handshake timeout 握手超时

Windows技术交流 • 2023-01-02 • 云技术社区 • 281 阅读

COSCLI、COSCMD、COSBrowser等工具都是非常好用的cos工具，coscmd支持https、http，coscli只支持https，下面这个case表面是coscli报错，实际是windows系统的问题。为了避免出现证书问题，建议使用coscmd ，在同地域cvm 、cos环境里，用http访问，效率高，没有证书相关问题。

coscli简介：https://cloud.tencent.com/document/product/436/63143

问题：coscli下载文件报net/http: TLS handshake timeout 握手超时

场景：同地域cvm、cos，cvm没有分配公网IP，只能通过内网访问同地域cos

coscli默认走https，不支持http访问

但是直接IE浏览器访问对应的http链接能正常下载文件，就https不行

【coscli测试】

配置coscli环境

mkdir c:\\coscli

cd c:/coscli

powershell -c wget http://windowscq-1251783334.cos.ap-chongqing.myqcloud.com/coscli-windows.exe -outfile c:/coscli/coscli.exe

fsutil file createnew c:/coscli/.cos.yaml 0

coscli config add -b windowscq-1251783334 -r ap-chongqing -a windowscq-1251783334 -c c:/coscli/.cos.yaml

coscli config show -c c:/coscli/.cos.yaml

测试coscli下载

coscli cp cos://windowscq-1251783334/ceshi.txt c:/users/Administrator/ceshi1.txt --config-path c:/coscli/.cos.yaml

【浏览器测试】

https://windowscq-1251783334.cos.ap-chongqing.myqcloud.com/ceshi.txt

http://windowscq-1251783334.cos.ap-chongqing.myqcloud.com/ceshi.txt

测试过程中发现

①firefox能直接访问cos https，但是coscli下载文件报net/http: TLS handshake timeout 握手超时

②IE能直接访问cos http，访问很快，但是IE访问cos https一直转圈，转很久很久才出结果

③当IE访问cos https时，不用管访问的结果，立即测试coscli下载cos文件已经正常

对比发现，客户端机器里的GlobalSign Root CA - R1证书不存在，当IE访问cos https时自动触发了该证书安装，因此coscli才恢复正常。coscli恢复后，多次重启机器，发现概率性出现GlobalSign Root CA - R1该特定证书不存在的情况，跟当前客户端机器的环境有关系，排查思路是修复好证书后把开机启动程序设置为不启动，多次重启机器观察看问题是否还能复现。

【解决方案】发现通过IE浏览器访问cos https链接时，会自动安装cos的GlobalSign Root CA - R1证书（有效期2028年1月28日）

运行certmgr.msc → 从下面2处手动删除GlobalSign Root CA - R1证书后，没有公网的cvm用coscli下载cos文件报错net/http: TLS handshake timeout 握手超时

证书里面里按截止日期顺序排列找日期是比较好定位的

然后用IE访问同地域cos https链接，不论IE访问是否立即得到结果（正常应该是转圈若干分钟），只要IE地址栏粘贴了同地域cos https链接（不用具体到文件，到域名即可，具体到文件也可以）回车，然后就会触发自动安装GlobalSign Root CA - R1证书，回车后不用等，马上测试coscli，恢复正常

例如https://cos.ap-chongqing.myqcloud.com

即便手动删除了GlobalSign Root CA - R1证书，firefox等浏览器还是能直接访问cos https，而不是像IE浏览器那样一直转圈若干分钟。原因是firefox等浏览器有独立的证书管理机制，而不是借用操作系统的。

总结：经查，发现IE访问http正常、访问https转圈若干分钟，而firefox访问http、https都正常，当IE访问https正常后，coscli访问也正常，重启机器后IE和coscli又不正常了。

怀疑coscli、IE走了系统默认的证书（可能有问题），firefox或其他高速浏览器走了单独的证书，有了解到

Chrome browsers, Firefox, Opera and Safari, i.e. all that are not based on the Internet Explorer engine use their own SSL and TLS support modules

Common web browsers (e.g. Google Chrome, Firefox, Microsoft Edge and Safari) maintain their own list of trusted CAs.

(i. e. 是拉丁语 id est 的缩写，意思是“那就是说、换句话说”，用来进一步解释前面所表明的观点。e.g. = for example)

手动删除掉证书后，在coscli超时期间，系统向ctldl.windowsupdate.com发送过请求（本地没有证书时，windows系统会自动更新证书）

上述方案，翻译成命令就是

start /min "C:\\Program Files\\Internet Explorer\\iexplore.exe" "https://cos.ap-chongqing.myqcloud.com"

或

start /min /d C:\\Progra~1\\Intern~1 iexplore.exe "https://cos.ap-chongqing.myqcloud.com"

/d是指定目录C:\\Progra~1\\Intern~1

C:\\Progra~1\\Intern~1就是C:\\Program Files\\Internet Explorer\\

或者执行coscli前，执行下面这2句命令也可以下载、导入GlobalSign Root CA - R1证书

certutil -urlcache -split -f http://windowscq-1251783334.cos.ap-chongqing.myqcloud.com/Root-R1.crt c:/Root-R1.crt

certutil -addstore root c:/Root-R1.crt

请注意，高版本系统的defender可能会拦截certutil命令。

这个Root-R1.crt是我从证书签发机构的官网下载后放到cos的，然后从cos http下载到cvm再导入

https://support.globalsign.com/ca-certificates/root-certificates/globalsign-root-certificates

https://valid.r1.roots.globalsign.com/

GlobalSign Root CA - R1证书历史久远，从windows xp时代就存在，在有问题的机器里，鬼使神差被删除了，导致访问cos https异常，假如机器有公网，访问cos https时会自动更新受信任的根证书列表安装对应站点的证书，但是有问题的机器正好没有公网导致了这种尴尬，只能人为干预来恢复GlobalSign Root CA - R1证书。

其实Windows的受信任根证书是很多的，至少400多个，其中就有这个GlobalSign Root CA - R1证书。

ctldl.windowsupdate.com是windows默认更新受信任根证书时查找的地址，精确点是这个目录下的.crt文件

http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/*.crt

这个目录下目前有433个.crt

使用下面这个命令可以把它们打包为.sst文件，

certutil -generateSSTFromWU c:\\WURoots.sst

.sst文件是放置.crt文件的"容器"，.sst文件在资源管理器里双击是能查看内容的

顾名思义，看certutil的generateSSTFromWU参数，就是从ctldl.windowsupdate.com去获取.crt来生成.sst文件

因为目录下证书比较多，且域名ctldl.windowsupdate.com接了cdn，cdn各节点的质量层次不齐，所以执行certutil -generateSSTFromWU c:\\WURoots.sst 命令时可能会超时，比如

操作超时 0x80072ee2 (WIN32: 12002) -- http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/06f1aa330b927b753a40e68cdf22e34bcbef3352.crt

CertUtil: -generateSSTFromWU 失败: 0x80072ee2 (WIN32: 12002)

CertUtil: 操作超时

操作超时 0x80072ee2 (INet: 12002 ERROR_INTERNET_TIMEOUT) -- http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/313b8d0e7e2e4d20ae8668ffe59db5193cbf7a32.crt

CertUtil: -generateSSTFromWU 失败: 0xc0000005 (NT: 0xc0000005 STATUS_ACCESS_VIOLATION)

如果某些客户端机器执行certutil -generateSSTFromWU c:\\WURoots.sst一直报错，那就换台机器执行，得到WURoots.sst 后拿到不能获取WURoots.sst 的机器来用。

一般来说找台网络好的机器执行certutil -generateSSTFromWU c:\\WURoots.sst 把生成的.sst文件传输到网络隔离的机器（即不能自动更新受信任根证书的机器，比如没有分配外网的机器）再导入就可以，可以打开certmgr.msc找到.sst文件位置手动导入（400多个证书一个一个弹窗让你确认，太麻烦了，还是看后面的静默导入方案吧），

也可以使用微软的专用工具updroots.exe就可以一次性静默、快速导入最新的433个受信任根证书

我把updroots.exe和WURoots.sst放在C盘根目录了

管理员身份打开cmd执行c:\\updroots.exe c:\\WURoots.sst

或者进到目录执行

cd /d c:\\

updroots.exe WURoots.sst

updroots.exe我放置到cos了，链接如下

http://windowscq-1251783334.cos.ap-chongqing.myqcloud.com/updroots.exe

updroots.exe实际是微软20年前出的给XP系统更新受信任根证书工具Rootsupd.exe里的命令（用7zip解压Rootsupd.exe就能提取到updroots.exe），但XP早就淘汰了，微软也把下载链接给做失效处理了，原本的下载链接是

http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe

不过卡巴斯基官网留存了这个软件

http://media.kaspersky.com/utilities/CorporateUtilities/rootsupd.zip