starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Allow disabling certificate validation in SMTP email settings (self-signed certificates) #2025

New Issue
Closed
opened 2026-04-25 00:02:33 +02:00 by adam · 9 comments
adam commented 2026-04-25 00:02:33 +02:00
Owner
Copy Link
Copy Source

Originally created by @jecpr on GitHub (May 29, 2024).

What happened?

I am still having this issue (https://github.com/advplyr/audiobookshelf/issues/2765) after the fix.
Current version 10.0.1. Running proton mail bridge and have verified i can connect and authenticate. Proton serves smtp on port 1025. I have tried with both secure selected and not.
Log output when secure not selected:

[2024-05-29 20:27:05.018] INFO: [EmailManager] Sending test email
[2024-05-29 20:27:05.024] ERROR: [EmailManager] Failed to verify SMTP connection config Error: self-signed certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1674:34)
    at TLSSocket.emit (node:events:519:28)
    at TLSSocket._finishInit (node:_tls_wrap:1085:8)
    at ssl.onhandshakedone (node:_tls_wrap:871:12) {
  code: 'ESOCKET',
  command: 'CONN'
} (EmailManager.js:17)

and with secure:

[2024-05-29 20:27:51.521] INFO: [EmailManager] Sending test email
[2024-05-29 20:27:51.527] ERROR: [EmailManager] Failed to verify SMTP connection config Error: self-signed certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1674:34)
    at TLSSocket.emit (node:events:519:28)
    at TLSSocket._finishInit (node:_tls_wrap:1085:8)
    at ssl.onhandshakedone (node:_tls_wrap:871:12) {
  code: 'ESOCKET',
  command: 'CONN'
} (EmailManager.js:17)

What did you expect to happen?

Ideally it wouldn't be validating tls certificates, so that it supports self signed certs on email bridges run by users.

A potential fix might be:
include the following in the getTransportObject within /server/objects/settings/EmailSettings.js:

payload.tls = {
    rejectUnauthorized: false
  }

Steps to reproduce the issue

  1. set up protonmail bridge or other bridge which relies on self signed cert
  2. attempt to send mail

Audiobookshelf version

v2.10.1

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

No response

Additional Notes

No response

Originally created by @jecpr on GitHub (May 29, 2024). ### What happened? I am still having this issue (https://github.com/advplyr/audiobookshelf/issues/2765) after the fix. Current version 10.0.1. Running proton mail bridge and have verified i can connect and authenticate. Proton serves smtp on port 1025. I have tried with both secure selected and not. Log output when secure not selected: ``` [2024-05-29 20:27:05.018] INFO: [EmailManager] Sending test email [2024-05-29 20:27:05.024] ERROR: [EmailManager] Failed to verify SMTP connection config Error: self-signed certificate at TLSSocket.onConnectSecure (node:_tls_wrap:1674:34) at TLSSocket.emit (node:events:519:28) at TLSSocket._finishInit (node:_tls_wrap:1085:8) at ssl.onhandshakedone (node:_tls_wrap:871:12) { code: 'ESOCKET', command: 'CONN' } (EmailManager.js:17) ``` and with secure: ``` [2024-05-29 20:27:51.521] INFO: [EmailManager] Sending test email [2024-05-29 20:27:51.527] ERROR: [EmailManager] Failed to verify SMTP connection config Error: self-signed certificate at TLSSocket.onConnectSecure (node:_tls_wrap:1674:34) at TLSSocket.emit (node:events:519:28) at TLSSocket._finishInit (node:_tls_wrap:1085:8) at ssl.onhandshakedone (node:_tls_wrap:871:12) { code: 'ESOCKET', command: 'CONN' } (EmailManager.js:17) ``` ### What did you expect to happen? Ideally it wouldn't be validating tls certificates, so that it supports self signed certs on email bridges run by users. A potential fix might be: include the following in the getTransportObject within /server/objects/settings/EmailSettings.js: ``` payload.tls = { rejectUnauthorized: false } ``` ### Steps to reproduce the issue 1. set up protonmail bridge or other bridge which relies on self signed cert 2. attempt to send mail ### Audiobookshelf version v2.10.1 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs _No response_ ### Additional Notes _No response_
adam added the enhancement label 2026-04-25 00:02:33 +02:00
adam closed this issue 2026-04-25 00:02:33 +02:00
adam commented 2026-04-25 00:02:33 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (May 29, 2024):

Are there security implications to using that flag? I haven't dug into it

@advplyr commented on GitHub (May 29, 2024): Are there security implications to using that flag? I haven't dug into it
adam commented 2026-04-25 00:02:34 +02:00
Author
Owner
Copy Link
Copy Source

@jecpr commented on GitHub (May 29, 2024):

Yeah, I think basically it would allow a man-in-the-middle style attack on the mail traffic. If you were pointing to a FQDN then technically someone could impersonate that server with a self-signed cert. Not sure this amounts to much of a risk in practice though?
Could this be an option provided for users who wish to take that risk (i.e. in development environments or internal only environments)?

@jecpr commented on GitHub (May 29, 2024): Yeah, I think basically it would allow a man-in-the-middle style attack on the mail traffic. If you were pointing to a FQDN then technically someone could impersonate that server with a self-signed cert. Not sure this amounts to much of a risk in practice though? Could this be an option provided for users who wish to take that risk (i.e. in development environments or internal only environments)?
adam commented 2026-04-25 00:02:34 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (May 29, 2024):

Yeah possibly. Can you share where you think the option would be and what alert message we should show the user?

@advplyr commented on GitHub (May 29, 2024): Yeah possibly. Can you share where you think the option would be and what alert message we should show the user?
adam commented 2026-04-25 00:02:34 +02:00
Author
Owner
Copy Link
Copy Source

@jecpr commented on GitHub (May 29, 2024):

Hmm, one option would be to just put the warning on secure being off to give a warning and make it the default for secure being off.
Otherwise, probs another button next to it which says 'certificate verification' or 'ssl verification' and gives a warning when off.

The warning might say something like: "Disabling SSL certificate validation may expose your connection to security risks, such as man-in-the-middle attacks. Only disable this option if you understand the implications and trust the mail server you are connecting to."

@jecpr commented on GitHub (May 29, 2024): Hmm, one option would be to just put the warning on secure being off to give a warning and make it the default for secure being off. Otherwise, probs another button next to it which says 'certificate verification' or 'ssl verification' and gives a warning when off. The warning might say something like: "Disabling SSL certificate validation may expose your connection to security risks, such as man-in-the-middle attacks. Only disable this option if you understand the implications and trust the mail server you are connecting to."
adam commented 2026-04-25 00:02:34 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (May 29, 2024):

I think those are good messages and having it be another toggle is good, but it should default to secure being on. If a user wants to use it insecurely that is a manual choice.

@nichwall commented on GitHub (May 29, 2024): I think those are good messages and having it be another toggle is good, but it should default to secure being on. If a user wants to use it insecurely that is a manual choice.
adam commented 2026-04-25 00:02:35 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (May 30, 2024):

I added this. If you want to test this you can switch to using the edge docker image

Defaults to enabled
image

@advplyr commented on GitHub (May 30, 2024): I added this. If you want to test this you can switch to using the `edge` docker image Defaults to enabled ![image](https://github.com/advplyr/audiobookshelf/assets/67830747/539c073d-7d11-4ffd-9e67-2b77fe049cc0)
adam commented 2026-04-25 00:02:35 +02:00
Author
Owner
Copy Link
Copy Source

@jecpr commented on GitHub (Jun 3, 2024):

Tested this and it works exactly as described. Many thanks!!!

Some additional context for developer / alternative solution:
Protonmail bridge uses self-signed certificates as a privacy feature. It is intended to only be hosted locally, hence is less of a security risk for MITM style attacks, but means there aren't any registered and searchable certificates (hence privacy). If you have it running as a service on your homelab though, it becomes slighly more complicated because it is sending self-signed certificates for hostname "localhost". So it fails most frameworks certficate checking in both ways: can't be verified and wrong subject name. For other applications, I've created a custom self-signed cert with the correct subject name, and then imported this cert into the ca store for the container / system. This works for most systems, but doesn't with this - I THINK because node doesn't trust the containers CA store, and just does it's own checking. So even when I import a CA cert with the correct subject to the container, the app still fails, warning it is a self-signed certificate.
Alternative solution:
a less user friendly alternative would be to configure node to trust the containers CA, and have some documentation to the effect of the above. Way less user friendly for anyone using protonmail or similar set-up, but it is an option in case of future issues with this feature.

@jecpr commented on GitHub (Jun 3, 2024): Tested this and it works exactly as described. Many thanks!!! Some additional context for developer / alternative solution: Protonmail bridge uses self-signed certificates as a privacy feature. It is intended to only be hosted locally, hence is less of a security risk for MITM style attacks, but means there aren't any registered and searchable certificates (hence privacy). If you have it running as a service on your homelab though, it becomes slighly more complicated because it is sending self-signed certificates for hostname "localhost". So it fails most frameworks certficate checking in both ways: can't be verified and wrong subject name. For other applications, I've created a custom self-signed cert with the correct subject name, and then imported this cert into the ca store for the container / system. This works for most systems, but doesn't with this - I THINK because node doesn't trust the containers CA store, and just does it's own checking. So even when I import a CA cert with the correct subject to the container, the app still fails, warning it is a self-signed certificate. Alternative solution: a less user friendly alternative would be to configure node to trust the containers CA, and have some documentation to the effect of the above. Way less user friendly for anyone using protonmail or similar set-up, but it is an option in case of future issues with this feature.
adam commented 2026-04-25 00:02:36 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jun 4, 2024):

Great, thanks for testing!

a less user friendly alternative would be to configure node to trust the containers CA, and have some documentation to the effect of the above. Way less user friendly for anyone using protonmail or similar set-up, but it is an option in case of future issues with this feature.

I'm not sure this is the issue but have no idea how nodemailer is handling this. If you can find a solution with https://www.nodemailer.com/ or maybe someone commented about it, that would be helpful.

@advplyr commented on GitHub (Jun 4, 2024): Great, thanks for testing! > a less user friendly alternative would be to configure node to trust the containers CA, and have some documentation to the effect of the above. Way less user friendly for anyone using protonmail or similar set-up, but it is an option in case of future issues with this feature. I'm not sure this is the issue but have no idea how nodemailer is handling this. If you can find a solution with https://www.nodemailer.com/ or maybe someone commented about it, that would be helpful.
adam commented 2026-04-25 00:02:36 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jul 9, 2024):

Added in v2.11.0

@advplyr commented on GitHub (Jul 9, 2024): Added in [v2.11.0](https://github.com/advplyr/audiobookshelf/releases/tag/v2.11.0)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2025
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?