[GH-ISSUE #412] Disable SMTP TLS verify

kerem commented

2026-02-27 08:15:35 +03:00

Owner

Originally created by @ajgon on GitHub (Jan 7, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/412

I'm using custom SMTP relay in my k8s cluster, with self-signed certificates. Unfortunatelly, I can't make LLDAP o speak with it, I'm getting this error:

2023-01-07T14:37:29.958857006+00:00 WARN     │  ┝━ 🚧 [warn]: Sending fatal alert BadCertificate | log.target: "rustls::conn" | log.module_path: "rustls::conn
" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/conn.rs" | log.line: 1285
2023-01-07T14:37:29.959013837+00:00 WARN     │  ┕━ 🚧 [warn]: Error sending email: lettre::transport::smtp::Error {
    kind: Connection,
    source: lettre::transport::smtp::Error {
        kind: Connection,
        source: Custom {
            kind: InvalidData,
            error: InvalidCertificateData(
                "invalid peer certificate: UnknownIssuer",
            ),
        },
    },
}

Is it possible to disable cert verification (or TLS/STARTTLS altogether) ?

Originally created by @ajgon on GitHub (Jan 7, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/412 I'm using custom SMTP relay in my k8s cluster, with self-signed certificates. Unfortunatelly, I can't make LLDAP o speak with it, I'm getting this error: ``` 2023-01-07T14:37:29.958857006+00:00 WARN │ ┝━ 🚧 [warn]: Sending fatal alert BadCertificate | log.target: "rustls::conn" | log.module_path: "rustls::conn " | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/conn.rs" | log.line: 1285 2023-01-07T14:37:29.959013837+00:00 WARN │ ┕━ 🚧 [warn]: Error sending email: lettre::transport::smtp::Error { kind: Connection, source: lettre::transport::smtp::Error { kind: Connection, source: Custom { kind: InvalidData, error: InvalidCertificateData( "invalid peer certificate: UnknownIssuer", ), }, }, } ``` Is it possible to disable cert verification (or TLS/STARTTLS altogether) ?

kerem closed this issue

2026-02-27 08:15:35 +03:00

kerem commented

2026-02-27 08:15:35 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 7, 2023):

It should be possible to provide the certificate in the config, and configure lettre (the email lib) to accept that as an additional root certificate in the TLS parameters.

It's not trivial, but it's possible.

In the meantime, why not get a properly signed certificate with letsencrypt?

@nitnelave commented on GitHub (Jan 7, 2023): It should be possible to provide the certificate in the config, and configure lettre (the email lib) to accept that as an additional root certificate in the TLS parameters. It's not trivial, but it's possible. In the meantime, why not get a properly signed certificate with letsencrypt?

kerem commented

2026-02-27 08:15:35 +03:00

Author

Owner

@ajgon commented on GitHub (Jan 8, 2023):

The problem is, I'm using relay inside k8s cluster - which means, I'm using k8s domains like relay.mail.svc.cluster.local etc. - which can't be (as far as I'm aware of) registered in LE. And fiddling with that system is cumbersome, and does more harm than good in my opinion.

Passing custom certs is the "proper" way of doing this, but again it's a PITA in k8s (you need to create certs in one pod, create secrets, migrate them through namespaces etc.), and (again in my opinion) not worth the effort.

The simplest and widely accepted solution in custom networks as this, is just disable SSL verification. You traffic is still encrypted, and you just trade convenience for possibility of MITM attack. Also if somebody can MITM inside your cluster, you have way bigger problem than disabled verification :)

In general certificate management is cumbersome, and I think it's a good idea, to add option to disable verification (which is by default off, meaning verification is enabled), so if user wants to do this, they explicitly have to say so.

@ajgon commented on GitHub (Jan 8, 2023): The problem is, I'm using relay inside k8s cluster - which means, I'm using k8s domains like `relay.mail.svc.cluster.local` etc. - which can't be (as far as I'm aware of) registered in LE. And fiddling with that system is cumbersome, and does more harm than good in my opinion. Passing custom certs is the "proper" way of doing this, but again it's a PITA in k8s (you need to create certs in one pod, create secrets, migrate them through namespaces etc.), and (again in my opinion) not worth the effort. The simplest and widely accepted solution in custom networks as this, is just disable SSL verification. You traffic is still encrypted, and you just trade convenience for possibility of MITM attack. Also if somebody can MITM inside your cluster, you have way bigger problem than disabled verification :) In general certificate management is cumbersome, and I think it's a good idea, to add option to disable verification (which is by default off, meaning verification is enabled), so if user wants to do this, they explicitly have to say so.

kerem commented

2026-02-27 08:15:35 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 8, 2023):

Yeah, I looked at the docs again, and it's possible to disable certificate
checks.
How do you feel about trying to do a PR? It wouldn't require a lot of Rust.

On Sun, 8 Jan 2023, 16:06 Igor Rzegocki, @.***> wrote:

The problem is, I'm using relay inside k8s cluster - which means, I'm
using k8s domains like relay.mail.svc.cluster.local etc. - which can't be
(as far as I'm aware of) registered in LE. And fiddling with that system is
cumbersome, and does more harm than good in my opinion.

Passing custom certs is the "proper" way of doing this, but again it's a
PITA in k8s (you need to create certs in one pod, create secrets, migrate
them through namespaces etc.), and (again in my opinion) not worth the
effort.

The simplest and widely accepted solution in custom networks as this, is
just disable SSL verification. You traffic is still encrypted, and you just
trade convenience for possibility of MITM attack. Also if somebody can MITM
inside your cluster, you have way bigger problem than disabled verification
:)

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/412#issuecomment-1374857765,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWL3H4EILR5Y6KNLKXTWRLJYPANCNFSM6AAAAAATT7OIUM
.
You are receiving this because you commented.Message ID:
@.***>

@nitnelave commented on GitHub (Jan 8, 2023): Yeah, I looked at the docs again, and it's possible to disable certificate checks. How do you feel about trying to do a PR? It wouldn't require a lot of Rust. On Sun, 8 Jan 2023, 16:06 Igor Rzegocki, ***@***.***> wrote: > The problem is, I'm using relay inside k8s cluster - which means, I'm > using k8s domains like relay.mail.svc.cluster.local etc. - which can't be > (as far as I'm aware of) registered in LE. And fiddling with that system is > cumbersome, and does more harm than good in my opinion. > > Passing custom certs is the "proper" way of doing this, but again it's a > PITA in k8s (you need to create certs in one pod, create secrets, migrate > them through namespaces etc.), and (again in my opinion) not worth the > effort. > > The simplest and widely accepted solution in custom networks as this, is > just disable SSL verification. You traffic is still encrypted, and you just > trade convenience for possibility of MITM attack. Also if somebody can MITM > inside your cluster, you have way bigger problem than disabled verification > :) > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/412#issuecomment-1374857765>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWL3H4EILR5Y6KNLKXTWRLJYPANCNFSM6AAAAAATT7OIUM> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

kerem commented

2026-02-27 08:15:35 +03:00

Author

Owner

@ajgon commented on GitHub (Jan 8, 2023):

Funny thing is, I've written some code in Rust long time ago... but don't remember a thing :D Maybe it's worth to do a little refresh... I'll try, and see where it gets me :)

@ajgon commented on GitHub (Jan 8, 2023): Funny thing is, I've written some code in Rust long time ago... but don't remember a thing :D Maybe it's worth to do a little refresh... I'll try, and see where it gets me :)

kerem commented

2026-02-27 08:15:36 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 8, 2023):

I'm sure you'll do fine, it shouldn't be too complicated. A few tips:

the email sending code is in server/src/infra/mail.rs
you want to build TLS parameters to pass to the SMTP relay. In the TLS
builder you have a dangerous_ method to disable the certificate checks.
you'll want to add a config variable. That's in server/src/infra/
configuration.rs and cli.rs (for the command line override flag). Also add
it to the docker config example at the top level. It should probably be a
positive flag (enable_certificate_check?) defaulting to true
there are no tests for that part of the code, so test by hand.

That should be enough to get you started, don't hesitate to ask here or in
discord if you need help!

On Sun, 8 Jan 2023, 19:29 Igor Rzegocki, @.***> wrote:

Funny thing is, I've written some code in Rust long time ago... but don't
remember a thing :D Maybe it's worth to do a little refresh... I'll try,
and see where it gets me :)

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/412#issuecomment-1374898160,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWMJ7VUBYQYHONSIMBDWRMBRRANCNFSM6AAAAAATT7OIUM
.
You are receiving this because you commented.Message ID:
@.***>

@nitnelave commented on GitHub (Jan 8, 2023): I'm sure you'll do fine, it shouldn't be too complicated. A few tips: - the email sending code is in server/src/infra/mail.rs - you want to build TLS parameters to pass to the SMTP relay. In the TLS builder you have a `dangerous_` method to disable the certificate checks. - you'll want to add a config variable. That's in server/src/infra/ configuration.rs and cli.rs (for the command line override flag). Also add it to the docker config example at the top level. It should probably be a positive flag (enable_certificate_check?) defaulting to true - there are no tests for that part of the code, so test by hand. That should be enough to get you started, don't hesitate to ask here or in discord if you need help! On Sun, 8 Jan 2023, 19:29 Igor Rzegocki, ***@***.***> wrote: > Funny thing is, I've written some code in Rust long time ago... but don't > remember a thing :D Maybe it's worth to do a little refresh... I'll try, > and see where it gets me :) > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/412#issuecomment-1374898160>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWMJ7VUBYQYHONSIMBDWRMBRRANCNFSM6AAAAAATT7OIUM> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

kerem commented

2026-02-27 08:15:36 +03:00

Author

Owner

@ajgon commented on GitHub (Jan 18, 2023):

Hmmm... I think, more-or-less I have a implementation ready but... does even smtp encryption config option works? I've tested it on current "releases" build, to be sure it wasn't affected by my changes:

tmp/release/x86_64/lldap send_test_email -v --smtp-encryption TLS --to test@example.net | grep smtp_options -A10
    smtp_options: MailOptions {
        enable_password_reset: false,
        from: None,
        reply_to: None,
        server: "localhost",
        port: 587,
        user: "admin",
        password: ***SECRET***,
        smtp_encryption: TLS,
        tls_required: None,
    },

tmp/release/x86_64/lldap send_test_email -v --smtp-encryption STARTTLS --to test@example.net | grep smtp_options -A10
    smtp_options: MailOptions {
        enable_password_reset: false,
        from: None,
        reply_to: None,
        server: "localhost",
        port: 587,
        user: "admin",
        password: ***SECRET***,
        smtp_encryption: TLS,
        tls_required: None,
    },

As you can see, regardless of option set, it still uses TLS 😱

Edit: draft PR is here: https://github.com/nitnelave/lldap/pull/423

@ajgon commented on GitHub (Jan 18, 2023): Hmmm... I think, more-or-less I have a implementation ready but... does even smtp encryption config option works? I've tested it on current "releases" build, to be sure it wasn't affected by my changes: ```bash tmp/release/x86_64/lldap send_test_email -v --smtp-encryption TLS --to test@example.net | grep smtp_options -A10 smtp_options: MailOptions { enable_password_reset: false, from: None, reply_to: None, server: "localhost", port: 587, user: "admin", password: ***SECRET***, smtp_encryption: TLS, tls_required: None, }, tmp/release/x86_64/lldap send_test_email -v --smtp-encryption STARTTLS --to test@example.net | grep smtp_options -A10 smtp_options: MailOptions { enable_password_reset: false, from: None, reply_to: None, server: "localhost", port: 587, user: "admin", password: ***SECRET***, smtp_encryption: TLS, tls_required: None, }, ``` As you can see, regardless of option set, it still uses TLS 😱 Edit: draft PR is here: https://github.com/nitnelave/lldap/pull/423 <img src="https://user-images.githubusercontent.com/150545/213282138-191b8195-4936-4085-9268-38cd865184c6.jpg" width="200" />

kerem commented

2026-02-27 08:15:36 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 18, 2023):

It seems the command line override is not well configured here:
https://github.com/nitnelave/lldap/blob/main/server/src/infra/configuration.rs#L269

Which means that config or environnement variables work, but not the
command line flag.

On Wed, 18 Jan 2023, 20:55 Igor Rzegocki, @.***> wrote:

Hmmm... I think, more-or-less I have a implementation ready but... does
even smtp encryption config option works? I've tested it on current
"releases" build, to be sure it wasn't affected by my changes:

tmp/release/x86_64/lldap send_test_email -v --smtp-encryption TLS --to @.*** | grep smtp_options -A10
smtp_options: MailOptions {

    enable_password_reset: false,

    from: None,

    reply_to: None,

    server: "localhost",

    port: 587,

    user: "admin",

    password: ***SECRET***,

    smtp_encryption: TLS,

    tls_required: None,

},
tmp/release/x86_64/lldap send_test_email -v --smtp-encryption STARTTLS --to @.*** | grep smtp_options -A10
smtp_options: MailOptions {

    enable_password_reset: false,

    from: None,

    reply_to: None,

    server: "localhost",

    port: 587,

    user: "admin",

    password: ***SECRET***,

    smtp_encryption: TLS,

    tls_required: None,

},
As you can see, regardless of option set, it still uses TLS 😱

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/412#issuecomment-1387690923,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWLZ5PM7NY3Q27VN7FTWTBDDXANCNFSM6AAAAAATT7OIUM
.
You are receiving this because you commented.Message ID:
@.***>

@nitnelave commented on GitHub (Jan 18, 2023): It seems the command line override is not well configured here: https://github.com/nitnelave/lldap/blob/main/server/src/infra/configuration.rs#L269 Which means that config or environnement variables work, but not the command line flag. On Wed, 18 Jan 2023, 20:55 Igor Rzegocki, ***@***.***> wrote: > Hmmm... I think, more-or-less I have a implementation ready but... does > even smtp encryption config option works? I've tested it on current > "releases" build, to be sure it wasn't affected by my changes: > > tmp/release/x86_64/lldap send_test_email -v --smtp-encryption TLS --to ***@***.*** | grep smtp_options -A10 > > smtp_options: MailOptions { > > enable_password_reset: false, > > from: None, > > reply_to: None, > > server: "localhost", > > port: 587, > > user: "admin", > > password: ***SECRET***, > > smtp_encryption: TLS, > > tls_required: None, > > }, > > > > tmp/release/x86_64/lldap send_test_email -v --smtp-encryption STARTTLS --to ***@***.*** | grep smtp_options -A10 > > smtp_options: MailOptions { > > enable_password_reset: false, > > from: None, > > reply_to: None, > > server: "localhost", > > port: 587, > > user: "admin", > > password: ***SECRET***, > > smtp_encryption: TLS, > > tls_required: None, > > }, > > As you can see, regardless of option set, it still uses TLS 😱 > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/412#issuecomment-1387690923>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWLZ5PM7NY3Q27VN7FTWTBDDXANCNFSM6AAAAAATT7OIUM> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

kerem commented

2026-02-27 08:15:36 +03:00

Author

Owner

@ajgon commented on GitHub (Jan 18, 2023):

Hmm... looks like, envs are also broken:

$ LLDAP_SMTP_OPTIONS__ENCRYPTION=STARTTLS tmp/release/x86_64/lldap send_test_email -v --to test@example.net | grep smtp_options -A10
    smtp_options: MailOptions {
        enable_password_reset: false,
        from: None,
        reply_to: None,
        server: "localhost",
        port: 587,
        user: "admin",
        password: ***SECRET***,
        smtp_encryption: TLS,
        tls_required: None,
    },

but config works :)

$ cat test.toml
verbose=true

[smtp_options]
smtp_encryption = "STARTTLS"

$ tmp/release/x86_64/lldap send_test_email -c test.toml --to test@example.net | grep smtp_options -A10
    smtp_options: MailOptions {
        enable_password_reset: false,
        from: None,
        reply_to: None,
        server: "localhost",
        port: 587,
        user: "admin",
        password: ***SECRET***,
        smtp_encryption: STARTTLS,
        tls_required: None,
    },

Edit: Ah, I see your point - let me try to fix that...

@ajgon commented on GitHub (Jan 18, 2023): Hmm... looks like, envs are also broken: ```bash $ LLDAP_SMTP_OPTIONS__ENCRYPTION=STARTTLS tmp/release/x86_64/lldap send_test_email -v --to test@example.net | grep smtp_options -A10 smtp_options: MailOptions { enable_password_reset: false, from: None, reply_to: None, server: "localhost", port: 587, user: "admin", password: ***SECRET***, smtp_encryption: TLS, tls_required: None, }, ``` but config works :) ```bash $ cat test.toml verbose=true [smtp_options] smtp_encryption = "STARTTLS" $ tmp/release/x86_64/lldap send_test_email -c test.toml --to test@example.net | grep smtp_options -A10 smtp_options: MailOptions { enable_password_reset: false, from: None, reply_to: None, server: "localhost", port: 587, user: "admin", password: ***SECRET***, smtp_encryption: STARTTLS, tls_required: None, }, ``` Edit: Ah, I see your point - let me try to fix that...

kerem commented

2026-02-27 08:15:36 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 24, 2023):

Solved with #423

@nitnelave commented on GitHub (Jan 24, 2023): Solved with #423

kerem referenced this issue

2026-02-27 08:18:04 +03:00

[PR #159] [MERGED] Implement LDAPS support #579

Rows
Columns

[GH-ISSUE #412] Disable SMTP TLS verify #159