TLS error Hostname/IP doesn't match certificate's altnames

[Shawn Parrish]

We recently upgraded from 0.4.12 to 0.8.14 (about freaking time, huh?)
and our SSL certificate checking is having some troubles with some
CAs.
We're receiving the following error when we test for 'authorized'.

"Hostname/IP doesn't match certificate's altnames"

Here's the pertinent code to reproduce.

var tls = require('tls');
var s = tls.connect(443, 'graph.facebook.com',function(err, response){
if(s.authorized){
console.log('authorized');
}else{
console.log('cert auth error: ', s.authorizationError);
}
});

We're seeing this with some digicert and some thawte certs so far.
Most don't throw the error.

Anything change in the CA handling or checkServerIdentity function of
0.8.14 that would make these connections show as unauthorized now?

Thanks,
Shawn

[Ben Noordhuis]

I guess it's to be expected. Here is what `openssl s_client
graph.facebook.com:443` prints:

CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
High Assurance EV Root CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Palo Alto/O=Facebook, Inc./CN=*.facebook.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root CA
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root CA
i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref.
(limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure
Server Certification Authority

AFAIK, all of DigiCert's signing authority has been revoked so it's no
wonder the certificate doesn't validate.

It *is* rather peculiar that the curl on my system accepts it just
fine, though. Maybe my system's certificate store needs updating...

[Shawn Parrish]

We thought that might be the case but the checks work fine in 0.4.12,
are seen as valid by all major browsers as well as curl, like you
said. Some Thawte certs which I believe are valid are also failing
with this error message.

I'm pretty sure the error is incorrect as the hostname matches.

Any other ideas?

Thanks,
Shawn

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[Ben Noordhuis]

On Thu, Nov 8, 2012 at 6:28 PM, Shawn Parrish <spar...@nodeping.com> wrote:
> We thought that might be the case but the checks work fine in 0.4.12,
> are seen as valid by all major browsers as well as curl, like you
> said. Some Thawte certs which I believe are valid are also failing
> with this error message.
>
> I'm pretty sure the error is incorrect as the hostname matches.
>
> Any other ideas?
>
> Thanks,
> Shawn

I wouldn't put too much weight on what 0.4.x does, its SSL/TLS
implementation is horribly flawed. If you have examples of sites that
you believe should validate, please open an issue and I'll look into
it.

[Shawn Parrish]

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

Looks like these certs don't have a subjectaltname element like most
wildcard certs do.
lib.js assumes wildcard certs will have subjectaltname and doesn't
check the depreciated subject.CN for wildcard match on lines 163 and
166.

I'll submit an issue, just wanted to document it here as well.
I can send a pull request as well if you'd like.

Thanks,
Shawn