mac SSL Certificate Installation

[Ocean West]

So I am venturing in to setting up a certificate with 13 on my server, ( just so I can get experience )
 
Background:

• I have a domain that I only use for my server ( Mac mini, Mavericks, with server.app installed)
• I am in a residential setting so Port's 80 is blocked by my ISP.
• I have my domain pointing to DynDns service and my router updates the service should my IP address change.
• I can reach my server console using HTTPS and my domain name externally. 
• And accessing FMP works internally and externally.

Actions:

• I had to make sure I had Read/Write access to the /Library/FileMaker Server/CStore directory
• I ran the CERTIFICATE terminal command on the server. Making sure I added my company name and location as COMODO (the CA requires it)
• Comodo offers a 90 day SSL Certificate for FREE, i decided to go this route before spending money.
  • Comodo.com

Results:

• the command results in a serverKey.pem and serverRequest.pem file. 
• opened the serverRequest.pem file in a text editor and copied the text
• on comoro added that text to the setup page
• confirmed my server ( had to use the MD5 Hash settings with text file on the server cause I don't have an email account for that domain)
• received a folder with a bunch of .crt files ( most of which were for comodo )
  • AddTrustExternalCARoot.crt
  • ComodoUTNSGCCA.crt
  • EssentialSSLCA_2.crt
  • mini_mydomain_com.crt
  • UTNAddTrustSGCCA.crt
• I ran the CERTIFICATE IMPORT command using the path to the certificate bearing my domain.
• A file was created in the CStore directory serverCustom.pem
• After turing on SSL in the console I restarted the server
   

Last night after I did all this I didn't notice anything different and when I ran the analyzer  https://sslanalyzer.comodoca.com on my domain it still was reporting the unsigned FileMaker certificate. 

 

Today I now have a Padlock Icon In the lower left of the any open file in front of the 100 Size indicator. and when on iOS i see a green Padlock in front of the FileName in the toolbar, and now my SSL is reporting as signed and not referencing the default FileMaker certificate.

 

 

 

This process would be the same for a wildcard domain or a single domain. The price for a wildcard from comodo was pretty expensive about $400 per year, but you might do better with a reseller, I got a wildcard for a client who uses comodo, and they only charged me about $120 per year.

 

I hope this experience was "by the book" and that if there are any recommendations or alteration to my process please continue the discussion!

[Matt Klein]

Hi Stephen -

 

I'm getting ready to offer a WebDirect solution to my clients and we need to use SSL because of the industry we are in.   I have the solution complete and tested it using FileMaker's standard SSL Certificate.   I know that most of my clients will not want to be bothered with getting the "There is a problem with this website's security certificate." message every time they access the WebDirect app because the certificate isn't issued by a trusted authority.

So,  I'm going to need to recommend they get themselves a custom SSL certificate from one of the supported authorities.  The majority of those clients will have a registered DNS name(ie.  www.mywebsite.com), but they will not be hosting their own website.  In other words,  their DNS name will point to servers at their web hosting service.   However,  the WebDirect app will be running locally on their network so we would need to reference their static public IP address.

 

I don't know anything about SSL Certificates and I've reviewed the FileMaker documentation and read through your post here.   I'm still not clear on how to use the CERTIFICATE create command if the WebDirect app is running on their FileMaker Server.    My question is,  would they use the public IP address as the "server_name" in the CERTIFICATE create command or do they need to get a DNS name or am I totally off base here.

 

Any help would be greatly appreciated.

[BrentHedden]

Stephen -

Do you know if installing a cert using the command line utility will work in a two machine configuration, specifically with outside web browsers to the WebDirect site? I'm not too concerned with internal traffic (Pro to Server), just the web traffic.

 

OK - after fiddling around for 1/2 a day, I was able to answer my own question.  Using this install method does work with web and client traffic, but it gets fancy when you've got a two machine configuration.

 

First, I followed the procedure that Stephen outlined in getting and installing the free 90 day certificate.  Worked exactly as he mentioned. 

 

HOWEVER, the fun comes when you've got a two machine configuration.  The manuals makes no mention of this, but you have to install the certificate on both machines.  You only have to create the request file once (on the database machine).  Once you get the files back from the authority, copy the contents (including the serverKey.pem file) from the database server's CStore directory to the web server's CStore directory.  Then follow the same install instructions, but doing so on the web server.  Reboot, and whala!  2048 bit encryption with IIS/Apache!

[fndimarco]

A followup regarding a two-server configuration, and a problem:

 

I followed the directions here and successfully installed a wildcard SSL certificate from GoDaddy on my database server.  Then, I copied the contents of the CStore folder and placed them in the web server's CStore folder.  I used the fmsadmin certificate import command to install the .crt file from GoDaddy and restarted the server.  

 

This was a qualified success.  Now, when I log in via WebDirect, I get a valid HTTPS connection.  Success!  However, on the server configuration (Console:Datebase Server: Security: Secure Connections), the require secure connections checkbox is off.  Turn that checkbox ON, and my connections all break -- web direct can't connect and if I try to open the file via FileMaker Open Remote... the files no longer show up.  

 

Did all the restart/reboot stuff.  No change.  So, if the secure connection is OFF but my web direct connections are secure, are my FileMaker/Go connections secure (my clients will access the solution via all these methods) as well because of my certificate?  Or am I having some other problem?

 

FileMaker Server 13v1, Win2008 Server -- everything was working fine before installing the certificate.  I, too, was trying to get rid of the annoying self-signed certificate for Web Direct connections.

[Matt Klein]

So, if the secure connection is OFF but my web direct connections are secure, are my FileMaker/Go connections secure (my clients will access the solution via all these methods) as well because of my certificate?

 

I've been doing quite a bit of research on this and talked to a FileMaker Engineer about it to get clarification.    Having the "Require Secure Connections" box marked is NOT required for secure HTTPS WebDirect connections.    The only thing you need to do to create the secure connection to WebDirect is use "HTTPS" in the URL.   If you have FileMaker's default SSL certificate,  you'll get the "annoying" message in the browser.    If you have a custom SSL certificate,  you won't get the message.

 

This is the case because the "Require Secure Connections" box in the Server configuration effects the traffic passing between FileMaker Server and the clients(Pro, Go, WebDirect) not the traffic passing between the Web Server and the browser.   WebDirect doesn't talk directly to the browsers.   WebDirect talks to the Web Server which talks to the browser.  So,  it's the Web Server that handles the secure SSL connections via Browser.

 

The only effect, that I've seen,  that the "Require Secure Connections" box has on WebDirect connections is that, when it's marked,  HTTP/non-secure connections cannot be made.   Without the box marked,  a user can use HTTP in the URL and access it without SSL.      This I believe can be mitigated by using the Get(ConnectionState) function in the startup script and exiting the app if a non-secure connection is made.

 

It is my understanding that if the "Require Secure Connections" box is not marked,  traffic between Server, Pro, Go, and WebDirect is NOT encrypted/secure.    So,  No, your Pro/Go connections are not secure.

 

All that said,  I'm interested to know if you found a solution to your issue of not being able to access the databases with the "Require Secure Connections" box marked.  I have run into that same problem and have not found a solution yet.

[fndimarco]

Hi Matt:  Thanks for you feedback on this -- I'm particularly happy to hear I am not alone and/or hallucinating these problems.  I have tried to fix this issue in various ways, including spinning up new, clean servers (on Amazon Web Services).  Same behavior: if I have "Require Secure Connections" checked, I can not access via Go or FM13.  

 

Also: If I turn off Require Secure Connections and connect via Web Direct using https://, I don't get the certificate error.  However, I added a step (to the FMServer_Sample.fmp12 file's login script that shows a dialog box with the results of Get (ConnectionAttributes) and Get (ConnectionState) -- and even though I see a lock in my browser's address bar, the results of those functions is blank for ConnectionAttributes and "1" (that is, not secure) for ConnectionState.

[Matt Klein]

However, I added a step (to the FMServer_Sample.fmp12 file's login script that shows a dialog box with the results of Get (ConnectionAttributes) and Get (ConnectionState) -- and even though I see a lock in my browser's address bar, the results of those functions is blank for ConnectionAttributes and "1" (that is, not secure) for ConnectionState.

Hmmmm....I did the same thing with my local server that uses the default FileMaker certificate and Get(ConnectionState) properly returned a "2".    I am unable to test this at my client site which uses a custom certificate because their web developers added some re-directions to ensure that HTTP cannot be used.

[oleung]

Matt and Marco, you both are not alone. I have.encountered same problem afer applying a cert. it goes wrong after restarting the server.

I'm thinking if this is related to the ssl cert.

Any advice? Already killed me whole day to try finding out a solution.

Oliver

[dansmith65]

I think this will answer your question about issues with Go Daddy certificates: http://forums.filemaker.com/posts/3d7fd28d98

 

To get the server to work with with secure connections using the default certificate again (after attempting to install a custom certificate), all you have to do is delete the CStoreserverCustom.pem file.

[Agnes Riley]

I am so happy I'm not alone.

 

I have a two server setup, where some time ago I was able to get the SSL cert installed for my web server, but now one of my client's IT department requires that the FM server is secured. So in the process of trying to achieve that I lost the secure connection from the web server and still have a gray (not green) lock on the FileMaker DB when I open it.

 

So, the question is, has anyone hacked this properly? I have a GoDaddy GoDaddy SHA-1 cert. And it is issued for the domain with 4 alternate names (subdomains).

 

When I download a cert as a ziip get these files: http://cloud.zerobluetech.com/image/2f2l3W0r2a1C

 

Thanks,

Agi

[FileMaker Magazine]

I've messed around with this for the better part of the day and my suspicions regarding the mysterious "green lock" (at least mysterious to me) have to do with the root certs and the intermediaries that FMS is storing - I'm guessing within their keystore - if that's where they're storing them.

 

When you read the info here http://help.filemaker.com/app/answers/detail/a_id/11413/ you see the following comment.

 

*SHA-256 certificates require the following minimum FileMaker versions: FileMaker Server 13.0v5, FileMaker Pro 13.0v4, FileMaker Go 13.0.8

 

Well, most CA's are not going to be issuing sha1 certs anymore, so I'm wondering if FMI has not included support for 256 (sha2) intermediate certs. I just installed a 256 QuickSSL Premium (supposedly supported) on a server today and despite Get(ConnectionAttributes) reporting the right common name and CA Issuers: GeoTrust DV SSL CA - G4, I get no green lock when going through the right domain name within fmnet:.

 

I'm suspect that they need to add some CA certs to FMS, but I'm not sure. I'm assuming that if you get a good commonName from Get(ConnectionAttributes) when in a FMP client and it's the exact same cert you've got installed on IIS/Apache then you're good to go - just not going to get the green lock.

 

Is anyone else using 256 certs? I meet all the requirements with the versions of v5 for server and v4 for FMPA (is Advanced the problem?)

[Agnes Riley]

I just checked and I am getting the following information when using Get (ConnectionAttributes): http://cloud.zerobluetech.com/image/3I2O22332a1Z

So I should be good then.

Thanks, Matt. I spent days on this and so did Stephen (who actually spent some time trying to help me get it green, as well).

Conclusion: green was never my color.

[Steven H. Blackwell]

Given all the issues that SSL and TLS have experienced in the past year, this entire business of certificates is going to come under increasing skepticism and review. FileMaker Server will have to undergo some changes as part of that process I would suspect.

 

As a general rule, you are going to need a custom certificate from one of the supported Certificate Authorities to make Encryption in Transit work correctly.  And there are going to need to be some way to assure that the certificate itself is legitimate.

 

Back to smoke signals.

 

Steven