Server: Allow SelfSigned/Untrusted certificates for outgoing mail servers

[OS3DrNick]

Steps to reproduce

1. Clean Install Nextcloud
2. GoTo Admin page, Additional settings, Email Server
3. Configure Mail Server, With SSL, Port 465, Test settings
   

   Expected behaviour

Would expect that the server accepts Self Signed certificates, or display a warning about its certificate.

Actual behaviour

Nextcloud test error comes back with:
A problem occurred while sending the email. Please revise your settings. (Error: Connection could not be established with host mail.***.nl [ #0])

Server configuration

Operating system: Raspbian Jesse
Web server: Apache 2.4.10
Database: Mysql 5.5.52
PHP version: 5.6.26
Nextcloud version: 10.0.1
Updated from an older Nextcloud/ownCloud or fresh install: Fresh
Where did you install Nextcloud from: Zip File

Signing status:

Signing status

No errors have been found.

List of activated apps:

App list

Enabled:
  - activity: 2.3.2
  - comments: 1.0.0
  - dav: 1.0.1
  - federatedfilesharing: 1.0.1
  - federation: 1.0.1
  - files: 1.5.2
  - files_pdfviewer: 0.8.1
  - files_sharing: 1.0.0
  - files_texteditor: 2.1
  - files_trashbin: 1.0.0
  - files_versions: 1.3.0
  - files_videoplayer: 0.9.8
  - firstrunwizard: 1.1
  - gallery: 15.0.0
  - notifications: 0.3.0
  - password_policy: 1.0.0
  - provisioning_api: 1.0.0
  - serverinfo: 1.1.1
  - survey_client: 0.1.5
  - systemtags: 1.0.2
  - theming: 1.0.1
  - updatenotification: 1.0.1
  - workflowengine: 1.0.1
Disabled:
  - admin_audit
  - encryption
  - external
  - files_accesscontrol
  - files_automatedtagging
  - files_external
  - files_retention
  - templateeditor
  - user_external
  - user_ldap
  - user_saml

The content of config/config.php:

Config report

{
    "system": {
        "instanceid": "oc5b9w8gt082",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***.nl"
        ],
        "datadirectory": "\/var\/www\/nextcloud\/data",
        "overwrite.cli.url": "https:\/\/**.nl",
        "dbtype": "mysql",
        "version": "9.1.1.5",
        "dbname": "nextcloud",
        "dbhost": "localhost",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "UTC",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_from_address": "**",
        "mail_domain": "***.nl",
        "mail_smtphost": "mail.**.nl",
        "mail_smtpport": "465",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "ssl"
    }
}

Basicly the 'bug' is that the error message only shows error #0 ,
This message should maybe include something more then #0, like certificate is invalid.

The feature request is to include a selection box (with big warnings) that allows the use of self signed (or untrusted) certificates.

[nickvergessen]

I guess the solution would be the same as https://github.com/nextcloud/server/issues/1413

[schiessle]

Why not get a valid certificate? These days, with LetsEncrypt and other free certificate providers, there is no reasons to not have a valid certificate.

[johnhomelan]

I also needed to be able to use an smtp server that uses a self signed cert (which I don't control), I made the attached changes to allow me to configure support for self signed certs.

ssl-patch.txt

[tigre-bleu]

I own a Zimbra Community server which comes with self signed certificates. Unfortunately, it is not easy to use letsencrypt certificates in that case so having an option to either pin TLS certificates or to disable certificate verification is still mandatory.

[aconitumnapellus]

Why not get a valid certificate? These days, with LetsEncrypt and other free certificate providers, there is no reasons to not have a valid certificate.

Not everyone has the possibility to get a free cert.
There are setups behind other ports than 443 / 80 and in that case, in combination with dyndns, it becomes very difficult.

[aconitumnapellus]

I also needed to be able to use an smtp server that uses a self signed cert (which I don't control), I made the attached changes to allow me to configure support for self signed certs.

ssl-patch.txt

Sadly, even after fixxing the patch with the newest source code, it doesnt work anymore...
:/

[eN0Rm]

I'm influenced by this as well

[raulcesar]

have this problem too :[[

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity and it seems to be missing some essential informations. It will be closed if no further activity occurs. Thank you for your contributions.

[kesselb]

https://unix.stackexchange.com/a/132163 here is another workaround. If you add the self-signed certificate to your certificate manager connections are accepted.

[pgnd]

in nextcloud/head, I'm setting up Email server (https://nextcloud.pgnd.lan/settings/admin)

my config includes

    config/local.config.php
      'mail_smtpmode'     => 'smtp',
      'mail_smtpsecure'   => 'tls',
      'mail_sendmailmode' => 'smtp',
      'mail_smtpauthtype' => 'PLAIN',
      'mail_from_address' => 'nextcloud',
      'mail_domain'       => 'example.com',
      'mail_smtphost'     => 'mail.example.com',
      'mail_smtpport'     => '587',
      'mail_smtpauth'     => 1,

I submit mail to a local mail server instance on the LAN, locked down with an internal self-signed, SSL cert.

When I click "Test email settings : Send Email", it FAILs with,

    A problem occurred while sending the email. Please revise your settings. (Error: Connection could not be established with host mail.example.com [ #0])

This apparently is a known problem, from Sep '18,

https://help.nextcloud.com/t/additional-settings-email-configuration-solved/22070/8

As suggested there, editing

edit 3rdparty/swiftmailer/swiftmailer/lib/classes/Swift/Transport/StreamBuffer.php

267 -   $this->stream = @stream_socket_client($host.':'.$this->params['port'], $errno, $errstr, $timeout, STREAM_CLIENT_CONNECT, $streamContext);

    +   $this->stream = @stream_socket_client($host.’:’.$this->params[‘port’], $errno, $errstr, $timeout, STREAM_CLIENT_CONNECT, stream_context_create(array('ssl'=>['verify_peer'=>false, 'verify_peer_name'=>false, 'allow_self_signed'=>true])));

fixes THAT problem -- email's sent/received

  Well done, testuser!

  If you received this email, the email configuration seems to be correct.

  Nextcloud - a safe home for all your data
  This is an automatically sent email, please do not reply.

IMO, this is not an 'enhancement' as much as a 'bug'. Inability to submit to completely legit SMTP email servers, with perfectly valid internal-CA/enterprise certs, is brokenness, not a missing feature.

And no, "just use LetsEncrypt", is not a solution,

[kesselb]

IMO, this is not an 'enhancement' as much as a 'bug'. Inability to submit to completely legit SMTP email servers, with perfectly valid internal-CA/enterprise certs, is brokenness, not a missing feature.

No. Nextcloud (php actually) checks your system certificate storage. System trusts the certificate => No patch required. ~Sure we could introduce some "skip certificate verification" flag but a proper setup is the better solution.~

[pgnd]

My CA crt is available on the server.

It's just not insecurely in the SYSTEM-WIDE root store. For intra-LAN-based comms, I do not use the system instance of openssl; rather I use one at '/some/other/bin/path/openssl', with relevant certs @ /some/other/secure/credential/path/*.pem, specified on a per-app basis.

I add the certs if & as necessary ONLY for authorized apps.

For client apps such as browsers, e.g. Firefox, the app has a cerfificate store to which one can add CA & client certs. It's deployed using Firefox's enterprise policy options.

For server apps such as Nginx, Postfix, etc, CA & client certs for intra-LAN server comms are, again, specific for each server app in their respective configurations. Backend, intra-lan comms use own-CA, self-signed certs with each app getting a config for the trusted_cert & ssl_cert locations; public-facing frontends use public-CA (e.g. LetsEncrypt) -signed certs, with app certs specified in per-app dirs.

How can NC be configured simlarly, using different certs/stores for different tasks?

PHP's ssl context options

https://www.php.net/manual/en/context.ssl.php

include options for specifying 'cafile', 'local_cert', 'local_pk', etc.

wherein php checks the system certificate you _tell_ it to check.

also there's the NC option for

'openssl' => array(
    'config' => '/absolute/location/of/a/customized/openssl.cnf',
),

[kesselb]

Sure we could introduce some "skip certificate verification" flag

'mail_smtpstreamoptions' => [
    'ssl' => [
        'allow_self_signed' => true,
        'verify_peer' => false,
        'verify_peer_name' => false
    ]
],

https://github.com/nextcloud/server/pull/12766 exposed the swift mailer streaming options. Add the above to your config.php: https://docs.nextcloud.com/server/16/admin_manual/configuration_server/email_configuration.html#troubleshooting