The OS is the container you’re running. You can choose to install certificates into it, given you control how the container is built. Fly doesn’t play a part in that.
LostKobrakai
distefam
Apparently, all I had to do was install ca-certificates into the base Debian image in my Dockerfile.
So, during the RUN apt-get update -y stage, just add ca-certificates as another package to be installed.
Thank you for pointing me in the right direction.
For reference, here is a related thread on Fly.io.
2
silverdr
… and I’ve got a TLS (STARTTLS) server running on “submission” port (587), which means ssl: false and began receiving errors:
{:error, {:send, {:network_failure, ~c"xx.xx.xx.xx", {:error, :closed}}}}
where “xx.xx.xx.xx” it the correct, expected IP address, and in server logs:
May 1 20:06:49 postfix/submission/smtpd[43779]: SSL_accept error from unknown[172.17.0.3]: -1
May 1 20:06:49 postfix/submission/smtpd[43779]: warning: TLS library problem: error:0A00010B:SSL routines::wrong version number:../ssl/record/ssl3_record.c:354:
May 1 20:06:49 postfix/submission/smtpd[43779]: lost connection after STARTTLS from unknown[172.17.0.3]
I suspect this started after recent server packages update, which might have hard-deprecated some earlier TLS protocols. I can use the server from every mail client I always used. Also from the container running Elixir application in question I can use openssl (of course with correct hostname rather than example.com):
openssl s_client -starttls smtp -connect example.com:587
and I get session correctly initiated:
[…]
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
[…]
and can manually interact with smptd using SMTP commands. This seems to exclude any configuration errors outside of the application itself. The relevant application config always looked like:
config :my_app, MyApp.Mailer,
adapter: Swoosh.Adapters.SMTP,
relay: System.get_env("SMTP_RELAY", "mail.myapp.net"),
hostname: System.get_env("SMTP_HOSTNAME", "server.myapp.net"),
username: System.get_env("SMTP_USERNAME", "no-reply@myapp.net"),
password: System.get_env("SMTP_PASSWORD"),
# auth: :always,
# ssl: false,
# tls: :always,
port: 587,
retries: 2
and worked fine all the time, until it stopped.
I tried:
allowed_tls_versions: [:"tlsv1.3"],
tls_options: [
versions: [:"tlsv1.3"]
],
and even the
sockopts: [
versions: [:"tlsv1.3"]
]
the last crashing with :badarg.
Any ideas what I might still try?
0
al2o3cr
What version of OTP are you on? Have you upgraded recently?
Asking because there’s a fix that just landed for TLSv1.3 in OTP 25 + 26:
3
silverdr
It’s 26! Gosh… this might be it. I didn’t upgrade OTP recently but I did upgrade mail server packages (security updates), which might have removed support for some earlier TLS protocols, which in turn might coincide with OTP 26 having problems with TLSv1.3… What’s the minimal OTP for Elixir 16?
Update: found it here:
So may have to try 24…
0
anuvrat
I encountered a similar error.
Same configuration works in a different application, but in a new one I’m trying to set up, things kept failing with :badarg or :tls_error with different configurations.
What helped was upgrading swoosh to its latest version.
Hope this helps.
0
silverdr
Accorging to mix.lock:
:gen_smtp, "1.2.0"
:swoosh, "1.16.5"
In fact swoosh was at
:swoosh, "1.15.2"
when the problem started but upgrading deps was one of the first things I tried
0
fmn
May 1 20:06:49 postfix/submission/smtpd[43779]: warning: TLS library problem: error:0A00010B:SSL routines::wrong version number:../ssl/record/ssl3_record.c:354:
to me this looks like a protocol version mismatch (for example, SSLv3 vs TLS1.2), or an attempt to use wrong protocol altogether (HTTPS on HTTP port or TLS on STARTTLS etc.)
that kind of issues are fairly easy to detect if you will dump the traffic and interpret it. both things can be done using Wireshark.
Wireshark filters are quite easy to use: you can see what cipher suites and protocol versions both parties are supporting / offering during initial handshake.
0
problem gone! 
silverdr
Erm… no, the application worked for a long time correctly and there were zero changes to the configuration or any relevant parts of the application code between the time it worked and stopped working. The only change was security updates to mail server. I can’t be sure if this started the trouble because the problem was not immediately noticed, only about two days after said server upgrade. Still, I suspect the security update dropped support for pre 1.3 TLS versions and gen_smtp docs say:
" tls_options used in ssl:connect , More info at ssl — OTP 29.0.2 (ssl 11.7.2) . Defaults to [{versions , ['tlsv1', 'tlsv1.1', 'tlsv1.2']}]"
At least that’s my suspicion, which combined with the TLSv1.3 bug with OTP > 24 seems to make good sense
0