| Q: Does this affect you? No action is otherwise required for end users, except for those site operators who manually deploy SSL certificates. If you manually deploy SSL certificates, then make sure that your contact information with the issuer (e.g. Digicert) is up-to-date; if your certificates are affected, they will contact you and advise you on how to proceed with reissuing and redeploying. Or, you can contact their customer service, reference the mail-archive link, and ask if your certificates are affected. If your SSL certificates are deployed automatically (Let’s Encrypt, AWS ACM, etc.) then no action is required. Either your certificates are unaffected, or they’ll be updated automatically by the automation. Q: What’s a simple summary of the problem? Imagine if root tried to userdel a malicious account, and the non-root user being deleted was able to tell the system “ignore that, I’m still valid”. The system would need to be quarantined and a replacement built without that flaw, since you could not state definitively that you had deleted the malicious user account.) This issue would allow a non-root certificate (‘intermediate’, ‘subCA’) to undo deletion (‘revocation’) of itself by the root authority, as well as undo deletion of its siblings (other intermediates issued by that root authority). To correct the issue, all non-root certificates issued incorrectly in this manner must be revoked and then destroyed, with proof of destruction. This ensures that the mis-issued intermediates can’t zombie-return someday by undoing their own deletion or the deletion of others. |