Error UI upon calling registerCertificate for Clortho primary

[ozten]

I've hooked up a new primary pointed to dev.diresworb.org that takes your LDAP username + '@vinz.clortho.org' and your LDAP password.

I've loggedin to http://dev.myfavoritebeer.org/

Everything goes well, I see proper interaction in Firebug. After we call navigator.id.registerCertificate(r.cert);
then I see:
http://skitch.com/oztenskitch/8rey2/error-on-success

Steps to repro:
0) https://vinz.clortho.org/ - accept SSL cert exception

1. https://vinz.clortho.org/browserid/sign_in - use your full mozilla LDAP email like
   ozten@mozilla.com
   Note: This isn't a stand-alone sign in screen, this is normally embeded in BrowserID, so don't worry about it not showing success, etc.
2. Go to https://vinz.clortho.org/browserid/provision and View Source. You should see your email address at the bottom of the file. Example:

window.provision(
  "ozten@mozilla.com"
);

if you see window.provision(null); then your username and password didn't work in the previous step.

You know have a valid session.

3. http://dev.myfavoritebeer.org/ click Sign in
4. Use a username @ vinz.clortho.org
   Example: ozten@vinz.clortho.org

I'll create a github repo soon with code for local debugging.

Note: There is an odd thing about the flow. Even though I have a good session, I'm still shown the login page....

[ozten]

To Repro locally:
https://github.com/ozten/vinz-clortho

[ozten]

One reason the error screen is being shown, is a self-signed SSL certificate.

BrowserID attempts to authenticateWithAssertion which hits /wsapi/auth_with_assertion.

This fails with

{ reason: "bad signature in chain", success: false }

[ozten]

At https://github.com/mozilla/browserid/blob/dev/lib/primary.js#L195
the issuer variable is set to 'eyedee.me' which is unexpected... still digging...

[ozten]

This happens running SHIMMED and non-SHIMMED.

[ozten]

Is there some magick with jwcert.JWCert.verifyChain?

I've edited the source of it's declaration, restarted, and don't see my console.log statements.

I've done the same to the other two functions with that name, no dice.

https://gist.github.com/1895837

I can put the value of bundle.certificates in here, if that is useful (just a big cert). I'm kind of stuck at this point.

@benadida or @lloyd any thoughts?

Summary: When we go to verify the chain, we think eyedee.me is the issuer. We then compare it's public key to the cert and die with "bad signature in chain". I've grepped through the code and don't see any hard-coded eyedee.me references.

[ozten]

I'm dumb.

grep'd my Primary's source and now see eyedee.me in lib/crypto.js.

[ozten]

Okay, interestingly I still have "bad signature in chain".

I see my server mentions provisioning a key with the algorithm 'DS' and browserid mentions an RSA key with algorithm 'RS'. Not sure if that is a mismatch, or meaningless.

[ozten]

I found an issue with my logic, my Primary was issuing certificates for mozilla.com email addresses, instead of dev.clortho.org. I saw a principal field in the decoded certificate, which tipped me off to this issue.

With that fixed, I'm still getting "bad signature in chain".

[ozten]

Okay... I've found another declaration of JWCert.verifyChain. I am able to edit that file and see my changes.

At this point:
https://github.com/mozilla/jwcrypto/blob/master/jwcert.js#L157
cert.verify(current_pk) fails.

Here are the values of cert and current_pk:

https://gist.github.com/d740a8b6d459f2451b76

[ozten]

Updating to 256 bits.

Everything looks good, but we fail at
https://github.com/mozilla/jwcrypto/blob/master/jws.js#L161

var sig_verification = key.verify(this.headerSegment + "." + this.payloadSegment,
utils.b64urltohex(this.cryptoSegment));

Here is an example of the live inputs:
https://gist.github.com/1904986

Hardcodding this call to true allows rest of flow to finish and proper assertion is granted.

[ozten]

@benadida figured it out, I was using different key pairs in lib/crypto.js versus the code that created /.well-known/browserid.

Meta observation is needing a way to detect this and inform primary developers.

[jbonacci]

Marking this as Verified.