From dennis at baaten.com Wed Sep 2 08:35:33 2020 From: dennis at baaten.com (Dennis Baaten) Date: Wed, 2 Sep 2020 08:35:33 +0200 Subject: DANE for Sendmail Message-ID: <022001d680f3$42e8ce50$c8ba6af0$@baaten.com> Initial support for DANE validation has landed in Sendmail: ftp://ftp.sendmail.org/pub/sendmail (or mirror https://ftp.bit.nl/mirror/sendmail/RELEASE_NOTES ). "Only TLSA RR 3-1-x is currently implemented." For other DANE supporting software & services check: https://github.com/baknu/DANE-for-SMTP/wiki/3.-Software-and-service-support Regards, Dennis on behalf of Internet.nl From ietf-dane at dukhovni.org Mon Sep 21 08:22:08 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 21 Sep 2020 04:22:08 -0200 Subject: PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates Message-ID: Please note that the Let's Encrypt intermediate CA certificate "X3" will soon be phased out in favour of "R3" and "E1" which have new keys, and so any DANE TLSA "2 1 1" records matching "X3" will not match "R3" or "E1". https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html If you are using Let's Encrypt with DANE-TA(2) [issuer CA] TLSA records, any extant "2 1 1" records need to be augmented soon with additional records matching the new "R3" and "E1", in advance of these reissuing your certificates. Failure to act in time is likely to result in an outage once renewals switch to signing via "R3" or "E1". Links to the actual certificates can be found at: https://letsencrypt.org/certificates/ https://letsencrypt.org/certs/lets-encrypt-r3.pem https://letsencrypt.org/certs/lets-encrypt-e1.pem The "2 1 1" digests of "R3" and "E1" are (but don't take my word for it, re-compute these for yourself): ; $ tlsagen lets-encrypt-r3.pem smtp.example.org 2 1 1 ; _25._tcp.smtp.example.org. IN TLSA 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D ; $ tlsagen lets-encrypt-e1.pem smtp.example.org 2 1 1 ; _25._tcp.smtp.example.org. IN TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10 The above were computed with the attached "tlsagen" script, but it is prudent to also check with tools from other sources, this email message could well have been a forgery (I hope your copy matches what I sent). -- Viktor. -------------- next part -------------- A non-text attachment was scrubbed... Name: tlsagen Type: application/octet-stream Size: 1598 bytes Desc: not available URL: From ietf-dane at dukhovni.org Mon Sep 21 09:50:32 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 21 Sep 2020 03:50:32 -0400 Subject: PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates In-Reply-To: References: Message-ID: <20200921075032.GQ64864@straasha.imrryr.org> On Mon, Sep 21, 2020 at 04:22:08AM -0200, Viktor Dukhovni wrote: > Links to the actual certificates can be found at: > > https://letsencrypt.org/certificates/ > https://letsencrypt.org/certs/lets-encrypt-r3.pem > https://letsencrypt.org/certs/lets-encrypt-e1.pem > > The "2 1 1" digests of "R3" and "E1" are (but don't take my word for it, > re-compute these for yourself): > > ; $ tlsagen lets-encrypt-r3.pem smtp.example.org 2 1 1 > ; > _25._tcp.smtp.example.org. IN TLSA 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D > > ; $ tlsagen lets-encrypt-e1.pem smtp.example.org 2 1 1 > ; > _25._tcp.smtp.example.org. IN TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10 It was correclty noted in: https://community.letsencrypt.org/t/dane-and-upcoming-le-issuer-certs/134172/2?u=ietf-dane that the "backup" CAs should also be listed, as LE might need to switch to using them in an emergency without prior notice. Therefore the full list of DANE-TA(2) digests to publish (when relying on these rather than "3 1 1" records) is: ; (These can be retired soon, but not just yet) ; ; letsencryptauthorityx3.pem ; letsencryptauthorityx4.pem ; _25._tcp.smtp.example.org. IN TLSA 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517616E8A18 _25._tcp.smtp.example.org. IN TLSA 2 1 1 B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E02CF362B ; (May not be needed if your leaf cert is RSA, ECDSA certs ; will I expect be soon signed with one of these). ; ; lets-encrypt-e1.pem ; lets-encrypt-e2.pem ; _25._tcp.smtp.example.org. IN TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10 _25._tcp.smtp.example.org. IN TLSA 2 1 1 BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270 ; (May not be needed if your leaf cert is ECDSA, once ; ECDSA certificate issuance cuts over to e1/e2). ; ; lets-encrypt-r3.pem ; lets-encrypt-r4.pem -- Viktor. From stse+dane at rootsland.net Wed Sep 23 14:23:04 2020 From: stse+dane at rootsland.net (Stephan Seitz) Date: Wed, 23 Sep 2020 14:23:04 +0200 Subject: check_dane and dnspython 2.0.0 Message-ID: <20200923T141811.blubb.419ee.stse@fsing.rootsland.net> Hello! I?m using check_dane (https://github.com/debfx/check_dane) together with Debian/testing. Since the upgrade of python3-dnspython to version 2.0.0, I?m getting deprecation warnings: check_dane:105: DeprecationWarning: please use dns.resolver.Resolver.resolve() instead tlsa_records = resolver.query(tlsa_domain, dns.rdatatype.TLSA) I?m afraid I was unable to fix the warning but I don?t realy speak python. So is anyone working on an upgrade? Shade and sweet water! Stephan -- | If your life was a horse, you'd have to shoot it. | From sys4 at arcsin.de Wed Sep 23 14:34:05 2020 From: sys4 at arcsin.de (Damian) Date: Wed, 23 Sep 2020 14:34:05 +0200 Subject: check_dane and dnspython 2.0.0 In-Reply-To: <20200923T141811.blubb.419ee.stse@fsing.rootsland.net> References: <20200923T141811.blubb.419ee.stse@fsing.rootsland.net> Message-ID: <6130cc05-c9da-991f-a9fb-9cfe75762531@arcsin.de> You could just open an issue on github. > I?m afraid I was unable to fix the warning but I don?t realy speak > python. From stse+dane at rootsland.net Thu Sep 24 10:15:57 2020 From: stse+dane at rootsland.net (Stephan Seitz) Date: Thu, 24 Sep 2020 10:15:57 +0200 Subject: check_dane and dnspython 2.0.0 In-Reply-To: <6130cc05-c9da-991f-a9fb-9cfe75762531@arcsin.de> References: <20200923T141811.blubb.419ee.stse@fsing.rootsland.net> <6130cc05-c9da-991f-a9fb-9cfe75762531@arcsin.de> Message-ID: <20200924T101021.blubb.c013b.stse@fsing.rootsland.net> On Mi, Sep 23, 2020 at 14:34:05 +0200, Damian wrote: >You could just open an issue on github. Yes, but I don?t have a github account, and I won?t create one only for a bug report/feature request (one of the reasons I like Debian: bugs can be reported by mail). There are no mail addresses in the files either. So I?m trying this list, maybe they are reading it. Shade and sweet water! Stephan -- | If your life was a horse, you'd have to shoot it. | From dane-users at fl1ger.de Thu Sep 24 11:13:27 2020 From: dane-users at fl1ger.de (Ralf Weber) Date: Thu, 24 Sep 2020 11:13:27 +0200 Subject: check_dane and dnspython 2.0.0 In-Reply-To: <20200924T101021.blubb.c013b.stse@fsing.rootsland.net> References: <20200923T141811.blubb.419ee.stse@fsing.rootsland.net> <6130cc05-c9da-991f-a9fb-9cfe75762531@arcsin.de> <20200924T101021.blubb.c013b.stse@fsing.rootsland.net> Message-ID: <903F4113-3B97-4A65-92CB-86A02D917155@fl1ger.de> Moin! On 24 Sep 2020, at 10:15, Stephan Seitz wrote: > On Mi, Sep 23, 2020 at 14:34:05 +0200, Damian wrote: >> You could just open an issue on github. > > Yes, but I don?t have a github account, and I won?t create one > only for a bug report/feature request (one of the reasons I like > Debian: bugs can be reported by mail). > > There are no mail addresses in the files either. So I?m trying this > list, maybe they are reading it. Not sure, but it?s literally a one line change (two if you count the README.md). As I have a GitHub account I?ve created pull request and until they merge that you can get the code that throws no warning from my fork ( https://github.com/fl1ger/check_dane ). So long -Ralf ??- Ralf Weber From ietf-dane at dukhovni.org Fri Sep 25 00:08:08 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 24 Sep 2020 18:08:08 -0400 Subject: PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates In-Reply-To: <62d0cafd-ed95-b504-d651-2e2e7376c496@samba.org> <20200921075032.GQ64864@straasha.imrryr.org> Message-ID: <20200924220808.GJ64864@straasha.imrryr.org> On Mon, Sep 21, 2020 at 03:50:32AM -0400, Viktor Dukhovni wrote: > Therefore the full list of DANE-TA(2) digests to publish (when relying > on these rather than "3 1 1" records) is: > > ; (These can be retired soon, but not just yet) > ; > ; letsencryptauthorityx3.pem > ; letsencryptauthorityx4.pem > ; > _25._tcp.smtp.example.org. IN TLSA 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517616E8A18 > _25._tcp.smtp.example.org. IN TLSA 2 1 1 B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E02CF362B > > ; (May not be needed if your leaf cert is RSA, ECDSA certs > ; will I expect be soon signed with one of these). > ; > ; lets-encrypt-e1.pem > ; lets-encrypt-e2.pem > ; > _25._tcp.smtp.example.org. IN TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10 > _25._tcp.smtp.example.org. IN TLSA 2 1 1 BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270 > > ; (May not be needed if your leaf cert is ECDSA, once > ; ECDSA certificate issuance cuts over to e1/e2). > ; > ; lets-encrypt-r3.pem > ; lets-encrypt-r4.pem It seems I failed to paste in the "r3/r4" hashes (which of course you should not take only from my messages, but check against a trusted source). That said, the missing hashes are: _25._tcp.smtp.example.com. IN TLSA 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D _25._tcp.smtp.example.com. IN TLSA 2 1 1 E5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77990F2D03 On Thu, Sep 24, 2020 at 11:48:23PM +0200, Bj?rn Jacke wrote: > your follow up mail on this topic is a bit confusing because you quote > the two *upcoming* E1/E2 cert hashes but the 2 *current* X3/X4 and not > the also the *upcoming* R3/R4 hashes here. Thanks for noticing. In case you want all the values, here's the bit of PostgreSQL I use to count usage of these in DANE survey TLSA records, this finds the hashes for all the combinations of selector (Cert(0) and SPKI(1)) and hashed matching type (SHA2-256(1) and SHA2-512(2)): WITH le(n, issuer, s, m, ihash) as ( VALUES ( 1, 'X3', 1, 1, '\x60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517616E8A18' :: bytea), ( 1, 'X3', 1, 2, '\x774FAD8C9A6AFC2BDB44FABA8390D213AE592FB0D56C5DFAB152284E334D7CD6ABD05799236E7AA6266EDF81907C60404C57EE54C10A3A82FCC2A9146629B140' ), ( 1, 'X3', 0, 1, '\x731D3D9CFAA061487A1D71445A42F67DF0AFCA2A6C2D2F98FF7B3CE112B1F568' ), ( 1, 'X3', 0, 2, '\x5EC5B0783C6E667E0965DF772943A06326768DE0F75DC0BD2FE378F02CCCA7D56C987656174CBE158CC29ECD763F8BDA3454332CC7D47FB934691409C5FB8686' ), ( 2, 'X4', 1, 1, '\xB111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E02CF362B' ), ( 2, 'X4', 1, 2, '\xA0F5D1333BC90BCEA0B0B5F401160B6E7F28A1256BC5B5D65F04B06B0BB0C96270AA81D8E2726394D385BF3E9EE46EB4AB7548C782D5688CC16D0CDFFEFB8594' ), ( 2, 'X4', 0, 1, '\x5DE9152BED31FA0515DD1FC746133F1327562EF72A84CF2D2403E748A604D0D4' ), ( 2, 'X4', 0, 2, '\x74DDAD9F8CDFA0FE6F6B70301B557A63A58B87FC2C17FAE0F65E47D141226C062A74FA14861DC47A720BD8699B99091A06BD695CDDE51222F837B9DECFC270C5' ), ( 3, 'R3', 1, 1, '\x8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D' ), ( 3, 'R3', 1, 2, '\x0F644C9A1DCB8C04BE6B385A60DBE4FDF7E2B81E335C9AD8C7CD0ABE2FF9E7E5BBFBB68B38DD0216F17808F48BDF6AF8C6347659C1F41A9858032C31F436D12C' ), ( 3, 'R3', 0, 1, '\x67ADD1166B020AE61B8F5FC96813C04C2AA589960796865572A3C7E737613DFD' ), ( 3, 'R3', 0, 2, '\x96C5793B2B57D8DF5891C94015720960E0DA4C2CF8CE1FC5707A0B46E5DB8CE3761FB5FDB430F619D1579F13E80FBDD973EF6A024129ED039AA193273158FCAD' ), ( 4, 'R4', 1, 1, '\xE5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77990F2D03' ), ( 4, 'R4', 1, 2, '\x59A91D97D81980951D0EF3C6D849B31606AF9AB2B0F7DCFAC93A53AE3263EB8902C3B7C564F33FF496F2D07C750B1B6924968C243882AF9E3532797EEF596F27' ), ( 4, 'R4', 0, 1, '\x1A07529A8B3F01D231DFAD2ABDF71899200BB65CD7E03C59FA82272533355B74' ), ( 4, 'R4', 0, 2, '\x0F0B4DD77EE99D8ED5724DA618B56017D08B757884796D087BF656E62D2717B5C913CB1E2EDA07AACBFDBFDCB1BA5BA52114D54C000E05B0CB755256A61C0C37' ), ( 5, 'E1', 1, 1, '\x276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10' ), ( 5, 'E1', 1, 2, '\x3561540FBF182BCE7749ACC131B421E691F083569C053E78F20274714C5E801226FF6EDB60641DDF70E71BD3A90DFE25DDD6464BE78106B77DECE4F6A3BFF13D' ), ( 5, 'E1', 0, 1, '\x46494E30379059DF18BE52124305E606FC59070E5B21076CE113954B60517CDA' ), ( 5, 'E1', 0, 2, '\x0FC8BDB5B93D95BB016BB543BD74B859E4C18930964D59CFC305B93EF3212C0C20F3084BA98FBF7AAC55D0D22C5B35566ED75BEBE6D5A7C53CA1F949C45C3C8E' ), ( 6, 'E2', 1, 1, '\xBD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270' ), ( 6, 'E2', 1, 2, '\x23A30BD3B617652E97224E1FAF673C4E09F1C197E4994274E676F2490893E9560D99F00A8859E399B2C65219CE2EB9B76784A0EC775AB4973A14FC1437AC7D9F' ), ( 6, 'E2', 0, 1, '\xBACDE0463053CE1D62F8BE74370BBAE79D4FCAF19FC07643AEF195E6A59BD578' ), ( 6, 'E2', 0, 2, '\xE8EC8405AB45605AE6E4A54EFD6D626F663CB7E61A10D9A6A6A08B118E0D35763D0118E263A6DB64516CA9F4E7F64FCD2B5DBF9E7A7BA265870606AF26F4D855' ) ) select count(distinct t.qname) as "#", le.issuer as "CA" from le join tlsa t on t.usage = 2 and t.selector = le.s and t.mtype = le.m and t.data = le.ihash join tlsabase b on b.tbase = t.qname join mx m on m.exch = b.qname group by le.n, le.issuer order by le.n; Updates to add the new hashes are happening more slowly than I'd hoped: # | CA -----+---- 978 | X3 32 | X4 15 | R3 9 | R4 15 | E1 10 | E2 If you're relying on "2 1 1" (or other Let's Encrypt DANE-TA(2)) TLSA records, please make the necessary changes promptly. -- Viktor. From pmenzel+dane-users at molgen.mpg.de Fri Sep 25 00:41:29 2020 From: pmenzel+dane-users at molgen.mpg.de (Paul Menzel) Date: Fri, 25 Sep 2020 00:41:29 +0200 Subject: dfn.de with DNSSEC and DFN-MailSupport published TLSA RR (was: Pilot phase for DNSSEC/DANE for DFN with dfnsec.de in August 2020) In-Reply-To: <7125968e-17d2-1b42-000d-8733f296babe@molgen.mpg.de> References: <45fc78bd-f955-23de-5f35-9daad67f9ecf@molgen.mpg.de> <010AEB9E-FB57-4C7E-8218-D14E0AC5D8B8@dukhovni.org> <7125968e-17d2-1b42-000d-8733f296babe@molgen.mpg.de> Message-ID: <0fc6e9de-f9e9-8821-3130-e4d442c61f19@molgen.mpg.de> Dear DANE users, Am 01.07.20 um 13:16 schrieb Paul Menzel: > Am 01.07.20 um 08:27 schrieb Viktor Dukhovni: >>> On Jul 1, 2020, at 4:01 AM, Paul Menzel wrote: >>> >>> I like to inform you, after several years of waiting, the Deutsche >>> Forschungsnetz will finally offer a solution for using their mail >>> support with DNSSEC/DANE [1]. For whatever reason, they do not want >>> to fiddle/test with dfn.de, and, therefore, are going to introduce >>> the new domain dfnsec.de first. >>> >>> The pilot phase is going to be from August 3rd to 31st, and they >>> are introducing faulty entries on Tuesday and Thursday from 10:00 >>> to 14:00. >> >> I take this to mean that dfn.de is planning to have DNSSEC signed MX >> hosts with TLSA RRs under a new dfnsec.de domain.? That's good news, >> thanks! > > Yes, it is meant as opt-in. Good news. The pilot was successful, and after over four years, the DFN finally delivered. Luckily, it looks like they were able to remove the internal doubts, and set up DNSSEC for dfn.de directory now and published the TLSA resource records [2]. >> In terms of candidate DNSSEC-signed domains currently using dfn.de MX >> hosts, that could/should consider switching to dfnsec.de, I currently >> find the following 33 in the DNSSEC/DANE survey dataset: > > [?] All the 33 domains are supported DANE now automatically. Yeah! > A lot of the subdomains of mpg.de use the DFN-MailSupport separately, > and from those, to my knowledge, only us ? molgen.mpg.de ? have set up > DNSSEC. (The other few DNSSEC users do *not* use the DFN-MailSupport ? > for example mpifr-bonn.mpg.de.) As written, unfortunately, not all subdomains of mpg.de have DNSSEC set up. My institute molgen.mpg.de and cpfs.mpg.de from Dresden do use DNSSEC, and therefore have DANE working now. [?] Kind regards, Paul [2]: https://www.mailsupport.dfn.de/news/aktivierung-der-tlsa-records PS: Example: > $ /usr/sbin/posttls-finger -t30 -T180 -c -L verbose,summary -l dane-only -P /etc/ssl/certs/ molgen.mpg.de > posttls-finger: initializing the client-side TLS engine > posttls-finger: using DANE RR: _25._tcp.a1241.mx.srv.dfn.de IN TLSA 3 0 1 27:0E:C9:DD:08:18:AB:C8:1C:96:68:3F:11:16:D8:A5:EA:66:66:D3:64:29:FD:5D:83:D6:11:F6:87:26:C9:3A > posttls-finger: setting up TLS connection to a1241.mx.srv.dfn.de[194.95.232.62]:25 > posttls-finger: a1241.mx.srv.dfn.de[194.95.232.62]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@strength:!aNULL" > posttls-finger: a1241.mx.srv.dfn.de[194.95.232.62]:25: depth=3 verify=1 subject=/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2 > posttls-finger: a1241.mx.srv.dfn.de[194.95.232.62]:25: depth=2 verify=1 subject=/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2 > posttls-finger: a1241.mx.srv.dfn.de[194.95.232.62]:25: depth=1 verify=1 subject=/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA > posttls-finger: a1241.mx.srv.dfn.de[194.95.232.62]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/L=Berlin/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=Geschaeftsstelle/CN=*.mx.srv.dfn.de > posttls-finger: a1241.mx.srv.dfn.de[194.95.232.62]:25: depth=0 matched end entity certificate sha256 digest 27:0E:C9:DD:08:18:AB:C8:1C:96:68:3F:11:16:D8:A5:EA:66:66:D3:64:29:FD:5D:83:D6:11:F6:87:26:C9:3A > posttls-finger: a1241.mx.srv.dfn.de[194.95.232.62]:25: subject_CN=*.mx.srv.dfn.de, issuer_CN=DFN-Verein Global Issuing CA, fingerprint=25:2C:32:73:0D:01:13:53:F5:59:1D:1E:CA:E4:DA:8B:E0:94:75:56, pkey_fingerprint=D5:6E:6C:41:CC:28:0F:66:71:8C:76:D1:F1:5B:F9:7C:EB:13:8A:AB > posttls-finger: Verified TLS connection established to a1241.mx.srv.dfn.de[194.95.232.62]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256 > > $ /usr/sbin/posttls-finger -t30 -T180 -c -L verbose,summary -l dane-only -P /etc/ssl/certs/ vw.molgen.mpg.de > posttls-finger: initializing the client-side TLS engine > posttls-finger: using DANE RR: _25._tcp.b1234.mx.srv.dfn.de IN TLSA 3 0 1 27:0E:C9:DD:08:18:AB:C8:1C:96:68:3F:11:16:D8:A5:EA:66:66:D3:64:29:FD:5D:83:D6:11:F6:87:26:C9:3A > posttls-finger: setting up TLS connection to b1234.mx.srv.dfn.de[194.95.234.102]:25 > posttls-finger: b1234.mx.srv.dfn.de[194.95.234.102]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@strength:!aNULL" > posttls-finger: b1234.mx.srv.dfn.de[194.95.234.102]:25: depth=3 verify=1 subject=/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2 > posttls-finger: b1234.mx.srv.dfn.de[194.95.234.102]:25: depth=2 verify=1 subject=/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2 > posttls-finger: b1234.mx.srv.dfn.de[194.95.234.102]:25: depth=1 verify=1 subject=/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA > posttls-finger: b1234.mx.srv.dfn.de[194.95.234.102]:25: depth=0 verify=1 subject=/C=DE/ST=Berlin/L=Berlin/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=Geschaeftsstelle/CN=*.mx.srv.dfn.de > posttls-finger: b1234.mx.srv.dfn.de[194.95.234.102]:25: depth=0 matched end entity certificate sha256 digest 27:0E:C9:DD:08:18:AB:C8:1C:96:68:3F:11:16:D8:A5:EA:66:66:D3:64:29:FD:5D:83:D6:11:F6:87:26:C9:3A > posttls-finger: b1234.mx.srv.dfn.de[194.95.234.102]:25: subject_CN=*.mx.srv.dfn.de, issuer_CN=DFN-Verein Global Issuing CA, fingerprint=25:2C:32:73:0D:01:13:53:F5:59:1D:1E:CA:E4:DA:8B:E0:94:75:56, pkey_fingerprint=D5:6E:6C:41:CC:28:0F:66:71:8C:76:D1:F1:5B:F9:7C:EB:13:8A:AB > posttls-finger: Verified TLS connection established to b1234.mx.srv.dfn.de[194.95.234.102]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA2560