Certificate Services and Mac OS X clients - Whats the best way to get certs on a Mac?

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 one‑time‑only 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' WPA2‑Enterprise 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 PEAP‑TLS, 802.1x machine certificate authentication. Due to compatibility restrictions on the Mac client side, we have had to resort to the less preferable EAP‑TLS (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 EAP‑TLS 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=SCAT‑001234.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 plain‑text CSR into the clipboard and paste into the 'Saved request' textbox.

Step 1d

Define the Subject Alternative Name; enter "san:dns=SCAT‑001234.your.full.domain.name" (without the quotes).

Step 1e

Click 'Submit'.

NOTE: All Step 2 parts are performed on the Microsoft Stand‑alone 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', right‑click 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 EAP‑TLS 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 WPA2‑Enterpise 802.1x EAP‑TLS '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 one‑time‑only 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 stand‑alone 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').