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

Re: OpenSSL: TXT_DB error number 2

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