Repository navigation
certificate not trusted errors with amazon cert chains #402
Description
Activity
I can't reproduce, maybe it's an issue with the request module. With just
require('https').get(...), I can access that URL just fine. bitbucket.org is using a 2048 bits DigiCert certificate so whatever the issue is, it's probably not nodejs/node-v0.x-archive#8894.There's a redirect that is causing the issue which request follows but https does not. This snippet will reproduce:
var https = require("https"); https.get('https://bbuseruploads.s3.amazonaws.com/ariya/phantomjs/downloads/phantomjs-1.9.8-macosx.zip?Signature=9qpxd%2B6yFBy%2B8DeBdSR2ylHkZXw%3D&Expires=1421254735&AWSAccessKeyId=0EMWEFSGA12Z1HF1TZ82', function (error, result) { console.log(error, result); });Thanks. The chain for that URL is:
Certificate chain 0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=*.s3.amazonaws.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification AuthorityThe S3 certificate is backed by the offending VeriSign that was phased out over a year ago.
@indutny Thoughts? I suppose we should cherry-pick the certificate but it's kind of bad form for AWS to be so negligent in upgrading their certificates.
Is there a way to contact amazon about it?
- added a commit that references this issue
on Jan 14, 2015 Probably the S3 community forum would be a good place to start by posting details of the issue. Seems like other cert-related issues have been discussed there. Specifically this thread seems like a very similar (identical?) issue/discussion.
Ben,
Do you remember that OpenSSL patch about cert chain? I think we should
consider it in one form or another. Or move the cert check to node.js.Adding 1024-bit CAs is not a solution at all!
On Wednesday, January 14, 2015, Peter Lyons notifications@github.com
wrote:Probably the S3 community forum
https://forums.aws.amazon.com/search.jspa?objID=f24&q=certificate&x=0&y=0
would be a good place to start by posting details of the issue. Seems like
other cert-related issues have been discussed there. Specifically this
thread
https://forums.aws.amazon.com/thread.jspa?messageID=590738򐎒
seems like a very similar (identical?) issue/discussion.—
Reply to this email directly or view it on GitHub
#402 (comment).openssl-1.0.2(beta in now) has a new flag to solve this. It's easy to backported to openssl-1.0.1 and working fine as written in nodejs/node-v0.x-archive#8894 (comment)
X509_V_FLAG_TRUSTED_FIRST? Seems reasonable but will the flag be opt-in or opt-out? Opt-out would change the behavior of code that specifies its own CA chain, wouldn't it?
Aside, does anyone know why the X509_V_FLAG_TRUSTED_FIRST patch hasn't been back-ported to 1.0.1? It was landed in openssl HEAD almost five years ago.
@bnoordhuis I'll ask Rich
I think it was @piscisaureus that landed 0926cb9 earlier today, provisionally resolving this issue. A better fix would still be good and I'm keeping the issue open for now but at least v1.0.2 will work with AWS again.
Seeing nodejs/node-v0.x-archive@1425ccd , there are still several 1024-bit root certs missed. Why that commit was not merged to io.js?
@bnoordhuis @indutny if I cut a 1.0.2 today, will this make it so node-pre-gyp can work again?
urgh, sorry, read the above comment from @bnoordhuis, will go ahead
@shigeki I was planning to take a reactive approach here (i.e. don't do anything until someone reports a bug) because I don't think the other CAs are in widespread use, but if you think that commit is worth taking, I'll land it.
Actually, I'll be happy to give you commit access so you can land it yourself. Just follow the regular review process, please. :-)
confirmed works in 1.0.2 thanks
@bnoordhuis I read the related thread of https://groups.google.com/d/msg/mozilla.dev.security.policy/JFGRyr4-F44/d0UGCCoUeh4J in part not a whole as it's a long thread and I found that mozilla took two actions, one is for Entrust, https://bugzilla.mozilla.org/show_bug.cgi?id=1045189 and the other for GTE, https://bugzilla.mozilla.org/show_bug.cgi?id=1047011 .
In Entrust case, mozilla added an intermediate cross certs of USERTrust CA in certdata.txt to mitigate deprecation. In iojs, it does not include in
node_root_certs.has its flag is not CKT_NSS_TRUSTED_DELEGATOR but I think it is not so much impacts because the cross cert will be expired soon in Nov. 2015.
In GTE case, mozilla is making surveys to check how much sites are affected. They showed the number is getting decreased and a new survey will be made in this month.Seeing above, I agree your plan to take a reactive approach with just remembering this issue existed.
It's my honor to have a commit access, thanks. In this case it would not be needed. I would like to help this project as much as I can spend time on iojs. Thanks.
Using io.js 1.0.1, Install the request module and run the following code:
Gives the result:
This appears to be the same bug as this nodejs issue:
nodejs/node-v0.x-archive#8894