For archival purposes to anyone reading this in the future. The answer i
was looking for, and solution i ended up using to this problem:
1) On the haproxy.example.com server, i used certbot to issue a cert to
that domain.
2) I installed a SSH key on haproxy.example.com and copied to
authoriz
On 2021-05-20 01:12, post...@ptld.com wrote:
Best i can gather from your last few replies is to rsync a copy of the
cert created on the load balancer to the backend servers and point
postfix at that cert.
Is that the answer?
This is all ive been trying to ask from the beginning, best method
On Wed, May 19, 2021 at 07:45:17PM -0400, post...@ptld.com wrote:
> > Letsencrypt will connect to the "submission" but request would go to
> > the "backend"
>
> Which "backend"? Okay, say i setup port 443 for certbot to use for
> verification on haproxy to proxy to the backend servers.
The onl
On Wed, May 19, 2021 at 07:23:01PM -0400, post...@ptld.com wrote:
> > On 05-19-2021 7:02 pm, Viktor Dukhovni wrote:
> >> Well submission.example.com is a linux server running haproxy on it.
> >> The only way (i know how) to create a certificate assigned to
> >> submission.example.com is to create
>
>
> Which "backend"?
>
"random or designated"
Viktor's comment:
7. Some suitable process arranges to update the peer servers
whenever a new certificate is obtained by some (
*random ordesignated)* server in the cluster. Or some completely
separate provisioning syst
On 05-19-2021 7:32 pm, IL Ka wrote:
I believe here is an answer:
Viktor:
No you just have to also proxy port 443 as well as 587, and then Let's
Encrypt will issue a certificate for submission.example.com
to (one of the) underlying servers.
Letsencrypt will connect to the "submission" but requ
> Using certbot (with a validation method that works with auto renew) i
> can create a certificate on the backend.exmample.com server and tell
> certbot the certificate will be for submission.example.com even though
> submission.example.com will not resolve to the server im running certbot
> on?
>
On 05-19-2021 7:02 pm, Viktor Dukhovni wrote:
Well submission.example.com is a linux server running haproxy on it.
The only way (i know how) to create a certificate assigned to
submission.example.com is to create that certificate using commands in
a bash shell using certbot physically on that ser
> Proxies are only needed for very large mail plants, where the message
> rate is too high for any one machine to handle, and you also need
> GeoIP DNS load-balancing, front-end proxies per datacentre, ...
>
> For those of us not working for Google, much simpler approaches
> are more robust (easier
On 05-19-2021 6:48 pm, Viktor Dukhovni wrote:\
You're fixated on the backend server name matching the certificate,
you really need to drop that assumption.
You misunderstand me. I know the cert has to match whatever the client
connected to, not the backend.
Out of the box, postfix is using a ce
> On 19 May 2021, at 7:05 pm, post...@ptld.com wrote:
>
> This is where im getting confused.
>
> Before you said make a cert for the load balancer where clients connect, and
> deploy it on the backend servers.
The cerificate is NOT for the load balancer it is for the cluster
of backend servers.
On 05-19-2021 6:48 pm, Viktor Dukhovni wrote:
2. This (same) certificate chain and associated private key is
deployed
on all the backend servers that sit behind the load-balancer.
Certificate renewal should happen on (one or all) the backend servers.
If more than one, space out the cron
On Wed, May 19, 2021 at 06:57:42PM -0400, post...@ptld.com wrote:
> > On 05-19-2021 6:48 pm, Viktor Dukhovni wrote:
> > Why would the cert be created "on the load balancer"? The load
> > balancer is just a TCP L4 proxy. Why does it need to be a trusted
> > component in the system?
>
> The "load
On 05-19-2021 6:48 pm, Viktor Dukhovni wrote:
Why would the cert be created "on the load balancer"? The load
balancer
is just a TCP L4 proxy. Why does it need to be a trusted component in
the system?
The "load balancer" is haproxy running on a linux server. It needs a
certificate because cl
On Thu, May 20, 2021 at 01:44:47AM +0300, IL Ka wrote:
> So, each backend can have it's own certificate, but for the same DNS name (
> haproxy.example.com), right?
Briefly during rollover. Not each its own, but some have a previous
version briefly during rollover.
> I didn't know that letsencry
post...@ptld.com:
> > On 05-19-2021 6:38 pm, Wietse Venema wrote:
> > This is too complicated.
> >
> > With a load balancer, the backend hosts don't need to exist in DNS,
> > and the backend hosts don't even need a globally unique IP address.
> > They can sit on 10.0.0.1 and 10.0.0.2 and have fake
On Wed, May 19, 2021 at 06:38:16PM -0400, Wietse Venema wrote:
> With a load balancer, the backend hosts don't need to exist in DNS,
> and the backend hosts don't even need a globally unique IP address.
> They can sit on 10.0.0.1 and 10.0.0.2 and have fake hostnames.
>
> What matters is that the
On 05-19-2021 6:44 pm, IL Ka wrote:
So, each backend can have it's own certificate, but for the same DNS
name (haproxy.example.com), right?
No. certbot will try to connect the server you are issuing the
certificate for using the domain name you want the cert for.
If the DNS (haproxy.example.co
On Wed, May 19, 2021 at 06:20:07PM -0400, post...@ptld.com wrote:
> > 2. This (same) certificate chain and associated private key is
> > deployed on all the backend servers that sit behind the
> > load-balancer.
>
> 1) Should i just physically copy (scp?) the cert files created on th
On 05-19-2021 6:38 pm, Wietse Venema wrote:
This is too complicated.
With a load balancer, the backend hosts don't need to exist in DNS,
and the backend hosts don't even need a globally unique IP address.
They can sit on 10.0.0.1 and 10.0.0.2 and have fake hostnames.
But they do need public IP,
> > > 2. This (same) certificate chain and associated private key is
> > > deployed
> > > on all the backend servers that sit behind the load-balancer.
> > >
> > > I wrote that CNAME doesn't work with several backends.
> > I now see it works if all backends share the same key and cert.
On 05-19-2021 5:58 pm, Viktor Dukhovni wrote:
3. The hostname "submission.example.com" is a CNAME alias for the
proxy:
submission.example.com. IN CNAME haproxy.example.com.
haproxy.example.com. IN A 192.0.2.1
I shouldn't have let us get side tracked on CNAM
This is too complicated.
With a load balancer, the backend hosts don't need to exist in DNS,
and the backend hosts don't even need a globally unique IP address.
They can sit on 10.0.0.1 and 10.0.0.2 and have fake hostnames.
What matters is that the servers on those backend hosts greet
and respond
On 05-19-2021 5:58 pm, Viktor Dukhovni wrote:
You're not paying careful attention, so I'll have spell it out in gory
detail.
No, follow all of that. I understand that and i *thought* i expressed as
much in my opening email.
2. This (same) certificate chain and associated private key is
On Thu, May 20, 2021 at 01:10:51AM +0300, IL Ka wrote:
> > 2. This (same) certificate chain and associated private key is
> > deployed
> > on all the backend servers that sit behind the load-balancer.
> >
> > I wrote that CNAME doesn't work with several backends.
> I now see it works
>
>
> 2. This (same) certificate chain and associated private key is
> deployed
> on all the backend servers that sit behind the load-balancer.
>
> I wrote that CNAME doesn't work with several backends.
I now see it works if all backends share the same key and cert. Sounds good)
Thank
On Thu, May 20, 2021 at 01:06:38AM +0300, IL Ka wrote:
> Disclaimer: I am not a network guru, but here is what I know.
Then don't distract the OP with speculative non-answers.
> WIth CNAME scenario you can't have more than one backend. Because HAProxy
> acts as L4 (TCP) balancer, it has no idea
Disclaimer: I am not a network guru, but here is what I know.
WIth CNAME scenario you can't have more than one backend. Because HAProxy
acts as L4 (TCP) balancer, it has no idea which server you are trying to
connect to and which server's certificate you are waiting for.
It just sends your packe
On Wed, May 19, 2021 at 05:13:32PM -0400, post...@ptld.com wrote:
> > On 05-19-2021 5:06 pm, Viktor Dukhovni wrote:
> >
> > Why would the Postfix server have a "different certificate".
> > DON'T DO THAT.
>
> Something is being lost in translation here. How could you not have a
> different certi
On 05-19-2021 5:26 pm, dev...@dvb.homelinux.org wrote:
You need one certificate for submission.example.com which is present on
all
servers.
But the problem is email clients are connecting to haproxy.example.com,
if they are given the certificate from submission.example.com it will
not work.
On Wed, May 19, 2021 at 04:51:42PM -0400, post...@ptld.com wrote:
> > On 05-19-2021 4:34 pm, IL Ka wrote:
> > Do you really have such a big load so one submission postfix isn't
> > enough?
>
> I don't know what i don't know. Im building it so i can easily add more
> servers if/when needed.
> On a
On 05-19-2021 5:06 pm, Viktor Dukhovni wrote:
Why would the Postfix server have a "different certificate".
DON'T DO THAT.
Something is being lost in translation here. How could you not have a
different certificate?
They are two different physical servers, with two different public IP's
and tw
On 05-19-2021 4:52 pm, Viktor Dukhovni wrote:
Now the client connects to submission.example.com and is being given
an certificate
from balanced1.example.com. Same problem exist.
Why would you get a certificate for the internal name? That's
clearly silly. Get a certificate for the external n
> On 19 May 2021, at 5:03 pm, post...@ptld.com wrote:
>
>> It aliases the server's hostname to the proxy. Clients connect to the
>> proxy thinking it is the server, and expect the server's certificate,
>> which the server will present, because the proxy is just doing layer 4.
>
> This is the
On 05-19-2021 4:52 pm, Viktor Dukhovni wrote:
It aliases the server's hostname to the proxy. Clients connect to the
proxy thinking it is the server, and expect the server's certificate,
which the server will present, because the proxy is just doing layer 4.
This is the part im not following yo
> On 19 May 2021, at 4:43 pm, post...@ptld.com wrote:
>
>> Don't misconfigure the client to connect to "haproxy.example.com", instead
>> publish a CNAME:
>> submission.example.com. IN CNAME haproxy.example.com.
>> Have the client connect to submission.example.com. The load
>> balancing in "h
On 05-19-2021 4:34 pm, IL Ka wrote:
Do you really have such a big load so one submission postfix isn't
enough?
I don't know what i don't know. Im building it so i can easily add more
servers if/when needed.
On a typical dedicated server (Intel Xeon E5, 128G ram) how many
messages (ball park)
On 05-19-2021 4:29 pm, Viktor Dukhovni wrote:
Don't misconfigure the client to connect to "haproxy.example.com",
instead
publish a CNAME:
submission.example.com. IN CNAME haproxy.example.com.
Have the client connect to submission.example.com. The load
balancing in "haproxy" can be by
>
> Load balancing.
>
Do you really have such a big load so one submission postfix isn't enough?
If you are speaking about fault tolerance only, then you could run
"submission only" postfix instead of haproxy. This postfix will then store
messages in queue and send them to the appropriate backend
>
>
>
> The client is trying to TLS with postfix, who has a certificate for
> submission.example.com
> The client is connected to haproxy.example.com
>
> haproxy.example.com:587 != crt submission.example.com
You can create a certificate with several domain names.
Honestly, I have never tried that
> On 19 May 2021, at 4:26 pm, post...@ptld.com wrote:
>
> How do i put the "correct certificate" (what is the correct cert?) on
> submission.example.com when the client is connecting to and expecting a
> certificate from haproxy.example.com ?
Don't misconfigure the client to connect to "haproxy
On 05-19-2021 4:19 pm, Viktor Dukhovni wrote:
Deploy the correct certificate on Postfix, DO NOT intercept TLS on
the proxy.
Now we back full circle to my first question lol.
This is what im asking best advice to do correctly.
How do i put the "correct certificate" (what is the correct cert?) on
> This is what i originally tried before email the list. With this kind of
> setup thunderbird reported:
>
> Sending of message failed.
> Unable to communicate securely with peer: requested domain name does not
> match the server's certificate.
>
> Postfix logs reported:
>
> warning: T
On 05-19-2021 4:07 pm, Viktor Dukhovni wrote:
The correct solution is to NOT terminate TLS on haproxy, and do TLS
end-to-end from client to Postfix, with haproxy only handling layer 4
TCP.
This is what i originally tried before email the list. With this kind of
setup thunderbird reported:
On 05-19-2021 3:33 pm, Viktor Dukhovni wrote:
The haproxy system just copies raw bytes between client and server,
it is not involved in TLS. The haproxy server will NOT be making
a TLS connection to Postfix, the remote client will do that.
Yes, this is my understanding.
haproxy only proxies tra
> On 19 May 2021, at 4:05 pm, post...@ptld.com wrote:
>
>> Sharing private keys between two servers is an extremely bad idea IMHO
>
> I agree, which is why im asking for ideas to solve this correctly.
The correct solution is to NOT terminate TLS on haproxy, and do TLS
end-to-end from client to P
On 05-19-2021 3:28 pm, IL Ka wrote:
Why forward it via haproxy?
What is wrong with postfix connected to the public IP?
Load balancing.
+--+
| email client |
+--+
|
+--+
| haproxy | -+
+--+ |
| |
On Wed, May 19, 2021 at 03:49:28PM -0400, Wietse Venema wrote:
> > I haven't yet have cause to look closely at the Postfix "haproxy" code.
> > So I could be mistaken, but at first blush it appears that Postfix
> > handles the haproxy protocol *before* TLS, even in wrapper mode.
>
> Haproxy can te
Viktor Dukhovni:
> > On 19 May 2021, at 3:07 pm, Wietse Venema wrote:
> >
> >> Server haproxy.example.com:587 accepts public connections and proxies to
> >> submission.example.com:587
> >> Each server was given its own SSL cert (Let's Encrypt certbot).
> >
> > If the remote SMTP client negotiat
On Wed, May 19, 2021 at 03:28:03PM -0400, post...@ptld.com wrote:
> > In which case the communication between haproxy and Postfix is
> > always in the clear. And especially on port 587 (STARTTLS, not
> > wrapper mode) the client will not initiate TLS until it gets through
> > the initial ESMTP gr
>
>
> Server haproxy.example.com:587 accepts public connections and proxies to
> submission.example.com:587
Why forward it via haproxy?
What is wrong with postfix connected to the public IP?
>
> Each server was given its own SSL cert (Let's Encrypt certbot).
>
If you use haproxy TLS support, th
So bottom line, the OPs use-case of TLS on both haproxy and Postfix
does
not appear to make much sense...
Sorry if i wasn't clear. Im just saying each server has a cert
installed, as in general setup. The cert on the haproxy server isn't
currently being used, but its there if needed depending
On 05-19-2021 3:07 pm, Wietse Venema wrote:
If the remote SMTP client negotiates a TLS handshake with
haproxy.example.com:587, then that remote SMTP client will not
negotiate a TLS handshake with submission.example.com:587.
Wietse
But does the haproxy negotiate a handshake with the clie
> On 19 May 2021, at 3:07 pm, Wietse Venema wrote:
>
>> Server haproxy.example.com:587 accepts public connections and proxies to
>> submission.example.com:587
>> Each server was given its own SSL cert (Let's Encrypt certbot).
>
> If the remote SMTP client negotiates a TLS handshake with
> hapro
post...@ptld.com:
> Server haproxy.example.com:587 accepts public connections and proxies to
> submission.example.com:587
> Each server was given its own SSL cert (Let's Encrypt certbot).
If the remote SMTP client negotiates a TLS handshake with
haproxy.example.com:587, then that remote SMTP clie
Server haproxy.example.com:587 accepts public connections and proxies to
submission.example.com:587
Each server was given its own SSL cert (Let's Encrypt certbot).
Postfix main.cf is using certbot cert for TLS
smtpd_tls_cert_file =
/etc/letsencrypt/live/submission.example.com/fullchain.pem
56 matches
Mail list logo
