When connecting to FMS via an FMP client we’re getting an alert "FileMaker Pro can’t verify the identity of “[domain.name.com]”
It goes on to say “An SSL certificate encrypts data sent to and from the host to keep the data private. The certificate for this host is invalid and it can’t be verified. Do you want to connect anyway?”
It connects, but instead of getting a green icon, we’re getting an orange one.
Hi @ovunque,
What’s the domain name in question?
Did it work before now? Who set up the server and who obtained the certificate?
Thanks for the quick reply.
It has worked in the past, on an earlier version of FMS/FMP. Plenty has changed since then.
We set up the server, certificate and control the domain. Preferable not to post on a public forum.
The domain is managed on a hosting provider. We use a subdomain dedicated to FMS whose A-Record points the IP address where FMS is hosted.
I don’t think that we can help you further without more details about what’s changed and what errors you’re seeing, at least.
Here are some screen grabs.
#1 Is the FMP popup we get when connecting to FMS from FMP
#2 is the popup after clicking “view certificate” in #1
#3 & #4 are grabs from the “details” section where “critical” is listed as “YES”
The process we used:
I’m not sure what would have changed since it worked. It was a few FMP/FMS versions back and FMS was new to accommodating Letsencrypt.
LMK if you need additional info.
Are you sending the intermediate certificate (from chain.pem)?
Also, are the two names that you’ve redacted exactly the same domain name, with no differences at all between them?
@ovunque, since you created this under “Server” instead of “Help”, you missed out on the standard questionnaire for new help topics, including the note about domain names. It’s much, much easier for us to help in most cases when you provide the real domain name. You’re not actually concealing anything that isn’t already made publicly available the moment you issue a certificate. All Let’s Encrypt certificates are permanently logged to the publicly-available Certificate Transparency logs. As such, obfuscating this information is not increasing secrecy of the domain names, but rather hindering the community in assisting you.
Not using the intermediate certificate (chain.pem). Should we?
The two domain are indeed exactly the same. The first one, of course tags the FMS port :5003.
The port isn’t important - certificates are port-agnostic. However, some browsers will return errors if you’re not service the chain as well. How to do this varies among webservers. Sometimes you just append it to the certificate (this is what fullchain.pem is), and sometimes you specify them separately.
I think OP’s server is sending the full chain.
$ openssl s_client -connect the.server.tld:5003
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = the.server.tld
verify return:1
140232417401600:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1487:SSL alert number 40
140232417401600:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
Certificate chain
0 s:/CN=the.server.tld
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
and on 443 as well:
$ openssl s_client -connect the.server.tld:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = the.server.tld
verify return:1
---
Certificate chain
0 s:/CN=the.server.tld
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----Thanks jared.m for the note about domains. It didn’t seem wise to be announcing a domain that is currently in the middle of being secured and not quite working (it’s a database server, not a web host) The databases themselves are also secured and encrypted, but just the same. But I understand what you’re trying to communicate.
Regarding chain.pem, I suspect you’re honing in on where the problem is.
This thread (Filemaker Server on Mac OS X) had a helpful link in it (http://bluefeathergroup.com/blog/lets-encrypt-ssl-certificates-for-filemaker-server-for-mac/). Based on that I ended up testing the GetSSL.sh script, which seems to have resolved the issue.
GetSSL.sh seems to import the fullchain.pem to the certificate whereas I did the cert.pem when trying to do manually.
What I’m not seeing with the GetSSL.sh approach is its making use of the .well-known/acme-challenge files. How’s that?
The GetSSL.sh script passes /Library/FileMaker Server/HTTPServer/htdocs to Certbot as the webroot, and Certbot writes to .well-known/acme-challenge/ within the htdocs direcetory.
It's very easy to figure out what the domain is from the certificate expiry time, which is in one of the screenshots.
It’s very easy to figure out what the domain is from the certificate expiry time, which is in one of the screenshots.
My prospects of achieving ace security genius status are not looking good at this point.
Could it be sending something different when SNI is used?
_az The GetSSL.sh script passes /Library/FileMaker Server/HTTPServer/htdocs to Certbot as the webroot, and Certbot writes to .well-known/acme-challenge/ within the htdocs direcetory.
Thanks for that.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.