不行了，找遍了国外社区都解决不掉，召唤大神的出现。python requests 在 Debian/Ubuntu 上无法进行 TLS 握手?

有个用 Requests 的脚本，访问 https://dictation.nuancemobility.net 这个 URL 。但是奇怪的是在 CentOS 可以正常工作，从服务器获得 200 响应，放到 Debian/Ubuntu 上就只能从服务器获得 500 响应。
这个代码如下：

<pre><code>

class Nuance_api():

def __init__(self, appid, appkey, n_id):
self.appid = appid
self.appkey = appkey
self.id = n_id

def recogenize(self, language, voicefile):
nuance_url = 'https://dictation.nuancemobility.net/NMDPAsrCmdServlet/dictation'
n_params = {'appId':self.appid, 'appKey':self.appkey, 'id':self.id}
voice_file = {'file': open(voicefile, 'rb')}
n_headers = {'Accept-Language':language, 'Content-Type':'audio/amr;codec=amr;bit=4.75;rate=8000', 'Accept':'text/plain', 'Accept-Topic':'Dictation'}
r = requests.post(url=nuance_url, params=n_params, headers=n_headers, files=voice_file, verify=False)
if r.status_code == 200 :
return r.text

</code></pre>

由于涉及到隐私的 key 等信息，单用这段代码测试比较麻烦。可以说明的是，这段代码在 CentOS 没有任何问题，可以返回识别的 text.

那么，事情就集中到： Debian/Ubuntu 上的 requests 为什么就不能像 CentOS 一样工作？

经过一些 debug ，这个服务器使用 TLS v1.2 或 v1 来进行握手，那么我甚至将代码改写为强制使用 TLS v1.2 ，在 Debian/Ubuntu 上同样失败。抓包显示，握手后服务端连续发来 4 个 hello ，但是在 CentOS 上的抓包显示为握手后就开始传输数据了。这表明握手并不成功（至少我这么认为）。

有些文章说 Debian/Ubuntu 上的 openssl 默认不设定任何 CA bundle ，但是 Requests 使用的是自己的 CA bundle ，为了测试，特意在代码中将 verify='我的 cacert.pem'，当我的 cacert.pem 里没有任何 root certificate 的时候，确实是 ssl verify failure ，加上该网站证书链里的顶级 VeriSign Class 3 证书，就可以通过验证。所以， CA bundle 不是症结。

那么，究竟为什么。到底 Debian/Ubuntu 上使用 Requests 的正确姿势是什么呢？

盼望这里有大神有些许经验。 Stackoverflow, GitHub 在这个问题上都阵亡了。满世界都是 ssl 验证不通过的问题，但是能有效解决的很少。涉及 requests ，那就更少了。

adrianzhang

2015-10-01 09:31:08 +08:00

@dingyaguang117 说起来一肚子苦水。

事情原本是这样的：标的环境是那个 Debian ，固定版本号的各种组件。在这个环境里写的脚本不 work 。为了找原因，用替换法，换个环境，结果就恰巧换到了那个 CentOS 。而脚本在 CentOS 上 work ，把我引入歧途，误以为问题出在 Debian 的某些配置上，既不是 Nuance 方面的问题也不是脚本的问题。所以一直纠结在 Debian 环境的排错上，所以才一周时间都徘徊在死胡同里。

跟作者沟通，他也直说了，即使是老版本，也需要用 data 对象，至于为什么 CentOS 上能工作，这对他来说也是一个谜。可能会涉及到更底层的一些东西，比如 python 的处理或者 Linux 本身的处理。这个没有时间去具体分析，等项目结束有空的时候，再去深挖一下到底是什么情况。太罕见了。