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

Re: OpenSSL: TXT_DB error number 2

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.