Hostnet vs Let's Encrypt ISRG Root X1

[DJMaze]

De laatste maanden heb ik problemen met het ontvangen van e-mails van twee smtp omgevingen (hostnet en voipoperator).

Het lijkt er op dat die servers niet mijn Let's Encrypt ISRG Root X1 certificaat snappen zodra zij een verbinding maken.

Postfix verbose TLS log:

code:

connect from kate2.hostnet.nl[91.184.19.54]
setting up TLS connection from kate2.hostnet.nl[91.184.19.54]
kate2.hostnet.nl[91.184.19.54]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
SSL_accept:before SSL initialization
read from 557B79B56DF0 [557B79B4E553] (5 bytes => -1 (0xFFFFFFFFFFFFFFFF))
read from 557B79B56DF0 [557B79B4E553] (5 bytes => 5 (0x5))
0000 16 03 01 01 0a .....
read from 557B79B56DF0 [557B79B4E558] (266 bytes => 266 (0x10A))
    0000 01 00 01 06 03 03 f4 a5|25 d0 5e 42 36 9b 7e 20 ........ %.^B6.~
    0010 14 b4 31 c9 90 8f 4c 04|cb f0 16 62 6d db 09 b7 ..1...L. ...bm...
    0020 06 de 98 b4 0a ab 00 00|8c c0 30 c0 2c c0 28 c0 ........ ..0.,.(.
    0030 24 c0 14 c0 0a 00 a5 00|a3 00 a1 00 9f 00 6b 00 $....... ......k.
    0040 6a 00 69 00 68 00 39 00|38 00 37 00 36 00 88 00 j.i.h.9. 8.7.6...
    0050 87 00 86 00 85 c0 32 c0|2e c0 2a c0 26 c0 0f c0 ......2. ..*.&...
    0060 05 00 9d 00 3d 00 35 00|84 c0 2f c0 2b c0 27 c0 ....=.5. ../.+.'.
    0070 23 c0 13 c0 09 00 a4 00|a2 00 a0 00 9e 00 67 00 #....... ......g.
    0080 40 00 3f 00 3e 00 33 00|32 00 31 00 30 00 9a 00 @.?.>.3. 2.1.0...
    0090 99 00 98 00 97 00 45 00|44 00 43 00 42 c0 31 c0 ......E. D.C.B.1.
    00a0 2d c0 29 c0 25 c0 0e c0|04 00 9c 00 3c 00 2f 00 -.).%... ....<./.
    00b0 96 00 41 00 ff 01 00 00|51 00 0b 00 04 03 00 01 ..A..... Q.......
    00c0 02 00 0a 00 1c 00 1a 00|17 00 19 00 1c 00 1b 00 ........ ........
    00d0 18 00 1a 00 16 00 0e 00|0d 00 0b 00 0c 00 09 00 ........ ........
    00e0 0a 00 0d 00 20 00 1e 06|01 06 02 06 03 05 01 05 .... ... ........
    00f0 02 05 03 04 01 04 02 04|03 03 01 03 02 03 03 02 ........ ........
    0100 01 02 02 02 03 00 0f 00|01 01 ........ ..
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write certificate
SSL_accept:SSLv3/TLS write key exchange
write to 557B79B56DF0 [557B79B536B0] (2905 bytes => 2905 (0xB59))
    0000 16 03 03 00 59 02 00 00|55 03 03 7e 69 79 7e 96 ....Y... U..~iy~.
    .....
    0b50 16 03 03 00 04 0e ......
    0b56 - <SPACES/NULLS>
SSL_accept:SSLv3/TLS write server done
read from 557B79B56DF0 [557B79B4E553] (5 bytes => -1 (0xFFFFFFFFFFFFFFFF))
read from 557B79B56DF0 [557B79B4E553] (5 bytes => 5 (0x5))
0000 15 03 03 00 02 .....
read from 557B79B56DF0 [557B79B4E558] (2 bytes => 2 (0x2))
0000 02 30 .0
SSL3 alert read:fatal:unknown CA
SSL_accept:error in error
SSL_accept error from kate2.hostnet.nl[91.184.19.54]: -1
warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:ssl/record/rec_layer_s3.c:1544:SSL alert number 48:
lost connection after STARTTLS from kate2.hostnet.nl[91.184.19.54]
disconnect from kate2.hostnet.nl[91.184.19.54] ehlo=1 starttls=0/1 commands=1/2

Zijn er hostnet klanten die last hebben van geretourneerde e-mails als in:

code:

Action: delayed
Status: 4.0.0
X-SpamExperts-Domain: out.mailfilter.hostnet.nl

Zijn er meer mensen die last hebben met Let's Encrypt ISRG Root X1?

Want op mijn servers kom ik er niet helemaal uit waarom hij crasht op de CA.
Een werkende handshake:

code:

SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
write to 557B79B02B80 [557B79B56100] (3007 bytes => 3007 (0xBBF))
0000 16 03 03 00 7a 02 00 00|76 03 03 fe c7 df ab 39 ....z... v......9
...
0bb0 09 f9 e9 c5 d8 8c c6 ba|7f 59 46 48 9a f1 bf ........ .YFH...
SSL_accept:SSLv3/TLS write finished

En als ik hostnet bel kom ik niet verder dan de 1e lijns support...

[Voor 9% gewijzigd door DJMaze op 19-03-2021 17:43]

[DJMaze]

Update: ik heb nu errors van alle Solarwinds SpamExperts aangesloten mailservers.
Heb daarom gebeld en een mail gestuurd naar SpamExperts.
Zodra ik van hun hoor wat het probleem is, zal ik dat hier melden.

[PerfectPC]

wacht effe, is het versturen of ontvangen?
indien ontvangen: tijd om je eigen certificate store te updaten
indien versturen: tijd om de andere kant te vragen hun cert store te updaten (ISRG X1 is nog maar 6j oud...)

[Voor 81% gewijzigd door PerfectPC op 29-03-2021 13:30]

[justahuman]

Stuur je wel de hele chain mee icm met de DST Root CA X3 die hem gecross signed heeft?

[DJMaze]

PerfectPC schreef op maandag 29 maart 2021 @ 13:27:
indien ontvangen: tijd om je eigen certificate store te updaten

CentOS 8.3 en nee ik heb expres geen cert store.
Zit niet te wachten op client certificates (dit is ook gewoon not-done in Postfix).
Ik denk dat je het andersom bedoelt, aangezien:

1. zij verbinden met mij
2. ik stuur certificaat
3. zij antwoorden met -1

justahuman schreef op maandag 29 maart 2021 @ 13:33:
Stuur je wel de hele chain mee icm met de DST Root CA X3 die hem gecross signed heeft?

Yep

Zover ik nu kan zien is het een DNS probleem:
* A example.com => IP website
* MX example.com => mail.website.com
* CNAME mail.website.com => server1.example.com

Het lijkt er op dat SpamExperts een certificaat van example.com verwacht en niet die van server1.example.com.
Elke andere mail server kan ik prima mail van ontvangen zonder gezeur (TLS 1.2 & 1.3)
En SpamExperts lukt het soms wel met andere domeinen naar de zelfde mail server.

[Voor 53% gewijzigd door DJMaze op 29-03-2021 16:54]

[AlbertJP]

DNS en TLS staan volledig los van elkaar, dus een CNAME is niet relevant. Het certificaat moet kloppen voor de hostnaam die de gebruiker in hun browser / mailclient intypt. Dus inderdaad voor example.com.

DJMaze schreef op maandag 29 maart 2021 @ 16:44:
CentOS 8.3 en nee ik heb expres geen cert store.
Zit niet te wachten op client certificates (dit is ook gewoon not-done in Postfix).
[...]

Dit gaat niet om een verzameling clientcertificaten maar om de rootcertificaten waarmee je server controleert dat een certificaat geldig is.

Je moet een 'chain' installeren die leidt naar een rootcertificaat dat in de store zit van de computer die het certificaat verifieert. Dat is in dit geval de computer aan de andere kant, voor zover ik zie.

Ik neem aan dat het 'intermediate' certificaat R3 wordt gebruikt hier. Die heeft twee versies: een voor mensen die de ISRG X1 root in hun certificate store hebben, en een voor mensen die alleen de oudere DST Root CA X3 in hun store hebben. Je kunt beide vinden op https://letsencrypt.org/certificates/. Weet je welke van beide je in je chain hebt staan?

[Voor 7% gewijzigd door AlbertJP op 29-03-2021 19:43]

[DJMaze]

@AlbertJP goed punt!

Ik heb nu alleen de R3 in de fullchain.pem en gesigned met DST Root CA X3.

Zal later weer eens ISRG X1 doen en kijken of het verschil gaf.

[AlbertJP]

Als je de beste compatibiliteit wilt, kun je R3 ondertekend door ISRG X1 én ISRG X1 ondertekend door DST Root CA X3 erin zetten. Je hebt dan een pad naar beiden toe en de client mag kiezen of die het laatste certificaat nog nodig heeft.

Dit betekent dat er een extra certificaat opgestuurd moet worden, dus dat is een paar kilobyte extra gegevens bij iedere handshake, maar als je te maken hebt met oude én nieuwe clients dan is het wel de makkelijkste oplossing.

[Voor 13% gewijzigd door AlbertJP op 31-03-2021 10:02]

[DJMaze]

@AlbertJP Ik heb bericht van hostnet

Hostnet schreef:
Uit de onderstaande log begrijpen wij dat uw server geen selfsigned certificaat accepteert en dat gebruiken wij wel op ons mail platform. Daardoor wordt de verbinding geweigerd. Dit is op te lossen door selfsigned certificaten te accepteren op uw server.

Ze snappen het blijkbaar niet bij Hostnet

Ik heb maar contact opgenomen met SpamExperts en daar een ticket ingeschoten omdat meer klanten van SpamExperts problemen hebben met mijn servers.

[valkenier]

Het is wel zo, dat een MX record geen CNAME hoort te bevatten voor zover ik weet.

RFC 2181 https://www.rfc-editor.org/rfc/rfc2181.txt

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.

Maar ik denk dat dat verder los staat van je probleem..

[DJMaze]

@valkenier klopt.
Ik had wel even met cname geklooit om te kijken wat hostnet daar mee deed.

[AlbertJP]

Hostnet lijkt het te hebben over verbindingen van buiten naar hun server, in plaats van van hen naar die van jou. Er is geen reden waarom jij een self-signed certificaat zou moeten maken als je al een geldig certificaat van Let's Encrypt hebt.

[DJMaze]

@AlbertJP nee.
Hostnet verbindt met mij.
Krijgt een certificaat van mij.
Hostnet stuurt een self-signed naar mij
Ik accepteer dat niet.

En dat niet accepteren is heel normaal (tenzij intern netwerk).
Echter, het gebeurt maar bij 1 domein waarvan de A en AAAA naar een andere server verwijzen.
Alsof hostnet raar doet als de MX verwijst naar een andere server en vervolgens die self-signed probeert te sturen.
Bij alle andere domeinen op de mailserver geen problemen.

[AlbertJP]

Nee, jij hoeft geen enkel clientcertificaat te accepteren. Hostnets SMTP-servers lijken overigens gewoon een certificaat van Sectigo te hebben als ik met SMTP naar hen verbind.

Ik heb even de logs nagekeken van een server die ik beheer en die heeft in de maand maart drie keer een mail vanaf kate2.hostnet.nl binnengekregen. Meest recente: 28 maart. De verbinding was steeds TLS1.2 met cipher ECDHE-RSA-AES256-GCM-SHA384. Geen foutmeldingen. (EDIT: dit is op dit moment de aanbevolen cipher voor TLS 1.2 dus aan de cipher suite van jou of Hostnet ligt het niet.)

Die server die ik beheer heeft een Let's Encrypt certificaat gevolgd door de R3 intermediate getekend door DST Root CA X3, en draait Exim i.p.v. Postfix. Heb je nog geprobeerd de intermediate te wisselen in jouw Postfix?

Edit: De MX en A hebben ook bij mij een verschillend IP-adres, dus dat is op zich geen probleem - hoewel ik er geen CNAME tussen heb zitten.

[Voor 26% gewijzigd door AlbertJP op 06-04-2021 20:56]

[DJMaze]

De aap is uit de mouw. Blijkbaar hebben ze problemen met SNI en MX lookups.

Onze excuses, het vorige bericht berust helaas op foutief geïnterpreteerde informatie.
Onze mailserver kate2.hostnet.nl serveert namelijk een *.hostnet.nl certificaat, dit certificaat is geldig en actief.

Aan de hand van uw reactie zijn wij een onderzoek gestart. Uit dit onderzoek is gebleken dat uw domein example.com bij het ontvangen van mail een certificaat afgeeft welke zich bekend maakt als 'mail.server.org'. Dit is een combinatie die ons uitgaande spamfilter niet accepteert. Wij raden u daarom aan om gebruik te maken van een certificaat welke zich bekend maakt als example.com.

Mijn DNS:
A: example.com => (ander ip die niet mail.server.org is)
MX: example.com => mail.server.org

Dus nee ik heb geen certificaat voor example.com want die staat op een andere server (niet in mijn beheer).

[Voor 10% gewijzigd door DJMaze op 08-04-2021 15:42]

[AlbertJP]

Alsnog komen we uit bij de CNAME. Ik ga ervan uit dat dit nog steeds klopt:

DJMaze schreef op maandag 29 maart 2021 @ 16:44:
* A example.com => IP website
* MX example.com => mail.website.com
* CNAME mail.website.com => server1.example.com

In het MX record staat/stond mail.website.com (zei je in een eerdere post). De DNS resolver van Hostnet zoekt daarmee (via mail.server.org) jouw IP op, maar de mailserver van Hostnet heeft daar geen weet van want die leest alleen maar MX records. Dus wat Hostnet doet is correct.

2 oplossingen:
- jij kunt een certificaat voor mail.website.com aanvragen omdat die naar jou verwijst.
- of je laat de CNAME ertussenuit halen

[Voor 22% gewijzigd door AlbertJP op 08-04-2021 17:27]

[DJMaze]

@AlbertJP nee geen CNAME.

A: example.com => 5.6.7.8
MX: example.com => mailserver.com
A: mailserver.com => 1.2.3.4

Hostnet zoekt certificaat example.com op 1.2.3.4
Ze zouden dan toch mailserver.com moeten controleren?

[Voor 10% gewijzigd door DJMaze op 08-04-2021 20:42]

[valkenier]

DJMaze schreef op donderdag 8 april 2021 @ 20:40:
@AlbertJP nee geen CNAME.

A: example.com => 5.6.7.8
MX: example.com => mailserver.com
A: mailserver.com => 1.2.3.4

Hostnet zoekt certificaat example.com op 1.2.3.4
Ze zouden dan toch mailserver.com moeten controleren?

Tuurlijk is dat zo. Je bent vrij om mail voor een domein te laten afhandelen door een MX op een ander domein, als die mailserver maar mail voor het oorspronkelijke domein accepteert. Daarvoor hoeft die mailserver geen certificaat, anders dan voor zichzelf te presenteren. Wat jij aanhaalt uit de mail van hostnet, dat hun uitgaande spamfilter zo’n combi niet accepteert, vind ik echt raar.

Bij mijn domein is het MX record ook een ander domein, dan mijn eigen domein.

[AlbertJP]

Klopt. Er zijn veel domeinen die mail via Google Apps laten lopen. Google heeft echt geen certificaten nodig voor alle domeinen die hun servers in het MX record hebben staan.

[DJMaze]

AlbertJP schreef op donderdag 8 april 2021 @ 22:42:
Klopt. Er zijn veel domeinen die mail via Google Apps laten lopen. Google heeft echt geen certificaten nodig voor alle domeinen die hun servers in het MX record hebben staan.

Ja dat dus!

valkenier schreef op donderdag 8 april 2021 @ 22:15:
Wat jij aanhaalt uit de mail van hostnet, dat hun uitgaande spamfilter zo’n combi niet accepteert, vind ik echt raar.

Het wordt nog raarder. Kreeg net een e-mail dat ze voor domein X nu twee verschillende certificaten krijgen.
1x de server naam
1x domein X

Wat kan als je je test 1x uitvoert met SNI en 1x zonder SNI.

Is er toevallig in de tussentijd iets gewijzigd aan de serverkant of maak je gebruik van load balancing?
Maak je gebruik van load balancing dan raad ik je aan om het SSL certificaat op alle server waar je gebruik van kan maken te (laten) controleren.
Mogelijk staat op 1 van de servers het correcte SSL certificaat nog niet ingesteld.
Als laatste stap kan je (laten) controleren of de load balancer het verkeer wel naar de juiste server(s) stuurt.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

P.S. SpamExperts werkt ook niet mee

Hi,

With regards to the attached logs:

"Attachment spamexperts-tls.log blocked - file type not allowed."

Our system does not allow this file type, if you can resend as a .txt file then I can receive them.

[Voor 6% gewijzigd door DJMaze op 09-04-2021 11:55]

[valkenier]

hikkie presenteert een geldig certificaat. Doen mailservers aan SNI? Ik dacht je hebt een MX record, en daar verbind je dan mee. Heeft het zin om dezelfde ontvangende mailserver als bereikbaar onder meerdere domeinen te configgen? Dat doet er toch niet toe? Je configureert op de server voor welke domein hij mail mag afhandelen, maar dat kan prima met 1 hostname plus certificaat. Of doe jij het anders?

[AlbertJP]

Mailservers doen zeker aan SNI tegenwoordig. Je hoeft alleen geen andere domeinen te configureren dan degene die in het MX record wordt genoemd, of domeinen die klanten als serveradres in hun mailprogramma hebben staan.

Als ik met s_client in de Linuxterminal je certificaat opvraag met én zonder SNI krijg ik in beide gevallen een voor hikkie. (Als ik het websitedomein als SNI invul krijg ik die overigens ook.) Ik denk dus niet dat het probleem aan SNI ligt.

EDIT: ik heb voor de zekerheid met IPv4 en IPv6 getest; dat maakt geen verschil.

[Voor 16% gewijzigd door AlbertJP op 09-04-2021 17:11]

[DJMaze]

AlbertJP schreef op vrijdag 9 april 2021 @ 16:50:
Als ik het websitedomein als SNI invul krijg ik die overigens ook.

Klopt, want ik heb daar geen certificaat voor.
Dan krijg je gewoon het server certificaat.

cPanel enzo hebben dan een bug dat je het certificaat van het eerste domein krijgt (vooral in Apache).
Die gebruik ik dus gelukkig niet.

Al met al kan ik dus nergens een fout aan mijn kant vinden.

[DJMaze]

Zitten ze bij SpamExperts nu ook te prutsen?

code:

$ swaks --to=[e-mail] --quit-after RCPT
=== Trying mail.website.com:25...
=== Connected to mail.website.com.
<- 220 mail.website.com ESMTP
-> EHLO mx133.antispamcloud.com
<- 250-mail.website.com
<- 250-PIPELINING
<- 250-SIZE 256000000
<- 250-ETRN
<- 250-STARTTLS
<- 250-ENHANCEDSTATUSCODES
<- 250-8BITMIME
<- 250-DSN
<- 250-SMTPUTF8
<- 250 CHUNKING
-> MAIL FROM:<@mx133.antispamcloud.com>
<- 250 2.1.0 Ok
-> RCPT TO:[e-mail]
<- 250 2.1.5 Ok
-> QUIT
<- 221 2.0.0 Bye
=== Connection closed with remote host.

The above log shows no TLS issue between us and the test is complete with a 250 OK.

Ik zie toch echt geen uitvoer van STARTTLS dmv `swaks -tls`, hoe kan je dan beweren dat er geen TLS probleem is?

[valkenier]

DJMaze schreef op dinsdag 13 april 2021 @ 11:55:
Zitten ze bij SpamExperts nu ook te prutsen?

[...]

Ik zie toch echt geen uitvoer van STARTTLS dmv `swaks -tls`, hoe kan je dan beweren dat er geen TLS probleem is?

Sorry, Wat heb je nou precies getest hierboven? Had je willen zie hoe de TLS handshake wordt opgebouwd? Waar zit spamexperts hier?

[DJMaze]

valkenier schreef op dinsdag 13 april 2021 @ 17:29:
Waar zit spamexperts hier?

Solarwinds SpamExperts is de SMTP leverancier aan Hostnet en anderen.

Aangezien Hostnet geen kennis in huis heeft om het euvel uit te zoeken, heb ik SpamExperts ook de data gegeven.

In dit geval deden die even een test zonder STARTTLS en zeggen dan "er zijn geen TLS problemen".

Tis toch te idioot dat "experts" dit niet kunnen uitzoeken?

[AlbertJP]

Weet je of Spamexperts de inkomende of de uitgaande mail van Hostnet afhandelt? Het is bij hen niet verplicht om allebei af te nemen.

En betekent een test zonder STARTTLS dat ze zonder encryptie met poort 25 hebben verbonden, of SMTPS op poort 465 hebben gedaan?

[valkenier]

Ik snap hem nu wel. Spamexperts heeft gewoon getest op poort 25. ( Het is geen submission). De server kondigt keurig aan STARTTLS te ondersteunen. Waar de test verder niks mee doet. Tja...... dat is geen goede test idd. 🤷‍♂️

[DJMaze]

@AlbertJP en @valkenier
Bedankt voor het meedenken.

Ik kreeg antwoord van hostnet:

code:

DNS TLSA RRset:
  qname: _25._tcp.hikkie.domain.nl.
  3 1 1 ad5b096f2f57111388e9474867c2e356ee4e579b334b9fdb48dbb435d9f08685
DANE TLSA 3 1 1 [ad5b096f..]: FAIL did not match EE certificate

Vroeger was er inderdaad een TLSA, maar door aanhoudende problemen niet meer.
Hoe zij er dan aan komen is mij een raadsel.

Voor nu is het opgelost doordat ik alle TLSA records heb verwijderd.

Echter heb ik nu wel een nieuwe TLSA uitgerold om te kijken hoe daar mee wordt omgesprongen.
Want een aantal DANE-EE checkers geven nog steeds de oude ad5b096f2f57111388e9474867c2e356ee4e579b334b9fdb48dbb435d9f08685

Terwijl anderen wel netjes de nieuwe melden.
DANE-EE (3) SPKI (1) SHA2-256 (1) 83b82f976d553d179a304fa5a2a9efc6ae66b18367399eb7d6783264f59a129c

[Voor 54% gewijzigd door DJMaze op 19-04-2021 15:40]