64902 Views 46 Replies Latest reply: Mar 28, 2013 5:14 AM by iChris123
Currently Being ModeratedApr 28, 2010 5:47 PM (in response to Matevz Gacnik)It is not possible since a Client-side Cert needs to be downloaded to the device to be recognized each time you go to the site. There is no means to do that on the iPad. Also, the Safari app on the iPad is a different "version" of what you would have on your Mac/PC. Not as full-featured.Mac OS X (10.6.3), iPad 64GB - Macbook Pro 13" - iMac 27"
Currently Being ModeratedApr 29, 2010 10:45 PM (in response to dlg_az)Well, client side certs can be downloaded to the iPad normally. You can use the configuration utility or simply email yourself a cert and install it from the mail app.
The problem is, there is no way to tell Safari to use that certificate while handshaking with the SSL page.
Currently Being ModeratedMay 1, 2010 8:39 PM (in response to Matevz Gacnik)Have you tried accessing the site on an iPhone? (With the certificates installed, that is.)
I am having issues with SSL authentication using a corporate certificate as well, in my case with Exchange ActiveSync. This is only a problem on my iPad - my iPhone is configured with identical settings and works fine. So it appears there may be an issue with the way the pad handles SSL authentication based on stored certificates.
Currently Being ModeratedMay 5, 2010 7:11 PM (in response to Matevz Gacnik)I have a similar problem with the iPad and client cert authentication.
The client cert (and CA cert to authenticate the server) have been loaded using the profile tool.
The web server requests a client cert and the cert dialog appears (strange though, it has 'localized string not found' in the dialog) and the appropriate client cert is selected.
The web client (Safari) simply hangs there with the loading symbol chugging away.
I checked the server (apache) logs as this is going on, and no request is made to the server once the cert is specified to the client.
It appears as though Safari is simply chewing away on the certificate in an endless loop.
The same cert works fine in IE and Firefox browsers on a windows box.
Currently Being ModeratedMay 6, 2010 8:23 PM (in response to G.e.o.f.f.)Some more checking using wireshark on the destination server.
I created a simple html page that is contained under a directory that requires SSL and a client certificate, as configured in the apache configuration.
This works fine from the IE and Firefox desktop browsers.
Now, using Safari on the iPad with the appropriate certificates installed (client cert and CA cert) using the profile management tool, I attempted to connect to this page.
Wireshark shows the iPad contacting the server and the TLSv1 protocol selection (Client Hello and Server Hello).
Following this the server issues the requested server certificate and the CA cert to the iPad device.
The iPad device responds with an ACK and this is where it stops the communication. No further packets appear.
During this time, the iPad has requested that a client certificate be selected using the dialog and the appropriate client cert is selected, however the network transaction does not show the iPad ever sending this certificate to the server.Core2 quad
Currently Being ModeratedMay 12, 2010 3:13 PM (in response to G.e.o.f.f.)I am observing the same issue with safari hanging. In my case the web servers are IIS6 on a win2k3 x86 platform, and ISA 2006. Interestingly, the mail application works through the same ISA 2006 server publishing OWA. I did need to provide a "foo" password for the profile to actually load on the Ipad. I see no actual connection attempt post authentication from the Ipad to the web server.
Currently Being ModeratedJun 14, 2010 1:26 PM (in response to Matevz Gacnik)I have exactly the same problem. All certs installed fine, but wen connecting to the https Server (Apache 2 in my case) Safari just hangs. All other browsers have no problem with this site and the same certificates.
The strange thing is it worked once or twice After installier the certificates, but not anymore.
Apple, do you hear us, please ?!
I also got this "localization String Not Found"...iMac Alu 24", Mac OS X (10.5.3)
Currently Being ModeratedJun 16, 2010 11:16 PM (in response to MacElk)I also met this problem.
At first It succeeded in client authentication. After I installed some other x.509 certificates through Safari browser it does not work any more.
I have tried web servers as the following:
IIS6.0/Windows Server 2003 -- failed
Apache2.2/Windows Server 2003 -- Safari hangs
Tomcat6/Windows Xp -- Safari hangs
Does anyboby have resolved this problem?iPhone OS 3.1.3
Currently Being ModeratedJun 17, 2010 4:50 AM (in response to Zhu Liu Lin)I can confirm that the problem only becomes visible if you install more than one identity certificate. Even though you're asked which one to use Safari stalls afterwards.
If you remove all other certificates than the one you need, Safari authenticates fine and you can browse the webpage.
I initiated a case with Apple support on this.
BTW: Two days ago there were 2 more postings in this thread, one was written by me. These have been gone, has anyone seen this before ?iMac Alu 24", Mac OS X (10.6.4), iPad 3.2
Currently Being ModeratedJun 29, 2010 1:46 PM (in response to MacElk)I started a case with Apple a month ago on this issue and have heard nothing.
Profile pushed to Ipad via configuration utility 2.2 for windows
Certificates pushed include all 3 public keys from my Microsoft windows 2003 enterprise edition 3 tier PKI, and a .pfx export of my public and private user certificate (created without high security windows options)
When prompted, I see two selections for certificates. One is my name, one is a GUID. Selecting my name actually gets Safari to move forward, however the server gets a request for anonymous access and not the identity that I selected.
I can find no documentation on how to accomplish this from Apple. Apple will not respond to my case, thus I am forced to conclude that this is a flaw that they are not prepared to / willing to deal with.
This isn't a valid business machine unless it can be protected with current authentication practices. Username and Password do not cut it for people who are serious about protecting identity and data.