STARTTLS / DANE difficulties?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

STARTTLS / DANE difficulties?

James B. Byrne
We are migrating our Postfix MX services and in the process have
disrupted a setup which has been very stable for the past couple of
years.  One of the remaining items is this sort of message which only
started very recently:


Jul 10 11:55:29 mx31 postfix-p25/smtpd[70030]: connect from
hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library
problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad
certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert number
42:
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: lost connection after
STARTTLS from hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: disconnect from
hr1.samba.org[144.76.82.147] ehlo=1 starttls=1 commands=2

I thought that these errors were the result of a misconfigured
certificate or private key for the postfix service.  However, I have
examined these and they appear to be correct:

postconf -n | grep -i tls
smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC5
smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom


# ll /usr/local/etc/pki/tls/private/
total 18
-rw-------  1 root  wheel  3243 Jun  7 15:37 2016003E.key
lrwxr-xr-x  1 root  wheel    12 Jul 10 12:19 ca.harte-lyne.mx31.key ->
2016003E.key

ll /usr/local/etc/pki/tls/certs
total 565
-rw-r--r--  1 root  wheel   10164 Jun  7 15:37 2016003E.pem
-rw-r--r--  1 root  wheel  822512 Jul 10 12:05 ca-bundle.crt
lrwxr-xr-x  1 root  wheel      22 Jul 10 12:07 ca.harte-lyne.mx31.crt
-> ca.harte-lyne.mx31.pem
lrwxr-xr-x  1 root  wheel      12 Jul 10 12:06 ca.harte-lyne.mx31.pem
-> 2016003E.pem

# openssl x509 -noout -text -in
/usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 538312766 (0x2016003e)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: CN=CA_HLL_ISSUER_2016, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=harte-lyne, DC=ca
        Validity
            Not Before: Jun  1 00:00:00 2018 GMT
            Not After : Jun 30 23:59:59 2023 GMT
        Subject: CN=mx31.harte-lyne.ca, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=hamilton, DC=harte-lyne, DC=ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
. . .

Can someone interpret for me what these messages are telling me?  Is
samba.org misconfigured or me?


--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

RE: STARTTLS / DANE difficulties?

Fazzina, Angelo
When you test connecting to your servers yourself do you get any errors ?
Not sure if sslv3 is ok to see if using TLS ???

Commands to try, just replace with your server name
openssl s_client  -connect mta5.uits.uconn.edu:465
openssl s_client -starttls smtp -connect mta5.uits.uconn.edu:587

openssl s_client  -connect <yourname>:465
openssl s_client -starttls smtp -connect <yourname>:587


good luck.



-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of James B. Byrne
Sent: Tuesday, July 10, 2018 12:56 PM
To: [hidden email]
Subject: STARTTLS / DANE difficulties?

We are migrating our Postfix MX services and in the process have
disrupted a setup which has been very stable for the past couple of
years.  One of the remaining items is this sort of message which only
started very recently:


Jul 10 11:55:29 mx31 postfix-p25/smtpd[70030]: connect from
hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library
problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad
certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert number
42:
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: lost connection after
STARTTLS from hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: disconnect from
hr1.samba.org[144.76.82.147] ehlo=1 starttls=1 commands=2

I thought that these errors were the result of a misconfigured
certificate or private key for the postfix service.  However, I have
examined these and they appear to be correct:

postconf -n | grep -i tls
smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC5
smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom


# ll /usr/local/etc/pki/tls/private/
total 18
-rw-------  1 root  wheel  3243 Jun  7 15:37 2016003E.key
lrwxr-xr-x  1 root  wheel    12 Jul 10 12:19 ca.harte-lyne.mx31.key ->
2016003E.key

ll /usr/local/etc/pki/tls/certs
total 565
-rw-r--r--  1 root  wheel   10164 Jun  7 15:37 2016003E.pem
-rw-r--r--  1 root  wheel  822512 Jul 10 12:05 ca-bundle.crt
lrwxr-xr-x  1 root  wheel      22 Jul 10 12:07 ca.harte-lyne.mx31.crt
-> ca.harte-lyne.mx31.pem
lrwxr-xr-x  1 root  wheel      12 Jul 10 12:06 ca.harte-lyne.mx31.pem
-> 2016003E.pem

# openssl x509 -noout -text -in
/usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 538312766 (0x2016003e)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: CN=CA_HLL_ISSUER_2016, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=harte-lyne, DC=ca
        Validity
            Not Before: Jun  1 00:00:00 2018 GMT
            Not After : Jun 30 23:59:59 2023 GMT
        Subject: CN=mx31.harte-lyne.ca, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=hamilton, DC=harte-lyne, DC=ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
. . .

Can someone interpret for me what these messages are telling me?  Is
samba.org misconfigured or me?


--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.harte-lyne.ca&amp;data=02%7C01%7Cangelo.fazzina%40uconn.edu%7C6922a5cc8abd4ad2f16608d5e6863894%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636668386513643202&amp;sdata=uwMebM%2BjRmEqZjkTTbuMggiZED7kKeYUaf8iX7dH32Q%3D&amp;reserved=0
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

RE: STARTTLS / DANE difficulties?

Fazzina, Angelo
My test of connecting to your server
openssl s_client -starttls smtp -connect mx31.harte-lyne.ca:587

    Start Time: 1531242804
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
250 SMTPUTF8
quit
221 2.0.0 Bye
closed
[root@mta5 alf02013]#

MY SERVER

    Start Time: 1531242903
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
250 DSN
quit
221 2.0.0 Bye
closed
[root@mta5 alf02013]#



-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075


-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Fazzina, Angelo
Sent: Tuesday, July 10, 2018 1:06 PM
To: [hidden email]
Subject: RE: STARTTLS / DANE difficulties?

When you test connecting to your servers yourself do you get any errors ?
Not sure if sslv3 is ok to see if using TLS ???

Commands to try, just replace with your server name
openssl s_client  -connect mta5.uits.uconn.edu:465
openssl s_client -starttls smtp -connect mta5.uits.uconn.edu:587

openssl s_client  -connect <yourname>:465
openssl s_client -starttls smtp -connect <yourname>:587


good luck.



-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of James B. Byrne
Sent: Tuesday, July 10, 2018 12:56 PM
To: [hidden email]
Subject: STARTTLS / DANE difficulties?

We are migrating our Postfix MX services and in the process have
disrupted a setup which has been very stable for the past couple of
years.  One of the remaining items is this sort of message which only
started very recently:


Jul 10 11:55:29 mx31 postfix-p25/smtpd[70030]: connect from
hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library
problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad
certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert number
42:
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: lost connection after
STARTTLS from hr1.samba.org[144.76.82.147]
Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: disconnect from
hr1.samba.org[144.76.82.147] ehlo=1 starttls=1 commands=2

I thought that these errors were the result of a misconfigured
certificate or private key for the postfix service.  However, I have
examined these and they appear to be correct:

postconf -n | grep -i tls
smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC5
smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom


# ll /usr/local/etc/pki/tls/private/
total 18
-rw-------  1 root  wheel  3243 Jun  7 15:37 2016003E.key
lrwxr-xr-x  1 root  wheel    12 Jul 10 12:19 ca.harte-lyne.mx31.key ->
2016003E.key

ll /usr/local/etc/pki/tls/certs
total 565
-rw-r--r--  1 root  wheel   10164 Jun  7 15:37 2016003E.pem
-rw-r--r--  1 root  wheel  822512 Jul 10 12:05 ca-bundle.crt
lrwxr-xr-x  1 root  wheel      22 Jul 10 12:07 ca.harte-lyne.mx31.crt
-> ca.harte-lyne.mx31.pem
lrwxr-xr-x  1 root  wheel      12 Jul 10 12:06 ca.harte-lyne.mx31.pem
-> 2016003E.pem

# openssl x509 -noout -text -in
/usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 538312766 (0x2016003e)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: CN=CA_HLL_ISSUER_2016, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=harte-lyne, DC=ca
        Validity
            Not Before: Jun  1 00:00:00 2018 GMT
            Not After : Jun 30 23:59:59 2023 GMT
        Subject: CN=mx31.harte-lyne.ca, OU=Networked Data Services,
O=Harte & Lyne Limited, L=Hamilton, ST=Ontario, C=CA,
DC=hamilton, DC=harte-lyne, DC=ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
. . .

Can someone interpret for me what these messages are telling me?  Is
samba.org misconfigured or me?


--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.harte-lyne.ca&amp;data=02%7C01%7Cangelo.fazzina%40uconn.edu%7C6922a5cc8abd4ad2f16608d5e6863894%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636668386513643202&amp;sdata=uwMebM%2BjRmEqZjkTTbuMggiZED7kKeYUaf8iX7dH32Q%3D&amp;reserved=0
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS / DANE difficulties?

Viktor Dukhovni
In reply to this post by James B. Byrne
On Tue, Jul 10, 2018 at 12:55:38PM -0400, James B. Byrne wrote:

> We are migrating our Postfix MX services and in the process have
> disrupted a setup which has been very stable for the past couple of
> years.  One of the remaining items is this sort of message which only
> started very recently:

What is the MX hostname associated with this Postfix instance?  What
domains does it serve?  That has bearing on the TLSA records seen
by the connecting SMTP client.

> Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library
>   problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad
>   certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert number > 42:

The client rejected the server's certificate chain.  The details
are known only to the client.

> I thought that these errors were the result of a misconfigured
> certificate or private key for the postfix service.  However, I have
> examined these and they appear to be correct:

"Correct" is in the eye of the beholder.  Did the certificate chain
match the associated DANE TLSA records?  Might samba.org have reason
to expect to authenticate your server via WebPKI?  You're using a
private CA...

>         CN=mx31.harte-lyne.ca

Its current cert chain seems to match the TLSA records for the above
name, though two of the three TLSA records seem redundant:

    mx31.harte-lyne.ca. IN A 216.185.71.31 ; AD=1 NoError
    mx31.harte-lyne.ca. IN AAAA ? ; AD=1 NODATA
    _25._tcp.mx31.harte-lyne.ca. IN CNAME _tlsa._dane.trust.harte-lyne.ca. ; AD=1 NoError
    _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 0 2 67274b355428905895c6b581950e0ed4f7d043f31f7e7020b716b7faa06776b6aadd33e127624b6e8c75c520a01d9cad3bd29f18fa7dcb3d5fd3917510e6722a ; AD=1 NoError
    _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 1 2 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c589b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f ; AD=1 NoError
    _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 1 2 c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e ; AD=1 NoError
      mx31.harte-lyne.ca[216.185.71.31]: pass: TLSA match: depth = 1, name = mx31.harte-lyne.ca
        TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
        name = mx31.harte-lyne.ca
        name = mx31
        name = mx31.hamilton
        name = mx31.hamilton.harte-lyne.ca
        depth = 0
          Issuer CommonName = CA_HLL_ISSUER_2016
          Issuer Organization = Harte & Lyne Limited
          notBefore = 2018-06-01T00:00:00Z
          notAfter = 2023-06-30T23:59:59Z
          Subject CommonName = mx31.harte-lyne.ca
          Subject Organization = Harte & Lyne Limited
          pkey sha256 [nomatch] <- 3 1 1 3fa3dae08e2fecff0611a75767ee0995a115e308a181ad79a6d163315742b270
          cert sha512 [nomatch] <- 3 0 2 cc5bd085ba7e1c136539083bf32ad6512b6c0fe5a31a8f2f775b627ab1c6525d7464c751191a4e1747072f5bd63d364713e48a4636ca25e31532ca0657444c7f
          pkey sha512 [nomatch] <- 3 1 2 39248e9342c4fc8fb67dac3f51e7a2d9e77d7a37df6fac0272006cc7d757e5346c9e11f93f7f8c34cacf95cd0e60d1ab5b3fc2b9881551fa9bc9a6fb6e3300a8
        depth = 1
          Issuer CommonName = CA_HLL_ROOT_2016
          Issuer Organization = Harte & Lyne Limited
          notBefore = 2016-11-01T00:00:00Z
          notAfter = 2035-11-01T23:59:59Z
          Subject CommonName = CA_HLL_ISSUER_2016
          Subject Organization = Harte & Lyne Limited
          pkey sha256 [nomatch] <- 2 1 1 9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
          cert sha512 [nomatch] <- 2 0 2 ab23a715c42f6cf8a2502b725969adedf1f6c6bedbb483fb49badc5470232297b34a3a7716b2dd7eb086bd6e462599db95f9af3415209eadea71450c72af942a
          pkey sha512 [matched] <- 2 1 2 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c589b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f
        depth = 2
          Issuer CommonName = CA_HLL_ROOT_2016
          Issuer Organization = Harte & Lyne Limited
          notBefore = 2016-11-01T00:00:00Z
          notAfter = 2036-10-31T23:59:59Z
          Subject CommonName = CA_HLL_ROOT_2016
          Subject Organization = Harte & Lyne Limited
          pkey sha256 [nomatch] <- 2 1 1 4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4
          cert sha512 [nomatch] <- 2 0 2 4a4ea8374f20e46009b03bd19793598b5f4e0d38aeba39644f6b8659057ca16a4c5bfd7f3779ec83c1d26c732edbc9d41454f9866d25109bcde177eae58a4481
          pkey sha512 [matched] <- 2 1 2 c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e

[ 4096-bit keys are IMHO overkill. ]

--
        Viktor.

chain.pem (29K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS / DANE difficulties?

James B. Byrne

On Tue, July 10, 2018 13:30, Viktor Dukhovni wrote:

> On Tue, Jul 10, 2018 at 12:55:38PM -0400, James B. Byrne wrote:
>
>> We are migrating our Postfix MX services and in the process have
>> disrupted a setup which has been very stable for the past couple of
>> years.  One of the remaining items is this sort of message which
>> only started very recently:
>
> What is the MX hostname associated with this Postfix instance?  What
> domains does it serve?  That has bearing on the TLSA records seen
> by the connecting SMTP client.

mx31.harte-lyne.ca - harte-lyne.ca / .harte-lyne.ca

>
>> Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library
>>   problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert
>> bad
>>   certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert
>> number > 42:
>
> The client rejected the server's certificate chain.  The details
> are known only to the client.
>
>> I thought that these errors were the result of a misconfigured
>> certificate or private key for the postfix service.  However, I have
>> examined these and they appear to be correct:
>
> "Correct" is in the eye of the beholder.  Did the certificate chain
> match the associated DANE TLSA records?  Might samba.org have reason
> to expect to authenticate your server via WebPKI?  You're using a
> private CA...
>
>>         CN=mx31.harte-lyne.ca

https://dane-test.had.dnsops.gov/server/dane_check.cgi?host=harte-lyne.ca
ere[prts that all declared servers, other than those currently
off-line, are error free.

>
> Its current cert chain seems to match the TLSA records for the above
> name, though two of the three TLSA records seem redundant:
>
>     mx31.harte-lyne.ca. IN A 216.185.71.31 ; AD=1 NoError
>     mx31.harte-lyne.ca. IN AAAA ? ; AD=1 NODATA
>     _25._tcp.mx31.harte-lyne.ca. IN CNAME
> _tlsa._dane.trust.harte-lyne.ca. ; AD=1 NoError
>     _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 0 2
> 67274b355428905895c6b581950e0ed4f7d043f31f7e7020b716b7faa06776b6aadd33e127624b6e8c75c520a01d9cad3bd29f18fa7dcb3d5fd3917510e6722a
> ; AD=1 NoError
>     _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 1 2
> 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c589b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f
> ; AD=1 NoError
>     _tlsa._dane.trust.harte-lyne.ca. IN TLSA 2 1 2
> c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e
> ; AD=1 NoError
>       mx31.harte-lyne.ca[216.185.71.31]: pass: TLSA match: depth = 1,
> name = mx31.harte-lyne.ca
> TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
> name = mx31.harte-lyne.ca
> name = mx31
> name = mx31.hamilton
> name = mx31.hamilton.harte-lyne.ca
> depth = 0
>  Issuer CommonName = CA_HLL_ISSUER_2016
>  Issuer Organization = Harte & Lyne Limited
>  notBefore = 2018-06-01T00:00:00Z
>  notAfter = 2023-06-30T23:59:59Z
>  Subject CommonName = mx31.harte-lyne.ca
>  Subject Organization = Harte & Lyne Limited
>  pkey sha256 [nomatch] <- 3 1 1
> 3fa3dae08e2fecff0611a75767ee0995a115e308a181ad79a6d163315742b270
>  cert sha512 [nomatch] <- 3 0 2
> cc5bd085ba7e1c136539083bf32ad6512b6c0fe5a31a8f2f775b627ab1c6525d7464c751191a4e1747072f5bd63d364713e48a4636ca25e31532ca0657444c7f
>  pkey sha512 [nomatch] <- 3 1 2
> 39248e9342c4fc8fb67dac3f51e7a2d9e77d7a37df6fac0272006cc7d757e5346c9e11f93f7f8c34cacf95cd0e60d1ab5b3fc2b9881551fa9bc9a6fb6e3300a8
> depth = 1
>  Issuer CommonName = CA_HLL_ROOT_2016
>  Issuer Organization = Harte & Lyne Limited
>  notBefore = 2016-11-01T00:00:00Z
>  notAfter = 2035-11-01T23:59:59Z
>  Subject CommonName = CA_HLL_ISSUER_2016
>  Subject Organization = Harte & Lyne Limited
>  pkey sha256 [nomatch] <- 2 1 1
> 9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
>  cert sha512 [nomatch] <- 2 0 2
> ab23a715c42f6cf8a2502b725969adedf1f6c6bedbb483fb49badc5470232297b34a3a7716b2dd7eb086bd6e462599db95f9af3415209eadea71450c72af942a
>  pkey sha512 [matched] <- 2 1 2
> 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c589b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f
> depth = 2
>  Issuer CommonName = CA_HLL_ROOT_2016
>  Issuer Organization = Harte & Lyne Limited
>  notBefore = 2016-11-01T00:00:00Z
>  notAfter = 2036-10-31T23:59:59Z
>  Subject CommonName = CA_HLL_ROOT_2016
>  Subject Organization = Harte & Lyne Limited
>  pkey sha256 [nomatch] <- 2 1 1
> 4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4
>  cert sha512 [nomatch] <- 2 0 2
> 4a4ea8374f20e46009b03bd19793598b5f4e0d38aeba39644f6b8659057ca16a4c5bfd7f3779ec83c1d26c732edbc9d41454f9866d25109bcde177eae58a4481
>  pkey sha512 [matched] <- 2 1 2
> c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e
>
> [ 4096-bit keys are IMHO overkill. ]
>

Having recently replaced our entire PKI because of Mozilla determining
our root certificate had an inadequate key size (selected back in
2005) I decided overkill is not thorough enough, but perforce
suffices.  That is also why we have two separate roots and certificate
chains, which will continue until the last of the original CA's
certificates are replaced or the services shutdown.

--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

RE: STARTTLS / DANE difficulties?

James B. Byrne
In reply to this post by Fazzina, Angelo

On Tue, July 10, 2018 13:05, Fazzina, Angelo wrote:

> When you test connecting to your servers yourself do you get any
> errors ?
> Not sure if sslv3 is ok to see if using TLS ???
>
> Commands to try, just replace with your server name
> openssl s_client  -connect mta5.uits.uconn.edu:465
> openssl s_client -starttls smtp -connect mta5.uits.uconn.edu:587
>
> openssl s_client  -connect <yourname>:465
> openssl s_client -starttls smtp -connect <yourname>:587
>


I can connect to my services without difficulty:

# openssl s_client -starttls smtp -connect mx31.harte-lyne.ca:587
CONNECTED(00000003)
depth=2 CN = CA_HLL_ROOT_2016, ST = Ontario, O = Harte & Lyne Limited,
OU = Networked Data Services, C = CA, DC = harte-lyne, DC = ca, L =
Hamilton
verify return:1
depth=1 CN = CA_HLL_ISSUER_2016, OU = Networked Data Services, O =
Harte & Lyne Limited, L = Hamilton, ST = Ontario, C = CA, DC =
harte-lyne, DC = ca
verify return:1
depth=0 CN = mx31.harte-lyne.ca, OU = Networked Data Services, O =
Harte & Lyne Limited, L = Hamilton, ST = Ontario, C = CA, DC =
hamilton, DC = harte-lyne, DC = ca
verify return:1
---
Certificate chain
 0 s:/CN=mx31.harte-lyne.ca/OU=Networked Data Services/O=Harte & Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=hamilton/DC=harte-lyne/DC=ca
   i:/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte & Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca
 1 s:/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte & Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca
   i:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne
Limited/OU=Networked Data
Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton
 2 s:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne
Limited/OU=Networked Data
Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton
   i:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne
Limited/OU=Networked Data
Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIJnDCCB4SgAwIBAgIEIBYAPjANBgkqhkiG9w0BAQ0FADCBwDEbMBkGA1UEAxQS
. . .
-----END CERTIFICATE-----
subject=/CN=mx31.harte-lyne.ca/OU=Networked Data Services/O=Harte &
Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=hamilton/DC=harte-lyne/DC=ca
issuer=/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte &
Lyne Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca
---
Acceptable client certificate CA names
. . .
/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte & Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca
/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne Limited/OU=Networked
Data Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton
/CN=CA HLL ISSUER 01/OU=Networked Data Services/O=Harte & Lyne
Limited/C=CA/ST=Ontario/L=Hamilton/DC=harte-lyne.ca
/CN=CA HLL ROOT/OU=Networked Data Services/O=Harte & Lyne
Limited/C=CA/ST=Ontario/L=Hamilton/DC=harte-lyne.ca
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 25642 bytes and written 480 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID:
050E0927F6972668834B7CF1128CD09652D2E3A0771F54D01506765C7007C0E9
    Session-ID-ctx:
    Master-Key:
EF2B819F9492D5C8B8E4728907EF383CC59404A2A935A654A7995D6863A9887BA0CF348D3253CBE154792D24EAC11C23
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 96 a3 78 b8 f9 08 0d d8-d6 d1 67 0a 25 dd 69 fb . . .

    Start Time: 1531246713
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
250 SMTPUTF8
QUIT
DONE



[root@inet18 ~]# openssl s_client -starttls smtp -connect
mx32.harte-lyne.ca:587
CONNECTED(00000003)
depth=2 CN = CA_HLL_ROOT_2016, ST = Ontario, O = Harte & Lyne Limited,
OU = Networked Data Services, C = CA, DC = harte-lyne, DC = ca, L =
Hamilton
verify return:1
depth=1 CN = CA_HLL_ISSUER_2016, OU = Networked Data Services, O =
Harte & Lyne Limited, L = Hamilton, ST = Ontario, C = CA, DC =
harte-lyne, DC = ca
verify return:1
depth=0 CN = mx32.harte-lyne.ca, OU = Networked Data Systems, O =
Harte & Lyne Limited, L = Hamilton, ST = Ontario, C = CA, DC =
hamilton, DC = harte-lyne, DC = ca
verify return:1
---
Certificate chain
 0 s:/CN=mx32.harte-lyne.ca/OU=Networked Data Systems/O=Harte & Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=hamilton/DC=harte-lyne/DC=ca
   i:/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte & Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca
 1 s:/CN=CA_HLL_ISSUER_2016/OU=Networked Data Services/O=Harte & Lyne
Limited/L=Hamilton/ST=Ontario/C=CA/DC=harte-lyne/DC=ca
   i:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne
Limited/OU=Networked Data
Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton
 2 s:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne
Limited/OU=Networked Data
Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton
   i:/CN=CA_HLL_ROOT_2016/ST=Ontario/O=Harte & Lyne
Limited/OU=Networked Data
Services/C=CA/DC=harte-lyne/DC=ca/L=Hamilton
---
Server certificate
-----BEGIN CERTIFICATE-----
. . .

    Start Time: 1531246902
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
250 SMTPUTF8
QUIT
DONE

--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS / DANE difficulties?

Viktor Dukhovni
In reply to this post by James B. Byrne
On Tue, Jul 10, 2018 at 02:26:05PM -0400, James B. Byrne wrote:

> > What is the MX hostname associated with this Postfix instance?  What
> > domains does it serve?  That has bearing on the TLSA records seen
> > by the connecting SMTP client.
>
> mx31.harte-lyne.ca - harte-lyne.ca / .harte-lyne.ca

If that's the only hostname resolving to that IP address, then its
DANE TLSA records do appear to be presently correct.  Can't speak
about the past if the machine was undergoing maintenance.

> >> Jul 10 11:55:30 mx31 postfix-p25/smtpd[70030]: warning: TLS library
> >>   problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad
> >>   certificate:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert number 42:
> >
> > The client rejected the server's certificate chain.  The details
> > are known only to the client.

The connecting client did not like one of the certificates in the
chain.  Perhaps it expected to find working a WebPKI certificate
from one of the usual suspects ("browser bundle" public root CAs).

You should ask the postmaster of the sending domain?  Is the problem
ongoing?  Or a transient glitch?

> > [ 4096-bit keys are IMHO overkill. ]
>
> Having recently replaced our entire PKI because of Mozilla determining
> our root certificate had an inadequate key size (selected back in
> 2005) I decided overkill is not thorough enough, but perforce
> suffices.  That is also why we have two separate roots and certificate
> chains, which will continue until the last of the original CA's
> certificates are replaced or the services shutdown.

There are interoperability advantages to being in the middle of the
pack, some implementations might have restricted key sizes.  The
most popular key size is RSA-2048.  There isn't much evidence that
this is the issue, so use this suggestion as you see fit.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS / DANE difficulties?

James B. Byrne

On Tue, July 10, 2018 20:35, Viktor Dukhovni wrote:
>
> The connecting client did not like one of the certificates in the
> chain.  Perhaps it expected to find working a WebPKI certificate
> from one of the usual suspects ("browser bundle" public root CAs).
>
> You should ask the postmaster of the sending domain?  Is the problem
> ongoing?  Or a transient glitch?
>

It is an ongoing problem with delivery to us of the samba-users
mailing list digest, of which I am a subscriber.

I am in communication with the person directly responsible for
implementing DANE at that site.  They have just implemented DANE which
is when the problems first started.

As we use 'smtp_tls_security_level = dane' and as they are missing a
number of TLSA RRs their problem with us may be an incomplete
implementation.  I have referred them to:
https://dane-test.had.dnsops.gov/server/dane_check.cgi?host=hr1.samba.org.
We will see if any changes result.

Thank you for your help, as always.

Regards,


--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS / DANE difficulties?

Viktor Dukhovni
On Wed, Jul 11, 2018 at 10:13:48AM -0400, James B. Byrne wrote:

> > The connecting client did not like one of the certificates in the
> > chain.  Perhaps it expected to find a working WebPKI certificate
> > from one of the usual suspects ("browser bundle" public root CAs).
> >
> > You should ask the postmaster of the sending domain?  Is the problem
> > ongoing?  Or a transient glitch?
>
> It is an ongoing problem with delivery to us of the samba-users
> mailing list digest, of which I am a subscriber.

Any logs they're willing to share would likely be enlightening.

> I am in communication with the person directly responsible for
> implementing DANE at that site.  They have just implemented DANE which
> is when the problems first started.

Do you know which MTA they're using?

> As we use 'smtp_tls_security_level = dane'

Your outbound use of DANE when sending email to them has no bearing
on difficulties with their outbound use of DANE when sending email to
you.

> and as they are missing a number of TLSA RRs

What does that mean???

> their problem with us may be an incomplete implementation.

Do they support certificate usage DANE-TA(2)?  Perhaps their MTA
only supports DANE-EE(3) and chokes on DANE-TA(2).  You could publish
both "3 1 1" and "2 1 1" TLSA records for each MX host, and see if
that resolves the issue.

    ; TLSA RRs matching the EE key, intermediate CA key and root CA key, respectively
    ; Just the EE and intermediate should be enough.
    ;
    _25._tcp.mx32.harte-lyne.ca. IN TLSA 3 1 1 9d111285068fd3e814269b472b75e46a2700f8655989e8c0007e33881ad09733
    _25._tcp.mx32.harte-lyne.ca. IN TLSA 2 1 1 9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
    _25._tcp.mx32.harte-lyne.ca. IN TLSA 2 1 1 4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4

    _25._tcp.inet08.hamilton.harte-lyne.ca. IN TLSA 3 1 1 478dbe42903020004738f55fc767c6c2ed5cf5b9e7d256b797bd305e84d03a55
    _25._tcp.inet08.hamilton.harte-lyne.ca. IN TLSA 2 1 1 9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
    _25._tcp.inet08.hamilton.harte-lyne.ca. IN TLSA 2 1 1 4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4

    _25._tcp.mx31.harte-lyne.ca. IN TLSA 3 1 1 3fa3dae08e2fecff0611a75767ee0995a115e308a181ad79a6d163315742b270
    _25._tcp.mx31.harte-lyne.ca. IN TLSA 2 1 1 9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
    _25._tcp.mx31.harte-lyne.ca. IN TLSA 2 1 1 4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4

    ... remaining MX hosts ...

If it does, the Samba list should disable DANE support until their
implementation is less crippled.  It needs to either not enforce
DANE for MX hosts with just DANE-TA(2) records, or properly support
DANE-TA(2) records.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS / DANE difficulties?

James B. Byrne
On Wed, July 11, 2018 11:12, Viktor Dukhovni wrote:

> On Wed, Jul 11, 2018 at 10:13:48AM -0400, James B. Byrne wrote:
>
>> > The connecting client did not like one of the certificates in the
>> > chain.  Perhaps it expected to find a working WebPKI certificate
>> > from one of the usual suspects ("browser bundle" public root CAs).
>> >
>> > You should ask the postmaster of the sending domain?
>> > Is the problem ongoing?  Or a transient glitch?
>>
>> It is an ongoing problem with delivery to us of the samba-users
>> mailing list digest, of which I am a subscriber.
>
> Any logs they're willing to share would likely be enlightening.
>

I will ask.

>> I am in communication with the person directly responsible for
>> implementing DANE at that site.  They have just implemented DANE
>> which is when the problems first started.
>
> Do you know which MTA they're using?
>

NMAP reports: Exim smtpd 4.91

>
>> and as they are missing a number of TLSA RRs
>
> What does that mean???
>

When I run a DANE test against the domain that is failing to connect
this is among the results:

Test # Host IP Status Test Description (§ Section)

103 hr1.samba.org FAILED Service hostname must have matching TLSA record
Resolving TLSA records for hostname '_25._tcp.hr1.samba.org'

403 hr1.samba.org FAILED All IP addresses for a host that is TLSA
protected must TLSA verify
Validating TLSA records for 0 out of 1 IP addresses found for host
hr1.samba.org

>> their problem with us may be an incomplete implementation.
>
> Do they support certificate usage DANE-TA(2)?  Perhaps their MTA
> only supports DANE-EE(3) and chokes on DANE-TA(2).  You could publish
> both "3 1 1" and "2 1 1" TLSA records for each MX host, and see if
> that resolves the issue.

I will attempt that as soon as I finish the movement of our MX
services off their current hosts and onto the new.

>
> If it does, the Samba list should disable DANE support until their
> implementation is less crippled.  It needs to either not enforce
> DANE for MX hosts with just DANE-TA(2) records, or properly support
> DANE-TA(2) records.
>

Ah.  Well, I know how welcome the news that 'one is doing something so
wrong that one should just stop doing it' can be.  I would rather
avoid the natural antagonism such advice is likely to engender.
Instead I have provided them a few clues as to where some obvious
problems lie and left it to their judgement as to how to proceed.
Eventually they will either sort out their troubles or arrive at the
same conclusion.

My concern in this is to assure myself that our services are running
correctly.  If they are and the difficulties all lie with samba.org
then can live without the mailing list digest for now.

--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS / DANE difficulties?

Viktor Dukhovni
On Wed, Jul 11, 2018 at 02:13:46PM -0400, James B. Byrne wrote:

> > Any logs they're willing to share would likely be enlightening.
>
> I will ask.

Please do, and ask for permission to post the results here or with
me off-list, but I would also need permission to share the logs
with the Exim developers, ideally on the exim-dev or exim-users
lists, so on-list would be best.

> > Do you know which MTA they're using?
>
> NMAP reports: Exim smtpd 4.91

Exim linked with OpenSSL is believed to handle DANE reasonably
correctly.  Exim linked with GnuTLS is known to exhibit some warts.
In a recent TLS WG discussion Phil Pennock (one of the Exim developers,
with an apparent focus on DANE) wrote in response to me:

    > For example, I recently learned that current GnuTLS
    > versions by default no longer validate certificates with SHA-1
    > issuer signatures, and that current versions of Exim linked with
    > these GnuTLS releases fail to validate some DANE-TA(2) chains issued
    > by private-CAs that still use SHA-1.

    That's fine by me.  Linking against GnuTLS has long had implications for
    mail delivery.  It blocked SSLv3 at a time when SSLv3 was still fairly
    widespread in corporate circles (Exchange).  Folks who care about TLS
    interop for real mail-systems use OpenSSL.

It would be good to know which flavour of Exim they have.  You don't
appear to be using SHA-1, indeed I see SHA512.  So if the issue is
with GnuTLS, it is not the SHA-1 issue.

> When I run a DANE test against the domain that is failing to connect
> this is among the results:

That has no bearin on traffic from them to you.

> > Do they support certificate usage DANE-TA(2)?  Perhaps their MTA
> > only supports DANE-EE(3) and chokes on DANE-TA(2).  You could publish
> > both "3 1 1" and "2 1 1" TLSA records for each MX host, and see if
> > that resolves the issue.
>
> I will attempt that as soon as I finish the movement of our MX
> services off their current hosts and onto the new.

Exim should have working DANE-TA(2) support, when linked with
OpenSSL, in is doing DANE X.509 verification via code I contributed
that is based on the original implementation of DANE in Postfix.
When linked with GnuTLS is it using the GnuTLS DANE implementation,
whose issues may not as yet have all been uncovered.

> > If it does, the Samba list should disable DANE support until their
> > implementation is less crippled.  It needs to either not enforce
> > DANE for MX hosts with just DANE-TA(2) records, or properly support
> > DANE-TA(2) records.
>
> Ah.  Well, I know how welcome the news that 'one is doing something so
> wrong that one should just stop doing it' can be.  I would rather
> avoid the natural antagonism such advice is likely to engender.

There are ways of communicating the message that their MTA's DANE
support is not ready for prime-time that will be gratefully accepted
(thanks for letting us know).

> My concern in this is to assure myself that our services are running
> correctly.  If they are and the difficulties all lie with samba.org
> then can live without the mailing list digest for now.

I've not found any issues on your side.

--
        Viktor.