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 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? In case of Let's Encrypt that would be privkey.pem + cert.pem + chain.pem. And... what about: "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"? Thank you, Andrei On Mon, Apr 1, 2019 at 12:31 AM Viktor Dukhovni <postfix-us...@dukhovni.org> wrote: > 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. >
