On 2018-04-16 at 13:04 -0400, Phil Pennock wrote: > What's confusing to me, the next morning, is that included in the Gmail > overrides is a force-enabling of validation (yes, using the CA system, > but selective for remote domains where I choose to trust they're not > going to press for a dodgy CA, and I'm still not happy at it). So for > the mail to have gone through, that "CN=invalid2.invalid" certificate > must have been issued by a CA in the public PKIX system. Which seems > like a CA/Browser violation. Or perhaps there's a bug in my validation > settings.
My tone here was inappropriate. I'm sorry. Even if I had been correct, it was still not a good way to communicate effectively. I try to do better than this and, I think, normally succeed these days. My crankiness should not spill over and affect others. In this case though, I was wrong. I've used the SNI-conditional certificates I'm seeing from Gmail to debug a misconfiguration in my overly-complex MTA config which meant that I wasn't getting mandated-verification when I thought it was statically configured via local file. This has now been fixed. No SNI, I get the CN=invalid2.invalid certificate, and now that mail sticks on my queue. With SNI, the mail goes out. gmail.com is requiring verification correctly. (DANE is always verified, it's not prone to misconfiguration, Exim locks in stronger security automatically once you've asked for DANE and it sees DANE; this was purely a mistake when trying to hard-require verification via CDB-file lookup). For the record: when sending with Exim, I'm reliably getting the invalid cert when not supplying SNI. It's a self-signed RSA2048/SHA256 certificate, serial number 90:76:89:18:e9:33:93:a0, duration Jan 1st 2015 to Jan 1st 2030, with (strangely) CA=true in the basic constraints. -Phil
signature.asc
Description: Digital signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
