Re: [Fed-Talk] Apple Mail / iOS S/MIME cert lookup on GAL
Re: [Fed-Talk] Apple Mail / iOS S/MIME cert lookup on GAL
- Subject: Re: [Fed-Talk] Apple Mail / iOS S/MIME cert lookup on GAL
- From: "Hoit, Daniel S." <email@hidden>
- Date: Thu, 27 Aug 2015 18:50:55 +0000
- Thread-topic: [Fed-Talk] Apple Mail / iOS S/MIME cert lookup on GAL
Just to echo what Lee is saying, this does work for us in 10.9, 10.10, and even in the latest 10.11 beta.
It did break in 10.8, and I don't remember about 10.7, but it worked correctly in 10.6 back in the day.
I should probably note though that the OS is technically pulling the certificates from AD, not the GAL (small distinction, but it might be important).
It shouldn't matter what version of Exchange you are running since this is an AD query for user account attributes.
I can take a machine that is bound, but has no email accounts set up, login with a local account and find a certificate from AD. If you want to test it, you should be able to use "security find-certificates -e email@hidden" to test it out.
Just to add to what Lee provided on the configuration
- 10.9/10/11
- Bound to AD using Apple's native AD plugin.
- User accounts have userCertificate populated in AD.
- Keychain Access has "Search directory services for certificates" checked in the preferences menu.
With just these settings, I can use the security command line tool to pull certificates. As far as making Mail use them though, you will also need:
- A valid identity for email signing/encryption in user's login keychain
- Trust chain in place so that certificates show as trusted/valid
This seems to work fine on OS X. Mail on iOS is another story though. From what I can tell, it doesn't like our split certificates.
--DH
On Jul 24, 2015, at 10:42 AM, "Miller, Timothy J." <email@hidden> wrote:
> userCertificate is part of the standard RFC 4523 LDAP core schema; it's included in the pkiUser and strongAuthenticationUser classes. It should be a DER encoded RFC 5280 Certificate object.
>
> userSMIMECertificate is defined in a different standard, RFC 2798, which defines the inetOrgPerson class. This should be a defined DER encoded signed PKCS#7 object following RFC 5751.
>
> userSMIMECertificate is supposed to be preferred over userCertificate for S/MIME applications. RFC 2798 has a slight ambiguity on that point since it doesn't use RFC 2119 nomenclature. It's possible that Apple Keychain Access and/or Address Book is looking for userSMIMECertificate, is strict about the implied SHOULD clause, and doesn't fall back on userCertificate when userSMIMECertificate is not available. The last time I did specific testing on this was c.2006, and I no longer have those notes.
>
> Publishing userCertificate to a directory can be done by anything. Subject to directory permissions. Microsoft Certificate Services will automatically publish to AD when the CA is run as an Enterprise CA.
>
> Publishing userSMIMECertificate requires the private key and therefore is not automatic. Outlook/Windows has this function in Trust Center in the S/MIME profile settings pane as the "Publish to GAL" button. Outlook/Mac has no equivalent.
>
> -- T
>
>>
>>
>> Lee,
>>
>>
>>
>> Is your Mac joined to AD natively through OS X or through are you
>> using a third-party product like Thursby or Centrify?
>>
>>
>>
>> My experience is that OS X 10.10 and below natively joined to AD
>> does not find certs in the GAL.
>>
>>
>>
>> Not disputing your experience. Just conveying my own.
>>
>>
>>
>> Walter
>>
>>
>>
>> On Jul 24, 2015, at 11:51 AM, Neely, Lee <email@hidden
>> <mailto:email@hidden> > wrote:
>>
>>
>>
>> 1) We’re using 10.10, 10.9
>>
>> 2) Exchange 2010 SP3
>>
>> 3) AD – Mac is Joined
>>
>>
>> On Jul 23, 2015, at 2:10 PM, Neely, Lee
>> <email@hidden <mailto:email@hidden> > wrote:
>>
>>
>>
>> Apple Mail will retrieve certificates from the GAL.
>> I’ve tested and it works.
>>
>> What it won’t do is retrieve them from other
>> directory services, even if other products, say Outlook 2011, can/do.
>>
>>
>>
>> Lee
Daniel Hoit
System Management Solutions Group
Lawrence Livermore National Laboratory
Email: email@hidden
(925) 424-5256
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden