Page 6 of 8 FirstFirst 12345678 LastLast
Results 101 to 120 of 151
  1. #101  
    Quote Originally Posted by Cmdr Grunt View Post
    ...
    I'm not sure why the pre is having trouble, but it may be the disparity between internal and external domain names. I'm attempting to get a free ssl cert from startcom and see what happens, because I just want to get my contacts synced up and don't know if I can wait for palm to re-jigger their EAS/SSL routines..
    I believe that the internal/external thing is the problem. I made the same decision, instead of waiting on Palm, I just got the free cert from StartCom, and it worked perfectly. After 3 or 4 days of frustrations, it was quite a relief.
  2. #102  
    Quote Originally Posted by hparsons View Post
    Again, the problem isn't that it's a self-signed certificate, others have used self-signed certs with no problem. The problem (most likely) is that the "real" name of the server is different than the public facing name (the name that you use). Look at the cert on the Pre, and compare it with the name you are using for the server. If they are different, that is the problem. The Pre is only seeng one name (the first name given the server), it should look at all of the names on the cert.
    Got it, I understand now
  3. #103  
    Our firm has a remote server and apparently a separate mail server. (one starts with remote.xxx-yyy.com/exchange and the other is mail.xxx-yyy.com.)

    I managed to d/l the cert for the mobile site by browsing to it through firefox on my computer. T'ferred it to my pre and can now access the remote server fine. The CN on the cert is the same as the fqdn. (i.e remote.xxx-yyy.com).

    But I still have a cert problem with the mail server where I sync with EAS. I have installed the root cert from the main server to try and access "mail.xxx-yyy.com." Unfortunately, I'm getting the dreaded date/time message. In this case, the CN on the cert is simply "xxx" and it does not have the "-yyy" portion or the ".com" portion of the domain name.

    From the posts here, I'm thinking my problem may be that the pre is looking for only "xxx" but is finding "xxx-yyy" and determining that they don't match.

    FWIW, this same cert worked fine with my 700p and I had no problem syncing with EAS.

    Any thoughts?
  4. #104  
    I'm having the same issue. We use a self-signed certificate - when I open the certificate on my desktop it shows as issued to/by mail.domainname.COM - yet when I open the certificate on my pre it shows as mail.domainname.LOCAL.

    Not sure why the pre changes the certificate or reads it that way. Here is hoping for an update soon or I will have to go back to my old centro.

    Anyone talked to Palm about this today? Any hopes of a quick update? I dont have the mental stamina to try and call.
  5. #105  
    can you guys help me fill in the blank

    1. http:// ???????
    2. domain= ??????
    3. user = royp
    4. password = 235788

    need help with 1 and 2...
    Sony n710 --> N760 --> NX70 ---> NZ90 ---> 4get sony ---> Treo 600 -- and two weeks later--> (Feb 05)Treo650 .... (March '08) Centro... Palm Pre (launch date)
  6. #106  
    Quote Originally Posted by omgitsroy326 View Post
    can you guys help me fill in the blank

    1. http:// ???????
    2. domain= ??????
    3. user = royp
    4. password = 235788

    need help with 1 and 2...
    1. Will be https://server.domain.com (this should be the same URL you would use to get to OWA)
    2. Domain will be the active Directory domain, and it's the short name. For instance, on my system the AD domain is ps.local . To fill in that blank. I put in ps
  7. #107  
    FYI- My experience-Using Exchange 2003 SP2 with External SSL cert, was able to connect and sync only after making a Device Security exception for my account in the Exchange System Manager (I'm admin) and emailing the cert to my gmail and installing from there. We have "enforce password on device, 4 characters" enabled. When I am not excluded, I can't sync. thanks
  8. #108  
    Our firm has Exchange 2007. I was initially not able to sync the Pre. I got the error that certain security policies were not supported. Our IT person and myself went into Exchange and viewed the settings for devices. We found that there was a selection [check the box] to allow non-provisionable devices. Once this was checked, I was able to sync my Pre. We are still trying to determine the nature, if any, of the vulnerability or exposure to which our server is now subjected.
  9. #109  
    Quote Originally Posted by hparsons View Post
    I believe that the internal/external thing is the problem. I made the same decision, instead of waiting on Palm, I just got the free cert from StartCom, and it worked perfectly. After 3 or 4 days of frustrations, it was quite a relief.
    I configured my server to use the free cert from Startcom. I am no longer getting an SSL cert error. The account seems to be setup correctly but all I get is an empty Outbox. Nothing syncs with the phone. Do you have any ideas what is causing this strange behavior? A couple other people have posted this issue, but I haven't seen a resolution. Thanks for your help.
  10. #110  
    Quote Originally Posted by degfu View Post
    I configured my server to use the free cert from Startcom. I am no longer getting an SSL cert error. The account seems to be setup correctly but all I get is an empty Outbox. Nothing syncs with the phone. Do you have any ideas what is causing this strange behavior? A couple other people have posted this issue, but I haven't seen a resolution. Thanks for your help.
    Sorry, I don't have the answer to that one... I have seen some folks that have Exchange 2007 report similar problems until applying SP1, but I don't run a Exchange 2007 system.
  11. #111  
    Quote Originally Posted by hparsons View Post
    Sorry, I don't have the answer to that one... I have seen some folks that have Exchange 2007 report similar problems until applying SP1, but I don't run a Exchange 2007 system.
    I have been having this same issue without a resolution since last weekend: I am using a GoDaddy cert (but also tested on a test site with a self-signed and verisign trial cert). I get the same thing every time: I authenticate, I can even see the session logged with no errors I can detect in the server logs.

    However, I only get an empty Outbox, and it seems to muddle the account preferences settings of Calendar and Contacts when I do this.

    My configuration:

    Exchange 2003 SP2
    Palm webOS 1.0.2
    GoDaddy cert

    Though I have seen there are many others having identical issues, I am aware of no official confirmation from Palm posted anywhere that this is a known issue. What I have seen is people have called, wade through L1 then L2 (is there a L3? I think I read someone got there...) and then are finally told, after many hours, that (more or less) they are aware of a few "issues" and are working on them. Whether or not this is one of them, it is not clear.

    If someone has any link to an acknowledgement of this specific issue it could help to at least know it's on their list.
  12. #112  
    Not clear this issue is on the list. They are primarily working on enabling non-SSL and dealing with PIN issues. The moderator of their blog IS aware of these issues. I hope he's passed them up the chain.
  13. #113  
    Count me as another Pre owner struggling to get EAS working to sync mail and calendar with Exchange 2007. Our company uses a root cert for the server + a client cert for each user which I got from our e-mail admin. Even after installing both on my Pre, I am still unable to complete the EAS config which always ends with an error "Unable to validate account settings. Please check the settings and try again". Co-workers have no problem connecting to this same server using an identical config on iPhones. I can also browse to the OWA address of the Exchange server using the Pre's browser but then get "The page requires a client certificate" warning, so it seems the Pre is having trouble presenting the client cert.

    Anyone have any other suggestions to try here?

    Any word on a possible fix via a ROM update?

    Loving the phone but definitely need to get EAS working...

    - Chris
  14. #114  
    Quote Originally Posted by ckgoodwin View Post
    Count me as another Pre owner struggling to get EAS working to sync mail and calendar with Exchange 2007. Our company uses a root cert for the server + a client cert for each user which I got from our e-mail admin. Even after installing both on my Pre, I am still unable to complete the EAS config which always ends with an error "Unable to validate account settings. Please check the settings and try again". Co-workers have no problem connecting to this same server using an identical config on iPhones. I can also browse to the OWA address of the Exchange server using the Pre's browser but then get "The page requires a client certificate" warning, so it seems the Pre is having trouble presenting the client cert.

    Anyone have any other suggestions to try here?

    Any word on a possible fix via a ROM update?

    Loving the phone but definitely need to get EAS working...

    - Chris
    Go over to Palm's support forums as there are some that have resolved this issue. Also do a detailed search based on your error message. Palm moderators have said their fix is not expected for a week or two, but they are working on it.
  15. #115  
    Thanks, I've been through the Palm forums as well as a few others and googled the bejezus out of this but have not found a solution for my particular set-up. If anyone knows of step/by/step instructions to get EAS working in a config where you use a root cert and client cert (no PIN) I would love to see it. Most "solutions" I have seen seem to involve tweaking things to work with self-signed certs which our IT team does not support.

    And if it makes you feel any better, it looks like the new iPhone software is also having a similar issue with this kind of config - http//forums.mactalk.com.au/31/66559-os-3-0-exchange-bug.html (can't post links yet so fill in your own colon in the above URL).

    Regardless, I sure hope this is something that gets fixed shortly...

    - Chris
    Last edited by ckgoodwin; 06/16/2009 at 03:42 PM.
  16. #116  
    Quote Originally Posted by ckgoodwin View Post
    Thanks, I've been through the Palm forums as well as a few others and googled the bejezus out of this but have not found a solution for my particular set-up. If anyone knows of step/by/step instructions to get EAS working in a config where you use a root cert and client cert (no PIN) I would love to see it. Most "solutions" I have seen seem to involve tweaking things to work with self-signed certs which our IT team does not support.

    And if it makes you feel any better, it looks like the new iPhone software is also having a similar issue with this kind of config - http//forums.mactalk.com.au/31/66559-os-3-0-exchange-bug.html (can't post links yet so fill in your own colon in the above URL).

    Regardless, I sure hope this is something that gets fixed shortly...

    - Chris
    You're right. If your IT team won't send you a root certificate that has the appropriate information in the fields, that route won't work for you. Apparently, there are two other issues. First, WM7 will require 3rd party certs, so many IT depts are getting them anyway, but Second, there is an issue with how the certs are encoded on the server "UTF-8" I believe. That's over my head, but someone posted this over at Palm.

    I'm expecting both Apple and Palm will need to address this shortly. In the meantime, I'm hopeful my IT dept. buying a GoDaddy cert will do the trick.

    If your IT supports (or will) WM7, maybe they'll come around.
  17. #117  
    Here's what was posted over at Palm from a letter sent by GoDaddy.

    ____________________

    Below is an actual email I received from GoDaddy's SSL support: Long story short, I got a refund from GoDaddy and went to registar.com and purchased a SSL for $38 and is good for three years. I have tested this SSL and all seem to be working great! Even the Pre accepts this cert.



    Discussion Notes Support Staff Response



    Dear Secure Certificate Customer,

    Thank you for contacting SSL Support regarding your issue with your Palm.

    The RFC industry standard requires that secure certificates be issued using the UTF-8 encoding format.

    The Palm Operating System is using the "printablestring" encoding format that preceded the current UTF-8 industry standard. Please see PrintableString - Wikipedia, the free encyclopedia for more information regarding the format.

    Most new servers use UTF-8 encoding, however, Palm devices are still requiring printablestring encoding. Palm devices cannot communicate with servers that have SSL certificates installed that use the new UTF-8 industry standard.

    If you require a printablestring encoded certificate to be issued so that your Palm device can communicate with the server, you will need to arrange to have the SSL certificate signing request (CSR) generated with software that defaults to printablestring encoding. Our issuing system will issue a printablestring encoded certificate if the CSR was already printablestring encoded.

    Microsoft 2003 servers are known to default to printablestring encoding. OpenSSL software can also be used to create a CSR with printablestring encoding.

    Once you have generated a new CSR on a server that has printablestring encoding, rekey your certificate, install it on the older server, and then export the certificate. This will give you a PFX file. You can them import this file to your new server or convert the PFX file into its separate parts (Private key and Public Certificate) for installation on non-windows servers.

    We have provided re-key instructions with appropriate links to CSR generation instructions and our Installation Instructions in our Help Center article located here:

    Re-Key an SSL Certificate - Help Center—Knowledge Base and FAQ

    Let us know if we can be of further service.

    To Contact Us:
    Email: ra@godaddy.com
    Phone: 480-505-8852
    FAX: 480-393-5009
  18. #118  
    Quote Originally Posted by realistdreamer View Post
    ... If your IT team won't send you a root certificate that has the appropriate information in the fields, that route won't work for you...
    Can you elaborate on what the "appropriate information in the fields" needs to be?

    I have seen other posts that recommend matching the CN in the cert to the actual EAS server FQDN - but does that apply to the root cert, the client cert or both?

    I am in IT myself and my friendly Windows admin counterpart is willing to try just about anything that doesn't violate our security policies. We are already using 3rd party certs on the server (from entrust.net) and I have installed that cert on the Pre as well but it did not help.

    Again, it seems like the Pre is getting hung up on the client cert - I am able to browse to xxxx.domain.com/owa in the web browser ok (which does not work without the root cert) but then get a "client cert needed" error after that so the client cert step is definitely not currently working.

    Love to hear any other suggestions...

    - Chris
  19. #119  
    Just becuase your Exchange server has a self-signed certificate DOES NOT MEAN THE CERTIFICATE IS CORRECT! How you connect through a web browser and through Outlook with HTTPS are different than how you connect through Outlook Web Access and Exchange ActiveSync. Therefore, just because one works does NOT mean the other works unless hostnames and how the certificate were generated and applied were done CORRECTLY at the Exchange server.

    In fact, you cannot generate the correct cert request on an Exchange 2007 server unless you do it from the powershell. And if you are using an Exchange 2003 server, it must be running SP2 or higher.

    EAS on the Pre is NOT the full blown version of the product and Palm has only enacted on or enable certain parts of it.

    You CANNOT have an EAS policy on your Exchange server that enforces the Palm Pre user to have a PIN number to secure it, or turn off the camera, or allow the use of client side certificates to verify identity.

    The lack of client side certificates (meaning you get a certficate for your Pre to verify its identity and therefore have two-factor identification) is a HUGE glaring hole and I can see why the Pre is not being touted as a full fledged business tool. Two factor identification is a big deal in the corporate IT world and for anybody that is dealing with private information, like social security numbers. I do government work and I'm sure that you would all like to know that if I'm emailing over the Internet and have your SSN and other personal information in that email, that its encrypted from end to end so nobody can get their hands on it.

    The other HUGE lack in this EAS version is the inability to schedule when I want EAS to do its thing. With WinMo phones, you can set peak times and non-peak times this way your phone isn't getting emails 24/7. You can then leave the volume on for important things like text messages or phone calls when you sleep and not hear the phone grabbing emails overnight. This is missing from the Pre version of EAS and this SUCKS!
  20. #120  
    Quote Originally Posted by ckgoodwin View Post
    Can you elaborate on what the "appropriate information in the fields" needs to be?

    I have seen other posts that recommend matching the CN in the cert to the actual EAS server FQDN - but does that apply to the root cert, the client cert or both?

    I am in IT myself and my friendly Windows admin counterpart is willing to try just about anything that doesn't violate our security policies. We are already using 3rd party certs on the server (from entrust.net) and I have installed that cert on the Pre as well but it did not help.

    Again, it seems like the Pre is getting hung up on the client cert - I am able to browse to xxxx.domain.com/owa in the web browser ok (which does not work without the root cert) but then get a "client cert needed" error after that so the client cert step is definitely not currently working.

    Love to hear any other suggestions...

    - Chris
    If you are getting this message, that means you have an authentication policy requiring the client side to use certificates for part of the authentication process. I mentioned in another post it looks like the Pre does not have the ability to do client side certs for authentication, at least in EAS it does not. The iPhone also has this limitation and it is just plain stupid. However, the Pre also does not have the ability to accept an EAS policy from an Exchange server that says you need to secure this thing with a PIN of x amount of digits, etc.

    Palm did announce that they are going to fix EAS, but it will be interesting to see what exactly they think needed to be fixed.
Page 6 of 8 FirstFirst 12345678 LastLast

Tags for this Thread

Posting Permissions