You don't have to communicate from the web server to the FMS using https, you can use http instead, which if you're sure of physical connections to the LAN mean that the FMS XML interface isn't externally accessible at all, and that the LAN is physically safe from 'snooping' of traffic would be one solution.
There have also been some suggestion of people being able to install pre-existing certificates into FMS however I have been unsuccessful in getting this to happen. Also if you do decide to proceed with installing a certificate there are only certain certificates from certain CAs which are certified to work - I have been similarly unsuccessful in getting more 'cost effective' certificates from other CAs to import and function correctly.
As far as I can tell you have four options
- accept/ignore the certificate errors - whatever code you're using from the web server to call the XML interface (if it is directly that, rather than the API - see 4. below if it's the API) could quite likely be able to be told to ignore the certificate errors...?
- use http accepting the risks associated with this
- install a certificate signed by an FM-certified CA
- if you're using the PHP API (rather than the XML interface directly) then you can tell the API not to verify the certificates and to proceed with any certificate. In the API code installed on your web server look for the file filemaker-api.php in the folder FileMaker\conf and un-comment line 36 to that it enables the VERIFYPEER => false command set there which will prevent it from being concerned by the untrusted nature of the FMS self signed certificate.
Hope this helps
Thanks for this. The soituation is that an asp web service (for which I am not responsible) receives data from 'outside' and then used the XML directly to interact with FMS. The current live situation is FMS 11 with the web service on the same machine as FMS in the new setup the paln is to leave the web service on the 'old' server and have FMS 13 on a 'new' server. I had thought that only the IP reference to FMS would need to change, I didn't realise we could still use http I was under the impression that if I had 'require secure connections' turned on that I would need to use https.
So are you saying I can use http for XML even with the 'require secure connections' turned on.
I can confirm that enabling 'Require secure connections' does not force the use of https for XML access (and consequently doesn't impact on CWP using the API either, both can use either http or https). You can still continue to use http, (though of course it would be better not to if that can be avoided but, you know ;-)
If you look at the detail of that config setting it says
Use Secure Sockets Layer (SSL) to encrypt data passed between FileMaker Server components and FileMaker Pro, Go, and WebDirect clients
making no mention at all of XML/CWP. It also goes on to point out that
Progressive downloading uses unencrypted HTTP connections, even if the Require secure connections setting is enabled
which in my understanding is acheived through the XML interface (at least that's how we now get at external container data using the API).
Clearly you'll want to test this for your specific situation, but I don't expect that you'll have any problems.
Thanks ever so much.
After further testing I have discovered that
( where 'firestorm' is the name of the server on the LAN ) does works whereas
Does not work, which seems a bit odd.
I have passed this info to the asp developer, so hopefully he can move forward now.
Indeed, that does seem odd - also note that in the URLs above yo're still using https...? are you sure you've tested the right thing...?
It seems that using the 'name' both http and https work as expected with the test xml url. I hope this is the last issue with this as the asp is a gateway from windows mobile devices which we are replacing with an FMGo development and so will only be required for a short time - we just need to get it working until the FMGo app is ready.