Security

All,

Trying to do EAP-TLS on MAC with certificates from a Windows CA.....thought I could get the MAC to go through certsrv, but it gets stuck when trying to install a cert. Has anyone run into this? Am I going about this the wrong way and if so, what would be the best way to do this?

Thanks,

Austin

I don't think you can use the "install cert" option on a non-Windows platform - it's some kind of ActiveX application that calls various Windows APIs. There should be some option in the cert server for downloading the cert - then you'd have to install it manually.

What you can do is generate a CSR (certificate signing request) through the Keychain application. Go to Certificate Assistant> Request a certificate from a certificate authority. From there, you can enter your name, email address and generate a CSR that can be pasted into the https://<SERVERIP>/CertSrv page. It will then spit back a certificate that you can install. You should also get the CA's cert while you are there and install in Keychain on the MAC.</SERVERIP>

Hi there,

Funnily enough, I tackled this issue only last week. We have a large userbase 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 manor 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 - its 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 procedeure... the client side CSR generation isn't pretty, but it works - and its 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 enroll 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 implimentation 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 ###

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.

1b. Navigate to the web-interface URL of the MS Standalone CA; select 'Request a certificate', followed by 'advanced certificate request'.

1c. Copy the plain-text CSR into the clipboard and paste into the 'Saved request' textbox.

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

1e. Click 'Submit'.


### All step 2. parts are performed on the Microsoft Stand-alone CA from the command line. ###

2a. After submitting the client CSR, use the following command to add the 'Client Authenticaion' 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

(replacing <REQUESTID> with the certificate request ID (found in the 'Pending Requests' section of the approproate Certificate Authority MMC snap-in).


2b. After submitting the client CSR, use the following command to add the 'Client Authenticaion' 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

(replacing <REQUESTID> with the certificate request ID (found in the 'Pending Requests' section of the approproate Certificate Authority MMC snap-in).


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

(replacing <REQUESTID> with the certificate request ID (found in the 'Pending Requests' section of the approproate Certificate Authority MMC snap-in).


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.


4. From the Mac client, retreieve the issued certificate from the CA; choose the 'certificate chain' option (*.p7b). Open this file with the Keychain Manager
applciation (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 issed the cert; if applicable, all of the CA certs in the certificate signing chain).


5. Delete all references to these certificates/keys from the *login* keychain - they should only be present in the *System* keychain.


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 an 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.

I hope this info is of assistance; please do not hesitate to contact me if you would like any further information :-)

Kind regards,

Tom</REQUESTID></REQUESTID></REQUESTID></REQUESTID></REQUESTID></REQUESTID>

Before I forget, one issue that was driving me up the wall was this: when integrating Microsoft stand-alone CA's into an Active Directory environment, it is necessary to manually install the stand-alone (i.e. subordinate) CA certificate into the NTAuth certificate store in order to ensure that your domain member machines can validate the certificate chain of a cert issued from the stand-alone CA.

Without taking this step to ensure the trust hierarchy is intact, and assuming you are using a domain-member MS IAS/NPS server for your RADIUS backend, you will run into issues with RADIUS auth - along the lines of 'Terminate Cause = 295'; this meaning (the exact wording escapes me) that the IAS server did not trust all certificates in the client certificate chain.

See: http://support.microsoft.com/kb/295663

Hope this all helps,

Tom

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 (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?

Hi Joe,

Firstly apologies for the delay in my response.

The reasoning behind the 5x certutil 'prerequisites' is that we are using stand-alone CA's 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 CA's 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 CSR's to include these additional extension attributes which are required to be present in a computer certificate which is used for 802.1x auth - 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 certs for Apple Mac clients from an Enterprise CA... our research concluded that the only way we could achieve this was by using stand-alone CA's inconjunction with the aformentioned in-house documentation.

One of the limitations of this approach is that given the Apple Mac's have 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 client these certificates every 2 years.

Please let me know your findings... if we can improve our process then that would be great :-)

HTH,

Tom

My apologies for not replying sooner. You know how life gets busy...

Three of us (me for PKI/Certificate Services, Ernesto for Cisco ACS/wireless networking, and Jack as our MAC specialist) have been doing some testing with the MACs, certificates, and connecting to our wireless network with EAP-TLS.

We’ve managed to go through a manual process to get the wireless working for the MACs using Tom’s procedure as a framework – thanks for the guidance Tom. (Again, our Windows machines work flawlessly with our PKI infrastructure – so I won’t mention them again...) At a high level, I’ll start with a quick blurb about Our Environment, move on to What We Found Works, and wrap up with What We’re Investigating. I’ll sign off with To Wrap Up.


Our Environment

We’re running a 2003 domain functional level (native mode) on Server 2003 R2 SP2 domain controllers. Our MACs have been integrated into Active Directory, which is to say that they are domain members. Unfortunately, they’re still MACs – so no Group Policy is applied – and may other nice things...

I added an Enterprise Root CA running Server 2008 R2 Enterprise (which sits idle, doing nothing) and an Enterprise Subordinate CA running Server 2008 R2 Enterprise (which hands out all the certificates). The majority of our MACs are running OS 10.4, so we used this OS as a starting point for our tests.


What We Found Works

To start with, we wanted to see if we could get a MAC that already had a Computer certificate on it to access our wireless network using EAP-TLS. We did get it to work by doing the following:

• We created a copy (2003 - v2) of the Computer template and called it WirelessComputer
  
• We configured WirelessComputer to be exportable (private key) and to use AD attributes (DNS name) to populate both the Subject Name (SN) and the Subject Alternate Name (SAN) – I’m guessing either SN or SAN would have worked fine (probably don’t need both SN & SAN – but there’s no harm in having them both)
  
• We removed the MAC from the domain
  
• We added a Windows virtual machine to the domain with the same name (and therefore the same DNS name) as the MAC – the Windows machine was issued a WirelessComputer certificate (based on Security settings of the WirelessComputer template and Group Policy being configured for Auto Enrolment)
  
• We exported the WirelessComputer certificate, including the chain, to a USB stick
  
• We removed the Windows virtual machine from the domain
  
• We added the MAC back on to the domain with its original name
  
• We imported the WirelessComputer certificate, from the USB stick, on to the MAC
  
• We moved the WirelessComputer certificate and our Root CA certificate to the System keychain – essentially following Tom’s procedure (Step 4) – Step 5 & 6 wasn’t necessary (but remember this is OS 10.4)
  
• We created the System Profile, using EAP-TLS, and we were good for machine level wireless access
  

Cumbersome but it worked. Next, we wanted to try issuing certificates directly to the MACs without running the five certutil commands, outlined in Tom’s post under the heading, “The following one-time-only modifications are required on the Microsoft Standalone CA to enable manual modification of various certificate extension attributes.”

We thought we could just make a copy of the WirelessComputer template, call it WirelessMacComputer, and configure it to have the SN supplied in the request. This would make the WirelessMacComputer certificate available on the CertSrv web page of our Enterprise Subordinate CA. We were hoping our MACs could hit the web page, request the WirelessMacComputer certificate and go from there. Unfortunately, when we hit the CertSrv web page with the MAC, we couldn’t modify the key length (it defaulted to 512 and Cisco’s requirement was 1024). So, we did the following to get the WirelessMacComputer certificate onto the MAC:

• We used the MAC to generate a request and saved it to a file on a USB stick
  
• We took the request generated by the MAC (from the USB stick) and using a Windows machine hit the CertSrv web page
  
• We requested the WirelessMacComputer certificate (Advanced request) and used the FQDN of the MAC for the friendly name – nothing else (we didn’t defined the SAN) – strangely (for I don’t understand why) the SN contained the friendly name we gave the certificate
  
• The rest was like the above procedure, we exported the WirelessMacComputer certificate from the Windows machine and imported it on the MAC – we picked up the rest from there
  

Better, but still cumbersome – and it still doesn’t address certificate renewal when they expire. (Sure you can configure your PKI for 50 years so that renewal isn’t a “real” issue, but management may not approve...)

We were going to look at creating a scripted solution, based on our findings above, which could be accomplished with a few Windows and MAC scripts. Just to cover the basics, like certificate issuance, revoking, renewal – just for our MACs (we have several thousand MACs and a green user base, any manual procedures are out of the question – our solution needs be totally transparent to the user).


What We’re Investigating

By this time we started looking for a pre-packaged solution. We contacted HumanIT (www.HumanIT.com), the company that assisted with our MAC integration into AD, and asked if they had a solution for us. Seems like they’ve done this for other clients already (which means they’ve already done the scripting), but only for OS 10.5 and above. HumanIT will check out a “custom” solution which will include support for 10.4; they feel confident they can deliver the solution. They just have to modify and vet their code against 10.4 (seems like 10.5 is a fair bit different under the hood).

The HumanIT solution deals with both the certificate integration with MAC clients and the generation/creation of the wireless/network/system profile needed to connect with EAP-TLS. We contacted Apple to see if they had any other partners that had a working solution which included OS 10.4, but their other partners were also providing solutions for OS 10.5 and above. We thought about upgrading our OSs, but that’s a lot of time and money (for licenses).


To Wrap Up

It will probably be a couple of weeks before we hammer out a statement of work with HumanIT, but I’ll post my findings if there is anything of interest. Tom, if you’re interested in contacting me, I sent you a message with my contact info to AirHeads (you should be able to pick it up in your messages folder). Anyone else that wants to contact me about this can send me a message (to AirHeads) with their contact info, but I don’t want to post my info publicly.

Tom, again, thanks for your guidance. This MAC thing is a beast.

---

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 (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?

---

My certificated automatically renewed. I think this is a non issue now.

Thanks for the info George, but our certificates are not automatically renewing on the MACs.

We did not go with the pre-packaged solution from HumanIT. Instead, we created some MAC scripts to request the certificates (from our CA's CertSrv web site) and move them to the appropriate folders.

Based on what we have in place, certification autorenewal does not occur. Can you describe what you are doing and/or your environment?

Could we use the same idea to have other OSs (like IOS or Android) generate CSRs to a microsoft based CA infrastructure ? Are there any caveats ?

 

 

Has anyone tried this new "automated" process?

 

http://support.apple.com/kb/HT4784