ホストマシンがCentOS6.Xのpython2系においてpycurlを含むスクリプトを実行したところ、
pycurl.error: (35, 'SSL connect error')
と出力されてしまっていた。。。
あー、SSLのアクセスがエラーなのね、と。。

尚、ステージング環境では同様のスクリプトは動いているという謎・・・
「差分マジ不明」、とか「そもそも前は使えてたんかな？」と疑問に思いつつ、色々と調べた。

以下の様に、インタラクティブモードで検証を行う

import pycurl
c = pycurl.Curl()
c.setopt(pycurl.URL, 'https://XXXX')
c.setopt(pycurl.VERBOSE, True)
c.perform()

ダメな環境のダメっぽいログ(これが原因かなと判断した)
----以下は抜粋----

* NSS error -5938
* Closing connection #0
* SSL connect error

OKっぽいログ(↓が出てたからOKと判断した)

-----以下は抜粋-----

< HTTP/1.1 200 OK

ここで、
んーー、pycurl自体が悪いのかなー、などと思案するも、
どうも大丈夫そう。(確認方法失念)

そもそものcurlのバージョンとかなのかな、と思案する。

yum info libcurl

それも同じ。。。

なにが悪いのか全然分からん、と思って
ここでようやく↓のログ

* NSS error -5938

について調べる。
※色々調べて3時間くらい無駄にしてる

NSSってなんや。。

無知なわたしはNSSを調べると、
https://ja.wikipedia.org/wiki/Network_Security_Services
SSLライブラリであるということが分かる。

ひとまず脆弱性があるらしいということなので、バージョンを調べる。

rpm -q nss nss-util nspr

nss-3.16.2.3-3.el6_6.x86_64
nss-util-3.16.2.3-2.el6_6.x86_64
nspr-4.10.6-1.el6_5.x86_64

脆弱性があるやつなのね・・・

と思ってスクリプトが正常実行できる環境で同様に確認してみる。

rpm -q nss nss-util nspr

nss-3.21.0-8.el6.x86_64
nss-util-3.21.0-2.el6.x86_64
nspr-4.11.0-1.el6.x86_64

バージョン全然違うやんけ。
curlもpycurlも実行環境(ホストマシン)のNSS見るということなんですね、きっと、なるほど。。。

ちなみに、

本番

cat /etc/redhat-release
CentOS release 6.6 (Final)

ステージング

cat /etc/redhat-release
CentOS release 6.8 (Final)

CentOSのバージョンも違うやんけ。

たぶん、CentOS6.6は脆弱性持ってるNSSが最初っからバンドルされている、
6.8は脆弱性対応済みのNSSをバンドルしている、
という差分があるんだろうな、という推測。

ひとまず↓を実行する

yum update nss nss-util nspr

その後、実行不可となっていたスクリプトを再度実行するとエラーが無く実行可能となった。(事象解決)
ここまで調査開始から8時間くらい費やしてる気がする。。

curl実行出来ない方はお試しあれ。。
(脆弱性対応してあれば問題無いんですけどね)