On Tue, Aug 20, 2013 at 01:27:01PM +0200, Sebastian Wiesinger wrote:
> I found the problem... In addition to my normal certificate, I had an
> EC certificate.
>
> smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt
Though I think OpenSSL will generally detect attempts to configure
a public key (certificate) without a matching private key, you
should check that the private key and certificate match:
(
# Adjust as necessary
certfile=/etc/postfix/certs/cacert-karotte-ec.crt # cert
pkeyfile=/etc/postfix/certs/cacert-karotte-ec.crt # private key
# Digest of public key from certificate:
openssl x509 -in ${certfile} -noout -pubkey |
openssl pkey -pubin -outform DER |
openssl dgst -sha1 -c
# Digest of public key from private key:
openssl pkey -in ${pkeyfile} -pubout -outform DER |
openssl dgst -sha1 -c
) | uniq -c
This should output a single digest with a count of "2".
> As soon as I removed that line it started working...
If you're willing to test briefly with the EC certificate re-enabled,
it would be helpful to capture a full packet capture tcpdump (aka
pcap) file with a failed delivery from gmx.de/web.de. Viewing this
with "wireshark" will show exactly where in the handshake the problem
ocurred and may shed some light on the reason.
After capturing all traffic from the source in question for a period of
time that includes at least one complete failed session, extract just that
session from the capture file by identifying the TCP source port of such a
session and running:
client_source_port=58459 # example adjust to match reality
tcpdump -s0 -r /tmp/full-capture.pcap -w /tmp/session-capture.pcap \
tcp port $client_source_port
The resulting output file should contain just a single TCP session with
three way handshake (SYN, SYN-ACK, ACK) and three-way shutdown
(FIN, FIN, ACK or in some cases either FIN or final ACK may be an RST).
Please post a URL to the binary PCAP file.
> Certificate:
> Subject Public Key Info:
> Public Key Algorithm: id-ecPublicKey
> Public-Key: (384 bit)
> pub:
> 04:6d:69:d6:06:1f:7c:b2:8d:2b:6b:a5:0e:d9:8f:
> c9:6c:cf:ad:32:3d:35:3b:82:a6:58:ea:38:66:ae:
> 3d:43:ac:b0:cd:41:28:c6:7a:f7:3f:da:cf:50:be:
> 93:a5:90:30:cb:98:9c:b7:a1:07:93:39:bf:32:7f:
> 01:9c:59:04:8a:7d:fc:72:e9:78:a9:e5:22:e7:22:
> 5d:b5:80:bf:77:e1:be:65:3d:ce:10:c4:f3:5c:52:
> 73:aa:80:56:81:02:29
> ASN1 OID: secp384r1
There are no known practical attacks on 256-bit EC keys and 384-bit
EC is slower. AES-128 with EC-256 is sufficiently secure for SMTP
TLS. Though I expect that if the sender has trouble with 384-bit
EC, they'll have trouble with EC in general.
--
Viktor.
