> On Jun 25, 2016, at 7:44 PM, Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote:
>
> Following TN2326 I created a (self signed) Certificate Authority and a
> Digital Identity called "MyServerId".
You probably used the Keychain Access app for this? That works fine, but you’ll
probably want every instance of the server app to create its own key-pair and
cert, and you don’t want the user to have to use Keychain Access. I’ve got some
utility code in my MYUtilities library that will create an Identity (key pair +
cert) programmatically:
https://github.com/snej/MYUtilities/blob/master/MYAnonymousIdentity.h
The MYGetOrCreateAnonymousIdentity() function returns a SecIdentityRef you can
use with CFStream.
> Absolutely not sure whether the code above is correct, but it seems to be
> working.
That was fast! This is frustrating stuff to implement. Or maybe the docs have
gotten a lot better recently ;-)
> Currently (as indicated in the code above) my client has a copy of the real
> server certificate and compares it with the certificate obtained from its
> inputStream.
> I am not sure whether putting the server certificate into the client is ok or
> a breach of security.
It’s fine; the certificate is public and intended to be shared. It’s the
private key that’s sensitive. What you’re describing is called “key-pinning”:
restricting a client to connect only with a server with a known public key.
If every instance of the server has its own key, then embedding a cert in the
client app doesn’t work. What’s usually done is to have the app store a copy of
the cert the first time it connects to the server (with the user’s approval),
and then require the same cert every subsequent time it connects. (This is
similar to what SSH does, where the first time you connect to a host it tells
you the key is unknown and asks if you want to trust it.)
The situation you want to watch out for is where the client connects to a
server it’s already connected to, but the cert’s public key doesn’t match the
previous one. This is where you sound the alarm to the user — either someone’s
trying to spoof the real server, or perhaps the server lost its keys and had to
create a new cert (maybe its disk crashed and there wasn’t a backup of the
keychain.)
—Jens
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
