> This will write a new 1280-bit RSA key and the corresponding
> self-signed certificate with server name "mail.example.com" valid
> for ~10 years to the file /etc/postfix/smtpd.pem, which you can
> use as the server certificate (and implicitly key) file:
"smtpd_tls_eecdh_grade (default: see "postconf -d" output)
This feature is available in Postfix 2.6 and later, when it is
compiled and linked with OpenSSL 1.0.0 or later." 
I'm using Postfix 2.7.1. "aptitude show postfix" shows libssl0.9.8 in
"postconf -d" lists this option. Does it mean that it's supported?
I read some articles about Diffie-Hellman Key Exchange. What I don't
understand is the connection between theory and its practical
For example, this article  says that it's necessary to have a
key pair on a client machine. But this one  doesn't say anything
regarding clients. Is it necessary to configure clients? Will it be
handled automatically (by OpenSSL)?
Will smtpd.pem be used to certify public keys or authorize a server? Will
used to encrypt a shared secret? What key will be used to decrypt the
shared secret (on the client)?
What is the purpose of DH parameters? What are export and non-export
On Sun, Nov 18, 2012 at 05:13:05AM -0500, thorso...@lavabit.com wrote:
> > This will write a new 1280-bit RSA key and the corresponding
> > self-signed certificate with server name "mail.example.com" valid
> > for ~10 years to the file /etc/postfix/smtpd.pem, which you can
> > use as the server certificate (and implicitly key) file:
> > Support for elliptic curve cryptography is available with Postfix
> > 2.6 and OpenSSL 0.9.9 or later.
> OpenSSL 0.9.8 supports it too.
This is true to some degree, but Postfix only enables EC ciphers
when compiled and linked with OpenSSL 1.0.0 or later. If the text
mentioning 0.9.9 is from Postfix documentation, we should update
it, there was never an OpenSSL 0.9.9 release, only development
On Sun, Nov 18, 2012 at 08:38:39AM -0500, thorso...@lavabit.com wrote:
> "smtpd_tls_eecdh_grade (default: see "postconf -d" output)
> This feature is available in Postfix 2.6 and later, when it is
> compiled and linked with OpenSSL 1.0.0 or later." 
> I'm using Postfix 2.7.1. "aptitude show postfix" shows libssl0.9.8 in
> "postconf -d" lists this option. Does it mean that it's supported?
No, Postfix with elliptic curve DH requires OpenSSL 1.0.0. However,
you can still use regular 1024-bit prime DH, preferably by generating
non-default DH parameters, although in practice it is likely that
the default prime group compiled into Postfix has not yet been
brute-forced. Thus lack of elliptic curve support is not critical.
On Mon, Nov 19, 2012 at 04:03:15PM -0500, Wietse Venema wrote:
> > I applied the suggested changes and decided to test the server.
> > "openssl s_client -tls1 -connect mail.example.com:25" returned
> > "SSL3_GET_RECORD:wrong version number". What is the problem?
> Stuff the error message into a search engine.
> The result: one ends of the connection wants to talk SSLv3 and the
> other end supports only TLSv1.
In this case the problem is deeper, one end is not even talking
SSL/TLS, the "wrong version number" is a bit of a red-herring, an
SMTP banner is misreported as an SSL record layer header with an
unexpected protocol version.
Avoiding this problem would have required a more bloated TLS record
layer, so better reporting is not easy.
On Tue, Nov 20, 2012 at 07:25:11AM -0500, c...@lavabit.com wrote:
> > SMTP servers negotiate TLS over SMTP via STARTTLS, you're trying
> > to start the SSL/TLS handshake without the prior SMTP handshake.
> > You must:
Check the server logs. This works when "mail.example.com" (that is
is whatever you're actually testing) is replaced by mx.lavabit.com.
> There is one thing I forgot to ask when we discussed DH keys and certs.
> Should I also alter courier config?
At no point did I suggest creating DH certificates, neither for
Postfix nor for any other software. EDH Key Exchange is NOT
certificate authentication, nobody uses DH certs, continue to
[For the record, in private peering arrangements I've sometimes
used ECDSA, but that won't work too well on the public internet,
for Internet facing SMTP servers one always needs at least RSA,
and given the OPs level of experience with SSL, ... I would not
recommend adventurous multi-certificate configurations]
> Should I point TLS_DHCERTFILE to /etc/postfix/smtpd.pem?
NO. Do not use DH certificates, use RSA. The DH parameter
files you were advised to generate are not certificates.
Your smtpd.pem file should be mode 0600 and contain an
RSA private key and associated self-signed certificate.
> Should I point TLS_CERTFILE to /etc/postfix/smtpd.pem?
> (Postfix uses it as smtpd_tls_cert_file.)
You can use the same certificate for both IMAP and SMTP, if the
same CN (hostname) is used by clients for both protocols.
> Should I point TLS_TRUSTCERTS to /etc/ssl/certs/cacert.pem?
> (Postfix uses the above as smtpd_tls_CAfile.)
You don't need a CA file, your certificate is self-signed.
> imapd.pem was generated with mkimapdcert.
Then you can use that if you like.
> I attached the script and comments connected with options:
Either you botched the recipe, or the use of "-keyout stdout" is
not a portable way of getting OpenSSL to output the key and
certificate back-to-back. Did the shell commands in the recipe
generate any error messages?
When I run this and check the contents of the smtpd.pem file (did
you ever look at the file contents? Why not?) I see:
> Either you botched the recipe, or the use of "-keyout stdout" is
> not a portable way of getting OpenSSL to output the key and
> certificate back-to-back.
It turned out that my version of genrsa doesn't support the -nodes
option. I removed it and it didn't raise any errors.
> When I run this and check the contents of the smtpd.pem file (did
> you ever look at the file contents? Why not?) I see:
> $ egrep '^-----' smtpd.pem
> -----BEGIN PRIVATE KEY-----
> -----END PRIVATE KEY-----
> -----BEGIN CERTIFICATE-----
> -----END CERTIFICATE-----
On Sun, Nov 25, 2012 at 07:12:00AM -0500, sl...@lavabit.com wrote:
> It turned out that my version of genrsa doesn't support the -nodes
> option. I removed it and it didn't raise any errors.
Actually that's universal, I forgot that while with req(1) encryption
of the private key is the default and "-nodes" turns it off, with
genrsa(1) no encryption is the default and "-aes128" or similar
turns it on.
> > When I run this and check the contents of the smtpd.pem file (did
> > you ever look at the file contents? Why not?) I see:
> So the output was overlapped, which is different than what I see
> (but I only tested OpenSSL 1.0.x on BSD-like systems). Thus it is
> safer to generate the key and cert in separate command invocations.
For the record, this is brain-damage in linux /dev/fd semantics.
On BSD-like systems and Solaris opening /dev/fd/<number> is equivalent
to calling dup(<number>) and returns a second file descriptor for the
- The file offset (i.e. open file table slot) is shared
between the original and new descriptor, consecutive
writes on either descriptor are concatentated, and don't
clobber each other.
- Since no new file is opened, the two files are open with
the same mode and no additional permission checks are applied
when opening /dev/fd.
Both of the above are false with Linux. Thus you can EPERM openining
/dev/stdout or /dev/fd/<number> and writes to /dev/stdout followed
by writes to the original standard output do clobber each other unless
one opens stdout with O_APPEND. I consider the Linux semantics broken,
but perhaps I am missing an important design consideration that makes
the Linux semantics correct.