Forums

Resolved
0 votes
That howto doesn't work unless you are relaying through your ISP's email server - I'm not.
I did originally go through Virgin Media's servers, but that caused a problem with 'replies' to my emails - can't remember the full details, but it didn't work.

With DuoCircle, accesses don't require the email address .. it needs a username and password (account details). I tried the stunnel method but without success; unless there's something missing in the howto.

At the moment, my C6 installation (appears to) authenticate the account details via the sasl_passwd (and since email go out, I've no reason to believe otherwise), but the emails themselves go in plain (fair enough as that's what they would do anyway!) - but I can't get the same result on the C7 box. Everything points to the certificates .. I'll need to do more hunting to see why/what I've forgotten to do but it's time. As it stands, I've purchases that I can't use as I receive, but not send unless I completely reconfigure all our devices.

As to the idea of a separate thread, the first thing I did was to look through the forums; there are already plenty of threads on the subject going back a number of years.

Part of the problem appears to be with the Postfix setup; the documentation for same says it doesn't support it, but then goes on to explain how TLS/SSL authentication can be done using either the Cyrus_auth plugin or the Dovecot plugin. Now, given the the entire COS user system appears to be built around ldap, there's even an additional plugin specifically designed for authenticating users from an ldap database (why is pam_unix even being used!). It strikes me therefore, that someone hasn't completely delved deep enough - and I can't as a) I can't look at the ldap db, and I don't have the time (or will!) to go too deep.

The authentication I mentioned (from the postfix manual) ...

/etc/sasl2/smtpd.conf:
pwcheck_method: auxprop
auxprop_plugin: ldapdb
mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5
ldapdb_uri: ldap://localhost
ldapdb_id: proxyuser
ldapdb_pw: password
ldapdb_mech: DIGEST-MD5


Authentication can also be achieved by logging into an IMAP server ..
saslauthd - Cyrus SASL password verification service

...
/etc/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Important

Do not specify any other mechanisms in mech_list than PLAIN or LOGIN when using saslauthd! It can only handle these two mechanisms, and authentication will fail if clients are allowed to choose other mechanisms.

Important

Plaintext mechanisms (PLAIN, LOGIN) send credentials unencrypted. This information should be protected by an additional security layer such as a TLS-encrypted SMTP session (see: TLS_README).

...
Saturday, May 04 2019, 06:41 PM
Share this post:
Responses (9)
  • Accepted Answer

    Monday, May 06 2019, 10:58 AM - #Permalink
    Resolved
    0 votes
    The original Let's Encrypt app used webroot and had a dependency on the web server but this was changed. I believe the reason was so as to not force the user to have the web server if they did not want it, so apps like OpenFire and ClearGLASS could still use Let's Encrypt without the web server installed. If you want to make the changes, you'll note the app also manipulates the firewall automatically and temporarily stops the web server if it is running to allow the standalone webserver to take over port 80. You'll need to make adjustments to that as well. I guess it would be cuter if the app detected if the web server were installed and running and then it could make the decision between the webroot and standalone method.

    Note you need to patch both the certificate creation and certificate renewal functions and maybe more (I am not a PHP person although I've done a couple of patches in PHP in the past).

    If you want to get any patch approved which involves a change in concept, you may need to engage Marc Laporte @ WilkSuite as they are the sponsors of the app. I'll ping Marc a message about this thread.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 06 2019, 10:34 AM - #Permalink
    Resolved
    0 votes
    I get that, but the point you're missing is that I'm not just suggesting hacking the app; I'm suggesting that it's changed from using --standalone to --webroot. I'm attempting to find out what needs to change (to submit a proposed update).

    The problem with the former is that there's too much hacking around if you have multiple servers that you want certificates for - especially if you're also using ProxyPass!

    Changing to --webroot does away with all those problems as a webserver (if present; if not the sandboxed version) will have access to the 'net (assuming port forwarding in place) .. and that's all that Let's Encrypt needs work - regardless of ProxyPass. I've managed to get a certificate for a proxied machine from the command line, 'bypassing' the presence of the Proxy simply by using the webroot option.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 06 2019, 10:19 AM - #Permalink
    Resolved
    0 votes
    I really don't suggest hacking the Let's Encrypt app. There is a big change coming sometime during 7.6 and you'll only have to redo it. I was suggesting using the technique outlined in Using Let's Encrypt Certificates for Mail. All you need to do is create a file something like /var/clearos/events/lets_encrypt/copy_to_mailserver:
    #!/bin/sh
    /usr/bin/scp /etc/letsencrypt/live/{your_certificate_name}/fullchain.pem root@mailserver:/etc/postfix/my_cert.pem
    /usr/bin/scp /etc/letsencrypt/live/{your_certificate_name}/privkey.pem root@mailserver:/etc/postfix/my_key.pem
    /usr/bin/ssh root@mailserver 'systemctl restart postfix'
    Change the file permissions to 0775.
    You may need additional ssh commands to change permissions and ownerships on the mailserver (they can be chained together in a single command)
    You would need to point /etc/postfix/main.cf to your new certificates and you'd need to set up ssh keys on your gateway and put its public key on the mailserver so you can ssh in without a password.

    [edit]
    For you mods, you don't need the webserver installed if you use the "--standalone" switch as it will use a mini built-in web server rather than "--webroot".
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 06 2019, 09:56 AM - #Permalink
    Resolved
    0 votes
    Ok, sussed it (nearly...)

    The following command correctly creates the necessary keychain (on a machine sitting LAN side of a ProxyPass server);

    certbot certonly --webroot -w /var/www/html --max-log-backups 200 --agree-tos -n -m xxx@yyy.zzz -d yyy.zzz

    https://certbot.eff.org/docs/using.html#webroot

    All that's needed is for the webserver app to be installed and the default directory (for the app) will validate any domain listed (assuming a public DNS entry is present).

    What I now need to know/do is to find out how to pass a subcommand to the command line(s) in Lets_Encrypt (function 'add') - adding it to the argument list caused an error.

    You could also do this without the need of a webserver installed (for eg - file servers) .. this could be achieved by making use of the sandbox version of httpd (the webconfig) and it's root.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 05 2019, 01:28 PM - #Permalink
    Resolved
    0 votes
    So Let's Encrypt sounds like it won't work unless run on a separate subdomain which means you needing to make a few changes on your side. It should not matter. If the built-in certificate worked for 6.x and DuoCircle, it should also work for 7.x and DuoCircle.

    You could also do some cute stuff following the Let's Encrypt HowTo concept. If you make your servers trust each other with ssh keys, then on the internet-facing sever as part of the updater script you can scp the updated certificate to your mail server then restart the mail services (postfix and whatever) with a remote ssh command.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 05 2019, 11:25 AM - #Permalink
    Resolved
    0 votes
    I'll be looking at it again, but in a few days; my patience was starting to run a bit thin(!)

    AFA using Let's Encrypt is concerned, it's out of the question - I'll explain ...

    I actually have 3 COS servers; the first is a VM server, the second is a file server (including Nextcloud), and the third is the subject of this grief; the mail server (and it's a VM).

    The VM server (which will also host the VM mail server) is the web interface to the other machines via ProxyPass and has Let's Encrypt installed. The file/Nextcloud server is served by ProxyPass (Nextcloud just uses 433), and the existing mail server's (hardware/C6) web interface and ActiveSync are also served by ProxyPass, with the IMAP/SMTP/CalDav accesses going direct - the gateway is a router with the VM server acting as dhcp/dns server. Thus the various web interfaces all have verifiable certificates.

    Now, because Let's Encrypt needs direct access to port 80/443, it only works on one machine (I only have a single IP address) as the two ports can only have a single port forward - to a single machine; with ProxyPass in the way, certificate requests from the other machines fail. Once I get the VM onto the server, there's a possibility that I might be able to share the certificates via a shared directory (VirtualBox) so that the Let's Encrypt certificates become visible to the mail server and then I have a single point of certificate. I was hoping to get the mail server working first with a self sign before physically moving the VM, but I may need to try that earlier than I anticipated.

    I purposely separated the the 3 aspects of my network to increase isolation between the various systems, and to ease backups - the file server has it's own backup (via the Baremetal Backup app), and the VM server will also have the same backup mechanism (to a separate HDD), backing up all the VMs (including the mail server)

    If you've got any suggestions, I'm more than happy to listen ...
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, May 04 2019, 07:48 PM - #Permalink
    Resolved
    0 votes
    Hi Richard,
    I can assure you it does work pretty much out of the box. I carried my implementation over from ClearOS 6, warts and all. Later on I switched to using Let's Encrypt certificates using the HowTo I wrote. This is pretty much unnecessary except it avoids you having to accept the certificate in your client one (unless you use Outlook in which case let's Encrypt is a god-send as you otherwise have to accept the certificate every time you start Outlook).

    The postfix certificates are /etc/postfix/cert.pem and /etc/postfix/key.pem. These are copies of the bootstrap certificate made when ClearOS was installed. It is a self-signed certificate and mine is dated 2012 as it is a copy over from ClearOS6 (I did a 6.x backup to a 7.x restore). It expired in 2013, I think, but Postfix and ISP's never seemed to care not do e-mail clients (.... except Outlook). Start with port 25. Then move to 587. If 587 does not work it is either your set up (do you have all the parameters mentioned in DuoCircle's article?) or there is a problem at the ISP. What do your logs say when sending?

    If you are concerned about certificates, switch to let's Encrypt.

    Note the DuoCircle article has missed a step. You need to run:
    postmap /etc/postfix/sasl_passwd
    after you create the /etc/postfix/sasl_passwd file.

    [edit]
    Also from DuoCircle's article, I would not set smtp_tls_CAfile. You should already have smtpd_tls_cert_file and smtpd_tls_key_file. As yout certificate is self-signed, you don't need the smtp_tls_CAfile.
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, May 04 2019, 07:24 PM - #Permalink
    Resolved
    0 votes
    That's it exactly. In the C6 box, I authenticate the client into the SMTP server and then pass it on to DC.

    Now, in C6, the client/server authentication works, and SASL authentication with DC work, but I never got 587 to work to transfer the email - I only managed to get the 25/2525 working (I use 2525).

    In C7 however, nothing worked; I tried the same setup as the C6 box, but the problem appears to be the certificates, and I tred your stunnel fix - but that didn't appear to work either. Again, it could be a certificate problem.

    On the face of it, the smtp server (when acting as a relay) appears to be incomplete, and certificates appear to be a) dumped in a number of places, and b) only implement a subset of what is actually required,
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, May 04 2019, 07:11 PM - #Permalink
    Resolved
    0 votes
    Hello Richard,
    I've split your reply out so the other thread does not get polluted with off-topic stuff. If you'd like to continue the discussion here, that would be fine.

    I relay out through turbo-smtp.com on port 587, so not an ISP. I use a username which looks like an e-mail address, but it does not have to. I used the instructions I linked to, but here are the instructions from DuoCircle. They are pretty much identical but are using port 25. It would not surprise me if 587 worked as well as DuoCircle seem to be very flexible.

    Authentication is 2 stage from a client. The client authenticates with ClearOS using the normal e-mail SMTP/LDAP and the e-mail gets sent to ClearOS. Postfix then relays the e-mail via DuoCircle using the authentication method detailed earlier.
    The reply is currently minimized Show
Your Reply