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

Re: OpenSSL: TXT_DB error number 2

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