Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 3858 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies
Posted

Hope my experience can help some searching soul out there. I got there in the end.

 

Recently, we upgraded our FMS 12 setup to 13. In the process we had to switch off Server.app's Websites function which we used to serve our php web pages through https with certificates from an external authority (Comodo). I moved our existing php files to the httpsRoot subfolder, which is where they should go. As expected, the URL in the browser was still confirmed as starting with 'https'. But the https connection now came up as untrusted by our own (and our customers'!!) browsers and our expensive green padlock had gone.

 

The FMS 13 Getting Started Guide just says to refer to 'your web server's documentation' for installing a certificate. That is easily said, after FMS13 disabled the Server.app's with all of its convenient features! Just as others describe elsewhere in this forum, I was taken by total suprise when FMS 13 fully took over Apple's and our standard web server setup.

 

What was the easiest way to get the certificates back? I was hoping a slight edit of some configuration file could do the trick, since the certificates were still present on the machine and I could see them in Keychain. Over 48 hours of trial and error followed, in which I tried editing the various Apache commands in FMS's http-ssl.conf file to get them to point to the existing certificates in the /etc/certificates directory. This just resulted in the web server not starting unless I reverted to the original version of the .conf file.

 

I looked at the CERTIFICATE and CERTIFICATE IMPORT fmsadmin commands which can be issued through Terminal. They are described in the final section of the FMS Server Help documentation. It would have been really nice had the 'Getting Started Guide' mentioned their existence, since they are your ONLY workable course of action! Ocean West's post elsewhere in this forum section provides a good step by step description of the process. However, he installs a new key/certificate pair instead of trying to get one to work which is already on your server machine. It did point me in the correct direction though.

 

I tried exporting the key/certificate files from Keychain, converting them to the requered .pem format through Terminal commands that I found. I renamed the key file as serverKey.pem, moved it to the CStore directory, and issued the CERTIFICATE IMPORT fmsadmin command providing exported .crt file as the required certificate. This raised an error stating that key and certificate did not match, and dashed my hopes.

 

It would seem that the serverKey.pem file which you can create with the CERTIFICATE CREATE command is FMS-encrypted, and FMS will correspondingly encrypt the .crt file during import. This probably means that unencrypted files of your own are a no go, and you are stuck with using the CERTIFICATE fmsadmin command set only with a freshly generated/ordered key/certificate pair. Which is ok if you have not already bought a certificate, but our situation is that we just want the old web server setup back so we could continue where we left off. No expenditure, no waiting on external validation - which I remember was time-consuming because we had to file business documents and wait for a phone call to verify our identity. This is beacuse our customers require that we have the safer and pricier Extended Validation version.

 

I decided to log on to our CA, Comodo, and noticed that we could replace our certificate based on a new .csr file. This brought the solution, which was  so uncomplicated that Filemaker should just have documented it! Here it is:

1. Use the CERTIFICATE CREATE command first, entering your domain name.

2. Upload the text from resulting serverKey.pem file to your CA.

3. When the certificate file arrives by email, use CERTIFICATE IMPORT + the .crt file's path. Pointing to its folder as Ocean West did, did not work for us.

4. Restart your server machine, ensuring that you have first properly closed all databases and shut down the Database Server.

 

The folks at Comodo were really helpful, not only by providing a free replacement service, but also by springing into immediate action when I raised an urgent ticket well before the official 48-hour leadtime had passed.

 

  • Like 2
  • 3 months later...

This topic is 3858 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.