Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

certificate not trusted errors with amazon cert chains #402

Closed
nicks opened this issue Jan 14, 2015 · 17 comments
Closed

certificate not trusted errors with amazon cert chains #402

nicks opened this issue Jan 14, 2015 · 17 comments
Labels
tls Issues and PRs related to the tls subsystem.

Comments

@nicks
Copy link

nicks commented Jan 14, 2015

Using io.js 1.0.1, Install the request module and run the following code:

var r = require('request')
r.get('https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-1.9.8-macosx.zip')

Gives the result:

events.js:73
      throw er; // Unhandled 'error' event
            ^
Error: certificate not trusted
    at Error (native)
    at TLSSocket.<anonymous> (_tls_wrap.js:895:36)
    at TLSSocket.emit (events.js:92:17)
    at TLSSocket._finishInit (_tls_wrap.js:438:8)

This appears to be the same bug as this nodejs issue:
nodejs/node-v0.x-archive#8894

@bnoordhuis
Copy link
Member

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.

@focusaurus
Copy link
Contributor

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);
});

@bnoordhuis
Copy link
Member

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 Authority

The 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.

@bnoordhuis bnoordhuis added tls Issues and PRs related to the tls subsystem. and removed unconfirmed labels Jan 14, 2015
@piscisaureus
Copy link
Contributor

Is there a way to contact amazon about it?

bnoordhuis added a commit to bnoordhuis/io.js that referenced this issue Jan 14, 2015
Nolens volens add back a 1024 bits Verisign Class 3 certificate that is
still in use by AWS S3.

Fixes: nodejs#402
@focusaurus
Copy link
Contributor

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.

@indutny
Copy link
Member

indutny commented Jan 14, 2015

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&#590738
seems like a very similar (identical?) issue/discussion.


Reply to this email directly or view it on GitHub
#402 (comment).

@shigeki
Copy link
Contributor

shigeki commented Jan 15, 2015

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)

@bnoordhuis
Copy link
Member

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.

@indutny
Copy link
Member

indutny commented Jan 15, 2015

@bnoordhuis I'll ask Rich

@bnoordhuis
Copy link
Member

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.

@shigeki
Copy link
Contributor

shigeki commented Jan 16, 2015

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?

@rvagg
Copy link
Member

rvagg commented Jan 16, 2015

@bnoordhuis @indutny if I cut a 1.0.2 today, will this make it so node-pre-gyp can work again?

@rvagg
Copy link
Member

rvagg commented Jan 16, 2015

urgh, sorry, read the above comment from @bnoordhuis, will go ahead

@bnoordhuis
Copy link
Member

@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. :-)

@pixelprodev
Copy link

confirmed works in 1.0.2 thanks

@rvagg rvagg closed this as completed Jan 18, 2015
@shigeki
Copy link
Contributor

shigeki commented Jan 20, 2015

@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.h as 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.

@indutny
Copy link
Member

indutny commented Jan 27, 2015

shigeki pushed a commit to shigeki/node that referenced this issue Mar 13, 2015
The host of melissadata.net has a cross root certification between
Starfield Class 2 and ValiCert Class 2. OpenSSL-1.0.1 only looks up
a cert chain to the deprecated ValiCert Class 2 CA and causes
untrusted error. We add it for a short-term remedy and it is to be
removed after upgrading OpenSSSL-1.0.2 and applying private patches
to support alternative cert chains.
See nodejs#402 and nodejs#589.

Fixes: nodejs#923
shigeki pushed a commit that referenced this issue Mar 13, 2015
The host of melissadata.net has a cross root certification between
Starfield Class 2 and ValiCert Class 2. OpenSSL-1.0.1 only looks up
a cert chain to the deprecated ValiCert Class 2 CA and causes
untrusted error. We add it for a short-term remedy and it is to be
removed after upgrading OpenSSSL-1.0.2 and applying private patches
to support alternative cert chains.
See #402 and #589.

Fixes: #923
PR-URL: #1135
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tls Issues and PRs related to the tls subsystem.
Projects
None yet
Development

No branches or pull requests

8 participants