Update: wow are you kidding? Is it because the cert subject name has a space in it?

See: https://social.technet.microsoft.com/Forums/en-US/d4fa29b7-b75a-4e75-9592-e0ea0b713b8a/mac-client-certificate-not-found?forum=configmanagerdeployment

As this issue seem unresolved and no MS person ever responded, I sure hope this isn't the issue. I will try out enrolling with an account with no space in the Name attribute and see if that makes any difference. I will be upset if that's the trouble I burned a whole day on.

following advice from post marked as answer from this technet post. Everything deinstalled and reinstalled OK judging from status messages. I find it interesting that status messages indeed indicate mp_mdm is being reinstalled - rather than simply stating it is being installed.

Yup the name of the account that is used to enrol the mac cannot have a space in the name.

• Proposed as answer by TemplarIT Tuesday, June 16, 2015 5:52 AM

Some hours later...

1. tried to enroll/connect on mac 10.10 client with no luck, actually getting an enrollment error which I haven't got before
2. removed MP / DP roles from the server that will be talking to Mac OS X clients, henceforth referred to as 'Ibcm'. Revoked all its certs on CA, made sure they were blocked in Config Mgr console. I've done this because I came to find that TechNet actually says that Intra/Internet servers need to have their certs' SAN configured as 'DNS=IntranetName.AD.Corp.Com&InternetName.Corp.Com' (as I interpret this).
3. Issued certs for IIS / DP to Ibcm with the SAN format mentioned in #2.
4. Reinstalled MP/DP on Ibcm and specified the new DP cert in the install wizard.
5. once status messages said everything was complete, aspnet_iisreg (v4*) and iisreset just to be sure asp iis components are in a consistent state
6. restart Ibcm
7. Review status messages and confirm Ibcm is acting happy
8. Install client on mac 10.10 system, restart after wizard is done, start enrollment wizard, use the SccmMacEnroller account (no spaces in the name attribute) to enroll; receive Enrollment error (0x8018002a).
9. Try sudo ./CMEnroll -s IntranetFQDNOfIbcmServer -IgnoreCertChaInvalidation -u 'SccmMacEnroller@IntranetUPN'; I get SSL Connection failed. HTTP response code is 500 and reason is Internal Server Error. I also tried using the Internet FQDN of the Ibcm server (same syntax as above otherwise) and got the same result.

Ibcm's \SMS_CCM\EnrollmentProxyPoint\Logs\EnrollmentWeb.log says:

ValidateServerCert - certificate error: RemoteCertificateNameMismatch    Enrollment    12/4/2014 9:15:54 AM    9 (0x0009)
System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with authority 'IntranetFQDNForIbcmServer'. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Threading.ExecutionContext.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.ConnectStream.WriteHeaders(Boolean async)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace:
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at IDeviceEnrollmentService.RequestSecurityToken(Message request)
   at DeviceEnrollmentServiceClient.RequestSecurityToken(Message request)
   at Microsoft.ConfigurationManagement.Enrollment.DeviceEnrollmentWebService.RequestSecurityToken(Message requestMessage)    Enrollment    12/4/2014 9:15:55 AM    9 (0x0009)

I'm guessing it doesn't like 'DNS=IntranetFQDN&InternetFQDN' on the SAN on the certs, but I don't know what else to do now since the TechNet doc says to do that (see the table\specific requirements entry for Management Points/DP's/etc. If I am misinterpreting what the TechNet link says, please correct me... :-/

I ended up removing all roles from the Ibcm server, redid everything as Internet only using Intranet FQDN and using an account to enroll that has no spaces in the Name attribute. It successfully enrolls and \SMS_CCM\EnrollmentProxyPoint\Logs\EnrollmentWeb.log reports

Found user credential in the message header for domain\SccmMacEnroller    Enrollment    12/4/2014 4:06:32 PM    7 (0x0007)
Forward client request    Enrollment    12/4/2014 4:06:33 PM    7 (0x0007)
Forward server response    Enrollment    12/4/2014 4:07:01 PM    7 (0x0007)

and the client UI on this mac (10.9.5) reported successful enrollment. However, clicking Connect Now still results in a 'Certificate not found' error on the config mgr preference item UI. My CA's root cert is in the System Keychain, and the cert issued to the user I enrolled with evaluated successfully so it is trusted.

Here are the zipped client log files from this mac; I don't know what the heck else to do.

I guess I'll check back in a year. Never could get it working nor get any help so we went with Filewave.

I know this is bumping an old topic, but I wanted to add:

config mgr client logging on iOS and OS X devices completely sucks. Whereas config mgr client logs on Windows platforms are gloriously verbose and actually help me troubleshoot things, client logs on apple devices really don't say anything more than 'something failed'. Shame on you! That is not a problem with Apple, it's a problem with you not being verbose enough in logs about what your client operations are doing!

Bumping an ancient topic - but I finally got this to work on the latest revisit! So two things:

1. Apple added support for OS X 8.5+ enrolling for certs from AD CS - so they can enroll and automatically re-renroll for the config mgr mac client certificate template on their own. We accomplished this with Profile Manager.
2. Mac clients don't accept anything but the Common Name format for the Subject, it seems. Once I switched my cert template's subject name format to Common Name, everything got a jump start. I have now enrolled several macs both in PoC and our live environment and it is a very exciting time.