使用MailChimp的API发生SSL错误

时间:2014-04-09 20:53:35

标签: ssl mailchimp

我正在尝试连接MailChimp的API,但不断收到错误:

  

错误。对列表/列表的API调用失败:SSL对等证书或SSH   遥控钥匙不行

然后,我创建了一个cacert.pem文件并将其设置在Mailchimp.php文件中:

$this->ssl_cainfo = ROOT . DS . 'cacert.pem';

得到这个:

  

错误。对列表/列表的API调用失败:SSL证书问题,验证   CA证书没问题。详细信息:错误:14090086:SSL   例程:SSL3_GET_SERVER_CERTIFICATE:证书验证失败

  

错误。对列表/列表的API调用失败:SSL对等证书或SSH   遥控钥匙不行

根据此页面:

我尝试将http://curl.haxx.se/docs/caextract.html文件用于我的cacert.pem文件,但这会导致上面列出的“不正常”错误。

我也尝试使用我们的主机提供的信息(一个文本文件,更改为.pem的扩展名,并将一个和/或两个数据块粘贴到其中,使其看起来像这样):

-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----

或只是一个:

-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----

不知道从哪里开始,尝试什么......等等。

使用此处的示例代码:https://github.com/mailchimp/mcapi2-php-examples

通过作曲家获取供应商文件:

"require": {
    "mailchimp/mailchimp": ">=2.0.0"
},

4 个答案:

答案 0 :(得分:18)

与MailChimp交谈时,他们仍然(2016年1月)使用的证书 - 出于兼容性原因,他们告诉我 - 是 GTE Cyber​​Trust Global Root (注意GTE是由Digicert购买的),所以你不需要替换整个bundle,只需添加或强制PHP来读取这个证书:

https://gte-cybertrust-global-root.digicert.com/info/index.html

(请注意,如果您尝试在Firefox中加载,则会收到“不安全的连接”警告,原因很明显 - 您可以添加例外。)

它是标准的.crt格式,这是你需要的。 Guide to certificate formats

您没有指定服务器是什么,但是这里是如何在Linux上添加额外的服务器而不必替换整个软件包等:

在Debian / Ubuntu上,证书存在/etc/ssl/certs/

  1. 将签名复制并粘贴到该目录中的新文件中,例如mailchimp-legacy.crt
  2. 运行sudo c_rehash /etc/ssl/certs - 这里发生了什么: c_rehash计算每个证书的短哈希,并创建一个符号链接到原始.pem或.crt文件。基本上它是openssl的快速查找表 - openssl也将执行散列并查找符号链接,而不是必须拥有证书名称数据库或依次打开每个文件以找到正确的。
  3. 检查它是否适用于此:ls -lh *.0 | grep 'mailchimp-legacy.crt'
  4. 你应该看到这样的事情:

    lrwxrwxrwx 1 root root 20 Feb 13 14:17 4d654d1d.0 -> mailchimp-legacy.crt
    lrwxrwxrwx 1 root root 20 Feb 13 14:17 c692a373.0 -> mailchimp-legacy.crt
    

    另外:在Debian上,还有一个名为/etc/ca-certificates.conf的文件,行!mozilla/GTE_CyberTrust_Global_Root.crt中的感叹号表示不使用该文件。我相信可以在/usr/share/ca-certificates/mozilla下放置一个带有该名称的证书副本并运行sudo update-ca-certificates,但在我看来它可能会在包裹& amp;配置文件下次更新。

    请务必删除您使用的所有变通方法 - 例如 - 证书目录中的旧CA捆绑包 - 在PHP中覆盖CURLOPT_CAINFO的任何地方 - php.ini中的openssl.cainfo行

    检查您的应用程序是否正常工作。我不需要重启PHP或我的网络服务器,变化是即时的。值得使用apt-get update/upgrade检查您是否拥有最新的证书包。

    以下是从命令行验证特定服务器的SSL连接(和验证)的方法:

    echo GET | openssl s_client -CApath /etc/ssl/certs/ -connect us3.api.mailchimp.com:443 2>&1
    

    监控:(已更新)MailChimp的v2.0 API(已弃用)有一个名为'helper/ping'的端点,它返回一些文本以指示API状态 - 可用作API运行状况的自动测试并且您的证书仍然有效。如果您使用的是v3.0,他们建议您使用API Root Resource并附加?fields=account_name,如果您实际上不需要检查任何数据。

    有人在评论中询问这是否与Heartbleed有关。 Heartbleed是一个与窃听RAM中数据有关的漏洞漏洞。 Mozilla removed GTE CyberTrust(两次),因为他们想remove all 1024-bit root certificates - 研究表明一个民族国家可以打破1024位的素数。

答案 1 :(得分:7)

您需要较旧的证书:

  

https://github.com/bagder/ca-bundle/blob/e9175fec5d0c4d42de24ed6d84a06d504d5e5a09/ca-bundle.crt

如页面所定义:

  

http://curl.haxx.se/docs/caextract.html

删除了RSA-1024

猜猜Mandrill和Mailchimp使用的是RSA-1024版本。

这就是你需要的那个。我有同样的问题。

答案 2 :(得分:0)

Debian和其他操作系统和浏览器已经删除了1024位证书,因为它们不再被认为是安全的。但Mailchimp还没有转向更高安全性的证书。因此,您必须手动将旧证书重新添加到系统中。

debian 上,正确的解决方案是按照Alternative chain verification failure after 1024b root CAs removal中的说明操作:

  1. 首先,转到GTE CyberTrust Global Root并复制证书:部分(包括-----BEGIN CERTIFICATE----------END CERTIFICATE-----。将其粘贴到文件中 /usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt使用此命令:cat > /usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt

  2. 使用以下命令检查它是否合适:openssl x509 -in /usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt -text -noout

  3. 要启用该证书,请将此行添加到/etc/ca-certificates.confmozilla/GTE_CyberTrust_Global_Root.crt

  4. 更新debian的证书:update-ca-certificates

答案 3 :(得分:-6)

在AppController中,当您创建新的Mailchimp实例时,您实际上可以传递以下选项:

'ssl_verifypeer'

'ssl_verifyhost'

'ssl_cainfo'

当Mailchimp请求数据时,这些映射到Curl。

首先,我尝试修改AppController的第44行,看起来像这样:

       $this->mc = new Mailchimp('yourAPIKey', array('ssl_verifypeer' => false)); //your api key here

这将允许您验证它是导致问题的对等证书。当然我不建议你认为这是一个有效的生产解决方案,这只是一个故障排除步骤。