On Sun, Mar 31, 2019 at 01:52:52PM +0300, Andrei Kovacs wrote:
> I've noticed the release of the new SNI feature in Postfix 3.4, but I
> cannot get a successful setup.
Sorry about that. I assume you've read:
http://www.postfix.org/postconf.5.html#tls_server_sni_maps
The mapping from an SNI domain name to a certificate chain is
typically indirect. In the input source files for "cdb", "hash",
"btree" or other tables that are converted to on-disk indexed
files via postmap(1), the value specified for each key is a
list of filenames. When postmap(1) is used with the -F option,
the generated table stores for each lookup key the base64-encoded
contents of the associated files. When querying tables via
postmap -Fq, the table value is decoded from base64, yielding
the original file content, plus a new line.
With "regexp", "pcre", "inline", "texthash", "static" and similar
tables that are interpreted at run-time, and don't have a
separate source format, the table value is again a list files,
that are read-in when the table is opened.
> My last attempt was to use tls_server_sni_maps,
There is no other mechanism, so not clear what you might have tried
first.
> but I'm not sure about the correct format (I've tried encoding the
> certificate as base64 according to the documentation).
The documentation says:
When postmap(1) is used with the -F option,
the generated table stores for each lookup key the base64-encoded
-------------------
contents of the associated files. When querying tables via
postmap -Fq, the table value is decoded from base64, yielding
the original file content, plus a new line.
That is, the base64 encoding/decoding is done *internally*, you are
not expected to (i.e. required to not) pre-encode the certificate
chain file(s). The only case in you need to do base64 encoding is
when you want (likely unwisely) to store the chain files in an SQL
database:
With tables whose content is managed outside of Postfix, such
as LDAP, MySQL, PostgreSQL, socketmap and tcp, the value must
be a concatenation of the desired PEM keys and certificate
chains, that is then further encoded to yield a single-line
base64 string. Creation of such tables and secure storage are
outside the responsibility of Postfix. With "socketmap" and
"tcp" the data would be transmitted in the clear. With LDAP and
SQL, you should generally use TLS to protect the sensitive data
in transit.
What's missing from the "tls_server_sni_maps" documentation (sorry
about that) is a reference to the
http://www.postfix.org/postconf.5.html#smtpd_tls_chain_files
documentation, which covers the expected file format. The syntax
for the RHS values of the (non-IPC) lookup tables used with
tls_server_sni_maps is the same as with the "chain files" parameter.
--
Viktor.
