Does not detect SSL certs that will be rejected by production Persona

[callahad]

Check it out! Two support documents!

sbx.mydexid.org delegates to sbx.mydex.org

They both look awesome from checkmyidp.org's perspective: sbx.mydexid.org, sbx.mydex.org

They both look awesome in dev address_info: sbx.mydexid.org, sbx.mydex.org

They don't look awesome in Production, the delegation fails, but the authoritative domain works

I suspect this has to do with the stricter SSL checking turned on in production. How can we fix / warn about this in checkmyidp.org?

[callahad]

cc: @gene1wood

Gene, is there a good way for us to know what SSL certs prod will accept, and what it won't, beyond asking you to dump the ca-certificates bundle periodically?

[gene1wood]

@callahad How does production enable the stricter SSL checking? Is this a config option that differs between login.dev.anosrep.org and both login.anosrep.org and login.persona.org? It looks like it fails in staging as well.

If the cause of this is a differing CA bundle that nodejs uses between dev and stage/prod, we can just update our ca bundle (assuming it's old or something).

As far as dumping the ca-certificates bundle periodically, I don't know that it would be necessary to do periodically since there's no way it would change without our intention. If the bundle is associated with the nodejs version then we could add a test in the test plan for when we update nodejs to test sites with some of these certificates issued by newer CAs. If the bundle is associated with a specific nodejs module I think we'd need to track, on the dev side, when this module was changed or updated in the package.json file and apply the same test plan.

If you can point me to the ca cert bundle that's in use in dev that is correct I can compare it to stage/prod and see why they differ.

[callahad]

@gene1wood As far as I can tell, dev does no SSL verification -- you can use self-signed certs.

IIRC, Stage and Prod go through Squid, which wants a real, valid certificate.

Does that sound right?

[gene1wood]

Aha, makes sense.

So it looks like squid uses the sslproxy_cafile to configure the ca bundle and our bundle is from Firefox circa April 2012 (not too old).

Looking at the bundle we have, it has the CA in question, "GlobalSign Root CA".

When hitting the url : https://login.anosrep.org/wsapi/address_info?email=foo@sbx.mydexid.org

I get this line in squid :

1365376168.461 1354 10.14.200.201 TCP_MISS/503 3987 GET https://sbx.mydexid.org/.well-known/browserid? - DIRECT/193.63.182.161 text/html

And when I try the url through squid manually I get :

The following error was encountered while trying to retrieve the URL: https://sbx.mydexid.org/.well-known/browserid

Failed to establish a secure connection to 193.63.182.161

The system returned: (71) Protocol error

This proxy and the remote host failed to negotiate a mutually acceptable security settings for handling your request. It is possible that the remote host does not support secure connections, or the proxy is not satisfied with the host security credentials.

Interesting. So when I go directly to the IP https://193.63.182.161/.well-known/browserid I get a different cert. This sounds like SNI

Yup, this host is using SNI which we don't support. This can be shown like this

openssl s_client -servername sbx.mydexid.org -connect sbx.mydexid.org:443
openssl s_client -servername dev.mydex.org -connect sbx.mydexid.org:443

Here's the current bug on lack of SNI support : https://github.com/mozilla/browserid/issues/2583