Closed Bug 1725039 Opened 3 years ago Closed 2 years ago

Network Solutions: 2021 Audit Observation #1

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bwilson, Assigned: keith.mckenney)

Details

(Whiteboard: [ca-compliance] [audit-finding])

As noted in https://bugzilla.mozilla.org/attachment.cgi?id=9233219, https://bugzilla.mozilla.org/attachment.cgi?id=9232451, and
https://bugzilla.mozilla.org/attachment.cgi?id=9233220, a couple of Network Solutions CAs performing direct OCSP signing do not have the Digital Signature bit.

Assignee: bwilson → keith.mckenney
Status: NEW → ASSIGNED

Network Solutions is required to file an Incident Report - https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Flags: needinfo?(keith.mckenney)

A minimum acceptable incident report will be sure to cover related issues from other CAs, as well as address why Network Solutions failed to detect these issues contemporaneously, as well as failed to report this issue once it was informed of it.

Because these are issues with a sub-CA, I'm making the same request of Sectigo as well, as one would expect the operating CA to have some vested interest in disclosure.

Flags: needinfo?(tim.callan)

Sectigo is following the open Web.com/Network Solutions bug 1721473, bug 1723121, bug 1725039, bug 1725041, bug 1725043, and bug 1725047. We are working with Network Solutions to provide information and advice in responding appropriately to them.

We fully expect that this particular bug will ultimately be CLOSED INVALID. Network Solutions will respond to this bug explaining why that is the case.

Flags: needinfo?(tim.callan)

We believe that this bug should be RESOLVED INVALID.

The "Network Solutions Certificate Authority" root certificate was issued in 2006 and then reissued in early 2011, which was before the BRs were first published and therefore before there was an unambiguous requirement to include KU=digitalSignature in CA certificates that directly sign OCSP responses. BR v1.0 section 1 states the following (and the latest version of the BRs still contains similar language):

“Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date.”

At the time of BR adoption Comodo, the CA service provider to Network Solutions, clearly articulated its practice for pre-existing roots on the IETF PKIX mailing list here, here, and here.

Flags: needinfo?(keith.mckenney)

Thanks. I certainly appreciate the pre-BR concerns here.

That said, I think there's an element worth understanding: following the effective date of the BRs, did you directly sign OCSP responses from this root certificate, despite the absence of the necessary keyUsage?

Flags: needinfo?(keith.mckenney)

Yes, we have directly signed OCSP responses from this root certificate and still do this today. The contemporary commentary on the IETF PKIX mailing list states why.

We disagree with the description of this keyUsage bit as “necessary” in this case. As comment 4 states, the affected root certificates precede the BRs, and so BR 7.1.2.1 did not apply at the time of their issuance. Since BR 7.3 (OCSP Profile) contains no requirement for OCSP response signing to only occur using root certificates issued in any specific time period or matching any specific requirement of any version of the BRs, we believe that BR 7.1.2.1 does not apply at the time of OCSP response signing either.

We are also confident that the BR 7.1.2.1 digitalSignature requirement is not enforced by clients, as evidenced by the many OCSP responses that Sectigo/Comodo and Network Solutions have both been signing from pre-BR roots for more than a decade without ever detecting any sign of interoperability problems.

If there is another argument for why the digitalSignature bit might be necessary, we don’t see what that is. We of course will consider and respond to any specific concern about another way this bit is thought to be necessary.

Flags: needinfo?(keith.mckenney)

I’m quite concerned by the response, and the supporting interpretation, in case it’s not clear. In particular, independent of the state of the BRs at the time this certificate was adopted, the BRs presently express a requirement with respect to responses. If we accept the argument here (which is unclear if this is Network Solutions’ argument or Sectigo’s argument), then it’s to say that any certificate that predates the BRs can be used to sign anything it wants.

This may seem extreme, but I do not see how a CA can, in good conscience, argue that they are somehow exempt from the requirements of 7.1.2.1(b), namely:

If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.

This is a clear present tense requirement. You have used the Root CA private key to sign an OCSP response. Independent of any issuance profile requirements, you don’t have the necessary bit set.

I’m further concerned with the analysis that fails to take into consideration past discussion and issues surrounding this. This is the sort of issue that raises several concerns:

  • Why did Network Solutions’/Sectigo’s previous auditors fail to find this.
  • Why did Network Solution/Sectigo fail to discover this in relation to other CAs incidents, such as Google Trust Services’ Bug 1652581
  • Why is Network Solutions, in 2021, arguing they can ignore the BRs because clients don’t complain, and what other systemic failures does that potentially signal?

To be abundantly clear, since Comment #2 appears to have not been addressed by Comment #3 not Comment #6: This is an incident. You used your root private key to sign OCSP responses without the digitalSignature bit set. This has been discussed in other CAs bugs. This has been discussed on the list. There is no excuse for ignoring this requirement.

I am deeply troubled by Comment #4’s apparent suggestion of “We told you we were going to keep misissuing, therefore it’s not misissuance”, and hope it was merely a hastily written reply in advance of a proper incident report, as expected and requested.

Flags: needinfo?(keith.mckenney)

(which is unclear if this is Network Solutions’ argument or Sectigo’s argument)

Hi Ryan. Network Solutions decides for itself what it wants to say and when it wants to say it, and the Sectigo team are not more than advisors. That said, we did advise this position, which Network Solutions chose to accept. If you reviewed the PKIX thread that Keith referenced in comment 4, you won’t be surprised to hear that this is my argument, and I am here to defend it.

If we accept the argument here...then it’s to say that any certificate that predates the BRs can be used to sign anything it wants.

That’s not the argument at all, and in any case “to sign anything it wants” is trivially refuted by BR 6.1.7, which imposes ongoing limitations on the types of certificate that Root CA Private Keys are permitted to sign.

Let’s start by looking for common ground. I think we can all agree that it’s a ”relevant event” (per BR 1.1) whenever a Root or Subordinate CA Private Key signs any block of data; and that therefore, at a minimum, that block of data must conform to the then-current BRs without any expectation of grandfathering (unless the then-current BRs explicitly say otherwise).

What we seem to disagree on at present is whether or not, or the extent to which, each ”relevant event” impinges on blocks of data that were signed by the same CA Private Key at any earlier time.

This may seem extreme, but I do not see how a CA can, in good conscience, argue that they are somehow exempt from the requirements of 7.1.2.1(b), namely:

If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.

This is a clear present tense requirement. You have used the Root CA private key to sign an OCSP response. Independent of any issuance profile requirements, you don’t have the necessary bit set.

I’m going to try to dissect your “clear present tense requirement” argument by following it to what I believe is its logical conclusion.

This particular BR requirement is an imperative in the first conditional, whereas the rest of BR 7.1.2.1(b) is made up of imperative sentences. The conditional “If the Root CA Private Key is used for signing OCSP responses” limits the circumstances under which the imperative “the digitalSignature bit MUST be set” applies. It’s important to realise that the conditional does not, and cannot, expand those circumstances. It’s called a conditional, not an ‘expansional’!

Whereas for the (unconditional) imperative sentences in BR 7.1.2.1(b) the circumstances are not limited, so these sentences could be rewritten as follows without changing the meaning:
“If the Root CA Private Key is or isn’t used for signing OCSP responses, KeyUsage MUST be present and MUST be marked critical and the bit positions for keyCertSign and cRLSign MUST be set.”

The conditional “If the Root CA Private Key is used for signing OCSP responses” is only present in the text because delegated OCSP signing is a thing. If ”the CA who issued the certificate in question” was the only option for OCSP response signing, then the conditional would not have been present in BR 7.1.2.1(b); instead, I expect it would have been worded as follows: ”This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign, cRLSign, and digitalSignature MUST be set.” (I’m still baffled as to why RFC3280/5280 chose to change the RFC2459 language, which clearly specified that the “cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information”; but this comment is already long enough without going over that ground again).

As a brief aside, as software engineers I’m sure we can agree that conditionals work exactly the same way in programming languages as they do in the English language: when an “if” statement is evaluated, the result only applies to the local thread of execution; the “if” condition doesn’t expand the scope so that a true result would cause the statement(s) in the conditional block to be executed in other threads of execution. Incidentally, here’s how BR 7.1.2.1(b) might look if written as pseudo-code:

if (true) then {
    KeyUsage MUST be present and MUST be marked critical.
    Bit positions for keyCertSign and cRLSign MUST be set.
} else {
    // This branch is never reached.
}

if (the Root CA Private Key is used for signing OCSP responses) then {
    The digitalSignature bit MUST be set
} else {
    No stipulation for the digitalSignature bit
}

The point I’m trying to make is that if we accept your argument that the scope of “the digitalSignature bit MUST be set” in BR 7.1.2.1 impinges on Root Certificates that were issued prior to the BRs, then (since “if” is conditional, not ‘expansional’) it follows that ALL of the present tense imperative statements in the current BRs MUST also impinge on all Root Certificates and Subordinate CA Certificates, both those issued prior to the original BRs and those issued since.

This impingement would imply that many pre-BR Root Certificates should have been the topic of complaints from browsers / other community members and the topic of CA Compliance Incidents by now! Let’s review a handful of BR requirements so that I can show you what I mean...

  • BR 7.1.1 (”Certificates MUST be of type X.509 v3”). This requirement was in BR v1. It’s a ”clear present tense requirement”, but were any pre-BR X509v1 Root Certificates (e.g., https://crt.sh/?id=10) penalized for non-compliance when they continued to issue Subordinate CA Certificates (e.g., https://crt.sh/?id=10244770) after the BRs were first adopted? Or were they grandfathered by the various browser/OS root programs? (Answer: They were grandfathered).
  • BR 7.1.2.1(b) (”keyUsage...MUST be marked critical”). This requirement was in BR v1. It’s a ”clear present tense requirement”, but were any pre-BR Root Certificates with non-critical Key Usage extensions (e.g., https://crt.sh/?id=1877101) penalized for non-compliance? Or were they grandfathered? (Answer: They were grandfathered).
  • BR 7.1.2.1(d) (”extKeyUsage...MUST NOT be present”). This requirement was in BR v1. It’s a ”clear present tense requirement”, but were any pre-BR Root Certificates containing the EKU extension (e.g., https://crt.sh/?id=34) penalized for non-compliance? Or were they grandfathered? (Answer: They were grandfathered).
  • BR 7.1 (”CAs SHALL generate non‐sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG”). This requirement was first added in BR v1.3.7 and came into force about 5 years ago. It’s a ”clear present tense requirement”, but were any pre-existing Root Certificates with insufficient serial number entropy (e.g., https://crt.sh/?id=12731951) penalized for non-compliance? Or were they grandfathered? (Answer: They were grandfathered).
  • Pre-existing Root Certificates with sha1WithRSAEncryption self-signatures were grandfathered when sha1WithRSAEncryption was deprecated for new certificate issuance.
  • Pre-existing RSA-1024 Subscriber Certificates were grandfathered when <RSA-2048 was deprecated for new certificate issuance.
  • I could go on, but I think I’ve made my point.

Please note that I am supporting my argument ”with the current BRs, and not one Root Program”. The ”relevant events” clause in BR 1.1 is my argument that grandfathering is a BR-compliant concept, and the Root Programs’ unanimous inaction over so many previous 'violations' of ”clear present tense requirements” by pre-existing Root Certificates is my evidence of how that grandfathering has been consistently applied.

I’m further concerned with the analysis that fails to take into consideration past discussion and issues surrounding this.

I believe I have considered the past discussion and issues surrounding this.

Why did Network Solutions’/Sectigo’s previous auditors fail to find this.

My guess is that they too believed that the pre-BR Root Certificates belonging to Network Solutions and Sectigo should be treated as grandfathered.

Why did Network Solution/Sectigo fail to discover this in relation to other CAs incidents, such as Google Trust Services’ Bug 1652581

I was watching that bug - see bug 1652581 comment 22. My assessment at the time was that GTS were indeed out-of-compliance and did need to replace their since-BR Root Certificates in order to continue to directly sign OCSP responses, but that the same was not true for Sectigo and Network Solutions because our pre-BR Root Certificates had been grandfathered.

I see now that 1 of the 6 Root Certificates (“GlobalSign Root CA - R2") replaced in bug 1652581 was a pre-BR Root Certificate. When I was watching that bug, I failed to take this on board and to realise that (in my opinion) GTS’s replacement of this pre-BR Root Certificate wouldn’t have been necessary. Mea culpa.

Why is Network Solutions, in 2021, arguing they can ignore the BRs because clients don’t complain, and what other systemic failures does that potentially signal?

I think that’s a gross mischaracterization of the third paragraph of comment 6. That paragraph is not an argument of any sort; it’s merely an observation that clients don’t complain. Grandfathering is the only “ignore the BRs” argument in comment 6.

Incidentally, GTS did not attract this criticism for making the same observation (that clients don’t complain) in bug 1652581 comment 0 and bug 1652581 comment 2.

This is an incident. You used your root private key to sign OCSP responses without the digitalSignature bit set.

I am deeply surprised and concerned that you believe that this bug is an Incident because, if you’re correct, the logical conclusion seems to be that grandfathering of pre-existing Root Certificates has been an illusion. However, I think the evidence shows that grandfathering of Root Certificates has been a very real thing, and I did think that in comment 5 you had accepted this.

I realize that you’re keen to see pre-BR Root Certificates deprecated as soon as possible, and I can’t help but feel that this (non-)Compliance conversation, regardless of the outcome (but especially if grandfathering has been an illusion!), will bleed into that Deprecation conversation.

I am deeply troubled by Comment #4’s apparent suggestion of “We told you we were going to keep misissuing, therefore it’s not misissuance”

We did not, and do not, believe that we were misissuing. Because grandfathering.

We have fully complied with the BR requirement to include the digitalSignature bit in new Root and Subordinate CA Certificates ever since we first became aware of that requirement, which was prior to the Effective Date of BR v1.

One final frustration: We (Comodo) were doing “the Root CA Private Key is used for signing OCSP responses” before it was cool. In fact we made it cool, blazing a trail for other CAs to follow. (To support this claim I could dig up some ancient Firefox and OpenSSL bugs that I filed / helped fix to make this mode of OCSP response signing viable in the WebPKI). If this bug is an Incident, then I can’t help but feel like we’re being punished for being an early adopter.

(In reply to Rob Stradling from comment #8)

This impingement would imply that many pre-BR Root Certificates should have been the topic of complaints from browsers / other community members and the topic of CA Compliance Incidents by now! Let’s review a handful of BR requirements so that I can show you what I mean...

  • BR 7.1.1 (”Certificates MUST be of type X.509 v3”). This requirement was in BR v1.
  • BR 7.1.2.1(b) (”keyUsage...MUST be marked critical”). This requirement was in BR v1.
  • BR 7.1.2.1(d) (”extKeyUsage...MUST NOT be present”). This requirement was in BR v1.
  • BR 7.1 (”CAs SHALL generate non‐sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG”). This requirement was first added in BR v1.3.7 and came into force about 5 years ago.
  • Pre-existing Root Certificates with sha1WithRSAEncryption self-signatures were grandfathered when sha1WithRSAEncryption was deprecated for new certificate issuance.
  • Pre-existing RSA-1024 Subscriber Certificates were grandfathered when <RSA-2048 was deprecated for new certificate issuance.
  • I could go on, but I think I’ve made my point.

I'd like to point out that those requirements are all profile errors, that can be tested with access to only the certificate†.

†: Only for the 64 bits from a CS(P)RNG-requirement it is hard to prove or disprove compliance with only one certificate; but even one certificate can get you a basic idea on the entropy of the serial number.

Please note that I am supporting my argument ”with the current BRs, and not one Root Program”. The ”relevant events” clause in BR 1.1 is my argument that grandfathering is a BR-compliant concept, and the Root Programs’ unanimous inaction over so many previous 'violations' of ”clear present tense requirements” by pre-existing Root Certificates is my evidence of how that grandfathering has been consistently applied.

Grandfathering only seems to have been applied to existing signed data (as in, the certificate exists, so lets keep it valid, but no new certificates may be created with [sha1, less than 64 bits of CSRNG, ...]. As certificates cannot be modified and these old certificates likely met the requirements at the moment of issuance, these old certificates are grandfathered as there is no way to know or comply with future requirements. Could you provide an example of a grandfathered situation in which new signatures were made on (otherwise) non-compliant data (within the scope of the root programs / BR) without that being classified as an Incident and non-compliance?

The examples in your list all point to profile errors that can be validated and tested with only access to the (newly) signed certificate. As OCSP is the signing of new data, I do not think this is comparable to the grandfathered certificate profiles: the requirements clearly state that OCSP may only be signed directly by the root CA iff the root CA certificate has digitalSignature set. An inaction to comply with new requirements is failing to comply with those new requirements.

As each OCSP signature is (supposedly) generated in the last few days, the latest BR apply to that operation of signing OCSP signatures, and if the root CA certificate does not fulfill the prerequisites for that, then they are non-compliant.

I believe the issue is not that the CA certificate does not contain the Digital Signature Bit, but that the CA actively used that certificate without the Digital Signature Bit to sign OCSP responses that it's not allowed to sign (because it does not comply with the Digital Signature Bit requirement).

...

That being said, I think that this requirement probably should be moved to s4.9.9 "On‑line revocation/status checking availability" or s4.9.10 "On‑line revocation checking requirements" from s7.1.2.1(b) "Certificate profile > ... > Root CA Certificate", as this misplacement seems to play a large role in why Sectigo argues that this requirement is only for root CAs issued after the requirements became effective (as the CA was issued according to the then-current profile requirements).

(In reply to Rob Stradling from Comment #8)

Incidentally, GTS did not attract this criticism for making the same observation (that clients don’t complain) in bug 1652581 comment 0 and bug 1652581 comment 2.

I believe you missed some deep concern and frustration on the list.

I am deeply surprised and concerned that you believe that this bug is an Incident because, if you’re correct, the logical conclusion seems to be that grandfathering of pre-existing Root Certificates has been an illusion

I think the flaw in your argument is that you're trying to argue that, in the following text:

"If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set."

That it should be read not as written, but instead as:

"If the Root CA Private Key will be used for signing OCSP responses, then the digitalSignature bit MUST be set."

That is, it's a requirement that only applies at time of issuance, not based on the activity itself (using the CA private key for signing OCSP responses).

The discussion here of grandfathering here similarly seems to be an argument against reading the requirement as:

"If the Root CA Private Key has ever been used for signing OCSP responses, then the digitalSignature bit MUST be set."

However, I'm simply highlighting that the requirement, as written, is "is". The BRs are full of examples in which new requirements are imposed on a go-forward basis. The requirement here, introduced in that first version, is that either you have the DigitalSignature bit set when issuing OCSP responses, or you use Delegated Responders. It does not retroactively apply to the certificate issuance, but if your certificate was not issued in a manner comporting to the profile, then you can't issue OCSP responses until you resolve that (e.g. through delegated responder).

This is no different than the prohibition on a go-forward basis of 1024-bit certificates, for example. It's saying that, in pseudo-code

if (digitalSignature not present)  {
  The CA MUST NOT sign an OCSP response except through a delegated responder
} else {
  The CA MAY sign an OCSP response
}

These are go-forward requirements, and that's why the nature of this makes it an incident. It's conceptually similar to issuing a 10-year cert after the effective date of the BRs - The Root CA Private Key is used to sign an OCSP response (present tense), therefore the (present) rules apply.

(In reply to Matthias from comment #9)

I believe the issue is not that the CA certificate does not contain the Digital Signature Bit, but that the CA actively used that certificate without the Digital Signature Bit to sign OCSP responses that it's not allowed to sign (because it does not comply with the Digital Signature Bit requirement).

Indeed! This was the similar remark to Google Trust Services regarding their omission. The "incident" here is that the Root CA Key was used after an effective date to sign something new, which was prohibited at the time it was signed.

That is, as Rob notes, delegated signing is a thing. The logical consequence of such a requirement is that as of the effective date, if a Root CA lacked the digitalSignature bit, then it MUST NOT sign OCSP responses, and instead must introduce a delegated signing certificate. That would be fully compliant.

That being said, I think that this requirement probably should be moved to s4.9.9 "On‑line revocation/status checking availability" or s4.9.10 "On‑line revocation checking requirements" from s7.1.2.1(b) "Certificate profile > ... > Root CA Certificate", as this misplacement seems to play a large role in why Sectigo argues that this requirement is only for root CAs issued after the requirements became effective (as the CA was issued according to the then-current profile requirements).

Yes indeed, this is one of the things on the plate for the validation. To describe precisely the profile of OCSP responses, but also describe the profile of what can issue OCSP responses. It's a bit in flux right now with many discussions going on :)

As a matter that is directly relevant to this conversion, Network Solutions and Sectigo have decided to transition the Network Solutions and Web.com branded digital certificate businesses entirely to a managed CA model, managed by Sectigo.

We intend to announce a target transition date and other relevant details by the end of this month.

We are looking into the details of transitioning with an eye toward an announcement by the end of the month.

Flags: needinfo?(keith.mckenney)

We are working on the details of our full transition to managed CA services. We are aiming to announce a transition schedule by the end of the month.

We have targeted a full transition to the managed service on or before November 8, 2021.

There has been some discussion on this bug about the proper form of certificates used to sign OCSP responses, and we expect there will be more discussion on this topic in other forums as the community works this one out.

From the practical perspective of Network Solutions as a CA Owner, regardless of the resolution the community comes to for going-forward CAs, we can’t see how it makes sense to attempt to change our roots during their phase-out. The queue for adding new roots into root stores is months long under the best of circumstances, and with Mozilla’s recent statements about prioritization of root requests, we imagine that roots for sunsetting CA owners will likely drop to the very bottom of that list.

Therefore, we are planning on focusing our efforts on the phase-out and continuing with the roots we have in place today until the phase-out is complete.

Are there any outstanding questions on this bug?

We have set a new target date for switching the last of our CA operations to Sectigo. We are aiming for November 17.

We have completed our transition to a full managed CA model through Sectigo. The last leaf certificate issued under our own roots will expire on 2022-12-13.

1. How your CA first became aware of the problem

Based on our 2021-22 WebTrust audit reports, Ben Wilson wrote up this bug. We felt our actions were in alignment with established practices for roots that existed prior to the BRs and expressed such in response. The dialog that ensued is visible in this thread, as is the eventual pronouncement by the Chrome Root Authority Program that it considers these roots noncompliant for direct OCSP signing.

2. Timeline

August 10, 2021, 15:29 PDT
Ben Wilson posts this bug.

August 13, 11:34 PDT
In comment 4 we express our opinion that this bug should be RESOLVED INVALID due to established patterns of treating roots issued prior to published requirements.

August 13 through September 9
Public discussion from multiple parties occurs on this thread.

September 9, 12:24 PDT
In comment 10 the Chrome Root Authority Program declares that our use of these roots for direct OCSP signing is noncompliant.

September 10, 11:56 PDT
We state in comment 11 our intention to discontinue acting as a CA Owner and transition our remaining certificate offerings to a managed CA model.

September 10 to October 8
We research the pragmatics of transitioning our CA, including our response to this particular incident in light of our updated understanding of requirements. We conclude that updating our OCSP roots is impractical for reasons stated in comment 15 and announce our intention to focus on transitioning to a managed CA model rather than updating roots for a service that we will soon be sunsetting.
On October 8 we publish this conclusion in comment 15. We receive no response from the Bugzilla community, which is normative behavior for assent among Bugzilla followers. Based on that (lack of) response, we continue with our focused plan to discontinue our CA services.

November 12
We switch our last CA to the managed model. No new certificates will be issued from the Network Solutions roots.

December 13, 2022
The latest notAfter date for certificates issued from our owned CA.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.

This is not a matter of certificate misissuance. For the reasons stated in part 2 of this post, we intend to continue signing OCSP responses directly from these roots for the remaining lifetime of our active certificate base.

4. Summary of the problematic certificates

This is not a matter of certificate misissuance.

5. Affected certificates

This is not a matter of certificate misissuance.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now

We created our "Network Solutions Certificate Authority” root before the BRs were created. After the BRs went into effect, major browser programs honored pre-existing roots in many instances. We believed that this common practice applied to direct signing of OCSP responses and continued to do so on the good faith understanding that our operations were fully in accordance with accepted community practices. That belief and our practice went unchallenged until August of this year.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future

We have transitioned away from signing new certificates using our owned roots and now operate purely using a managed CA model. The last certificate issued on our own roots is set to expire on December 13, 2022.

Are there any questions or comments on the incident report we posted last week or any other aspects of this bug?

Flags: needinfo?(bwilson)

Ben, we believe this issue is well explored and that we have clearly articulated our response. As there have been no additional comments, we believe it’s time to close this bug. Can we close this bug?

I will close this bug sometime next week - to give anybody a chance to ask any more questions or make additional comments.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED

In comment 19 we stated we were transitioning away from signing new certificates using the Network Solutions Certificate Authority root and its Subordinate CA’s. Earlier this month, however, we saw the need to issue 2 certificates in order to stay compliant with the Baseline Requirements. The purpose of this comment is to inform the community of this fact and the reasoning behind it.

The Baseline Requirements require CAs to host test websites with at least a revoked, an expired, and a valid certificate that chain up to each publicly trusted Root Certificate. As the existing revoked and valid test certificates were about to expire, we have replaced them. As these certificates are for our own use, the issuance of these 2 certificates does not impact our existing plans for removing this Root Certificate from the Mozilla Root Store.

Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [audit-finding]
You need to log in before you can comment on or make changes to this bug.