> I know a lot of people disagree with me here, but I have yet to see an argument that can convince me that CN, SAN, not-valid-before or not-valid-after have any bearing on the security of the certificate or give me as a user any information that helps me make a safe decision. All of these fields are crucial in a CA validation scheme, but only add a false sense of security in TOFU. When making self-signed certs for my domains, I make sure that all fields are correct and set the expiration date years into the future. If any of the fields don't match, I want that to be seen as indication that something isn't right. This might be good enough to prevent a sloppy attempt at interception. Some admins are not as careful about their certs, but that's on them. As long as we're using X.509, the browser should inform the user of any discrepancies. As for renewal of CA-signed certs: when receiving a new cert from the same CA, if the old cert is within 30 days of expiration, the browser could either silently accept it, or show the user a notice along the lines of: "The old certificate is about to expire in 20 days, renewal in this time frame is expected. Do you want to continue?". For crawlers like Lupa, sure, there's no need for any kind of cert validation, except for generating TLS-related statistics, which would be quite interesting.
---
Previous in thread (3 of 4): 🗣️ Björn Wärmedal (bjorn.warmedal (a) gmail.com)