I only believe you can have one certificate installed/active, but will check. But one question: Why would you want two different certificates, the business case?
And, you will one certificate for the WPE (the FileMaker Web Publishing Engine) on one server and the FileMaker Database Server on the other server.
Shouldn't the LAN wifi connections be secure?
I think maybe the only way way is with two machine deployment and one certificate each?
Since last year certificates for intranet are not easily available.
Just a guess, but maybe the right one: Have an internal DNS server pointing xxx.yourcompany.com (the same as the external) to your internal IP number ... and I guess that the certificate will authenticate correctly.
Maybe you should point Claus Lavendt to this tread, he will be able to confirm or tell that I am wrong here.
I see. I think OSX server can do the internal DNS.
And your Firewall/Router does maybe also have a DNS server you can turn on to handle the inside, if it is not already active.
2 of 2 people found this helpful
I asked the same question to my local FMI service engineer. Here's how I understand his response.
You certainly may install a compatible third-party SSL certificate on your internal FMServer (database server) through the normal process. If the certificate you install references a publicly available DNS server name, then it will resolve properly and you will see the green lock icon (or the closed lock on Windows).
If that FMServer is not available on the public internet, and so the named server you reference is not really 'resolvable', then the third party certificate cannot be verified. The encryption of the connection WILL happen, it is just the verification of the certificate that cannot work. Thus, you will see the icon for an 'unverified' server (the grey/black icon on Mac, the closed lock overlaid with a warning icon on Windows).
By the way, I believe this second appearance is the same if you use the FMI pre-installed certificate. It is a valid certificate and an encrypted connection, but the verification is incomplete since the certificate is not verifiable by a third party and the public DNS system.
I hope that helps clarify what will happen. Whether you choose to use the built-in certificate or buy one is really up to you. Certainly the recommendation is to buy your own, even for a machine that is not public.
- Drew Tenenholz
Thanks for the explanation. This is good to know. If the icon is not green it is still a secure connection. I did purchase a certificate and it shows green when connected from WAN.
I am guessing that Get(ConnectionState) will return 2 in this case just like the default certificate. I will have to check that out. Probably should have been the first thing I did before asking here. Good to know either way. On the LAN I am not so worried about verifying the server name.
Slightly off topic, do you know if progressive download works in this case when Get(ConnectionState) returns 2 or is it only for 3?
bigtom, FMS only uses one certificate. Other services can make use of other certificates and I used to do this all the time back when FMS played well with Apple's Server.app. But it would be nice if FM supported multiple certificates because making everyone going through the WAN puts all your traffic through your main WAN router which is a lot less efficient than going through switches on your LAN. For this reason I like running machines like the Mac Pro with two ethernets, one directly to the WAN router and one to a LAN switch. If on the LAN, connecting via the LAN URL or IP is much faster than going through the WAN URL. I've sped people up a lot by simply changing their host pointer on the LAN to the local LAN address of the FM server. Hopefully FM will improve on this in the future. But for now you get one SSL certificate for FMS and you'll want to use it on your WAN connections. And I agree you're less concerned with your LAN connections, but it still would be good to have them confirming the SSL certificate instead of encrypting without confirmation. You're still getting encrypted, but supporting multiple SSL certificates for 3rd party verification sure would be a nice security improvement. It also would be nice for shared hosting so that different companies on the shared hosting could have their own SSL certificate URL. Then again, apparently FMS 15 EULA is not going to allow that in the future.
2 of 2 people found this helpful
Seems to me that the main challenge here is one of DNS. The internal traffic should be routable to that DNS name the same as the external traffic so that the FQDN as stated in the SSL certificate is recognized by the clients and you can get a green lock for both internal and external.
It's one of those lurking issues with all things SSL: you have to have a good handle on the DNS. Not saying that bigtom doesn't but making a general statement because it is one of those hidden complexities that catches a lot of FM devs out, those that have never had to deal with DNS much before.
Good point, Wim. I've messed around with DNS and run a couple of DNS servers, but I know it is a limited understanding. But I have a clients with DNS IT experts who are able to route the DNS server traffic back inside the LAN instead of out to the WAN for the FMS URL and it work properly. So, yes, knowing how to run DNS can solve a lot of these problems. One of the challenges of being a FileMaker developer is having to have a bit of a general understanding of other services like DNS, AD, web hosting, etc., and to know how to find experts in those areas when you need it assistance. Most importantly, don't over sell what you know. Personally for my company, we have a relationship with a company that has staff certified experts in both Windows and Mac Servers (not desktop) and we refer them to handle such issues and they refer their database work to us. It works out pretty well!
Taylor Sharpe wrote:
One of the challenges of being a FileMaker developer is having to have a bit of a general understanding of other services like DNS, AD, web hosting, etc., and to know how to find experts in those areas when you need it assistance. Most importantly, don't over sell what you know.
Yep: "It's not what you don't know that will hurt you; it's what you know that isn't so."
I've made the point before: as FM developers we do need to think about the deployment and not just focus on the development. Nothing wrong with not wanting to get involved with things like DNS and AD, etc. But those are becoming increasingly important factors in a stable deployment. So find help; either internally at the client or other developers that you feel you can trust.
I have a general understanding of DNS, but it has been some time since I dealt with a local DNS server directly.
The router has some DNS options, but it is not an enterprise piece of hardware. I will need ot explore what it can do.
The idea of setting up a DNS server is intersting and I may give it a try. I do think getting all the connections to verify off of the one certificate is important at least from the prepective of the client seeing that everything is "green".
Changing host files to point to the server might not be the best option as this seems difficult to manage on a large scale and maybe not possible for iOS.
There is an OSX server machine on the network that handles all the time machine backups for the network. I am thinking I can use this as a DNS server as well. Does this sound like a bad idea? I will figure this out eventually.
1 of 1 people found this helpful
Wim, it would almost make for a good Devcon presentation to talk about the tangent technologies to FileMaker Server that technically are not FileMaker development, but need understood and taken care of or your solution will have problems.