Quoting Ryan Kelly <[email protected]>:

On 22/04/2015 08:11, Robin Bankhead wrote:

However, it now looks like syncserver is not happy: it's throwing a 503
on the first post-verification connection attempt.  This is true whether
behind Apache, or running directly (as in the below output).

hazel syncserver # make serve
./local/bin/pserve ./syncserver.ini
/usr/local/src/syncserver/local/lib/python2.7/site-packages/tokenserver/verifiers.py:47:
FutureWarning: The BrowserID certificate format has not been finalized
and may change in backwards-incompatible ways.  If you find that the
latest version of this module cannot verify a valid BrowserID assertion,
please contact the author.
  super(LocalVerifier, self).__init__(**kwargs)
Starting server in PID 6098.
serving on 0.0.0.0:5000 view at http://127.0.0.1:5000
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): fxa.example.com
INFO:mozsvc.metrics:{"code": 503, "request_time": 0.04334402084350586,
"remoteAddressChain": ["192.168.2.7"], "agent": "Mozilla/5.0 (X11; Linux
x86_64; rv:37.0) Gecko/20100101 Firefox/37.0",
"token.assertion.connection_error": 1, "token.assertion.verify_failure":
1, "tokenserver.assertion.verify": 0.03910994529724121, "path":
"http://fxa.example.com:5000/token/1.0/sync/1.5";, "method": "GET"}


This is almost certainly an issue with the syncserver trying to talk to
the fxa-auth-server, but failing.

In our production deployment, these two things are separate systems and
there's a bit of public-key crypto that ties them together.  To
authenticate to sync, the flow is as follows:

  * browser logs in to fxa-auth-server and gets a signed certificate
  * browser creates an "assertion" using the signed certificate and
    submits it to syncsever
  * syncserver loads the public key from fxa-auth-server and uses it
    to verify the assertion.

That last step seems to be failing.  The syncserver needs to be able to
make a https request out to the configured publicUrl of your
fxa-auth-server, requesting your local equivalent of this file:

  https://api.accounts.firefox.com/.well-known/browserid

Can you confirm whether this file is available on your setup?

Yes, it returns the following json file:

{"public-key":{"algorithm":"RS","n":"25553862601725963530408486652015263736459768932884706922556688204802029831337831657259534879136875448443305950197935287179018384657726091245553400153011657607567365321446826659131451739649963839703729245618497447650409005557504543753128598969375238725366778552494369439059857520759126627135738383047894258310742724853499535075781770828836348601435788359631686322422154698796253855849190652435829725353771243059969499994473427564562223850882369560273986829514021118590850754237699726596405270126802288263213762385388566956627243828118321434460926110767466041250764339314071716234929146714838210135206719025328865568369","e":"65537"},"authentication":"/.well-known/browserid/sign_in.html","provisioning":"/.well-known/browserid/provision.html"}

And I bet I know what's wrong now: I've been using a self-signed cert for all the servers (the same one, in fact). It's for example.com, no wildcard to explicitly cover the subdomain fxa.example.com, so I'm guessing that syncserver is not satisfied with that.

I can make a wildcard cert (or one specific to fxa.example.com) but will even that work if it's still self-signed? Can I import my own CA cert into syncserver somehow?

Cheers,
Robin Bankhead

_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev

Reply via email to