Re: secure sockets
Re: secure sockets
- Subject: Re: secure sockets
- From: Doug Mitchell <email@hidden>
- Date: Thu, 10 Jul 2003 08:43:45 -0700
On Wed., July 9 2003, Michael Robinette <email@hidden> wrote:
1. SSLSetCertificates takes an array of certificates whose first
item must be an Identity cert. I only understand the basics of
SSL, and what I've read (netscape docs) indicates that only one
certificate is used. A second certificate would be one from a
trusted authority? Can there be more than two?
The first certificate is actually presented in the form of a
SecIdentityRef, which is an abstract grouping of a cert and its
associated private signing key. Additional certs in the CFArrayRef are
indeed SecCertificateRefs, and are optional. These additional certs are
specified only to the degree that the peer needs to validate the cert
chain. Most peers will have a set of built-in trusted root certs, so
you normally don't have to send that unless it's a root cert that your
peer doesn't know about (in which case the peer's user will probably
get asked about connecting to an untrustworthy server). All
intermediate certs - certs in the chain between your server's cert and
the root cert it ultimately verifies to - must be sent (and hence must
be passed to SSLSetCertificate).
2. Is there a standard (or semi-standard) place to store/choose
certificates? Right now I'm using the keychain.
A keychain, definitely. That is the only way to cook up and/or obtain
the SecIdentityRef needed for the first item passed to
SSLSetCertificate. Additional certs could conceivably be converted from
raw data to SecCertificateRefs on the fly but the recommended way to
store all of this is in a Keychain.
3. From what I understand certificates are bound to a host,
so that when you create the certificate, it can only be used
on a machine whose host name is the same as that in the
certificate. How do you deal with this on a machine in a
dhcp environment and HOSTNAME=-AUTOMATIC- ?
The DHCP configuration will be determining the machine's IP address,
which is not what would be in the certificate. What you want to put in
the cert is exactly the same thing which client would use when
attempting to connect to the server - like a Rendesvous name (e.g.
"dougscube.local.").
--dpm
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.