Results 1 to 6 of 6

Thread: [SOLVED] Problem with IPhone and Local CA

  1. #1
    Join Date
    Apr 2006
    Posts
    31
    Rep Power
    9

    Default [SOLVED] Problem with IPhone and Local CA

    I have 3 I-Phone users that used to be able to connect to our old Dovecott IMAP using a cert issued by tinyCA. I set up Zimbra as a commercial CA and signed the csr using our internal tinCA set-up (our root CA is imported into all our windows clients).

    The i-phones will not use the CA at all (HTTPS IMAP(S) or SMTP over SSL)
    All the windows clients have no problems.

    I do not want to go to a self signed cert that is not part of our internal CA

    can anyone help me with one or more of the following:-

    1:-

    I have my CA.pem from tinyCA what needs to be in the CA.key file so I can self sign in zimbra against our existing CA

    2:-

    Importing (not generating) a self signed CA into zimbra

    3:-

    Adding my CA into the i-phone

    Notes

    The i-phones were OK with a self signed cert on dovecot
    The phone fails all ssl communications
    The phone is OK if you remove ssl (ie IMAP(S) to IMAP)
    Other clients are OK with the cert (firefox outlook IE)
    My ZCS is 5.0.4 GA Release (open source)
    The server logs show a good SSL connection but nothing else for the i-phones

  2. #2
    Join Date
    Apr 2006
    Posts
    31
    Rep Power
    9

    Default Additional information

    The i-phones will view pages on the company intranet protected by SSL certs signed in tinyCA against our root CA (subject to the standard grumble because it does not recognise the root CA).

    The problem I seem to have is with SSL certs signed by our CA using a CSR.
    Either that or it is a 5.0.4 ssl / i-phone issue.

    Has anyone else had success with 5.0.4 GA Release (open source) and the i-phone?

  3. #3
    Join Date
    Apr 2006
    Posts
    31
    Rep Power
    9

    Default [Solved] Problem with IPhone and Local CA

    This was a subtle DNS problem.
    Although the DNS setup was OK with all other clients (Windows 98 to Vista, Linux and FreeBSD) it failed with the I-Phone (the only client that you can't run any tests from in a standard form).

    Background
    External DNS points to the firewall that port forwards to the Zimbra Server
    Internal DNS points to Zimbra's internal IP address

    Internal A name record (Bind)
    mailserver IN 1H A xxx.xxx.xxx.xxx

    The above record works with the I-Phone on the local network

    Internal A name record (Bind)
    mailserver.ourdomain.co.uk. IN 1H A xxx.xxx.xxx.xxx

    The above record is ignored by the I-Phone that defaults to external DNS The I-Phone tries to connect to the mail server with a loop back through the firewall. This loopback is blocked and the I-Phone fails. There does however seem to be some attempt to first contact using the internal IP address as a connection is registered in the logs before it dies.

    It is almost as if the I-Phone goes to the internal address finds the SSL decides that it does not like the look of the internal DNS record and tries to re-connect useing the DNS record for the external IP address.

    Dear Apple

    Please Let me import my own CA
    Please Give me the just some of the basic trouble shooting tools

    I can't think of many IP based devices that can't do a ping

    Rob


  4. #4
    Join Date
    May 2006
    Location
    England.
    Posts
    927
    Rep Power
    10

    Default

    This should still work though, if internally mailserver.ourdomain.co.uk resolves to the internal IP of the zimbra box, and externally it resolves to your public IP which if the firewall doing forwarding, then the iphone should just see this as normal.

    I've not tested importing a certificate onto the iphone yet though, so I may be missing something.

  5. #5
    Join Date
    Apr 2006
    Posts
    31
    Rep Power
    9

    Default

    Quote Originally Posted by Dirk View Post
    This should still work though, if internally mailserver.ourdomain.co.uk resolves to the internal IP of the zimbra box, and externally it resolves to your public IP which if the firewall doing forwarding, then the iphone should just see this as normal.
    Default firewall rules tend to prohibit loop back routes as a way of preventing spoofing packets to probe the firewall.This has been the practice on most firewalls I have used and is the case with our current one (pfSense).

    Using one form of internal A name record the I-Phone takes the external DNS as authoritative (or can't use the internal record despite the fact all other clients can) and attempts to access an internal resource using an external IP address. This is blocked. Using HTTP (not HTTPS) the device seemed to connect but then fails the re-direct to HTTPS (this leads to questions about is there a difference between how the protocols are handled). As the whole thing is devoid of any diagnostic tools speculation is pointless.

    Quote Originally Posted by Dirk View Post
    I've not tested importing a certificate onto the iphone yet though, so I may be missing something.
    The I-Phone is currently a locked down consumer item, although now Apple is releasing the SDK this may change. At the moment you have a snowball's chance in hell of getting your own root CA into it without unlocking the phone. My main gripe is even the most basic IP capable device should do a ping and a trace route. I know it's the Apple way to hide scary stuff from the user but omitting basic troubleshooting tool is NOT the way to go.

    Rob
    Last edited by Robert Mortimer; 04-11-2008 at 06:44 AM. Reason: Better English

  6. #6
    Join Date
    Apr 2006
    Posts
    31
    Rep Power
    9

    Default

    UPDATE

    A CA can be imported into i-phone either by mailing the CA to the device and opening it (The user will then be asked if they want to install)

    Or

    You can also use the i-phone enterprise config utility

    Rob

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •