but it still bothers me that this value hasn’t changed to my custom path

The startup script copies over your custom certificate path to the fixed path you’ve mentioned, the path in config doesn’t update. Shouldn’t be an issue.

MTA’s rarely enforce validating the certificate unlike web browsers and I think MUAs (mail clients). Certs issues shouldn’t affect the supported cipher suites. You’ll either have the RSA or ECDSA digital signature based cipher suites, the project doesn’t presently support ECDSA IIRC… it may be possible that you’re using ECDSA? That’s explicitly excluded at present (ignore RSA+AES, that’s about RSA for key exchange which is different):

smtpd_tls_exclude_ciphers = aNULL, LOW, EXP, MEDIUM, ADH, AECDH, MD5, DSS, ECDSA, CAMELLIA128, 3DES, CAMELLIA256, RSA+AES, eNULL

my cert is RSA (sha256RSA)

Just a quick update… I now ran:

./testssl.sh -t smtp localhost:25

inside the container and again got the same output.

The Ubuntu Server is running as a VM on a standalone ESXi.

I would love to try the test-environment.

Hi @polarathene

I don’t have a reverse-proxy setup. I also just checked on the server itself using: ./testssl.sh -t smtp localhost:25 which gives me the exact same result (besides “Domain name mismatch” of course).

After every change in the config I already always use docker-compose down and then start it up again with docker-compose up afterwards.

is there a way to get these settings logged? / debug what should happen manually inside the docker?

@theoneandonly-vector I would assume the problem is because you’ve changed the config from the original setting you created the container with. Docker is generally immutable and that’s how we know it as, that if we restart it, the state is reset.

This isn’t happening with your docker-compose setup though. You need to properly take the container down IIRC with a docker-compose down, then bring it back up with the new env var / config. I forget the specifics. The current code will see the new env var, but also read the modified config from initial setup. Even if this internal config is not mounted locally and resides in the container it’s not reset to the image state until the container is properly brought down.

My PR did catch that and has fixed it accordingly, I just need to review it this coming weekend and get that merged for everyone elses benefit. In the meantime, try the workaround I mentioned above.

@aendeavor does have a point though, both our TLS_LEVEL should support more than TLS v1.3. That does suggest something else is interfering. Can you describe your setup a bit more? If there are middleboxes involved, these can act as TLS proxies that are enforcing TLS v1.3 due to some security policy if at an enterprise company?

---

Using Cloudflare? Check it.

I don’t think Cloudflare proxies SMTP?

@polarathene I understand. We’d be glad to even merge only a small portion of the original PR - after all, every improvement is worthwhile;) So if you think you can create a new PR which can be merged, even if it’s small, I’d encourage you to do it:)

I use let’s encrypt-certificate created on another docker.

This shouldn’t affect the error related to shared cipher suites. It will be an issue with some e-mail communications if the certificate is rejected by older servers once LetsEncrypt is issuing certificates with their new root CA that the old servers may not have. I’m not sure if that’s happened just yet. For MTA exchanges they don’t tend to verify certs, but MUA(mail clients) might, so it may be an issue on old client devices.

ECDHE-RSA-AES256-GCM-SHA384

This cipher suite is already in the existing support and not requiring my PR from what I can see.

here the cipher listed and “TLS_LEVEL=intermediate” should allow tls 1.2, and even 1.1…:

TLS version support does not mean all cipher suite are supported, this can be for various reasons beyond the control of this project alone.

You should verify that your changes are in fact making the other cipher suites and TLS versions available, not that you just saved a config file. testssl.sh is a project which can help check your server, or you can try some other service online that may reveal what ciphers are supported. Try get a proper list of supported cipher suites, not just the first one that is negotiated by the tool.

---

@polarathene is working on it, and he/she will be reaching back to when the PR is ready.

I’ve been quite busy with other commitments unfortunately. I could allocate some time to get the improved cipher list pushed through and follow up with any other details at a later date I think.

Without more information, I can’t say that it’d make much of a difference for resolving this issue. Especially since the cipher suite in question is already supported by the current releases. Please confirm that your server actually does list ECDHE-RSA-AES256-GCM-SHA384 as a ciphersuite (or any ciphersuites below TLS 1.3).

This is not a “bug”, and I don’t know whether you can call it a “missing feature”. This PR needs to be re-opened, but it hasn’t been yet. @polarathene is working on it, and he/she will be reaching back to when the PR is ready. In the meantime, there is nothing that can be done. You may assist him/her with the PR, that would speed things up.