Should I specify it like this?

smtpd_tls_cert_file = /etc/postfix/smtpd.pem
smtpd_tls_key_file = /etc/postfix/smtpd.pem

There is a line from a previous setup:

smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem

Can I remove it?

OpenSSL 0.9.8 supports it too.

Viktor, thank you so much for your help.

"smtpd_tls_eecdh_grade (default: see "postconf -d" output)

<snip>

    This feature is available in Postfix 2.6 and later, when it is
    compiled and linked with OpenSSL 1.0.0 or later." [0]

I'm using Postfix 2.7.1. "aptitude show postfix" shows libssl0.9.8 in
dependencies.

"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
implementation.

For example, this article [1] says that it's necessary to have a
key pair on a client machine. But this one [2] 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
it be
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
ciphers? [2]

[0] http://www.postfix.org/postconf.5.html#smtpd_tls_eecdh_grade
[1]
http://www.packetsource.com/article/encryption/40070/diffie-hellman-k...
[2] http://www.postfix.org/TLS_README.html#server_cipher

The second setting is optional, since the default is:

        $ postconf -d smtpd_tls_key_file
        smtpd_tls_key_file = $smtpd_tls_cert_file

Yes. It is almost never needed.

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
snapshots.

--
        Viktor.

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.

src/tls/tls_dh.c:

   /*
    * Generated via "openssl dhparam -2 -noout -C 512 2>/dev/null" TODO:
    * generate at compile-time.
    */
  static unsigned char dh512_p[] = {
      0x88, 0x3F, 0x00, 0xAF, 0xFC, 0x0C, 0x8A, 0xB8, 0x35, 0xCD, 0xE5, 0xC2,
      0x0F, 0x55, 0xDF, 0x06, 0x3F, 0x16, 0x07, 0xBF, 0xCE, 0x13, 0x35, 0xE4,
      0x1C, 0x1E, 0x03, 0xF3, 0xAB, 0x17, 0xF6, 0x63, 0x50, 0x63, 0x67, 0x3E,
      0x10, 0xD7, 0x3E, 0xB4, 0xEB, 0x46, 0x8C, 0x40, 0x50, 0xE6, 0x91, 0xA5,
      0x6E, 0x01, 0x45, 0xDE, 0xC9, 0xB1, 0x1F, 0x64, 0x54, 0xFA, 0xD9, 0xAB,
      0x4F, 0x70, 0xBA, 0x5B,
  };

   /*
    * Generated via "openssl dhparam -2 -noout -C 1024 2>/dev/null" TODO:
    * generate at compile-time.
    */
  static unsigned char dh1024_p[] = {
      0xB0, 0xFE, 0xB4, 0xCF, 0xD4, 0x55, 0x07, 0xE7, 0xCC, 0x88, 0x59, 0x0D,
      0x17, 0x26, 0xC5, 0x0C, 0xA5, 0x4A, 0x92, 0x23, 0x81, 0x78, 0xDA, 0x88,
      0xAA, 0x4C, 0x13, 0x06, 0xBF, 0x5D, 0x2F, 0x9E, 0xBC, 0x96, 0xB8, 0x51,
      0x00, 0x9D, 0x0C, 0x0D, 0x75, 0xAD, 0xFD, 0x3B, 0xB1, 0x7E, 0x71, 0x4F,
      0x3F, 0x91, 0x54, 0x14, 0x44, 0xB8, 0x30, 0x25, 0x1C, 0xEB, 0xDF, 0x72,
      0x9C, 0x4C, 0xF1, 0x89, 0x0D, 0x68, 0x3F, 0x94, 0x8E, 0xA4, 0xFB, 0x76,
      0x89, 0x18, 0xB2, 0x91, 0x16, 0x90, 0x01, 0x99, 0x66, 0x8C, 0x53, 0x81,
      0x4E, 0x27, 0x3D, 0x99, 0xE7, 0x5A, 0x7A, 0xAF, 0xD5, 0xEC, 0xE2, 0x7E,
      0xFA, 0xED, 0x01, 0x18, 0xC2, 0x78, 0x25, 0x59, 0x06, 0x5C, 0x39, 0xF6,
      0xCD, 0x49, 0x54, 0xAF, 0xC1, 0xB1, 0xEA, 0x4A, 0xF9, 0x53, 0xD0, 0xDF,
      0x6D, 0xAF, 0xD4, 0x93, 0xE7, 0xBA, 0xAE, 0x9B,
  };

--
        Viktor.

Viktor Dukhovni:

Fixed in the next release.

        Wietse

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?

thorso...@lavabit.com:

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.

        Wietse

SMTP servers negotiate TLS over SMTP via STARTTLS, you're trying
to start the SSL/TLS handshake without the prior SMTP handshake.
You must:

        $ openssl s_client -starttls smtp -connect mail.example.com:25

--
        Viktor.

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.

--
        Viktor.

Check the server logs. This works when "mail.example.com" (that is
is whatever you're actually testing) is replaced by mx.lavabit.com.

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
use RSA.

[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]

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.

You can use the same certificate for both IMAP and SMTP, if the
same CN (hostname) is used by clients for both protocols.

You don't need a CA file, your certificate is self-signed.

Then you can use that if you like.

I am not going to read it, sorry about that.

--
        Viktor.

/var/log/mail.info:

warning: cannot get RSA private key from file /etc/postfix/smtpd.pem:
disabling TLS support
warning: TLS library problem ... Expecting: ANY PRIVATE KEY

I used these commands [0] to create smtpd.pem:

 # cd /etc/postfix
 # tmp=$(mktemp smtpd.pem.XXXXXX)
 # openssl req -x509 -new -newkey rsa:1280 -nodes -keyout /dev/stdout \
        -days $((365 * 10)) -subj "/CN=mail.example.com" > $tmp
 # chmod 0600 $tmp
 # mv $tmp smtpd.pem

Why Postfix fail to get a key from smtpd.pem?

main.cf:

smtpd_tls_cert_file = /etc/postfix/smtpd.pem
smtpd_tls_key_file = /etc/postfix/smtpd.pem

Thanks

[0] http://article.gmane.org/gmane.mail.postfix.user/233328

There is no usable private key in your smtpd.pem configuration file.

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:

        $ egrep '^-----' smtpd.pem
        -----BEGIN PRIVATE KEY-----
        -----END PRIVATE KEY-----
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----

Which shows the expected key and certificate.  Post the output for
your system.  You can alsways generate the key separately:

   # cd /etc/postfix
   # tmp=$(mktemp smtpd.pem.XXXXXX)
   # openssl genrsa -nodes -out "$tmp" 1280
   # openssl req -x509 -new -key "$tmp" \
        -days "$((365 * 10))" -subj "/CN=mail.example.com" >> "$tmp"
   # chmod 0600 "$tmp"
   # mv "$tmp" smtpd.pem

Don't be so helpless. Take some initiative to follow the clues to their
logical conclusions. If the software sees no key in the file, check the
file and figure out what's there, and perhaps why.

--
        Viktor.

Hello,

It turned out that my version of genrsa doesn't support the -nodes
option. I removed it and it didn't raise any errors.

It was:

   -----BEGIN CERTIFICATE-----
   -----END CERTIFICATE-----
   -----END PRIVATE KEY-----

I removed the -nodes option and it worked.

$ openssl s_client -starttls smtp -connect mail.example.com:25
CONNECTED(00000003)
depth=0 /CN=mail.example.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=mail.example.com
verify return:1
---
Certificate chain
 0 s:/CN=mail.example.com
   i:/CN=mail.example.com
---
Server certificate
-----BEGIN CERTIFICATE-----

...

-----END CERTIFICATE-----
subject=/CN=mail.example.com
issuer=/CN=mail.example.com
---
No client certificate CA names sent
---

...

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1280 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: ...
    Session-ID-ctx:
    Master-Key: ...
    Key-Arg   : None
    ...
    Verify return code: 18 (self signed certificate)
---
250 DSN
read:errno=0

How to debug the above output? Is it OK?

Thank you

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.

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.

Nothing to debug, you're all set.

--
        Viktor.

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
same file:

        - 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.

So my one-shot recipe can be adjusted as follows:

        tmp=$(mktemp smtpd.pem.XXXXXX)
        openssl req -new -x509 -newkey rsa:1280 -nodes -keyout /dev/stdout \
                -days $((356 * 10)) -subj "/CN=$(uname -N)" >> "$tmp"
        mv "$tmp" smtpd.pem

but this is perhaps over-optimization, and two steps are just fine.

--
        Viktor.