I’m trying to understand how we can get certificates, based on the Computer template, onto our Macintosh OS 10.5.8 workstations (the Windows workstations are no problem). We are going to use Cisco’s ACS to control which wireless workstations can access our Intranet. Workstations with a “Computer” certificate issued by our CA will have access to our Intranet; workstations without a “Computer” certificate issued by our CA will be segregated onto a VLAN that can only access the Internet. (We’re going to be doing something similar with our wired workstations shortly, but my immediate focus is wireless clients.) The certificate we need is based on the Computer template. While researching our options, I came across a discussion forum entry, MacOSX and Windows CA, from Tom Ranson (available at https://airheads.arubanetworks.com/vBulletin/archive/index.php/t-1437.html). There may be another solution available (other than the one presented in the MacOSX and Windows CA discussion forum entry), so feel free to suggest alternatives. I’m going to include an edited/formatted version (for readability) of the discussion forum posts at the end of this post. There are three posts in the MacOSX and Windows CA discussion forum entry that apply specifically to my situation: · Tom Ranson’s initial post on the MacOSX and Windows CA discussion · Joe Fonte’s questions · Tom Ranson’s reply to Joe Fonte’s questions I’m going to be doing a few more tests, but I welcome any suggestions that might simplify the process. Perhaps scripting for the initial certificate request or the renewal request or anything else that we can explore? Some background information that may prove useful (the last two bulleted points make more sense after reading the MacOSX and Windows CA discussion forum entry): · We’re using AD CS on two Server 2008 R2 Enterprise boxes. We have an Enterprise Root CA and an Enterprise Subordinate CA (used for issuing certificates). We have about 50K Windows workstations and about 10K Macintosh workstations. · We have the wireless access working with Windows workstations. Active Directory and Certificate Services are working as expected. · As a test, before trying to follow any of Tom’s procedures, I issued a certificate to an XP virtual machine, exported it and installed it on a Mac (our Root CA was added to the Mac previously – so the certificate initially issued to the XP virtual machine would be trusted). The Mac wasn’t able to connect; the ACS reported that there was a problem with the certificate (the DNS entry in the certificate didn’t match the Mac’s name). (Our Mac workstations are domain members.) · Next I removed the Mac from the domain, renamed my XP virtual machine to the Mac’s name (based on our naming standard), got the certificate issued to the XP virtual machine and exported it and installed it on the Mac, removed the XP virtual machine from the domain and added the Mac back onto to domain. Wireless worked. Based on this – I’m wondering if the 5 certutil command line entries (in the onetimeonly modifications section – prior to Step 1a), Step 2a, Step 2b, and Step 2C are actually needed. Tom Ranson’s initial post on the MacOSX and Windows CA discussion Funnily enough, I tackled this issue only last week. We have a large user base of corporate Mac's (OS X 10.5.8 +) which required access to our 'Trusted Devices' WPA2Enterprise wireless network. It was desired that we treat them in the same manner as our existing much larger Windows XP Professional client base - that being with PEAPTLS, 802.1x machine certificate authentication. Due to compatibility restrictions on the Mac client side, we have had to resort to the less preferable EAPTLS (i.e. no PEAP tunnel) for these devices - it’s a risk we're willing to take. It was a real headache to break the back of it; however I can provide you with these notes which should help you. We are yet to 'polish' the procedure... the client side CSR generation isn't pretty, but it works - and it’s easy for all IT staff to work with. Our environment consists of a Microsoft PKI; Root CA with 3x Enterprise subordinates (automatic issuing of computer certificates to Windows clients) and now 2x new stand-alone subordinate CA's to handle non-domain integrated clients (i.e. Mac's and Linux machines). In short, these instructions demonstrate how to enrol and configure machine certificates for an Apple Mac client (tested with 10.5.8 +) and a Microsoft stand-alone CA environment. This documentation assumes you are working on a fully-patched out-of-the-box client and Windows 2003 R2 Enterprise Edition CA configuration (as of 1st September 2009). These notes do not cover the implementation of a Microsoft based PKI nor do they address the important considerations which one must take when doing so, so as to avoid common PKI mistakes (which can cause you a really, really big headache in a few years time(!)). I would like to point out that I am neither an Apple nor a Microsoft engineer, but a Network Engineer by trade ;-) Anyone please feel free to comment or point out how this could be achieved more simply/cleanly/'just plain better'... The following one-time-only modifications are required on the Microsoft Standalone CA to enable manual modification of various certificate extension attributes # To allow the 'Application Policy' of 'Client Authentication' extension in certificate requests (on the standalone CA). certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.4.1.311.21.10 # To allow the 'Enhanced Key Usage' extension in certificate requests (on the standalone CA). certutil -setreg policy\EnableRequestExtensionList +2.5.29.37 # To allow the 'Client Authentication' extension in certificate requests (on the standalone CA). certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.3.2 # To allow the 'Key Usage = Digital Signature, Key Encipherment' extension in certificate requests (on the standalone CA) (*** Believed to be included in the CA policy configuration by default (?) ***). certutil -setreg policy\EnableRequestExtensionList +2.5.29.15 # To allow the 'Subject Alternative Name' attribute to be included in the issued certificate. certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 Process to request and install an 802.1x EAPTLS capable client machine certificate on an Apple Mac OS X 10.5.8+ client ### Pre-requisite: Mac OS X 10.5.8+ client must be bound to the LDAP domain (Active Directory) and thus will have a computer object in an AD OU/container; we use an asset number for client hostnames/binds etc. therefore this value, for simplicity, must be used here and within the critical fields of the certificate (i.e. the Subject Alternative Name (SAN)). In our environment (and for the remainder of these instructions) this would be i.e. SCAT-001234, where 001234 is the client ID number. The Subject Alternative Name must match the FQDN of the computer object within AD ### Step 1a Generate the client CSR using the Mac OS X Certificate Assistant GUI with the CN=SCAT001234.your.full.domain.name (and email address = whatever@you.want; perhaps helpdesk@..... etc.). The certificate 'Subject' value is not important; however it is wise to use a sensible standard convention here to ease certificate tracking. Step 1b Navigate to the web-interface URL of the MS Standalone CA; select 'Request a certificate', followed by 'advanced certificate request'. Step 1c Copy the plaintext CSR into the clipboard and paste into the 'Saved request' textbox. Step 1d Define the Subject Alternative Name; enter "san:dns=SCAT001234.your.full.domain.name" (without the quotes). Step 1e Click 'Submit'. NOTE: All Step 2 parts are performed on the Microsoft Standalone CA from the command line. Step 2a After submitting the client CSR, use the following command to add the 'Client Authentication' EKU to the certificate request, prior to approving it. Note: The contents of the file 'EKU_Client_Authentation.txt' are: "30 0a 06 08 2b 06 01 05 05 07 03 02" (without the quotes) - this is the BLOB string for 'Client Authentication'. certutil -v -setextension <RequestID> 2.5.29.37 0 @C:\EKU_Client_Authentication.txt Replace <RequestID> with the certificate request ID (found in the 'Pending Requests' section of the appropriate Certificate Authority MMC snap-in). Step 2b After submitting the client CSR, use the following command to add the 'Client Authentication' Application Policy to the certificate request, prior to approving it. Note: The contents of the file 'Application_Policies_Client_Authentation.txt' are: "30 0c 30 0a 06 08 2b 06 01 05 05 07 03 02" (without the quotes) - this is the BLOB string for 'Policy Identifier=Client Authentication'. certutil -v -setextension <RequestID> 1.3.6.1.4.1.311.21.10 0 @C:\Application_Policies_Client_Authentication.txt Replace <RequestID> with the certificate request ID (found in the 'Pending Requests' section of the appropriate Certificate Authority MMC snap-in). Step 2c After submitting the client CSR, use the following command to add the 'Key Usage = Digital Signature, Key Encipherment' extension to the certificate request, prior to approving it. Note: The contents of the file 'Key_Usage.txt.txt' are: "03 02 05 a0" (without the quotes) - this is the BLOB string for 'Key Usage = Digital Signature, Key Encipherment'. certutil -v -setextension <RequestID> 2.5.29.15 0 @C:\Key_Usage.txt Replace <RequestID> with the certificate request ID (found in the 'Pending Requests' section of the appropriate Certificate Authority MMC snap-in). Step 3 Check that the above attributes have been added to the CSR; from within the Certificate Services MMC, select the CSR under 'Pending Requests', rightclick and select 'All tasks' and select 'View Attributes/Extensions'). Steps 2a, 2b, and 2c add a total of 3x necessary *extensions* to the CSR to allow the client certificate to be used for 802.1x EAPTLS authentication, and Step 1d adds a total of 1x *attribute* to the CSR (the SAN value) which (in our case) Microsoft IAS/NPS uses to match the client certificate to the computer object within Active Directory. Once happy, issue the client certificate via the Certificate Authority MMC snap-in. Step 4 From the Mac client, retrieve the issued certificate from the CA; choose the 'certificate chain' option (*.p7b). Open this file with the Keychain Manager application (default) and install the client certificate into to the Mac OS X (10.5.8 or greater) 'System' keychain. Now, using the Keychain Manager, manually move the client public and private keys (generated by the Certificate Assistant in Step 1a) from the 'login' keychain (of the user who generated the CSR on the Mac) to the 'System' keychain. In order for the 802.1x EAP-TLS authentication to function on the client, the *System* keychain must contain: · The client certificate (issued by the CA) · The client public key (generated in this case by the Certificate Assistant application; must be manually moved from the 'login' keychain) · The client private key (generated in this case by the Certificate Assistant application; must be manually moved from the 'login' keychain) · The 'Root CA' certificate · The 'Issuing CA' certificate (for the CA which issued the cert; if applicable, all of the CA certs in the certificate signing chain) Step 5 Delete all references to these certificates/keys from the *login* keychain - they should only be present in the *System* keychain. Step 6 Copy the 'Root CA' certificate to the 'X509Anchors' keychain; our experience has shown that this Keychain may not be 'present' in the Keychain Manager by default (you can locate and 'add' it). At this point, you should have a usable client certificate within your client's System keychain (plus all of the associated parts of a working certificate installation within the System and X509 Anchors keychains). We have deployed our Mac's with a WPA2Enterpise 802.1x EAPTLS 'System Profile' defined within the client network preferences; this provides machine-authentication based connectivity regardless of whether or not a user is logged onto the client. Joe Fonte’s questions We're looking at the same scenario as Tom. Cisco ACS will be used to control which wireless clients get access to our intranet (those with a "computer" certificate) issued by our 2008 R2 Enterprise CA. Non Domain member machines without a "computer" certificate (like personal laptops) will only be allowed Internet access. So, based on Tom's process, we're going to make a copy of the Computer template, call it something like WindowsComputer for issuing (autoenrollment) to PCs. Domain member computers will be able to get attributes directly from Active Directory (AD) and everything will (and does - we've tested it) work fine. In order to get a "Computer" certificate to show up on the Web page (CertSrv), we need to disable getting the attributes from AD and enable supply the attributes in the request (on the certificate template). (This was based on a Microsoft technician’s response to "why isn't my Computer template showing up in the drop down list on CertSrv".) I copy the Computer template, name it MacComputer, and configure it to get attributes from the request. So I'm going through Tom's procedure and I'm wondering... Are the 5 certutil command line entries (in the onetimeonly modifications section – prior to Step 1a) needed, and if so, what impact might they have on certificates that might be requested/issued in the future? Will the MACs be able to automatically renew the certificate when they are getting close to expiring? Tom Ranson’s reply to Joe Fonte’s questions The reasoning behind the 5x certutil 'prerequisites' is that we are using standalone CAs to provide computer certificates to Apple Mac (well, any non-Enterprise integrated) clients which are suitable for use in the 802.1x authentication process. The issued certificates must contain certain attributes to be used for 802.1x (on an Enterprise CA, these attributes would be determined from the certificate template used to issue the certificate, whereas stand-alone CAs do not use certificate templates and thus the information must be included in the CSR 'manually'). # To allow the 'Application Policy' of 'Client Authentication' extension in certificate requests (on the standalone CA). certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.4.1.311.21.10 # To allow the 'Enhanced Key Usage' extension in certificate requests (on the standalone CA). certutil -setreg policy\EnableRequestExtensionList +2.5.29.37 # To allow the 'Client Authentication' extension in certificate requests (on the standalone CA). certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.3.2 # To allow the 'Key Usage = Digital Signature, Key Encipherment' extension in certificate requests (on the standalone CA) (*** Believed to be included in the CA policy configuration by default (?) ***). certutil -setreg policy\EnableRequestExtensionList +2.5.29.15 # To allow the 'Subject Alternative Name' attribute to be included in the issued certificate. certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 The above 5x certutil commands change the CA policy to allow CSRs to include these additional extension attributes which are required to be present in a computer certificate which is used for 802.1x authentication - by default, these extensions are not permitted by the CA policy. Note that all we have done here is permit these extensions in certificates which the CA will ultimately issue - we have not yet populated these extensions with the required values (populating the values is handled in Steps 2a, 2b and 2c - this we handle in practice with a short (and very badly written!) script which we run on the CA, providing the CSR ID to modify - if you'd like a copy please just let me know). I'll be interested to hear about your findings with issuing computer certificates for Apple Mac clients from an Enterprise CA... Our research concluded that the only way we could achieve this was by using standalone CAs in conjunction with the aforementioned inhouse documentation. One of the limitations of this approach is that the Apple Mac has no way (that we know of) of performing autoenrollment (which Group Policy does a good job of handling for Windows domain member clients); we must complete this manual process for each Apple Mac client - and also that we must manually renew these client certificates every 2 years.

Ladies and Gentlemen, I have a new quirk which seems easier than your earlier posts, however I could not have gotten there without your advice. First I decided against using a computer account to do the certificate and decided to create certificates based on user accounts, these can be created by any user with AD access, but here is the good thing, they work seemlessly on both MAC and PC. Using User authentication for mac's negates the X509 keychain business making less work for you. You can use the computer only version for PC's with autoenrollment, I do like that method for PC, but for MAC user based auth is better :) if you like but you would just need two policies in IAS. As for the Certificate server you can add a new Template within the CA under templates by right clicking and then choosing Authenticated Session if you like. This would negate the script. As the the Authenticated session then appears in the WEB GUI interface for the users when they log in. For more information I am writing a Cisco White Paper detailing all my work which I will add a link to when complete. Many thanks to all here, you helped me discover what I wanted and I will share my knowledge with you all when the document is complete Stay tuned.... Keith Baldwin Consultant Systems Engineer

Hi Keith, This seems like a good solution for user level authentication, but we need the machine to have network access before a user logs in. We need to be able to push out software, patches, fixes and also have remote control of the machine prior to user login. If I'm reading your (Keith's) reply correctly, network connectivity will be established at user login. Prior to that, no network connectivity??? Thanks, Joe.

Hi All, we are looking for Auto Enrollment of Computer Certificates on Apple MAC clients...could anyone please provide the best procedures for this... Thanks in Advance.

Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end. I have duplicated the template we use for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config. Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile. bye LH PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request.

Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end. I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config. Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile. bye LH PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request.

Hi all, engaged in similar project to include MACOS in our certificate based authenticated WIFI network, I read with a lot of interest the various posts above and I ended up with the following question. Indeed if you allow certifcate to be exportable, how do you make sure the machine you are accepting on your network is really the one which it's supposed to be (and you manage as a corporate asset) and NOT an unmanaged machine where someone would have imported the certificate of legitimate asset. To keep confidence shouldn't we have unexportable certificates ? Thanks in advance for your help.

Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end. I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config. Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile. bye LH PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request. Hi LH, This thread has possibly too deep for my needs! But your post has been really helpful for me to know that Mac devices can pickup certs from a Microsoft CA. So thanks for that :) My next query is whether or not iOS devices like the iPad can support autoenrollment of certs over Wi-Fi. Manually cert provisioning is not scalable for enterprise. I'm thinking that they probably dont have this feature support natively but it oculd be achieved through an app?

Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end. I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config. Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile. bye LH PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request. Hello LH! im testing 802.1x with EAP-TLS & Client Certificates with MAC OS X Snow Leopard. I'm using an Windows 2008 Enterprise Enterprise Issuing PKI with MS NPS 2008 R2. I followed your advise but i can't get things working, NPS always reports "Reason Code: 8" "Reason: The specified user account does not exist.". I don't know whats wrong with my config, are there any additional steps to do? Thank you very much for advice, Greetz Seb

Hi, Im trying to get my mac to work, and it following this guide. But im stuck at Step 1d, I dont see anywhere to type the Subject Alternative Name. I have done the one-time-only modifications but with no difference. Im using CA Enterprise. Step 1d Define the Subject Alternative Name; enter "san:dns=SCAT001234.your.full.domain.name" (without the quotes). Thanks for any reply. Regards Ole

Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end. I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config. Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile. bye LH PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request. Hello LH! im testing 802.1x with EAP-TLS & Client Certificates with MAC OS X Snow Leopard. I'm using an Windows 2008 Enterprise Enterprise Issuing PKI with MS NPS 2008 R2. I followed your advise but i can't get things working, NPS always reports "Reason Code: 8" "Reason: The specified user account does not exist.". I don't know whats wrong with my config, are there any additional steps to do? Thank you very much for advice, Greetz Seb I'm having the same issue, and it appears that the certificate is representing itself as a User, not a Computer certificate. Upon further research it seems that after checking the cert before and after steps 2a-c, nothing has changed. I've run the initial scripts and have been beating my head against this for 3 weeks. HELP!!!!!!!!!