HAProxy / Lets Encrypt / Postfix - Dovecot
-
Is this configuration possible?
pfSense / HAProxy will offload the SSL (w/ ACME cert) and forward on to the postfix dovecot server with a self signed certificate. The idea is that ACME will renew the certificates with HAProxy decrypting (using LetsEncrypt Cert) and re-encrypting with the self signed certificate, which will not expire (in a reasonable amount of time) and the data will be encrypted to the back end.
My assumption is that it's totally possible, but I don't want to go down a rabbit hole to find out its not. If anyone has done this type of configuration, any pointers or things to watch out for?
-
To make this easier to understand.
Is it for securing the mail protocols (ie IMAPS) or for a webfront on the mailserver?
I have done the later -
I don't think that's going to work properly. Especially for clients that want to do STARTTLS. HAProxy doesn't know enough about SMTP/POP3/IMAP protocols to actually proxy the protocols, just the TCP/TLS portion.
So it might work for some cases but I don't think you or your clients would be happy with the limitations.
Setup your acme client/acme.sh/certbot/whatever on the mail server directly and let it have its own certificate directly. Or setup ACME on pfSense to write the certs out and then have the mail server periodically fetch them from there and reload. Or have a script push them from pfSense to the mail server.
-
I'm using postfix myself on a dedicated server.
No firewall what so ever that protects the mail ports 25, 465 and 587 - 465 and 587 being used by my mail clients, as 993 SIMAP and 995 SPOP, 110 and 143 are abandoned these days, and not postfix related.
Even STARTTLS (587) starts to fade out, it's all"465" = SMTPS these days.postfix uses the same certs from LetsEnscrypt / acme.sh as the web servers on that server.
Most mails leave and enter saying " .... Trusted TLS connection established from/to .... " on port 25.What I want to say : postfix, IMHO, seems rock solid to me, and can be exposed to the net directly.
Note : I do have fail23ban scanning my main postfix mail log so it can block the mail-port hammers, and other mail servers that do not support my "minimum mail protocol requirements".
@jimp said in HAProxy / Lets Encrypt / Postfix - Dovecot:
Setup your acme client/acme.sh/certbot/whatever on the mail server directly and let it have its own certificate directly. Or setup ACME on pfSense to write the certs out and then have the mail server periodically fetch them from there and reload. Or have a script push them from pfSense to the mail server.
My acme.sh "deploy.sh" hook script :
#!/bin/sh set -e check_path="/root/.acme.sh/${Le_Domain}/${Le_Domain}.conf" destination="/etc/ssl/" destinationdir=${destination}${Le_Domain} if [ -f $check_path ]; then if [ ! -d $destinationdir ]; then mkdir $destinationdir fi cat $CERT_KEY_PATH $CERT_FULLCHAIN_PATH ${destination}dh/RSA4096.pem > ${destinationdir}/${Le_Domain}.pem cp $CERT_KEY_PATH ${destinationdir}/${Le_Domain}.key chmod 400 ${destinationdir}/${Le_Domain}.pem chmod 400 ${destinationdir}/${Le_Domain}.key service apache2 reload >/dev/null service postfix reload >/dev/null # courier will also use these certs. service courier-pop-ssl force-reload >/dev/null service courier-imap-ssl force-reload >/dev/null # exception - extra treatment : if [ "$Le_Domain" == "yyyy.xxxx-bbbb.org" ]; then service monit reload >/dev/null service webmin restart >/dev/null fi ACCOUNT_EMAIL=gw.kroeb@gmail.com cat <<-EOF | mail -r acme@aaaa-vvvvv.tld -s "Certificates renewed" $ACCOUNT_EMAIL Renewed the following certificate(s): Host: $Le_Domain $(/root/.acme.sh/acme.sh --version 2>&1) EOF fi
used by acme.sh :
--deploy-hook The hook file to deploy cert
where the hook file is this "deploy.sh"
For every cert on my server, the using processes are restarted / reloaded.edit : note : the acme.sh usage above is not to be confonded with the"acme.sh" version used by the LetEnsrypt package written by Jimp.
-
Thanks for the information. I think I will setup a more conventional method to have the certs on the mail server. Just wanted to see if it was possible and not to go down the rabbit hole and waist lots of hours and head scratching trying to implement something that is not doable.
RHLinux
-
@Gertjan That's not true. SMTP 465 is deprecated. Should use 587 Submission.
Proxying SMTP & IMAP using Haproxy will not work, You can set smtpd_upstream_proxy_protocol=haproxy in main.cf for Postfix but the problem is that IPs for SPAM filtering will not proxy pass.
I suggest not bothering, this will waste your life away, Haproxy is a HTTP Load Balancer not a SMTP/IMAP Load Balancer, better to Open Port 25, 587 & 993 NAT -> Port Fowarding then use Port 443 for Webmail through Haproxy.
Clients that use STARTTLS will not work and will not Initialize through Haproxy.
Old Post I know but this is more for people that comes across this in the future.
Regards.
-
@VioletDragon said in HAProxy / Lets Encrypt / Postfix - Dovecot:
That's not true. SMTP 465 is deprecated. Should use 587 Submission.
If I read this : What SMTP port should be used? Port 25 or 587? and I compare that with the very first phrase from RFC 8314 stating the very obvious ( is it ? ) "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access" I see a conflict.
Port 587 is initiated using clear text.
Port 465 is TLS (before known as SSL) from byte 0.So : in 2024, we have to go back to a partial 'clear' message exchange ? I'm not sure about that ^^
Example : I hope to shut down in the nearby future all "port 80" ports for all my web server. It will become "port 443" only. Non pure https (TLS) traffic for web server is dead.
(Ok, I agree, maybe not this decade yet ^^ )But, this isn't really an issue, as mails dropped from our mail clients (people I know), on our mail server is not really "Public Internet thing". I as an admin can decide how mails get dropped by the MUA as I see fit.
This port can't be used by the 'public', only by the known mail clients, the ones that have an account == a mail addresses + password with this mail server.My own opinion is : everything goes TLS these days, "no more 'in the clear' text streams'.
( the major exception is : DNS resolving, as our 13 main DNS root servers still "don't do TLS" [for understandable $$$$ reasons] )Btw Submission 587 dates from somewhere in the last century, and 465, using SSL and now TLS, is far more recent. IMHO : more logic to use.
I still expose port 587 as an 'mail drop' entry point on on mail server, but the STARTTLS is mandatory, is has to be asserted by the client, if not : no access. So why even initiating this a clear text initial handshake ? I went 100 % TLS == port 465 - all the way right from the start.
The only things that needs to 100 % compliant RFC is port 25 : I still (have to) accept clear (non TLS) mails, as some mail server don't do TLS, or have their setup wrong. Working with certificates is still not main stream knowledge these days.
I also send, ones in a while, clear mails, as the destination doesn't accept 'TLS' - also strange.Btw : my mail server is hosted on a dedicated bare bone iron case, somewhere in a data center in Paris. It has it own pool of IPv4 and IPv6 (for all my individual domain names) and it's not behind a firewall worth mentioning.
That said : ip(4/6)tables is used by fail2ban to keep the mail/web/etc abusers out of the door for a while.
I started this server using Debian Lenny, way, way in the past. Debian 11.9 Bullseye today (I know, I should upgrade).
I'm not a proxy user neither, as I don't have to hide several hosts (domains) behind one IP over a single upstream connection. -
@Gertjan Reason why 465 is deprecated due to its encryption over SSL which isweak hence why it’s been replaced for 587 over TLS. Just because cloud providers and ISPs supports 465 still doesn’t mean you should.
Port 25 is used for Mail Servers to Exchange Mails and should not be used for Client to Server Roles.