TLS Manual Configuration

For feature requests, please see:

For troubleshooting questions, please post in the following format:

Can’t configure mattermost to use own TLS certificate

Steps to reproduce
How can we reproduce the issue (what version are you using?)
I’ve followed the steps at Configure TLS on Mattermost server — Mattermost documentation

Expected behavior
Describe your issue in detail
Due to a recent update causing issues with iPhones, we have determined that we need to set up TLS for mattermost. We purchased a TLS certificate through GoDaddy and are attempting to set it up for mattermost. The files we receved consisted of 2 .crt files and a .pem file. Based on my research, the .pem file is the TLS certificate file. We also received a generated-private-key.txt file and a generated-csr.txt file.

I may be configuring this completely wrong but I pointed to the .pem for the certificate file and the private-key.txt file for the tls key file settings. Upon restarting mattermost per the instructions, I am no longer able to access mattermost. The port settings are set to use port 443 and I even try to access mattermost on the server itself using “localhost” but am having on success and had to revert to a saved snapshot of the server to restore functionality without TLS.

I suspect I am doing something wrong but this is my first time messing with TLS so I’m hoping I can get some assistance.

Observed behavior
What did you see happen? Please include relevant error messages and/or screenshots.
Mentioned above.

Does the Mattermost service start successfully? What do the logs say?

Have you asked GoDaddy? There are several different file types for PKI. You mentioned getting two .crt files and a .pem, but then refered to a private-key.txt file. Where did that come from?

It’s my understanding that you need to have the key NOT protected with a passphrase. It sounds like maybe yours is, and you’re referring to something that suggests putting the passphrase into a .txt file That A) won’t work with Mattermost, and B) is pointless… if anyone has access to the file containing the key, they can read your text file, too.

You could also follow the instructions for Let’s Encrypt and see if that works. It may be sufficient, and may get you going until you can get clarification from GoDaddy which is the server cert and which is the private key.

I did some digging around at the files send from GD and found that they sent the certificate in a couple different formats but also sent it as a txt file. The only reference to the key was in a txt file as well. After researching, it appeared that I could simply rename the extension from .txt to .key so I’ve been working with that.

After correcting some permission issues when mattermost attempted to read the .key file, I’ve got to a point where its no longer throwing errors about they key but is still failing to load. I’ve ommitted the domain name in the log for privacy.

Jan 22 08:10:50 * mattermost[14292]: {“timestamp”:“2024-01-22 08:10:50.120 -06:00”,“level”:“info”,“msg”:“Should not persist transitionally prepackged plugin: not a newer version”,“caller”:“app/plugin.go:1108”,“plugin_id”:“com.mattermost.plugin-channel-export”,“prepackaged_version”:“1.0.0”,“existing_version”:“1.0.0”}
Jan 22 08:10:50 * mattermost[14292]: {“timestamp”:“2024-01-22 08:10:50.153 -06:00”,“level”:“info”,“msg”:“Should not persist transitionally prepackged plugin: not a newer version”,“caller”:“app/plugin.go:1108”,“plugin_id”:“com.mattermost.apps”,“prepackaged_version”:“1.2.2”,“existing_version”:“1.2.2”}
Jan 22 08:10:50 * mattermost[14292]: {“timestamp”:“2024-01-22 08:10:50.153 -06:00”,“level”:“info”,“msg”:“Should not persist transitionally prepackged plugin: not a newer version”,“caller”:“app/plugin.go:1108”,“plugin_id”:“focalboard”,“prepackaged_version”:“7.11.4”,“existing_version”:“7.11.4”}
Jan 22 08:10:50 * mattermost[14292]: {“timestamp”:“2024-01-22 08:10:50.310 -06:00”,“level”:“info”,“msg”:“Starting Server…”,“caller”:“app/server.go:927”}
Jan 22 08:10:50 * systemd[1]: Started Mattermost.
Jan 22 08:10:50 * mattermost[14292]: {“timestamp”:“2024-01-22 08:10:50.328 -06:00”,“level”:“info”,“msg”:“Server is listening on [::]:443”,“caller”:“app/server.go:1003”,“address”:“[::]:443”}
Jan 22 08:10:50 * mattermost[14292]: {“timestamp”:“2024-01-22 08:10:50.328 -06:00”,“level”:“info”,“msg”:“Sending systemd READY notification.”,“caller”:“commands/server.go:130”}
Jan 22 08:10:50 * systemd[1]: mattermost.service: main process exited, code=exited, status=1/FAILURE
Jan 22 08:10:50 * systemd[1]: Unit mattermost.service entered failed state.
Jan 22 08:10:50 * systemd[1]: mattermost.service failed.

What do “systemctl status mattermost.service” and “journalctl -xeu mattermost.service” say?

Also, * config.json setting: ".LogSettings.ConsoleLevel": DEBUG", and see if the mattermost.log says anything more

My apologies. I mean to reply to this post sooner but got caught up in a multitude of other things.

I was able able to figure it out. I found a post online that mentioned UTF-8 encoding in GoDaddy’s key files causing issues in some instances. The fix was to simply add a blank line to the top of the key file. Sure enough, after trying that, the server was able to read the file and load successfully. Of all things… :dizzy_face:

1 Like