Issuer API error: UNABLE_TO_VERIFY_LEAF_SIGNATURE

[stenington]

Originially reported in #841.

Hi!

I've a similar issue:

Here is the JSON answer that OpenBadges sends back:

{"message":"could not get assertion: unreachable",
"stack":"Error: could not get assertion: unreachable\n    at makeError (/var/www/openbadges/lib/analyze-assertion.js:6:26)\n    at Request._callback (/var/www/openbadges/lib/analyze-assertion.js:18:23)\n    at self.callback (/var/www/openbadges/node_modules/request/main.js:120:22)\n    at Request.EventEmitter.emit (events.js:95:17)\n    at ClientRequest.self.clientErrorHandler (/var/www/openbadges/node_modules/request/main.js:223:10)\n    at ClientRequest.EventEmitter.emit (events.js:95:17)\n    at CleartextStream.socketErrorListener (http.js:1520:9)\n    at CleartextStream.EventEmitter.emit (events.js:95:17)\n    at SecurePair.<anonymous> (tls.js:1365:19)\n    at SecurePair.EventEmitter.emit (events.js:92:17)",
"code":"http-unreachable",
"extra":{"message":"UNABLE_TO_VERIFY_LEAF_SIGNATURE",
"stack":"Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE\n    at SecurePair.<anonymous> (tls.js:1346:32)\n    at SecurePair.EventEmitter.emit (events.js:92:17)\n    at SecurePair.maybeInitFinished (tls.js:959:10)\n    at CleartextStream.read [as _read] (tls.js:463:15)\n    at CleartextStream.Readable.read (_stream_readable.js:320:10)\n    at EncryptedStream.write [as _write] (tls.js:366:25)\n    at doWrite (_stream_writable.js:219:10)\n    at writeOrBuffer (_stream_writable.js:209:5)\n    at EncryptedStream.Writable.write (_stream_writable.js:180:11)\n    at write (_stream_readable.js:573:24)\n    at flow (_stream_readable.js:582:7)\n    at Socket.pipeOnReadable (_stream_readable.js:614:5)"}}

I've read the doc, it is said that this kind of error is due to a malformed assertion... But the thing is, everything was working fine some days ago (4 or 5)...

You can access the assertion link, I've checked it and didn't find any missing things:
https://badge.unow.fr/api/v1/badges/data/21/22/a98682c8d79331dbb0f1790e953a2b8f.json

I've also read that this error: UNABLE_TO_VERIFY_LEAF_SIGNATURE may be linked to a problem with the SSL certificate. But again... some days ago, the certificate was already there and it did work, so why the problem would appear so suddenly?

Do you have any idea?
Let me know if I can provide you with more information,
Regards,
Regis aka Kulgar.

[stenington]

@Kulgar moved your issue to it's own ticket. You can follow progress here!

[stenington]

@jdotpoz Has anything changed with SSL or certificates lately in our environments? Looks like both staging and prod is suffering from this, but not the backpack I host at stenington.org which makes me think it's on our side somewhere.

[stenington]

Helps if I ping the right person. @jdotpz see above. :)

[Kulgar]

Thanks @stenington, thought it was somehow linked to the other issue... but it doesn't seem to be the case, you're right.

If you want me to help, no problem, I'll be glad to!

[mopi16]

I have the same issue with https://ohioresa.mopi16.com/badge/assertion/badgeissued.php?i=3&b=1

This is the response from Openbadges:

{"message":"could not get assertion: unreachable","stack":"Error: could not get assertion: unreachable\n    at makeError (/var/www/openbadges/lib/analyze-assertion.js:6:26)\n    at Request._callback (/var/www/openbadges/lib/analyze-assertion.js:18:23)\n    at self.callback (/var/www/openbadges/node_modules/request/main.js:120:22)\n    at Request.EventEmitter.emit (events.js:95:17)\n    at ClientRequest.self.clientErrorHandler (/var/www/openbadges/node_modules/request/main.js:223:10)\n    at ClientRequest.EventEmitter.emit (events.js:95:17)\n    at CleartextStream.socketErrorListener (http.js:1520:9)\n    at CleartextStream.EventEmitter.emit (events.js:95:17)\n    at SecurePair.<anonymous> (tls.js:1365:19)\n    at SecurePair.EventEmitter.emit (events.js:92:17)","code":"http-unreachable","extra":{"message":"UNABLE_TO_VERIFY_LEAF_SIGNATURE","stack":"Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE\n    at SecurePair.<anonymous> (tls.js:1346:32)\n    at SecurePair.EventEmitter.emit (events.js:92:17)\n    at SecurePair.maybeInitFinished (tls.js:959:10)\n    at CleartextStream.read [as _read] (tls.js:463:15)\n    at CleartextStream.Readable.read (_stream_readable.js:320:10)\n    at EncryptedStream.write [as _write] (tls.js:366:25)\n    at doWrite (_stream_writable.js:219:10)\n    at writeOrBuffer (_stream_writable.js:209:5)\n    at EncryptedStream.Writable.write (_stream_writable.js:180:11)\n    at write (_stream_readable.js:573:24)\n    at flow (_stream_readable.js:582:7)\n    at Socket.pipeOnReadable (_stream_readable.js:614:5)"}}

** sorry... not sure how to get this in that pretty comment box.

If you run this to ground or have any ideas, please let me know!

Thanks!

[stenington]

Fairly certain this is related to a difference in how node handles SSL in v0.10 from earlier versions. We're looking at going to v0.8 instead of v0.10 until we can research more carefully.

This issue was helpful in understanding what I think is the problem and a potential solution.

[mopi16]

Thanks for the note. I ended up removing all https from the urls and it does work. This is not ideal from our standpoint, but we will take it for the time being.

Please keep us posted on any fixes for this issue... Likewise, if it turns out the issue is with our setup and there is something we can do on our end, let us know that too. :)

Thanks again!

[stenington]

@mopi16 I believe with v0.8 you won't have to do anything to be able to use https, but we'll still eventually go to v0.10 and then you may have to make changes on your side to present a complete keychain. It looks like your site may have missing CA certs similarly to the papertrail endpoint in the referenced issue: https://gist.github.com/stenington/6c760ece88d9c445b4c5

[mopi16]

@stenington Thanks for the catch! I'll get that patched up.

[stenington]

Production is now running under node 0.8 so https assertions should be fine. The errors encountered previously should no longer occur, so let us know if they do for you.

[mopi16]

@stenington Thank you. Once I fixed up our SSL issue that you pointed out, the assertion passed. Thanks again for your help!

[stenington]

@Kulgar Although your https assertions should be working again now, you may also want to check for missing CA certs to avoid trouble when we go to v0.10. I'm not sure when that will be exactly; I'd like to do a little more research on any changes we may have to make on our end first, but while you're thinking about it it may save you some trouble later.

[Kulgar]

@stenington Thanks! I'll try and let you know if everything works fine.
I don't think I have any missing CA certs... I did put the "intermediate CA file" of my CA authority. If I don't have any troubles (warnings messages and such) with Mozilla Firefox browser connexions, do I have to worry about when you will go to v0.10?

[brianloveswords]

@stenington any idea what we need to do to be able to fix this so we can move back to node v0.10 ?

[stenington]

This page about node 0.8 vs 0.10 mentions:

https now does peer verification by default. This means that if you try to access an SSL endpoint which has a Certificate Authority that is not in the default CA list, you will get an error where you did not before. You can set rejectUnauthorized to false to get the old behavior.

In the backpack it's request.get calls that are failing (for certain https urls), and it looks like passing strictSSL: false sets rejectUnauthorized to false under the hood.

I'm not sure I fully understand the repercussions of doing this (i.e. why node v0.10 changed the behavior from v0.8) but if we want to stick with the v0.8 behavior, maybe that's all we need to do.

[stenington]

Oh interesting, looks like setting NODE_TLS_REJECT_UNAUTHORIZED=0 in the environment will do this globally, maybe? See here

[stenington]

Found a fix summarized in #980 that should close this out. @Kulgar @mopi16 let us know if problems start cropping up again.

[Kulgar]

No Problem! Thanks! :)