The following is my experience with connecting a Windows Phone 8 device (specifically the Nokia Lumia 920) to the Novell Mobility Connector for Data Synchronizer. I hope it helps someone out.
We just got our first Windows Phone device trying to connect to our Mobility server. I ran through the steps to set it up. It created the account on the phone, started synchronizing, then said "There is a problem with the certificate." I had already told it to ignore the self-signed nature of the cert. We have hooked up numerous iOS and Android devices and have not had this issue. Naturally I was confused.
I did some research and found that Windows Phone is indeed more anal about certificates. The suggested work around was downloading the server certificate to the phone manually (it turned out this is not actually necessary). This did not change anything.
In my case the problem wound up being that the certificate had been created improperly. The common name was set to a friendly name. I recreated it with the common name set to the dns name of the server. This did not work either. I realized that the phone would never see the name of the server because in our setup they connect to a bare IP which is not redirected to a name. Once I set the common name attribute to the ip of the server everything was peachy.
With the Common Name attribute set correctly, I was able to connect the Windows Phone. I did not have to manually download the newly created cert, I just said to continue when it alerted me that it was not from a trusted root authority.
The moral of the story in this case is to make sure you know what you are doing when you create your SSL certificate. If you do it wrong some devices (e.g. iOS and Android devices) will let you get away with it, but others will not.
We just got our first Windows Phone device trying to connect to our Mobility server. I ran through the steps to set it up. It created the account on the phone, started synchronizing, then said "There is a problem with the certificate." I had already told it to ignore the self-signed nature of the cert. We have hooked up numerous iOS and Android devices and have not had this issue. Naturally I was confused.
I did some research and found that Windows Phone is indeed more anal about certificates. The suggested work around was downloading the server certificate to the phone manually (it turned out this is not actually necessary). This did not change anything.
In my case the problem wound up being that the certificate had been created improperly. The common name was set to a friendly name. I recreated it with the common name set to the dns name of the server. This did not work either. I realized that the phone would never see the name of the server because in our setup they connect to a bare IP which is not redirected to a name. Once I set the common name attribute to the ip of the server everything was peachy.
With the Common Name attribute set correctly, I was able to connect the Windows Phone. I did not have to manually download the newly created cert, I just said to continue when it alerted me that it was not from a trusted root authority.
The moral of the story in this case is to make sure you know what you are doing when you create your SSL certificate. If you do it wrong some devices (e.g. iOS and Android devices) will let you get away with it, but others will not.