* Refactor/simplify Transport/MailTransport
* Add serverCert column to HostAuth table in EmailProvider
* During first connection to server, save the server certificate
in the HostAuth; on subsequent connections, ensure that the
certificate presented has the same public key as the one
stored
* For now, we'll just fail to connect (with a CertificateException)
if there's a mismatch
TODO: Add some UI to handle different certificates
Bug: 6888866
Change-Id: Ia79497e89eaad8d43617b50d3771121b2ed7f687
This prevents things from always failing if the server requires a client
SSL certificate.
Note that the solution used to determine if a certificate request was
made for a given request is approximate; it is timestamp based and can
theoretically give a false positive. In practice, this is very unlikely,
since another cert request had to have happened around the same time,
AND the response must be a 401/403.
Change-Id: Ieb77cf91db3bd52ba4adf1fb07357fef7e204ba5
When the KeyStore fails to give us back a certificate for any reason (it
was removed from the keystore perhaps), propagate the error back up.
Change-Id: I4f0ef783c1665589cc8ccb43d95da43a297a3e9a
This introduces an exception which needs to be thrown from a KeyManager
when it tries to establish a connection with a server requesting a
certificate.
Change-Id: I06dfad7789ed5d320b630e7e4380e15da42a48df
This introduces the ability for clients (i.e. the exchange service) to
register "special connection types" that use a client certificate stored
in the system keystore. The alias is encoded into the URI scheme for
those clients, and the socket factory used for those connections will
use the approprate KeyManager.
Lots of TODO's, including bubbling a lot of this up to the higher level
and wiring the UI to actually set the alias in the HostAuth table.
Change-Id: If5e1901c5b58731fdabd3e6b6da7198134b512d2
Paul Westbrook