我的OpenShift帐户中有2个档位,第一个返回OK(200)响应,而另一个返回Forbidden(403)响应。两者都向同一主机发送相同的cURL请求。齿轮的主要区别在于一个齿轮运行Node.js而另一个齿轮运行Python。
此问题在json调用同一主机中复制,Python齿轮工作(200)和Node.js齿轮失败,(403)响应或 self_signed_cert_in_chain 错误取决于我如何拨打电话。
似乎没有关于如何比较两个齿轮之间差异的任何信息。任何协助解决底层问题是什么以及如何解决它,以便Node.js应用程序可以进行json调用将是非常棒的。
curl -d '{}' -H "Content-Type: application/json" https://cn-dc1.uber.com:443/ --trace-ascii -
== Info: About to connect() to cn-dc1.uber.com port 443 (#0)
== Info: Trying 104.36.192.190... == Info: connected
== Info: Connected to cn-dc1.uber.com (104.36.192.190) port 443 (#0)
== Info: Initializing NSS with certpath: sql:/etc/pki/nssdb
== Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
== Info: SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA
== Info: Server certificate:
== Info: subject: CN=*.uber.com,OU=Domain Control Validated
== Info: start date: Apr 21 23:32:02 2014 GMT
== Info: expire date: Aug 06 23:59:59 2017 GMT
== Info: common name: *.uber.com
== Info: issuer: CN=GlobalSign Domain Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE
=> Send header, 230 bytes (0xe6)
0000: POST / HTTP/1.1
0011: User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
0051: NSS/3.16.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
008d: Host: cn-dc1.uber.com
00a4: Accept: */*
00b1: Content-Type: application/json
00d1: Content-Length: 2
00e4:
=> Send data, 2 bytes (0x2)
0000: {}
<= Recv header, 17 bytes (0x11)
0000: HTTP/1.1 200 OK
<= Recv header, 15 bytes (0xf)
0000: Server: nginx
<= Recv header, 37 bytes (0x25)
0000: Date: Tue, 06 Jan 2015 08:14:47 GMT
<= Recv header, 32 bytes (0x20)
0000: Content-Type: application/json
<= Recv header, 28 bytes (0x1c)
0000: Transfer-Encoding: chunked
<= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
<= Recv header, 69 bytes (0x45)
0000: File-Hashes: locale/messaging.json=a9e6142c96a4ace9494767b208793
0040: 1b3
<= Recv header, 54 bytes (0x36)
0000: File-Hashes: cn.txt=97ac2d5737a3c0768f703a97c465c7ac
<= Recv header, 27 bytes (0x1b)
0000: ReceivedAt: 1420532087986
<= Recv header, 27 bytes (0x1b)
0000: ReturnedAt: 1420532087993
<= Recv header, 25 bytes (0x19)
0000: X-Uber-App: cn_failover
<= Recv header, 44 bytes (0x2c)
0000: Strict-Transport-Security: max-age=2592000
<= Recv header, 2 bytes (0x2)
0000:
<= Recv data, 75 bytes (0x4b)
0000: 40
0004: {"messageType":"Error","description":"Invalid application type"}
0046: 0
0049:
{"messageType":"Error","description":"Invalid application type"}== Info: Connection #0 to host cn-dc1.uber.com left intact
== Info: Closing connection #0
curl -d '{}' -H "Content-Type: application/json" https://cn-dc1.uber.com:443/ --trace-ascii -
== Info: About to connect() to cn-dc1.uber.com port 443 (#0)
== Info: Trying 104.36.192.200... == Info: connected
== Info: Connected to cn-dc1.uber.com (104.36.192.200) port 443 (#0)
== Info: Initializing NSS with certpath: sql:/etc/pki/nssdb
== Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
== Info: SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA
== Info: Server certificate:
== Info: subject: CN=*.uber.com,OU=Domain Control Validated
== Info: start date: Apr 21 23:32:02 2014 GMT
== Info: expire date: Aug 06 23:59:59 2017 GMT
== Info: common name: *.uber.com
== Info: issuer: CN=GlobalSign Domain Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE
=> Send header, 230 bytes (0xe6)
0000: POST / HTTP/1.1
0011: User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
0051: NSS/3.16.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
008d: Host: cn-dc1.uber.com
00a4: Accept: */*
00b1: Content-Type: application/json
00d1: Content-Length: 2
00e4:
=> Send data, 2 bytes (0x2)
0000: {}
<= Recv header, 24 bytes (0x18)
0000: HTTP/1.1 403 Forbidden
<= Recv header, 15 bytes (0xf)
0000: Server: nginx
<= Recv header, 37 bytes (0x25)
0000: Date: Tue, 06 Jan 2015 08:15:08 GMT
<= Recv header, 25 bytes (0x19)
0000: Content-Type: text/html
<= Recv header, 21 bytes (0x15)
0000: Content-Length: 162
<= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
<= Recv header, 2 bytes (0x2)
0000:
<= Recv data, 162 bytes (0xa2)
0000: <html>
0008: <head><title>403 Forbidden</title></head>
0033: <body bgcolor="white">
004b: <center><h1>403 Forbidden</h1></center>
0074: <hr><center>nginx</center>
0090: </body>
0099: </html>
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
== Info: Connection #0 to host cn-dc1.uber.com left intact
== Info: Closing connection #0
要解决这两个服务器解析到不同IP的问题,我尝试了以下命令并获得了有趣的结果。
curl -d '{}' -H "Content-Type: application/json" https://104.36.192.191:443/ --trace-ascii -
服务器失败的结果
== Info: About to connect() to 104.36.192.191 port 443 (#0)
== Info: Trying 104.36.192.191... == Info: connected
== Info: Connected to 104.36.192.191 (104.36.192.191) port 443 (#0)
== Info: Initializing NSS with certpath: sql:/etc/pki/nssdb
== Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
== Info: SSL: certificate subject name '*.uber.com' does not match target host name '104.36.192.191'
== Info: NSS error -12276
== Info: Closing connection #0
curl: (51) SSL: certificate subject name '*.uber.com' does not match target host name '104.36.192.191'
[node-squirrell.rhcloud.com 54a7f92a5973ca681a00000d]\> timed out waiting for input: auto-logout
Connection to node-squirrell.rhcloud.com closed.
来自OK服务器的结果
== Info: About to connect() to 104.36.192.191 port 443 (#0)
== Info: Trying 104.36.192.191...
== Info: Adding handle: conn: 0x7fb939804000
== Info: Adding handle: send: 0
== Info: Adding handle: recv: 0
== Info: Curl_addHandleToPipeline: length: 1
== Info: - Conn 0 (0x7fb939804000) send_pipe: 1, recv_pipe: 0
== Info: Connected to 104.36.192.191 (104.36.192.191) port 443 (#0)
== Info: SSL certificate problem: Invalid certificate chain
== Info: Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
这看起来像Python和Node.JS齿轮之间的ssl / certification库不一样或配置不同。
答案 0 :(得分:0)
失败的(使用IP)似乎只是打破名称不匹配。还有一个提示:https://www.ssllabs.com/ssltest/analyze.html?d=cn-dc1.uber.com&latest 表示证书链可能包含额外的可下载中间证书,您的应用可能不支持它。您可能需要将其添加到nodejs密钥库。