Results 1 to 8 of 8
  1.    #1  
    I realize that a lot has been mentioned on this topic, but I didn't see anyone mentioning the IIS manager as a part of the solution to their Exchange sync issues, so thought I would pass this along.

    I am using Win SBS 2003 and Exchange 2003.

    I kept getting the date/time error trying to sync to my self-issued certificate exchange server. Turns out my default web site certificate was not issued to my FQDN, but to my local server instead.

    I found that I had to go to the IIS manager, select properties for my Default web site, go to the Directory Security Tab, and launch the "web server certificate wizard" by clicking the "Server Certificate" tab.

    I discovered that in setting up the SSL certificate for my default web server that I had used my local server name instead of the FQDN. Using the wizard, I was able to make a back up copy of my current cerificate, remove the current certificate, and then create a new certificate with the FQDN (<domain name>.com) rather than my local server name (<server>.<domain>.local).

    Then when I made sure I had the root certificate loaded onto my phone (not the one I just created, but the one from the Certification Authority application in SBS), the thing synced right up and has been working great (gets contacts, calendar, and email).

    I can do this since I am running a small network in my home office, and have only two users, so it's not a big deal for me to change the certificate.
  2. #2  
    This is extremely helpful. Did you find this over in Palm's forums? Is it something you think an IT department with 2000 users would do? Does it create a security issue by using the public address?

    The Certificate they gave me has "*.company.com" and the Pre won't work with it. It sounds like they need to replace the cert on the server AND get me a new certificate from CA.

    Hmmm? Does that sound right?
  3. #3  
    I'm an exchange admin.. I don't see how changing the name located on the cert made any difference. It's more likely that your self-signed cert had expired. You will get the time/date error if that happens. When you created a new one it would reset the date and thus work.
  4. #4  
    James, I'm not a site admin, but after trying to deal with this for days (and talking to Palm) it is clear that the public address in the certs on the Pre and the Server have to match. No mismatches, no alias, no wildcards. It is also clear that the cert on the Pre needs to be created as a root by the Certificate Authority.

    There are MANY out here who have unexpired certificates who are getting this GENERIC date/time error. Palm has admitted as such.

    I don't know if this solution will work for me or not, but it's consistent with what's out there on precentral and palm support.
  5. #5  
    that's a basic issue, that should have prevented almost any device from properly using or syncing with EAS or OWA. The cert has be to assigned to the external domain name you are trying to connect with IE: mail.mydomain.com, the local default ssl cert is servername.internaldomain.local and won't authenticate external sll connections.
  6. #6  
    Quote Originally Posted by Funky Cricket View Post
    that's a basic issue, that should have prevented almost any device from properly using or syncing with EAS or OWA. The cert has be to assigned to the external domain name you are trying to connect with IE: mail.mydomain.com, the local default ssl cert is servername.internaldomain.local and won't authenticate external sll connections.
    I'm glad you think it's basic because I'm having horrible trouble with my IT people. They are nice, it's just that they deal with so many newbies who bring human error to the system, they can't hear it when it's ACTUALLY AN IT ISSUE.

    Is there a SIMPLE way to explain to them what they need to do so I can get the Pre working without disabling a network for 2000 people?
  7. #7  
    More griping.

    [Rant]
    • Why is it hard for IT to understand that the Pre is looking for the same address on the cert as is in the mail setup?
    • Why is it hard to understand that you can't be at root if there is a doman above your branch?
    • Why is it hard to understand that you can't use a wildcard in an FQDN?


    I'm not an IT person, but it makes sense to me. Tell me you can't fix it because it compromises security. Tell me you can't fix it because of downtime. Tell me you can't fix it because you don't have the time (45minutes tops).

    But, please don't collect your salary for being an IT admin and tell me you don't understand how server security works after it's explained to you.

    [/Rant]
  8. #8  
    My IT folks are trying to come through for me. I work in a school district which has email addys setup like me@district.k12.state.country.

    We use Exhange 2003 and have all SPs. My IT folks emailed me a root certificate (I checked it's the root) with:

    • Name - owa.district.k12.state.country
    • Issued by - owa.district.k12.state.country
    • Common Name (Issuer Info) - owa.district.k12.state.country
    • Common Name (Subject Info) - owa.district.k12.state.country

    They didn't complete most of the other issuer or subject information so it's blank. All of it is now in certificate manager on the Pre

    When I fill out manual setup, I use https://owa.district.k12.state.country for the mail server.

    Still gives the same SSL error. It's not expired, is a root and there is not date/time issue. I'm stumped

    • Do they need to have different in the fields?
    • Do they need to fill out the other info?
    • What do I put, if anything, in the Domain field of the mail setup?


    I know I'm close and I want the IT dept to get props for helping me fix this. Any suggestions?
    Last edited by realistdreamer; 06/11/2009 at 05:42 PM. Reason: not complete

Tags for this Thread

Posting Permissions