Re: postfix and multiple TLS certificates

[Tobias Reckhard]

On 11.12.2015 09:11, Zalezny Niezalezny wrote:
> is it possible to configure in Postfix multiple TLS certificates.

AFAIK, you can configure each smtp and smtpd instance with a certificate
of its own, so you could, for instance, have several smtpds listening on
different IP addresses, each with an individual certificate. You could
also specify different smtp transports services and have them use
different certificates or CAs. But one smtpd and one smtp can be
equipped with only one certificate.

> For example, on my LAN relay server I must configure TLS for the unix
> domains and for windows domains. Both domains use different names. How
> to manage that part ?

You're talking about receiving mail from the Internet, right? Typically,
you'll have shared MX records for both domains. Your relay servers'
certificates would typically reflect their host names, which doesn't
necessarily need to have any similarities with the domains it's
receiving mail for. You typically use the same name as the one in
$myhostname as the CN of a server's certificate.

> How to generate certificates than ? Is it possible to map some how TLS
> certificates for the different domains ?

Supposing that you have different MX records for your two domains, then
I suppose that you might be able to generate or request certificates
with corresponding SubjectAlternativeNames. I'm not sure whether those
are widely supported in Internet MTAs, though.

Cheers,
Tobias

Re: postfix and multiple TLS certificates

[Zalezny Niezalezny]

Hi,

thanks for Your feedback. I just solved my issue.

I will simply generate normal key and csr with openssl command. My local
certify authority will provide me certificate which will be signed with the
list of specified by me domains. Then we can have single certificate which
will be able to encrypt traffic for all specified domains.


This is solution for my internal relay system but I believe it should also
works with external domains.



Thanks for Your support..

Cheers

Zalezny

On Fri, Dec 11, 2015 at 2:24 PM, Tobias Reckhard <
tobias.reckh...@secunet.com> wrote:

> On 11.12.2015 09:11, Zalezny Niezalezny wrote:
> > is it possible to configure in Postfix multiple TLS certificates.
>
> AFAIK, you can configure each smtp and smtpd instance with a certificate
> of its own, so you could, for instance, have several smtpds listening on
> different IP addresses, each with an individual certificate. You could
> also specify different smtp transports services and have them use
> different certificates or CAs. But one smtpd and one smtp can be
> equipped with only one certificate.
>
> > For example, on my LAN relay server I must configure TLS for the unix
> > domains and for windows domains. Both domains use different names. How
> > to manage that part ?
>
> You're talking about receiving mail from the Internet, right? Typically,
> you'll have shared MX records for both domains. Your relay servers'
> certificates would typically reflect their host names, which doesn't
> necessarily need to have any similarities with the domains it's
> receiving mail for. You typically use the same name as the one in
> $myhostname as the CN of a server's certificate.
>
> > How to generate certificates than ? Is it possible to map some how TLS
> > certificates for the different domains ?
>
> Supposing that you have different MX records for your two domains, then
> I suppose that you might be able to generate or request certificates
> with corresponding SubjectAlternativeNames. I'm not sure whether those
> are widely supported in Internet MTAs, though.
>
> Cheers,
> Tobias
>

RE: postfix and multiple TLS certificates

[José Roberto]

Hi,

I think it's possible based on master.cf, you could set specific doamin for a 
smtp or submission and you set a specific TLS certificate in that  process, 
like we use for ehlo for a different IP and ehlo for a specific domain, but you 
need testing it.


José RobertoE-mail: zep...@outlook.com | Skype: zeponi | ICQ: 159416293
Informações profissionais: http://br.linkedin.com/in/jralves

Date: Fri, 11 Dec 2015 09:11:04 +0100
Subject: postfix and multiple TLS certificates
From: zalezny.niezale...@gmail.com
To: postfix-users@postfix.org

Hi, 
is it possible to configure in Postfix multiple TLS certificates.For example, 
on my LAN relay server I must configure TLS for the unix domains and for 
windows domains. Both domains use different names. How to manage that part ?
How to generate certificates than ? Is it possible to map some how TLS 
certificates for the different domains ?

Thanks in advance for Your support.

Zalezny   

Re: Change return-to path in postfix

[Wietse Venema]

basil varghese:
> Hi Wietse,
> 
> Makes sense! I guess sender_canonical_classes will work for us. I am trying
> to set this up for an emergency messaging system. Users can send emergency
> messages to groups either from outlook or post from a web application. The
> mail system has a high reputation.

In that case you should set the envelope sender on ALL messages
from the alerting system, just like mailing lists do (see the headers
of this email message: the return-path address is owner-postfix-users@).

This requires zero changes to Postfix, and should be done by the
sending application.

Wietse

> If I change the envelop sender for mails from client's outlook in postfix,
> will that affect our email reputation in anyway.?
> 
> 
> 
> Thanks
> Basil
> 
> 
> 
> 
> On Wed, Dec 9, 2015 at 11:59 PM, Wietse Venema  wrote:
> 
> > basil varghese:
> > > I have an SMTP application that handle mailing lists and it use postfix
> > > relay to send emails to end users. For some emails sent to some groups,
> > the
> > > "return-path" header is set to "from" header instead of "reply-to"
> >
> > According to Internet email RFCs(*), the Return-Path: header is
> > output only: it is created upon final delivery of an email message,
> > with value of the envelope sender address (the address in the "MAIL
> > FROM:" command, in terms of the SMTP protocol), and it is never
> > read for making delivery decisions.
> >
> > > I want my users receive the bounces only to "reply to" address. Is it
> > > something I can handle at postfix end. I want to rewrite the "return-to"
> > > path in each mail to the value found in "reply-to"
> >
> > According to Internet email RFCs, undeliverable mail is returned
> > to the address in the "MAIL FROM:" command, not some header address.
> > Therefore, you need to specify the correct envelope sender address.
> > If you want to do something non-standard like copy the envelope
> > address from some message header, that is not built into Postfix,
> > and will require a content filter.
> >
> > One mechanism that is built into Postfix is (sender_)canonical_maps.
> > With "sender_canonical_classes = envelope_sender", this can be used
> > to transform the sender envelope based on table lookup.
> >
> > Other mechanisms are built into mail clients. For example, choosing
> > the sender based on the content of the message or header.
> >
> > Wietse
> >
> > (*) Start with RFC 5321 and RFC 5322.
> >
> 
> 
> 
> -- 
> Regards
> basil

Re: Change return-to path in postfix

[basil varghese]

Hi Wietse,

Makes sense! I guess sender_canonical_classes will work for us. I am trying
to set this up for an emergency messaging system. Users can send emergency
messages to groups either from outlook or post from a web application. The
mail system has a high reputation.

If I change the envelop sender for mails from client's outlook in postfix,
will that affect our email reputation in anyway.?



Thanks
Basil




On Wed, Dec 9, 2015 at 11:59 PM, Wietse Venema  wrote:

> basil varghese:
> > I have an SMTP application that handle mailing lists and it use postfix
> > relay to send emails to end users. For some emails sent to some groups,
> the
> > "return-path" header is set to "from" header instead of "reply-to"
>
> According to Internet email RFCs(*), the Return-Path: header is
> output only: it is created upon final delivery of an email message,
> with value of the envelope sender address (the address in the "MAIL
> FROM:" command, in terms of the SMTP protocol), and it is never
> read for making delivery decisions.
>
> > I want my users receive the bounces only to "reply to" address. Is it
> > something I can handle at postfix end. I want to rewrite the "return-to"
> > path in each mail to the value found in "reply-to"
>
> According to Internet email RFCs, undeliverable mail is returned
> to the address in the "MAIL FROM:" command, not some header address.
> Therefore, you need to specify the correct envelope sender address.
> If you want to do something non-standard like copy the envelope
> address from some message header, that is not built into Postfix,
> and will require a content filter.
>
> One mechanism that is built into Postfix is (sender_)canonical_maps.
> With "sender_canonical_classes = envelope_sender", this can be used
> to transform the sender envelope based on table lookup.
>
> Other mechanisms are built into mail clients. For example, choosing
> the sender based on the content of the message or header.
>
> Wietse
>
> (*) Start with RFC 5321 and RFC 5322.
>



-- 
Regards
basil

Re: postfix and multiple TLS certificates

[Brian Sebby]

This is what I do on a mail server that I set up to consolidate the functions 
of several previous postfix servers.

In main.cf, I have it set up to listen on the primary IP address for the 
server, and tell it to use the certificates for that primary hostname using 
smtp_tls_cert_file, smtpd_tls_cert_file, and the other TLS options.  Then, in 
master.cf, I configure a second IP address, and set the options for that 
listener:

other.mail.server:smtp  inetn   -   n   -   0   smtpd
-o myhostname=other.mail.server
-o smtp_tls_cert_file=/path/to/certfile.pem
-o smtpd_tls_cert_file=/path/to/certfile.pem

It seems to work pretty well for us.  A wildcard certificate or one with 
multiple subject alternate names will also work, but those tend to be more 
expensive.


Brian

--
Brian Sebby  (se...@anl.gov)  |  Infrastructure and Operation Services
Phone: +1 630.252.9935|  Computing and Information Systems
Cell:  +1 630.921.4305|  Argonne National Laboratory

> On Dec 11, 2015, at 8:00 AM, José Roberto  wrote:
> 
> Hi,
> 
> I think it's possible based on master.cf, you could set specific doamin for a 
> smtp or submission and you set a specific TLS certificate in that  process, 
> like we use for ehlo for a different IP and ehlo for a specific domain, but 
> you need testing it.
> 
> 
> 
> José Roberto
> E-mail: zep...@outlook.com  | Skype: zeponi | ICQ: 
> 159416293
> Informações profissionais: http://br.linkedin.com/in/jralves 
> 
> 
> Date: Fri, 11 Dec 2015 09:11:04 +0100
> Subject: postfix and multiple TLS certificates
> From: zalezny.niezale...@gmail.com
> To: postfix-users@postfix.org
> 
> Hi, 
> 
> is it possible to configure in Postfix multiple TLS certificates.
> For example, on my LAN relay server I must configure TLS for the unix domains 
> and for windows domains. Both domains use different names. How to manage that 
> part ?
> 
> How to generate certificates than ? Is it possible to map some how TLS 
> certificates for the different domains ?
> 
> 
> Thanks in advance for Your support.
> 
> 
> Zalezny

postfix and multiple TLS certificates

[Zalezny Niezalezny]

Hi,

is it possible to configure in Postfix multiple TLS certificates.
For example, on my LAN relay server I must configure TLS for the unix
domains and for windows domains. Both domains use different names. How to
manage that part ?

How to generate certificates than ? Is it possible to map some how TLS
certificates for the different domains ?


Thanks in advance for Your support.


Zalezny

Re: postfix and multiple TLS certificates (SNI support?)

[Viktor Dukhovni]

On Fri, Dec 11, 2015 at 11:50:40AM -0600, Brian Sebby wrote:

> other.mail.server:smtpinetn   -   n   -   0   
> smtpd
>   -o myhostname=other.mail.server
>   -o smtp_tls_cert_file=/path/to/certfile.pem
>   -o smtpd_tls_cert_file=/path/to/certfile.pem
> 
> It seems to work pretty well for us.  A wildcard certificate or one with
> multiple subject alternate names will also work, but those tend to be more
> expensive.

Over the years there have from time to time been requests for
server-side SNI support in Postfix, but most users have found
workable alternatives, such as above.

A key reason that SNI support is not there yet, is that we like to
do things right(TM) in Postfix or not at all, and it is not entirely
clear what the "right" configuration interface for server-side SNI
might me (we can ignore implementation difficulties for now).

The main obstacle is that the primary cert/key are as "root" *before*
smtpd(8) drops privileges, while SNI information arrives during
the connection, when smtpd(8) is already running as the unprivileged
"postfix" user, possibly within a chroot jail.  This means that
smtpd(8) would need to arrange to gain access to all requisite keys
and certificates while still running root during process startup.

Now we certainly don't want to pay the cost of loading all the
certificates and keys into memory, so the options are perhaps:

  1. Use a table lookup that maps domain names (or domain name
 suffixes) to base64-encoded chain (PKCS#7) and key (PKCS#8)
 objects.  The table would be a "cdb" or "lmdb" database owned
 by root, mode 0[46]00.

example.com
   
chain=MIIByQYJKoZIhvcNAQcCoIIBujCCAbYCAQExADALBgkqhkiG9w0BBwGgggGcMIIBmDCCAT6gAwIBAgIBATAKBggqhkjOPQQDAjAWMRQwEgYDVQQDDAtleGFtcGxlLmNvbTAeFw0xNTEyMTExODUyMDlaFw0xNjAxMTAxODUyMDlaMBYxFDASBgNVBAMMC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEb2rusHCpKLrDj0tOIqr+g22Iq9eDg4atYtRhKVas6ve2L9o9d3cRnnGIt9qTJV3E6vjvGfxBPV6q+H14Q8XDbqN9MHswHQYDVR0OBBYEFELpnC1wAEKrfE2xJuRt/lX6FF2MMB8GA1UdIwQYMBaAFELpnC1wAEKrfE2xJuRt/lX6FF2MMAwGA1UdEwQFMAMBAf8wEwYDVR0lBAwwCgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwIDSAAwRQIgRtBQtdE4AGJozAVkGs81uYW/KVBquoHYBP7XxBC/z6YCIQDXzLBOw5ivFiWf1a/9tl1ddHL0IWYBX61NM0clM/oDJqEAMQA=
   
key=MHcCAQEEIMoR3bMT+b2/5NCa/ZGZom/a3cMoE1wGu+awdw8pOII2oAoGCCqGSM49AwEHoUQDQgAEb2rusHCpKLrDj0tOIqr+g22Iq9eDg4atYtRhKVas6ve2L9o9d3cRnnGIt9qTJV3E6vjvGfxBPV6q+H14Q8XDbg==

 The PKCS#12 content would be protected by file-system permissions,
 not a password.  The smtpd(8) server is not a human, and any
 required password would have to be stored along with the
 certificates.  In such cases, since passwords are not optional
 with PKCS#12, I tend to use passwords such as "umask 077",
 which convey where the effective security lies.

 There would need to be a tool that "compiles" a directory
 of PKCS#12 files into such a table.

  2. Leave the keys and certificates in files, and use strong
 passphrases for the keys, but configure smtpd(8) with a root
 owned table (mode 0[46]00) that maps domains or domain suffixes
 to a (password, key, chain) triple.

# Filenames are relative to the queue directory, because
# that's the chroot jail.
#
example.com 
pw=ABLLUpNBh8eakVs4Qinv,
key=sni/example.com.pem,
chain=sni/example.com.pem

 The private key files would then be owned by "postfix" (mode
 0400) and protected from other non-privileged Postfix processes
 via the associated strong passwords.

 example.com.pem:

 -BEGIN ENCRYPTED PRIVATE KEY-
 MIHeMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAiCQc48rR0diwICCAAw
 HQYJYIZIAWUDBAECBBCwIPRri8y1TOo872zl1It/BIGQfPsiJk83asYBOgJ60a44
 IBq1v/wSE9v8yD9jTq8Cb/jQBvie9tdMSCr8xjwVlvC/vDfbNx6W+d3wjQRM6rzY
 sXWVBeSb2TzxKGfZ9xD9ejZhUGXADIYsuoUDfZlz3vl6htViq7sjYWL8Dgz/PDit
 Sf4Rk1tiqV3cnFMY2OgQz06HGn0U22elq2MpYExL3BCz
 -END ENCRYPTED PRIVATE KEY-
 -BEGIN CERTIFICATE-
 MIIBmDCCAT6gAwIBAgIBATAKBggqhkjOPQQDAjAWMRQwEgYDVQQDDAtleGFtcGxl
 LmNvbTAeFw0xNTEyMTExODUyMDlaFw0xNjAxMTAxODUyMDlaMBYxFDASBgNVBAMM
 C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEb2rusHCpKLrD
 j0tOIqr+g22Iq9eDg4atYtRhKVas6ve2L9o9d3cRnnGIt9qTJV3E6vjvGfxBPV6q
 +H14Q8XDbqN9MHswHQYDVR0OBBYEFELpnC1wAEKrfE2xJuRt/lX6FF2MMB8GA1Ud
 IwQYMBaAFELpnC1wAEKrfE2xJuRt/lX6FF2MMAwGA1UdEwQFMAMBAf8wEwYDVR0l
 BAwwCgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0E
 AwIDSAAwRQIgRtBQtdE4AGJozAVkGs81uYW/KVBquoHYBP7XxBC/z6YCIQDXzLBO
 w5ivFiWf1a/9tl1ddHL0IWYBX61NM0clM/oDJg==
 -END CERTIFICATE-

Beyond that, support for this may require sufficiently recent
OpenSSL releases (1.0.2 is enough, 1.0.1 may suffice), as the
server-side SNI interface is IIRC a pain to work with