• Status Unconfirmed
  • Percent Complete
  • Task Type Information
  • Category Notifications → Email
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Low
  • Reported Version 1.0-rc7
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray
Opened by ericblade - 31.10.2018
Last edited by peterdd - 03.11.2018

FS#2521 - TLS email with self-signed certificate doesn't work, "Completely unexpected exception"

I use a personal email server with a self-signed certificate (i’m not sure if it’s possible to use my https certificate for that? i don’t even kind of understand what all I did to get this email server setup, and I don’t really want to mess with it... especially since my https certificate comes from Let’s Encrypt... so i might have to muck with the email server every 60 days ... not sure?) ..

anyway, when I try to connect to it with Flyspray, I get above the Test Email button, “Completely unexpected exception: Unable to connect with TLS encryption
This should never happend, please inform Flyspray Developers”

Most systems have a way to override and accept an invalid cert, but I’m not seeing anything obvious about doing that with Flyspray. Does a function for this already exist, or do we need a way to do that? (alternatively, I would accept help in properly configuring my email lol)

Project Manager

Flyspray currently uses Swiftmailer 5.x, see composer.json, so 5.4.9 at the moment.

There is an entry in :

6.1.0 (2018-07-02)
 * fixed startTLS only allowed tls1.0, now allowed: tls1.0, tls1.1, tls1.2

which is only PHP7+

Could you try with a simple Swiftmailer test send script if there is a difference between 5.4.9 and current 6 versions connecting to your TLS email server?

Also a Vagrantfile how you setup your mail server would be great so I can reproduce the stuff. I currently have vagrant test setups for Flyspray using Mailhog and ejabberd for testing as configured sending notification partners, but no real world SMTP server.

I have absolutely no idea what you're talking about there. I setup email and flyspray with some dockerfiles and minimal changes. Email has a self signed tls cert and version support won't matter there. When I connect to my email server via Thunderbird or Gmail mobile, I have to tell it to ignore that my tls cert is invalid.

Project Manager


So which dockerfile? There is no official Flyspray dockerfile yet.

Could you provide how you did it?

I also could create a project Flyspray/flyspray-docker on, so there is an official project for using with docker?

I also think about Flyspray/flyspray-vagrant project, that provides some 'Vagrantfile' for the different OS and OS flavours.

Project Manager

Also problem you described on the mailing list:

'Also, I can't seem to get Avatars to work on it at all. I attempt to upload an Avatar, and it.. appears? to store it somewhere? maybe? but nothing ever shows up for it. Same with the Gravatar option.'

is due to using an inofficial untested docker file. Nobody of that guys who provide flyspray dockerfiles yet got in contact with the official Flyspray project. IMHO a better way would be simply say "Hi, I made a docker for Flyspray, check it out or provide suggestion for the project." here on or make a pull request on

For example some made nginx setup for Flyspray but telling nobody. And the thing you used just forgot to setup correct permissions for the avatars/ directory, so you couldn't upload profile images.

I now registered the and projects so there are official sources for that virtualization techs people can contribute.

None of that really helps me with the TLS problem, though. :-) It's pretty standard to be able to force TLS connection to use a self-signed certificate in some way or other.

I attempted to upgrade to latest Flyspray, but simply changing the version number retrieved in the Dockerfile resulted in nothing good happening (the whole installation process just hung running composer)

The current installation process, building the environment, then configuring via web page setup, then altering the environment (removing the setup directory) doesn't fit very well with the Docker work flow. Of course, whatever steps the setup takes could be automated, with some default values provided, and that would solve that problem. I'm familiar enough with Docker, that I could easily put that all together (assuming that composer actually were to function properly, or there's some way of doing it without composer) pretty quickly, like in a few minutes, if I knew what to do for the setup step.

Thanks for the tip on the Avatars. I chown'd the avatars directory and now that works.. so i updated my local copy of the docker to chown and chgrp both attachments and avatars.

Perhaps there should be a bug that Avatar upload appears to succeed, even when there's no permissions to allow it to do so.


Available keyboard shortcuts


Task Details

Task Editing