5 Replies Latest reply: Sep 25, 2014 2:30 AM by RosarioCarcò
RiverdaleMAC Level 1 Level 1 (0 points)

I am using OSX 10.8.5 and Safari 6.1.1

 

I'm trying to use the Canada Post website for online shipping (ship-in-a-click) via the site:

 

http://www.canadapost.ca/personal/tools/cst/intro-e.asp

 

When I choose my option (in this case INTERNATIONAL) a pop-up opens asking to select a client certificate. A list of five certificates, which are all apparently valid and not expired, is given. No matter which certificate I select I cannot get past this pop up window. It just pops back up again.

 

The certificates are all in the form:

 

com.apple.idms.appleid.prd. then a very lengthy alpha numeric string

 

From what I have read with certificate problems you can just delete them and next time you visit the site will ask you to select a new one. However, in this case, with all the certificates seemingly being valid, I don't think that will be the solution. Although, I am a complete novice when it comes to these issues.

 

Can anybody suggest something other than using Firefox/Chrome etc. although if that is the ONLY choice then so be it. But surely this can be solved within Safari, no? The rest of the Canada Post site seems to behave OK with Safari.

 

Thank you.


OS X Mountain Lion (10.8.5)
  • ErebusBat Level 1 Level 1 (5 points)

    This is actualy a bug in Safari.  When you connect to a SSL protected site (HTTPS) the site can also authenticate you with a certificate file.  This is not widley used and you don't need it if you don't know about it. 

     

    The problem is: the server is telling Safari that it *can* accept a client certificate and safari is trying to send (a wrong) one.

     

    I ran into this while adding SSL Client Authentication to our corporate website (to identify our employees, not customers).

     

    To make matters worse if you only have one com.apple.idms.appleid.prd.xxxx certificate then Safari will silently send THAT certificate which will fail the authentication check, effectivly locking you out of the server.

     

    In my testing it appears that chrome and firefox do handle this situation as appropriate (they do not send a client certificate if they don't have one matching what the server says it will accept).

  • RiverdaleMAC Level 1 Level 1 (0 points)

    Thanks for letting me know it is a bug. I'm about to update to Mavericks, any chance the version of Safrai that works with that has had the bug fixed? Or does that introcue another whole level of issues?

     

    Thanks again.

  • ErebusBat Level 1 Level 1 (5 points)

    Neither.  I am on Mavericks and it shows the exact same issue, so it neither fixes the problem or intoduces new ones, at least with my site.

     

    I also noticed that it is somewhat based on the loction (IP) of the server because on my local laptop (During development) and on our QA server would try and send a certificate that it should not send.  HOWEVER once we implemented the SSL client certificate on our production server it would no longer send the certificate.  I have no idea why and speculate that it is because our production server has a public IP.

     

    If you want you can use my site and see if the problem persists for you there (http://whf.to); however given the seemingly random why Safari decides to send certificates you may or may not see the issue.  If Safari does indeed send a certificate you should get an error page that details what happened (in somewhat lay-terms).

     

    Sorry that Mavericks doesn't fix the issue for you.

  • Pitasso Level 1 Level 1 (0 points)

    You mentioned that you faced this problem while adding SSL Client Authentication to your website. Is there any fix on a website level?

     

    Some of my customers have the same problem on my website and asking them to use chrome/firefox or change any settings in Safari is not a solution=( Could you give any advice on that?

     

    Thanks!

  • RosarioCarcò Level 1 Level 1 (0 points)

    In our case it comes as soon as you start using iCloud. If you are logged in as an admin, then the certificate (com.apple.idms.appleid.prd...) gets into the keyChain without asking for permission. And Safari tries to use this certificate to access any other web-page you might call. But strangely, if you are logged in with a normal user account, you do not have the problem at all. I guess the keyChain might be locked or in that case the certificate goes into the correct container where it does no harm or where it can be used for iCloud access only. I would have to verify and test this latter case.

    As our users want to access our Exchange-2010 Mail-Server through OWA, I tried even disabling/ignoring client certificates in the IIS-Server of our CAS&HUB servers, but with no avail.

    So for the moment being the only workaround is to delete the com.apple.idms.appleid.prd certificate from the keychain and delete it again as soon as it is introduced again, or not using iCloud at all.

     

    Any other hints? Or is it still a bug? Rosario