Loading ...
Sorry, an error occurred while loading the content.

Re: OpenSSL: TXT_DB error number 2

Expand Messages
  • thorsopia@lavabit.com
    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
    Message 1 of 21 , Nov 18, 2012
    • 0 Attachment
      "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-key-exchange-a-non-mathematicians-explanation
      [2] http://www.postfix.org/TLS_README.html#server_cipher
    • Viktor Dukhovni
      ... 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
      Message 2 of 21 , Nov 18, 2012
      • 0 Attachment
        On Sun, Nov 18, 2012 at 05:13:05AM -0500, thorsopia@... 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:
        >
        > Should I specify it like this?
        >
        > smtpd_tls_cert_file = /etc/postfix/smtpd.pem
        > smtpd_tls_key_file = /etc/postfix/smtpd.pem

        The second setting is optional, since the default is:

        $ postconf -d smtpd_tls_key_file
        smtpd_tls_key_file = $smtpd_tls_cert_file

        > There is a line from a previous setup:
        >
        > smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
        >
        > Can I remove it?

        Yes. It is almost never needed.

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

        --
        Viktor.
      • Viktor Dukhovni
        ... 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
        Message 3 of 21 , Nov 18, 2012
        • 0 Attachment
          On Sun, Nov 18, 2012 at 08:38:39AM -0500, thorsopia@... wrote:

          > "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?

          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.
        • Wietse Venema
          ... Fixed in the next release. Wietse
          Message 4 of 21 , Nov 18, 2012
          • 0 Attachment
            Viktor Dukhovni:
            > 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.

            Fixed in the next release.

            Wietse
          • thorsopia@lavabit.com
            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
            Message 5 of 21 , Nov 19, 2012
            • 0 Attachment
              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?
            • Wietse Venema
              ... 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
              Message 6 of 21 , Nov 19, 2012
              • 0 Attachment
                thorsopia@...:
                > 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.

                Wietse
              • Viktor Dukhovni
                ... 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
                Message 7 of 21 , Nov 19, 2012
                • 0 Attachment
                  On Mon, Nov 19, 2012 at 03:48:14PM -0500, thorsopia@... 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?

                  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.
                • Viktor Dukhovni
                  ... 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
                  Message 8 of 21 , Nov 19, 2012
                  • 0 Attachment
                    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.

                    --
                    Viktor.
                  • Viktor Dukhovni
                    ... 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
                    Message 9 of 21 , Nov 20, 2012
                    • 0 Attachment
                      On Tue, Nov 20, 2012 at 07:25:11AM -0500, citb@... 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:
                      >
                      > > $ openssl s_client -starttls smtp -connect mail.example.com:25
                      >
                      > The above command returned
                      >
                      > SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol

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


                      > There are related fields:
                      >
                      > TLS_DHCERTFILE=
                      > TLS_CERTFILE=/usr/lib/courier/imapd.pem
                      > TLS_TRUSTCERTS=/etc/ssl/certs
                      >
                      > 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:

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

                      --
                      Viktor.
                    • citb@lavabit.com
                      ... /var/log/mail.info: warning: cannot get RSA private key from file /etc/postfix/smtpd.pem: disabling TLS support warning: TLS library problem ... Expecting:
                      Message 10 of 21 , Nov 23, 2012
                      • 0 Attachment
                        >> > $ openssl s_client -starttls smtp -connect mail.example.com:25
                        >>
                        >> The above command returned
                        >>
                        >> SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol
                        >
                        > Check the server logs.

                        /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
                      • Viktor Dukhovni
                        ... 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
                        Message 11 of 21 , Nov 24, 2012
                        • 0 Attachment
                          On Fri, Nov 23, 2012 at 07:55:28PM -0500, citb@... wrote:

                          > > > SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol
                          > >
                          > > Check the server logs.
                          >
                          > /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

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

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

                          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.
                        • sllex@lavabit.com
                          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. ... I removed the -nodes
                          Message 12 of 21 , Nov 25, 2012
                          • 0 Attachment
                            Hello,

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

                            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
                          • Viktor Dukhovni
                            ... 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
                            Message 13 of 21 , Nov 25, 2012
                            • 0 Attachment
                              On Sun, Nov 25, 2012 at 07:12:00AM -0500, sllex@... 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:
                              >
                              > > $ egrep '^-----' smtpd.pem
                              > > -----BEGIN PRIVATE KEY-----
                              > > -----END PRIVATE KEY-----
                              > > -----BEGIN CERTIFICATE-----
                              > > -----END CERTIFICATE-----
                              >
                              > It was:
                              >
                              > -----BEGIN CERTIFICATE-----
                              > -----END CERTIFICATE-----
                              > -----END PRIVATE KEY-----

                              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.

                              > I removed the -nodes option and it worked.
                              >
                              > [...]
                              > Verify return code: 18 (self signed certificate)
                              > ---
                              > 250 DSN
                              > read:errno=0
                              >
                              > How to debug the above output? Is it OK?

                              Nothing to debug, you're all set.

                              --
                              Viktor.
                            • Viktor Dukhovni
                              ... For the record, this is brain-damage in linux /dev/fd semantics. On BSD-like systems and Solaris opening /dev/fd/ is equivalent to calling
                              Message 14 of 21 , Nov 26, 2012
                              • 0 Attachment
                                On Sun, Nov 25, 2012 at 04:15:41PM +0000, Viktor Dukhovni wrote:

                                > > > 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-----
                                > >
                                > > It was:
                                > >
                                > > -----BEGIN CERTIFICATE-----
                                > > -----END CERTIFICATE-----
                                > > -----END PRIVATE KEY-----
                                >
                                > 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
                                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.
                              Your message has been successfully submitted and would be delivered to recipients shortly.