Right. Given a pile of about 100 compromised keys that were issued by 38 different CAs, how would you automate the revocation process? Automation being important so as to be scalable. e.g. what if it were 1000 CAs?
-
-
The CA/B forum baseline requirements should require that every CA registers an automated certificate revocation endpoint that takes cert keypairs as input. Are there any standardization efforts working towards something like this?
1 reply 0 retweets 1 like -
0 replies 0 retweets 0 likes
-
Sadly, the info used in section 1.5.2 of CPS isn't always accurate. Some don't include an email address. And some list an email address that apparently isn't used for reporting certificate problems. e.g. when contacting the
@SectigoHQ (formerly Comodo) address, you get this:pic.twitter.com/OiL7Yw18xQ
0 replies 0 retweets 3 likes -
Oh, and the one that included no email address in 1.5.2 (not sure if that's a requirement?) is
@register_com https://crt.sh/?caid=91 http://ca.register.com/repository/Register_CPS.pdf …pic.twitter.com/wVt6rK8zb3
2 replies 0 retweets 0 likes -
Will, many of the certs you've identified have already expired. Most CAs won't revoke server auth certs that have already expired. In fact, it's common practice to stop including CRL entries for revoked certs once they expire.
1 reply 0 retweets 0 likes
Yeah, I plan to have my next round of cert notifications limited to the not-yet-expired ones.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.