In article <[email protected]> you write: >Plausibly, based on the logs, the client did not like the handshake, >and sent some sort of alert. Sadly, the logging omits the crucial >alert number or description, so there's not much to go on.
Yeah, tomorrow I'll try and get better logging. >Perhaps these SNI configurations fail to include the intermediate CA >certs? And the client is enforcing use of TLS? No, it's the full chain. >Also, keep in mind that Comcast implements DANE, and you're now >serving a different certificate, that does not match the TLSA >record, then all the pieces fit together... >But the returned certificate, does not match the SNI name. That might be it. I published new TLSA records to match the new certs but between the 1 hour TTL and one of my DNS servers being slow to pick up updates, I can imagine you might see an old one. >If your server has "multiple personality disorder", trying to make >both MTA-STS and DANE work can be daunting, though by using >the same underlying public key, with "3 1 1" records the TLSA >records might be "personality-agnostic". :-) Let me see if I can persuade acme.sh to generate certs with the same key. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
