Hi Victor,
thanks for the explanation what's happening in the internals of Postfix, but
the problem is still a mystery for me ...
I use the default Debian (Buster) /etc/ssl/openssl.cnf without any
modifications, so I don't think that there is any default certificate chain
that might be preloaded into each new SSL_CTX.
It looks like SNI works for you, but I cannot get it working - and tried really
hard for more than a week (I read everything I found on Google and it looks
like there are few people with working setup, and the remaining say that it
does not work) :-/
Any idea how to debug it myself? ... or even better - I can allow you root
access to the test server to check it yourself (just send me a private e-mail
with your ssh public key).
Many thanks!
JM
> On 9 Jun 2020, at 19:07, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
>
> On Wed, May 27, 2020 at 12:40:25AM +0200, Ján Máté wrote:
>
>> The error is "SNI data for smtp.myserver.eu does not match next
>> certificate" even if I am 100% sure that the key+cert+chain is OK,
>> because I use the same key+cert+chain (loaded from same files) for the
>> smtpd_tls_chain_files (and there it works).
>
> This is the symptom, the cause is indicated by the message one logged
> next to it.
>
>> /etc/postfix/main.cf:
>> tls_server_sni_maps = hash:/etc/postfix/table_hash-tls_server_sni_maps
>> smtpd_tls_chain_files =
>> /etc/letsencrypt/live/eu.server.smtp/privkey.pem
>> /etc/letsencrypt/live/eu.server.smtp/fullchain.pem
>>
>> /etc/postfix/table_hash-tls_server_sni_maps
>> smtp.myserver.eu /etc/letsencrypt/live/eu.myserver.smtp/privkey.pem
>> /etc/letsencrypt/live/eu.myserver.smtp/fullchain.pem
>> smtp.myserver2.eu /etc/letsencrypt/live/eu.myserver2.smtp/privkey.pem
>> /etc/letsencrypt/live/eu.myserver2.smtp/fullchain.pem
>
> I just tested with:
>
> main.cf:
> smtpd_tls_loglevel = 1
> smtpd_tls_security_level = may
> smtpd_tls_chain_files =
> ${config_directory}/ee1pkey.pem
> ${config_directory}/ee1cert.pem
> ${config_directory}/cacert.pem
> tls_server_sni_maps = hash:${config_directory}/sni
>
> sni
> mx1.example.com
> .../ee1pkey.pem
> .../ee1cert.pem
> .../cacert.pem
> mx2.example.com
> .../ee2pkey.pem
> .../ee2cert.pem
> .../cacert.pem
>
> My logs below...
>
>> May 26 22:38:58 myserver postfix/smtpd[72379]: maps_file_find:
>> tls_server_sni_maps:
>> hash:/etc/postfix/table_hash-tls_server_sni_maps(0,lock|fold_fix|src_rhs_is_file):
>> smtp.myserver.eu <http://smtp.myserver.eu/> =
>> LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUpRd0lCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQ1Mwd2dna3BBZ0VBQW9J...
>
> You generally don't want to log this data (your log level is too high),
> and should not publish it, it is liable to reveal part of your private
> key, though luckily, in this case, only some of the fixed header bits
> and none of the key material.
>
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index 1 in
>> SNI data for smtp.myserver.eu does not match next certificate
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library problem:
>> error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing
>> certificate:../ssl/ssl_rsa.c:1107:
>
> The second message is the real problem, OpenSSL believes it already has
> a certificate loaded for that algorithm, which should not be the case.
> The new key then does not match the already installed certificate. But
> there shouldn't be one already loaded.
>
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: error loading
>> private keys and certificates from: SNI data for smtp.myserver.eu: aborting
>> TLS handshake
>
> And so things go wrong. On the other hand, my logs show:
>
> postfix/postfix-script[95733]: starting the Postfix mail system
> postfix/master[95735]: daemon started -- version 3.6-20200511,
> configuration /var/tmp/postfix/etc
>
> -- No SNI servername used
> postfix/smtpd[95756]: connect from localhost[127.0.0.1]
> postfix/smtpd[95756]: Anonymous TLS connection established from
> localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
> bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
> SHA256
> postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1
> starttls=1 quit=1 commands=3
>
> -- SNI servername: mx1.example.com
> postfix/smtpd[95756]: connect from localhost[127.0.0.1]
> postfix/smtpd[95756]: Anonymous TLS connection established from
> localhost[127.0.0.1] to mx1.example.com: TLSv1.3 with cipher
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature
> RSA-PSS (2048 bits) server-digest SHA256
> postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1
> starttls=1 quit=1 commands=3
>
> -- SNI servername: mx2.example.com
> postfix/smtpd[95756]: connect from localhost[127.0.0.1]
> postfix/smtpd[95756]: Anonymous TLS connection established from
> localhost[127.0.0.1] to mx2.example.com: TLSv1.3 with cipher
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature
> RSA-PSS (2048 bits) server-digest SHA256
> postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1
> starttls=1 quit=1 commands=3
>
>> In short: if a connection from the client is performed without SNI (or
>> SNI hostname not present in the tls_server_sni_maps) then everything
>> works as expected (key+cert+chain from smtpd_tls_chain_files is used),
>> but if I connect using a valid SNI hostname (the new
>> tls_server_sni_maps is used) then the same key+cert+chain not works.
>
> It seems that somehow, a certificate of the same type is already loaded
> into the SSL handle under construction. It is unclear how that
> happened.
>
>> postmap -Fq smtp.myserver.eu hash:/etc/postfix/table_hash-tls_server_sni_maps
>>
>> returns the correct key+cert+chain:
>>
>> -----BEGIN PRIVATE KEY-----
>> ...
>> ... here is the private key for smtp.myserver.eu
>> ...
>> -----END PRIVATE KEY-----
>> -----BEGIN CERTIFICATE-----
>> ...
>> ... here is the certificate for smtp.myserver.eu
>> ...
>> -----END CERTIFICATE-----
>> -----BEGIN CERTIFICATE-----
>> ...
>> ... here is the certificate for intermediate CA
>> ...
>> -----END CERTIFICATE-----
>
> That seems reasonable, is there anything in your system-wide openssl.cnf
> file that looks like a default certificate chain that might be preloaded
> into each new SSL_CTX?
>
> --
> Viktor.
