Node.js请求CERT_HAS_EXPIRED

Question

我正在使用Mikeal的请求（https://github.com/mikeal/request）向服务器发出https请求。但是，我一直收到CERT_HAS_EXPIRED的授权错误。

request({
        url: 'https://www.domain.com/api/endpoint',
        strictSSL: false
    }, function(error, response, body) {
        if(!error && response.statusCode == 200) {
            res.json(JSON.parse(body));
        } else {
           res.json(response.statusCode, {'error': 'error'})
        }
});

我尝试将strictSSL设置为true和false，两者都输出CERT_HAS_EXPIRED的相同错误。导致此问题的原因是什么方法可以在nodejs中修复它？

Answer 1

解决此问题的最佳方法：

续订证书。这可以使用Greenlock免费完成，{{3}}通过Let's Encrypt™v2

颁发证书

less 不安全的解决方法：

'use strict';

var request = require('request');
var agentOptions;
var agent;

agentOptions = {
  host: 'www.example.com'
, port: '443'
, path: '/'
, rejectUnauthorized: false
};

agent = new https.Agent(agentOptions);

request({
  url: "https://www.example.com/api/endpoint"
, method: 'GET'
, agent: agent
}, function (err, resp, body) {
  // ...
});

通过agent使用rejectUnauthorized，您至少可以将安全漏洞限制在处理该网站的请求中，而不是让您的整个节点完全处理，完全不安全。

其他选项

如果您使用的是自签名证书，则可以添加此选项：

agentOptions.ca = [ selfSignedRootCaPemCrtBuffer ];

对于可信对等连接，您还可以添加以下两个选项：

agentOptions.key = clientPemKeyBuffer;
agentOptions.cert = clientPemCrtSignedBySelfSignedRootCaBuffer;

坏主意

遗憾的是process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';甚至记录在案。它应该仅用于调试，并且永远不应该在一些在野外运行的代码中进行调试。几乎每个在https之上运行的库都有一种传递代理选项的方法。不应该修复那些。

Answer 2

在文件顶部添加：

process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

危险这将禁用整个node.js环境中的HTTPS / SSL / TLS检查。请使用下面的https代理查看解决方案。

Answer 3

这是一种更简洁的方法来实现CoolAJ86提出的“不太安全”的方法

?discrete_scale

Answer 4

我认为strictSSL: false应该（应该在2013年工作）。简而言之，有三种可能的方式：

1. （显而易见）让您的CA续订证书，并将其放在您的服务器上！
2. 更改request对象的默认设置：
   
   const myRequest = require('request').defaults({strictSSL: false})
   
   许多在内部使用node-request的模块也允许注入request - 对象，因此您可以使用已修改的实例。
3. （不推荐）通过为Node.js进程设置环境变量NODE_TLS_REJECT_UNAUTHORIZED=0，覆盖所有 HTTP（S）代理连接的所有证书检查。

Answer 5

尝试临时修改request.js并在任何地方harcode rejectUnauthorized = true，但最好将证书扩展为长期解决方案。

Answer 6

今天早上在我的Macbook Pro上调试时，我在Heroku和本地生产环境中遇到了此问题。

经过一个小时的调试，此问题在本地和生产上均自行解决。我不确定是什么解决了这个问题，所以有点烦人。当我以为自己做了某件事时就发生了，但是恢复我的修复并没有使问题恢复原状：（

有趣的是，似乎我的数据库服务MongoDb从今天早上开始就一直出现服务器问题，因此很有可能与此有关。