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

Re: TLS Library Problem? Postfix 2.9.6

Expand Messages
  • weber@...
    ... openssl s_client -starttls smtp -connect mail.domian.de:25 CONNECTED(00000003) depth=2 C = US, O = thawte, Inc. , OU = Certification Services Division, OU
    Message 1 of 8 , Feb 11, 2013
    • 0 Attachment
      Am 2013-02-12 01:07, schrieb Wietse Venema:
      > weber@...:
      >> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
      >> library
      >> problem: 18823:error:04075070:rsa routines:RSA_sign:digest too big
      >> for
      >> rsa key:rsa_sign.c:127:
      >> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
      >> library
      >> problem: 18823:error:14099006:SSL
      >> routines:SSL3_SEND_CLIENT_VERIFY:EVP
      >> lib:s3_clnt.c:2983:
      >
      > The TLS library (i.e. OpenSSL) is not part of Postfix, so this may
      > be the wrong mailing list.
      >
      > What does
      >
      > $ openssl s_client -starttls smtp -connect servername:25


      openssl s_client -starttls smtp -connect mail.domian.de:25

      CONNECTED(00000003)
      depth=2 C = US, O = "thawte, Inc.", OU = Certification Services
      Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN =
      thawte Primary Root CA
      verify error:num=20:unable to get local issuer certificate
      verify return:0
      ---
      Certificate chain
      0 s:/O=mail.domain.de/OU=Go to
      https://www.thawte.com/repository/index.html/OU=Thawte SSL123
      certificate/OU=Domain Validated/CN=mail.domain.de
      i:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
      1 s:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
      i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c)
      2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
      2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c)
      2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
      i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
      cc/OU=Certification Services Division/CN=Thawte Premium Server
      CA/emailAddress=premium-server@...
      ---
      Server certificate
      -----BEGIN CERTIFICATE-----
      MIIEOjCCAyKgAwIBAgIQSlUaiYoSfpq8Je9tqw4GYDANBgkqhkiG9w0BAQUFADBe
      MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMuMR0wGwYDVQQLExRE
      b21haW4gVmFsaWRhdGVkIFNTTDEZMBcGA1UEAxMQVGhhd3RlIERWIFNTTCBDQTAe
      Fw0xMjA2MTMwMDAwMDBaFw0xMzA2MTMyMzU5NTlaMIGwMRgwFgYDVQQKFA9tYWls
      LnpiZm1haWwuZGUxOzA5BgNVBAsTMkdvIHRvIGh0dHBzOi8vd3d3LnRoYXd0ZS5j
      b20vcmVwb3NpdG9yeS9pbmRleC5odG1sMSIwIAYDVQQLExlUaGF3dGUgU1NMMTIz
      IGNlcnRpZmljYXRlMRkwFwYDVQQLExBEb21haW4gVmFsaWRhdGVkMRgwFgYDVQQD
      FA9tYWlsLnpiZm1haWwuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
      AQDAmiudVoYwLPurkEGr1hcGeCZN54qAAur2Dh+c49nTLwupCJg0CmpCLKbgUob3
      wupH7TLyTodGYR3mMaOxiDjVExoiIblR9hDSnvm2pnH3wqbFA8mjiCRrCvdKLQeE
      pykUob2wAyIU7ZvD1VJa/WrPLEoBAbsJCu4xMv8GYnLGBld3VFM31dNGCJQt8Y7S
      55ICMPKjVrQFNtkRRlCKqZnjpsmtWL/7Tji8qLVc8t8zPjB4oDPmSNhhd8bMjPBj
      MAUi5Z1vsxbr40I/pTJ589QK2qcWNwEXXqZ2t6Nn2UoDnNDG/Z8bWmjRty+rThXA
      2AJR1h57T8pFf3KgGedrhT1tAgMBAAGjgaAwgZ0wDAYDVR0TAQH/BAIwADA6BgNV
      HR8EMzAxMC+gLaArhilodHRwOi8vc3ZyLWR2LWNybC50aGF3dGUuY29tL1RoYXd0
      ZURWLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMgYIKwYBBQUH
      AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMA0GCSqG
      SIb3DQEBBQUAA4IBAQCYg3cdadM1yTaBSqE1AoEZHLq//WuabpkkGIqNUJVzuI7C
      XqY5HOoLvuN7JBHJeNnFiZ9oMaVJeflc7FhExhxFF0M+lbpw77ZCVjpsCzYbr64h
      Q1xcjxiu9E1tXNzB9VYW3f14fO08+z+ldg+Ip4Thukn1M4VEV2iIKsDjgZKANCMk
      rRDVYHV9HjctIYdUv7hSvpOP+IZYyl19QVOPeXwYo1BSUfbf0q61VTnU2U4fXzMC
      XmXU1iiTBmyLBp3rpPISIrIFyidZnz3t5DdpTbSG0stAdMdgTT1XI1l3W7Ok/B4V
      +EYiEb5JOwXLuXh0h82R7DZo0ZyEL0RxA21EbCup
      -----END CERTIFICATE-----
      subject=/O=mail.domain.de/OU=Go to
      https://www.thawte.com/repository/index.html/OU=Thawte SSL123
      certificate/OU=Domain Validated/CN=mail.domain.de
      issuer=/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
      ---
      Acceptable client certificate CA names
      /C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
      /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006
      thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
      ---
      SSL handshake has read 4609 bytes and written 504 bytes
      ---
      New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
      Server public key is 2048 bit
      Secure Renegotiation IS supported
      Compression: zlib compression
      Expansion: zlib compression
      SSL-Session:
      Protocol : TLSv1.2
      Cipher : ECDHE-RSA-AES256-GCM-SHA384
      Session-ID:
      01A34AF6F2586EFB5FCF8A4860FF9D13607FAE8BF2774587801985C6E5106C13
      Session-ID-ctx:
      Master-Key:
      09925141BD917D5E098A9BB18B8B547C732E6A38564CEEF3DAA18ECE963E24E7767D786E1276A117D13CAB5343C3B87C
      Key-Arg : None
      PSK identity: None
      PSK identity hint: None
      SRP username: None
      TLS session ticket lifetime hint: 3600 (seconds)
      TLS session ticket:
      0000 - ae 98 22 74 98 e5 42 e3-d5 ab 25 80 bb 1a b6 ab
      .."t..B...%.....
      0010 - 45 fd 31 cb 63 96 1b 7d-44 1e 78 86 15 c5 de 17
      E.1.c..}D.x.....
      0020 - 05 42 1a bb 5b f2 e2 23-4a 63 cb 90 ed e8 a0 ca
      .B..[..#Jc......
      0030 - 54 4e 08 7c c2 14 3a 0a-ad fe 31 89 6b 83 84 86
      TN.|..:...1.k...
      0040 - 91 ce a8 06 7e 30 78 e4-ef e2 7c 7f 96 90 99 d8
      ....~0x...|.....
      0050 - ab 51 2a 6d 51 bb 2d 32-da b9 64 ec af 61 06 3a
      .Q*mQ.-2..d..a.:
      0060 - 2f 9b e9 ea f3 23 38 01-7a 6f ed d2 d6 b8 65 8c
      /....#8.zo....e.
      0070 - a7 9d 64 15 ff ca b8 e2-25 87 b0 86 a8 e5 87 97
      ..d.....%.......
      0080 - 63 29 ab ac 79 81 1d af-c9 43 fb 09 53 5f 88 4d
      c)..y....C..S_.M
      0090 - a5 da 2e b9 6d 79 c5 c3-61 05 98 ab b6 49 4f 61
      ....my..a....IOa
      00a0 - e2 b2 47 30 d8 84 7f 5e-78 a5 b8 d4 2d c1 ac 9a
      ..G0...^x...-...

      Compression: 1 (zlib compression)
      Start Time: 1360631194
      Timeout : 300 (sec)
      Verify return code: 20 (unable to get local issuer certificate)
      ---
      250 8BITMIME
      quit
      221 2.0.0 Bye
      closed



      >
      > have to say about this?
      >
      > Wietse
    • Viktor Dukhovni
      ... Gentoo builds software from source, are you sure you built OpenSSL 1.0.1c and not the troubled 1.0.1d? ... This is only possible when the client and server
      Message 2 of 8 , Feb 11, 2013
      • 0 Attachment
        On Mon, Feb 11, 2013 at 11:58:07PM +0100, weber@... wrote:

        > on my backup relay server i find these lines in the logs.
        > i rebuild openssl and postfix.
        > i am on gentoo linux.
        >
        > openssl 1.0.1c

        Gentoo builds software from source, are you sure you built OpenSSL
        1.0.1c and not the troubled 1.0.1d?

        > Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
        > library problem: 18823:error:04075070:rsa routines:RSA_sign:digest
        > too big for rsa key:rsa_sign.c:127:
        > Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
        > library problem: 18823:error:14099006:SSL
        > routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:

        This is only possible when the client and server are using TLSv1.2
        and the client presents its own certificate. Do you have a client
        cert? If so, can you post the output of:

        $ openssl x509 -in clientcert.pem

        Also the output of:

        $ postconf -n | egrep '^(smtp_)?tls_'

        > any ideas? what causes these errors?

        The TLSv1.2 digest algorithm negotiated with the server is reportedly
        "too big" for your client certificate. If so, this feels like an
        implementation bug. The client should not present a certificate
        for which it can't generate a signature using the agreed digest.

        https://tools.ietf.org/html/rfc5246#section-7.4.8

        The hash and signature algorithms used in the signature MUST be
        one of those present in the supported_signature_algorithms field
        of the CertificateRequest message. In addition, the hash and
        signature algorithms MUST be compatible with the key in the
        client's end-entity certificate. RSA keys MAY be used with any
        permitted hash algorithm, subject to restrictions in the
        certificate, if any.

        You can retry the s_client command with the same client certificate
        configured with Postfix,

        $ openssl s_client \
        -cert clientcert.pem -key clientkey.pem \
        -state -debug -msg -starttls smtp -connect mail.zbfmail.de:25

        I'm only able to reproduce your problem when I generate and use an
        insecure 512-bit RSA client certificate (not a good plan).

        SSL_connect:SSLv3 write client key exchange A
        SSL_connect:error in SSLv3 write certificate verify A
        SSL_connect:error in SSLv3 write certificate verify A
        140735152091612:error:04075070:rsa routines:RSA_sign:digest too big for rsa key:rsa_sign.c:127:
        140735152091612:error:14099006:SSL routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:

        When I specify a 1024-bit key, the handshake completes normally.
        Whatever motivated you to configure a client certificate, and
        particularly a pointlessly weak one that is well short of 1024-bits,
        was probably the result of a particularly delirious nightmare.

        Just relax and set:

        main.cf:
        smtp_tls_cert_file =
        smtp_tls_key_file =

        as documented in:

        http://www.postfix.org/TLS_README.html#client_cert_key

        --
        Viktor.
      • weber@...
        Viktor, thanks for the detailed reply. i checked the crt with openssl rsa -in private.key -text -noout and voila, 512 bit like you said. after generating all
        Message 3 of 8 , Feb 12, 2013
        • 0 Attachment
          Viktor,
          thanks for the detailed reply.
          i checked the crt with
          openssl rsa -in private.key -text -noout

          and voila, 512 bit like you said.

          after generating all things new all is fine now.

          thanks for help.

          marko



          Am 2013-02-12 07:58, schrieb Viktor Dukhovni:
          > On Mon, Feb 11, 2013 at 11:58:07PM +0100, weber@...
          > wrote:
          >
          >> on my backup relay server i find these lines in the logs.
          >> i rebuild openssl and postfix.
          >> i am on gentoo linux.
          >>
          >> openssl 1.0.1c
          >
          > Gentoo builds software from source, are you sure you built OpenSSL
          > 1.0.1c and not the troubled 1.0.1d?
          >
          >> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
          >> library problem: 18823:error:04075070:rsa routines:RSA_sign:digest
          >> too big for rsa key:rsa_sign.c:127:
          >> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
          >> library problem: 18823:error:14099006:SSL
          >> routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:
          >
          > This is only possible when the client and server are using TLSv1.2
          > and the client presents its own certificate. Do you have a client
          > cert? If so, can you post the output of:
          >
          > $ openssl x509 -in clientcert.pem
          >
          > Also the output of:
          >
          > $ postconf -n | egrep '^(smtp_)?tls_'
          >
          >> any ideas? what causes these errors?
          >
          > The TLSv1.2 digest algorithm negotiated with the server is reportedly
          > "too big" for your client certificate. If so, this feels like an
          > implementation bug. The client should not present a certificate
          > for which it can't generate a signature using the agreed digest.
          >
          > https://tools.ietf.org/html/rfc5246#section-7.4.8
          >
          > The hash and signature algorithms used in the signature MUST be
          > one of those present in the supported_signature_algorithms field
          > of the CertificateRequest message. In addition, the hash and
          > signature algorithms MUST be compatible with the key in the
          > client's end-entity certificate. RSA keys MAY be used with any
          > permitted hash algorithm, subject to restrictions in the
          > certificate, if any.
          >
          > You can retry the s_client command with the same client certificate
          > configured with Postfix,
          >
          > $ openssl s_client \
          > -cert clientcert.pem -key clientkey.pem \
          > -state -debug -msg -starttls smtp -connect mail.zbfmail.de:25
          >
          > I'm only able to reproduce your problem when I generate and use an
          > insecure 512-bit RSA client certificate (not a good plan).
          >
          > SSL_connect:SSLv3 write client key exchange A
          > SSL_connect:error in SSLv3 write certificate verify A
          > SSL_connect:error in SSLv3 write certificate verify A
          > 140735152091612:error:04075070:rsa routines:RSA_sign:digest too
          > big for rsa key:rsa_sign.c:127:
          > 140735152091612:error:14099006:SSL
          > routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:
          >
          > When I specify a 1024-bit key, the handshake completes normally.
          > Whatever motivated you to configure a client certificate, and
          > particularly a pointlessly weak one that is well short of 1024-bits,
          > was probably the result of a particularly delirious nightmare.
          >
          > Just relax and set:
          >
          > main.cf:
          > smtp_tls_cert_file =
          > smtp_tls_key_file =
          >
          > as documented in:
          >
          > http://www.postfix.org/TLS_README.html#client_cert_key
        • weber@...
          sorry for 2nd reply, and no i had openssl 1.0.1c on gentoo i see theres now 1.0.1d-r1 and the 1.0.1d is MASKED now. marko
          Message 4 of 8 , Feb 12, 2013
          • 0 Attachment
            sorry for 2nd reply,

            and no i had openssl 1.0.1c on gentoo
            i see theres now 1.0.1d-r1 and the 1.0.1d is MASKED now.

            marko



            Am 2013-02-12 07:58, schrieb Viktor Dukhovni:
            > On Mon, Feb 11, 2013 at 11:58:07PM +0100, weber@...
            > wrote:
            >
            >> on my backup relay server i find these lines in the logs.
            >> i rebuild openssl and postfix.
            >> i am on gentoo linux.
            >>
            >> openssl 1.0.1c
            >
            > Gentoo builds software from source, are you sure you built OpenSSL
            > 1.0.1c and not the troubled 1.0.1d?
            >
            >> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
            >> library problem: 18823:error:04075070:rsa routines:RSA_sign:digest
            >> too big for rsa key:rsa_sign.c:127:
            >> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
            >> library problem: 18823:error:14099006:SSL
            >> routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:
            >
            > This is only possible when the client and server are using TLSv1.2
            > and the client presents its own certificate. Do you have a client
            > cert? If so, can you post the output of:
            >
            > $ openssl x509 -in clientcert.pem
            >
            > Also the output of:
            >
            > $ postconf -n | egrep '^(smtp_)?tls_'
            >
            >> any ideas? what causes these errors?
            >
            > The TLSv1.2 digest algorithm negotiated with the server is reportedly
            > "too big" for your client certificate. If so, this feels like an
            > implementation bug. The client should not present a certificate
            > for which it can't generate a signature using the agreed digest.
            >
            > https://tools.ietf.org/html/rfc5246#section-7.4.8
            >
            > The hash and signature algorithms used in the signature MUST be
            > one of those present in the supported_signature_algorithms field
            > of the CertificateRequest message. In addition, the hash and
            > signature algorithms MUST be compatible with the key in the
            > client's end-entity certificate. RSA keys MAY be used with any
            > permitted hash algorithm, subject to restrictions in the
            > certificate, if any.
            >
            > You can retry the s_client command with the same client certificate
            > configured with Postfix,
            >
            > $ openssl s_client \
            > -cert clientcert.pem -key clientkey.pem \
            > -state -debug -msg -starttls smtp -connect mail.zbfmail.de:25
            >
            > I'm only able to reproduce your problem when I generate and use an
            > insecure 512-bit RSA client certificate (not a good plan).
            >
            > SSL_connect:SSLv3 write client key exchange A
            > SSL_connect:error in SSLv3 write certificate verify A
            > SSL_connect:error in SSLv3 write certificate verify A
            > 140735152091612:error:04075070:rsa routines:RSA_sign:digest too
            > big for rsa key:rsa_sign.c:127:
            > 140735152091612:error:14099006:SSL
            > routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:
            >
            > When I specify a 1024-bit key, the handshake completes normally.
            > Whatever motivated you to configure a client certificate, and
            > particularly a pointlessly weak one that is well short of 1024-bits,
            > was probably the result of a particularly delirious nightmare.
            >
            > Just relax and set:
            >
            > main.cf:
            > smtp_tls_cert_file =
            > smtp_tls_key_file =
            >
            > as documented in:
            >
            > http://www.postfix.org/TLS_README.html#client_cert_key
          • Viktor Dukhovni
            ... Do you know how you accidentally ended-up with a 512-bit RSA key? [ Did you use the snake-oil key-pair included with the O/S? ] ... If anyone else runs
            Message 5 of 8 , Feb 12, 2013
            • 0 Attachment
              On Tue, Feb 12, 2013 at 09:22:55AM +0100, weber@... wrote:

              > I checked the certificate with:
              >
              > $ openssl x509 -in cert.pem -text -noout
              >
              > and voila, 512 bit like you said.

              Do you know how you accidentally ended-up with a 512-bit RSA key?
              [ Did you use the snake-oil key-pair included with the O/S? ]

              > >You can retry the s_client command with the same client certificate
              > >configured with Postfix,
              > >
              > > $ openssl s_client \
              > > -cert clientcert.pem -key clientkey.pem \
              > > -state -starttls smtp -connect mail.zbfmail.de:25
              > >
              > >I'm only able to reproduce your problem when I generate and use an
              > >insecure 512-bit RSA client certificate (not a good plan).
              > >
              > > SSL_connect:SSLv3 write client key exchange A
              > > SSL_connect:error in SSLv3 write certificate verify A
              > > SSL_connect:error in SSLv3 write certificate verify A
              > > 140735152091612:error:04075070:rsa routines:RSA_sign:digest too
              > >big for rsa key:rsa_sign.c:127:
              > > 140735152091612:error:14099006:SSL
              > >routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:

              If anyone else runs into similar trouble in the future, when testing
              with "openssl s_client" compare apples-to-apples by providing the
              same settings to s_client as to Postfix. For greater generality
              also specify the same CApath and CAfile.

              With the just released Postfix 2.10 it is easy to script the right
              s_client invocation:

              #! /bin/sh

              usage() { echo "Usage: $0 [-h] [-g gateway] [-p port]" >&2; exit 1; }

              gateway=$(uname -n)
              port=25

              while getopts "hg:p:" arg
              do
              case $arg in
              g) gateway="$OPTARG";;
              p) port="$OPTARG";;
              *) usage;;
              esac
              done

              set -- -state -showcerts -starttls smtp -connect "$gateway:$port"
              while read f p; do
              v=$(postconf -hx "$p")
              [ -n "$v" ] && set -- "-$f" "$v" "$@"
              done <<EOF
              key smtp_tls_key_file
              cert smtp_tls_cert_file
              CApath smtp_tls_CApath
              CAfile smtp_tls_CAfile
              EOF

              openssl s_client "$@"

              When debugging TLS-library errors with connections to remote servers,
              you can quickly eliminate the local Postfix client as the culprit
              if s_client exhibits the same symptoms. Perhaps we should ship a script
              of this sort in the auxiliary/ directory of the Postfix distribution.

              > >Just relax and set:
              > >
              > > main.cf:
              > > smtp_tls_cert_file =
              > > smtp_tls_key_file =
              > >
              > >as documented in:
              > >
              > > http://www.postfix.org/TLS_README.html#client_cert_key

              Do you really need a client certificate? Is the relay configured
              with a set of trusted client certificates? You should make sure
              that the 512-bit cert is no longer trusted by the relay.

              If client certificates are not required, don't use them.

              --
              Viktor.
            • Eray Aslan
              ... No. The snake-oil key-pair is 1024 bit rsa in gentoo. -- Eray Aslan
              Message 6 of 8 , Feb 13, 2013
              • 0 Attachment
                On Tue, Feb 12, 2013 at 04:51:33PM +0000, Viktor Dukhovni wrote:
                > Do you know how you accidentally ended-up with a 512-bit RSA key?
                > [ Did you use the snake-oil key-pair included with the O/S? ]

                No. The snake-oil key-pair is 1024 bit rsa in gentoo.

                --
                Eray Aslan <eras@...>
              Your message has been successfully submitted and would be delivered to recipients shortly.