Client SSL Certificate Authentication

Some comments on this thread.

I have been investigating iPad (IOS5.1) client certificate authentication with IIS (7.5). By default the end user certs I use are issued by an Intermediate CA (best practice, and most common deployment method in most organisations). As a result I ran into the problem mentioned above and could not get an iPad to use a client certificate to authenticate against IIS.

To be clear the cert issue heirarchy is:

1. Root CA
2. Intermediate CA
3. End User Cert

IIS is all setup correctly for certificate auth and the same certificate works find for authentication when used on a Windows machine with IE.

I had a fairly good look at this with Wireshark and it appears what is happening is related to the server TLS handshake - and the way the IOS determines which profile certificate to send in response. When SSL client auth is turned on in IIS at one point in the TLS negotiation the IIS server issues a TLSv1 handshake: "Server Hello, Certificate, Certificate Request, Server Hello Done".

Now the important bit: in the "Certificate Request" component of the handshake the server issues a list of Trusted Root CA's (from the Trusted Root CA's section of the Windows certificate store). It very stongly appears that the iPad will only supply a client certificate that is immediately signed by one of these certificates. Since the end user cert is actually signed by the Intermediate CA - which is not in the list sent down by IIS - the iPad does not find a match. It is a this time the "No itentities" message appears in the iPCU console if you have the device hooked up.

If you could somehow convince IIS to send down the Intermediate CA in the handshake list it is very probable the iPad would work. Since Apache is more flexible in this regard this is possibly why people have had more luck getting client cert authentication working in that environment.

Unfortunately it appears impossible to get IIS to send down the Intermediate CA in the handshake. I spent quite a lot of time on this, trying the MakeCTL tools to make trusted CA lists etc. but nothing I did could convince IIS to issue the Intermediate CA - and thus nothing would make the iPad authenticate.

This really is something Apple should fix. The iPad should look through the entire client certificate chain to the issuing root CA - to see if it matches any of the IIS listed root CA's - rather than just the CA which immediately signed the client cert.

Since this is not something I could wait for I had to resort to a kludge:

1. I setup an openssl CA
2. The openssl Root CA cert was put in the IIS server cert store as a trusted root. This meant it was sent in the server TLS handshake.
3. I issued an openssl client certificate (immediately signed by the openssl root CA) and installed in on the iPad. A this stage the iPad would supply the OpenSSL client cert in the TLS handshake - but IIS wouldn't accept it because it does not correspond to an AD user.
4. I then turned on IIS DS client mapping and (in AD users and computers MMC "Name Mappings" option) I loaded up the end user public cert.

At this stage IIS recognised the OpenSSL cert, mapped it to an AD user permitted access to the IIS site.

This is not optimal. I need an AD cert installed on the iPad for Wireless, Exchange etc. and an OpenSSL cert for IIS client authentication. At least though I can do AD authentication for iPad devices to IIS servers now - which avoids the pain of users having to enter AD credentials. I look forward to a permanent fix for this problem though.

Hi Apple Support

I'm facing exaclty the same issue which is described by annafromvan nuyswith ipad ios 5.1 and TMG 2010.

As long I use client certificates issued by a root ca, the ipad takes that for authentication purpose on protected webressources (TMG).

But under the constellation of

- Root CA

- Intermediate CA

- Client Certificate

... is is not taken into care from the ipad. It is not given as an option to select a client cert from, although it is on the ipad. Want to mention, that the very same client certificate is working on my PC ...

This is a really urgent problem for me, since we have hundrets of ipads in usage ...

Please, any feedback.

Hi siouxme,

Currently there is no solution for that problem, only way is to issue certificates from the RooCA server or what is better option to build new PKI infrastructure dedicated for iPad devices with only RootCA in the infrastructure, so you do not have to change your Certificate Policy statements of existing PKI.

We all hope that this problem will be fixed in some new version of iOS.

Stibra

I'm curious to see if anyone has got this to work with a Bluecoat proxy for AD authenticaiton? Currnetly we have a Root CA >immedidate CA that signs and issues client certificates from AD DS. When we turned on client authentication on our ProxySG appliance we get an untrusted SSL certificate message. I'm wondering if this is because our CA is using 2 levels (Root and Intermediate) and cannot authenticate? What we would ideally like is to have the user seamlessly authenticate against our proxy to reduce the headaches of having to enter credentials each day to Safari.

hi

i've tested on ipad ios 5.1 and 5.1.1 with no success.

with manipulation of the server side CTL for allowed Root CAs, the ipad does not behaive different.

so you cannot work arround... this way.

we'll try a seperate CA with direct signing of certs.

Martin

I encountered the same problem on iPad 3 with iOS 5.1.1.

Using the information from annafromvan nuys above, I confirmed that a client certificate with an intermediate authority does not work at all in Safari. It fails silently, behaving as though the certificate is not installed. I used a StartSLL free certificate to test this. This identical configuration works correctly on Windows with Chrome, IE, and Opera. This also works in Firefox under the condition that basic authentication is disabled, otherwise Firefox only prompts for a password.

I was unable to confirm whether or not a root-signed certificate solves the problem. I tried using a free CAcert client certificate, which is root-signed. The result was that the server reported the certificate as ill-formed in all browsers.

What I figured eventually was a different workaround, which saved me from setting up a CA just for my iPad.

Safari does work with self-signed certificates. One way to get self-signed certificates is to generate them with a program from http://www.yasinkaplan.com/tekcert.asp and then export them with the private key to a PFX file. Once installed, Safari will present the certificate silently to the server(s). The drawback to this workaround is that each self-signed certificate has to be trusted by the server as though they are separate CAs.

I can see how this would hurt iPad usage at big companies.

Once again, I can confirm, that with a ROOT CA=>Client Cert (withouth intermediate) there is no problem.

My company experienced the same behavior with client certificates and iOS that are described in this thread. Through our Apple Enterprise contact, an Apple Systems Engineer recommended the following:

This is a known issue and something that Microsoft has issued a workaround for.

http://support.microsoft.com/kb/933430/EN-US

See method 3 in the index.

Method 3 resolved the issue for getting iOS 5.1.1 and 6.0 beta 2 to prompt and use client certificates with Microsoft Threat Management Gateway [TMG] on Windows Server 2008 R2.

For IIS 7.5 on Windows Server 2008 R2, I also had to enable client certificate negotiation. This setting must be enabled or disabled through the command-line. The only downside with enabling client cert negotation is that it caused our internal desktop IE8 browsers to also start prompting for client certificates instead of automatically passing the NT token through for the sites requiring Integrated Windows Authentication. I have not resolved the IE8 client certificate prompting yet.

I used the information from http://tuganologia.blogspot.com/2010/03/iis-75-and-70-certificate-trust-lists.ht ml as a guide, but instead of setting the CTL properties, enabled the clientcertnegotiation property.

A list of parameters for the netsh http add sslcert command can be found here http://msdn.microsoft.com/en-us/library/windows/desktop/cc307220(v=vs.85).aspx

There is no "update". You must look at the current settings, copy the information, delete the SSL server certificate binding, and then re-add it with the modified settings.

First off, we need to run a command console with elevated privileges (run cmd.exe as administrator).

For my servers, I did the following:

Execute the command: netsh http show sslcert

Make note of the results (i.e. copy them into Notepad).

netsh http delete sslcert ipport=0.0.0.0:443

netsh http add sslcert ipport=0.0.0.0:443 certhash=<hash> appid=<appid> certstorename=MY clientcertnegotiation=enable

The other parameters seemed to be at their defaults and I did not specify them in the command-line when re-adding.

Execute netsh http show sslcert again to verify the settings look the same as the original but with clientcertnegotation enabled.

One more note, client certs only seem to work with Mobile Safari. After applying the Microsoft server-side changes, only Mobile Safari would prompt for and use client certificates. Chrome, Atomic Web, and iCabMobile browsers on iOS do not seem able to utilize client certs installed on iOS.

Hope this helps.

Jmarckel, did you test this with client certificates on iOS devices issued by subordinate CA or RootCA?

We tried all that before, but it is not working with subordinate CA issued client certificates.

For RootCA issued client certificates there is no need to modify anything on IIS 7.5 on Windows 2008 R2, everything is working by default.

Yes, we are using client certificates issued by a subordinate CA on iOS 5.x devices. We have a two-tier PKI with a self-signed root. The certs are put on the iOS devices through the MDM solution we are using (which I believe is using SCEP requests).

In order for the iOS devices to prompt and use the client cert, the following was done on the web servers running IIS 7.5 / Windows Server 2008 R2 w/ SP1:

• In the IIS management console, at the server root, enable “Active Directory Client Certificate Authentication”.
• Set up SSL for the web site.
• Enable Integrated Windows Authentication for the site and disable other authentication types.
• Set the site to Accept or Require client certificates.
• Apply method 3 from Microsoft KB 933430 which is
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
  • Value name: SendTrustedIssuerList
  • Value type: REG_DWORD
  • Value data: 0 (False)
• Enable clientcertnegotiation for the site per my previous post.

The same here...for a website we use an official 2048-bit SSL Cert, it is a cert-chain with 3 tiers. To authenticate at this website (running on a tomcat) we use browser client-certs. With every browser (chrome, firefox, internet explorer) on every OS it works fine, but only with Safari on MacOS, iPads and iPhones it does not work. Safari only tells me that there can't be established a secure connection.

Any solutions?

Hi All,

Same situation here.

From someone i heard that there is a fix that might make it to ios6. I tried with ios6 on iPhone and iPad, but did not get it to work. Looks like the fix did not make it. Can anyone confirm this result?

This bug prevents us from using ios in our enterprise environment. Should be fixed asap because this is basic certificate functionality!

Thanks.

Hi

With iOS6 and TMG the iPad handles 1-tier and 2-tier client certificates, as expected.

So there is a defenitly a change from iOS5 to iOS6.

Now we run into the problem, that our iPADs holds 3 certificates:

• 1st + 2nd is for and frrom MDM (2-tier) with extended usage 'IPsec Internet Key Exchange'
• 3rd is for SSO to TMG and webapps with extende usage 'Client Authentication'

While using iPAD with iOS5 the user wasn't requested to select a certificate, instead the only recognized certificate (3rd one) was used and sent back to authenticate.

Now with iOS6, the user is promted to select a certificate each time a new connection is opened.

=> Does anyone know about a trick to overcome this user-prompts? I thought, if its not dedicated marked for 'client authentication' Safari wouldn't count such certificates as an option...

Martin

Hi, you can use the following settings for Safari:

Setting>safari>autofill>Names and Passwords > on

Hi, unfortunatly this does not change anything.

The prompt to select a certificate still pops up. And after some minutes this happens again....

Other proposals?