Hi Viktor,
Thank you for your explanation, I've been able to configure the SNI
functionality. Just one issue is left, but that's maybe for a further
improvement of postfix: it would be nice if there were a "catch-all" entry
in the SNI map table, like '* /path/to/cert.pem" or 'default
/path/to/cert.pem', because otherwise there is no way of specifying a
default certificate. Maybe this is not a so-needed feature, but maybe in
some occasions some users might want a self signed certificate for the
default and only use real certificates for one or some of the domains
hosted on the same server.
As a suggestion, I'd recommend making the documentation a bit easier to
understand by at least adding some examples. I think everybody would
welcome this.
Thank you again for your support,
Andrei
On Mon, Apr 1, 2019 at 5:40 PM Viktor Dukhovni <postfix-us...@dukhovni.org>
wrote:
> On Mon, Apr 01, 2019 at 02:09:25PM +0300, Andrei Kovacs wrote:
>
> > So, if I understand correctly, the configuration for the SNI file if it
> is
> > in hash format should be:
> >
> > domain1.com static:/path/to/pem1.pem
> > domain2.com static:/path/to/pem2.pem
>
> That makes no sense. You're putting tables inside tables. It is
> not turtles all the way down. The correct syntax is:
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> tls_server_sni_maps = ${indexed}sni-chains
>
> sni-chains:
> domain1.example /etc/postfix/sni/domain1.example.pem
> domain2.example /etc/postfix/sni/domain2.example.pem
>
> The "sni-chains" table MUST be created with "postmap -F". It holds
> a snapshot of the *content* of the listed files, not their names!
>
> If you later change the file content, but don't rebuild the table,
> the data in the table will remain stale. You'll need to rebuild
> the table (again with "postmap -F") whenever you want to start using
> new certificates, even if the file names are unchanged.
>
> The files must always list the private key before the associated
> certificate chain. You can list a file with just the key first,
> and then the certificate file. An advanced use case is to list
> multiple files for the same domain, each with a key and certificate
> chain for a different algorithm. Or you can concatenate multiple
> chains into a single file (again one per algorithm, with the key
> first).
>
> > Is it correct? And if so, the pem1.pem and pem2.pem files should contain
> in
> > the exact order the PEMs for Private Key, Certificate and Chain, right?
>
> Yes, but without those "static:" prefixes.
>
> > In case of Let's Encrypt that would be privkey.pem + cert.pem +
> > chain.pem.
>
> Let's Encrypt certbot provides a 'fullchain.pem' for the last two.
> Putting everything in one file makes for better atomicity. But
> if you're not racing "postmap -F" against certbot, the chances
> of running into trouble are low.
>
> > "Note that the SNI lookup tables should also have entries for the domains
> > that correspond to the Postfix SMTP server's default certificate(s). This
> > ensures that the remote SMTP client's TLS SNI extension gets a positive
> > response when it specifies one of the Postfix SMTP server's default
> > domains, and ensures that the Postfix SMTP server will not log an SNI
> name
> > mismatch for such a domain. The Postfix SMTP server's default
> certificates
> > are then only used when the client sends no SNI or when it sends SNI
> with a
> > domain that the server knows no certificate(s) for."
> >
> > ... how should this be speficifed? Like "default
> > static:/path/to/default.pem"?
>
> No. The syntax is exactly the same as with any other domain:
>
> myhostname.example /etc/postfix/chain.pem
>
> even when the default is:
>
> smtpd_tls_chain_files = /etc/postfix/chain.pem
>
> As explained, this ensures a positive ACK to the client, and
> suppresses logging of SNI mismatch. We could perhaps suppress such
> logging for $myhostname, for which presumably the default chain is
> the right one to use.
>
> --
> Viktor.
>
