Podcast
Root Causes 313: SSL Revocation Reason Codes


Hosted by
Tim Callan
Chief Compliance Officer
Jason Soroko
Fellow
Original broadcast date
June 23, 2023
In 2022 Mozilla added a root program requirement that CAs include Reason Codes when revoking public TLS certificates. In this episode we explain the reason codes, along with some explicitly forbidden reason codes, and go into the backstory behind this requirement.
Podcast Transcript
Lightly edited for flow and brevity.
First is keyCompromise. That makes good sense, right? “The certificate subscriber must choose the keyCompromise revocation reason code when they have reason to believe that the private key of the certificate has been compromised, i.e. an unauthorized person has had access to the private key and the certificate.” That I think surely is just about the most defensible and important reason to revoke certificates, and definitely we want one for that.
The next one is called affiliationChanged. “The certificate subscriber should choose the affiliationChanged Revocation Reason Code when the organization’s name or other organizational information in the certificate has changed.” The idea here is that in a good world of PKI hygiene, we understand that certs exist for a certain amount of time and that information sometimes changes. Sometimes a company gets acquired or they rebrand themselves or they change their legal name, etc., and this isn’t going to, by amazing coincidence, perfectly line up with the actual information in a cert. The industry recognizes that over time, these things will true up on their own, so there isn’t an obligation necessarily to revoke here. However, people can, and people certainly may want to, especially if they want the information in their certificate to match the information they’re saying they are to the public, and so, under those circumstances, you would use the affiliationChanged Reason Code as a legitimate reason to be revoking your old certificate.
Next is cessationofOperation. “The certificate subscriber should choose the cessationofOperation Revocation Reason Code when they no longer own all the domain names in the certificate or when they will no longer be using the certificate because they’re discontinuing their website.” This makes good sense. This is a cert for a domain. I’m not using that domain anymore. Let’s say I sold the domain or gave up rights to it, and there’s still a cert hanging around. I don’t like that, so, I’m going to go ahead, and revoke that cert. That would be cessationofOperation.
The last one is privilegeWithdrawn. “The CA will specify the privilegeWithdrawn Revocation Reason Code when they obtain evidence that the certificate is misused or the certificate subscriber has violated one or more material obligations under the subscriber agreement.” So, this is, the certificate is being used on a phishing site kind of scenario. Things along those lines that cause privilegeWithdrawn.
First one is unspecified, and what Mozilla wants you to do is instead of using the unspecified Reason Code, they say don’t have one at all. Omit that value entirely.
The next one is cACompromise, and the point here is they say the cACompromise Reason Code is used to revoke a CA certificate like an intermediate. It should not be used on end entity certificates. Using CA Compromise on an end entity certificate is fundamentally wrong. It misunderstands where things fit in the PKI chain, in the PKI ecosystem.
Then there is certificateHold. They do not want to use certificateHold. Once upon a time, people would do things like use Suspend Mode in OCSP and things along those lines. They don’t want certificateHold to be used.
removeFromCRL is a reason code, and here, I’ll read this out loud. “The removeFromCRL Reason Code may only appear in delta CRLs and indicates that a certificate is to be removed from a CRL because the certificate was expired or was removed from Hold.” So they want that to be used in a specific way. And again, it shouldn’t be a Revocation Reason Code for a Leaf Cert that’s being traditionally revoked.
And then, lastly, this one is aACompromised. AA stands for Attribute Authority, and the aACompromised Reason Code is inapplicable in the TLS scenario, and that’s because it’s used for attribute certificates when aspects of the attribute authority have been compromised, and this isn’t an attribute certificate.
So, there you go. All those are also explicitly forbidden because Mozilla is of the opinion that using them as a Revocation Reason Code for a Leaf Certificate would be inappropriate and non-sensical. And then we’re given that list of five, and there is acknowledgement of the fact that there could be another reason, in which case a reason code is not to be used.
First of all, it’s just sort of a general instinct to clean things up, and Mozilla makes the point that there never was any guidance or policy around this, and every CA just kind of made their own decisions about what to do with reason codes, and they would have different policies about why to use a different reason code in different circumstances. Many of them just didn’t use reason codes at all or whether a reason code was used or not used, it might be the exact same circumstance, and it might be used sometimes and not used other times because of the way software was written or systems were implemented or who knows. Different CAs might have different interpretations of the same thing, and then, their policies and interpretations might also change over time. So, something that’s revoked last year for Reason Code A, this year might be attributed to Reason Code B. And so, I think the Mozilla team – I’m channeling them a little here, but I think I’m getting this right – it caused the Mozilla team to feel like this is valueless information. Like, we can’t do anything. We can’t learn from this. We can’t make the web PKI better because when you look at these reason codes, they just don’t tell you anything that’s concrete or actionable or reliable or consistent. And so, what Mozilla is, I think, attempting to do is to put a certain amount of evidentiary rigor in place here in the hopes that reason codes will become a source of actionable information for improving the health of the web PKI ecosystem.

