Viktor Dukhovni:
> On Mon, Apr 01, 2019 at 10:38:49AM -0400, Viktor Dukhovni 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).
>
> It seems a documentation update is needed, but I'd like to hear
> whether the above is sufficiently clear, or whether more remains
> unclear. This may need a new section in TLS_README. Or should we
> spin off a smaller SNI_README?
If you can fix this for the stable release without refactoring
documentation that would be best. Refactoring can happen in the
development release.
Wietse
