Sectigo: Subject field with unvalidated information included in certificates
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: tim.callan, Assigned: tim.callan)
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
Attachments
(2 files)
|
Assignee | |
Comment 1•4 years ago
|
||
1. How your CA first became aware of the problem
As part of our ongoing internal code review project, we discovered that our systems had the possibility of issuing OV and EV certificates that contain the postOfficeBox subject field. As we were not aware of this possibility, we had no requirement to ensure the information that would erroneously populate this field was valid.
Though the postOfficeBox field is permissible for inclusion in OV certificates, any field containing unvalidated information is not permissible. Furthermore, the EV Guidelines prohibit this field at all for EV certificates.
2. Timeline
September 30, 2021
Internal code review reveals the potential to issue certificates with postOfficeBox.
Development ticket created.
October 10
Fix deployed
October 11
Investigation of corpus of certificates begins. An initial query reveals 23 EV certificates with the postOfficeBox field, which are known to be noncompliant, and 740 OV certificates, which will require further investigation.
EV certificates scheduled for revocation on October 16.
October 12
Investigation of OV certificates complete, revealing 312 false positives and 428 noncompliant certificates. The false positives are certificates in which contents of the postOfficeBox field match actual post office box information that was validated at time of issuance.
OV certificates are scheduled for the same revocation batch on October 16 to match the EV revocation schedule.
October 16
Revocation of all affected certificates scheduled to occur. We will follow up to confirm revocation after it is complete.
3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
We have deployed a code fix and are no longer able to issue certificates with the postOfficeBox OID.
4. Summary of the problematic certificates
453 total certificates.
428 OV certificates issued between July 4, 2019, and Sept 16, 2021.
25 EV certificates issued between Aug 20, 2019, and June 25, 2021.
5. Affected certificates
The list of affected certificates is available in attachment 9246175 [details].
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now
In the very early days of Comodo the product team chose a set of fields for inclusion in OV certificates from among those available. postOfficeBox was among them, as it seemed a potentially valuable piece of information about a business and how it could be reached. The company included this field in its first set of API calls and early web forms for ordering. These API calls and web forms remain in production. In particular, the API is still widely used today.
While it is not possible to include a value for postOfficeBox in a certificate order through our modern ordering experiences such as our retail storefronts, ACME, or the Sectigo Certificate Manager platform, nonetheless it is possible to populate this field through one of these earlier services. In the event that such an order came in prior to our recent code deployment, the submitted data would pass through to the issued certificate without requiring review from the Validation team – this because our contemporary processes and systems had no expectation of postOfficeBox data existing as an actual field in an actual certificate.
When EV certificates became reality, we built that issuance process upon our existing OV systems. The first version of the EV Guidelines did not prohibit this field, so there was no effort to remove it. When a subsequent update to the EV Guidelines prohibited additional fields beyond those specifically prescribed, Comodo should have identified and removed the ability to publish this field in an EV certificate. We can see now that did not happen at the time.
In the case of EV certificates, postOfficeBox is simply disallowed, so the 23 EV certificates detected with this field are all misissued. For OV certificates, postOfficeBox is allowed so long as the information it contains has been validated. In this case we compared the contents of the postOfficeBox field to the confirmed address information in our records for each certificate. Those with a match to a validated post office box were issued correctly and are not on the revocation list. Those with contents in the postOfficeBox field that are not post office boxes (even if they match validated address information) or that do not match validated information (even if they appear to be legitimate post office boxes) are misissued and are scheduled for revocation.
These certificates were not detected before now because the total volume is low. They did not appear in our random sample for internal or external audit, and neither we nor a member of the community found them otherwise. We ultimately discovered them after internal code review revealed the possibility that such certificates could be issued.
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 blocked issuance of any certificate with the postOfficeBox field. This addresses the misissuance problem for both EV and OV certificates.
This incident and the revocation exercise are a direct result of our initiative to investigate and verify our issuance systems and practices with the eventual goal of ensuring 100% compliance for all issued certificates. Along with investigation of our certificate base, code review is one of the methods we are applying toward that goal.
Most of the code we have reviewed and documented so far has not revealed issuance problems, and therefore we have no discussion of these reviewed code modules on Bugzilla. On this occasion it did, however. There is the possibility of similar future discoveries, and in the event they occur we will report and fix them and revoke the affected certificates as you see here.
|
||
Updated•4 years ago
|
|
||
Comment 2•4 years ago
|
||
Hello Tim,
Can you give us more information about why https://crt.sh/?id=3608838685 is not included in your attachment? As this certificate looks like in the same case (i.e. including postOfficeBox) and has been revoked via CRL too.
Thanks,
|
|
Assignee | |
Comment 3•4 years ago
|
||
|
|
Assignee | |
Comment 4•4 years ago
|
||
(In reply to Gea-Suan Lin from comment #2)
Can you give us more information about why https://crt.sh/?id=3608838685 is not included in your attachment?
The original list of certificates that we identified and revoked was correct. When preparing the list of crt.sh links for publication to this bug, we accidentally omitted a few certificates and included a few duplicates. Because the total count was correct at 453, we failed to detect the error.
I have included the corrected list as attachment 9247849 [details].
This confusion was enabled by the fact that our original list in attachment 9246175 [details] quoted crt.sh IDs rather than certificate serial numbers. crt.sh IDs aren’t known to our CA system (whereas certificate serial numbers are), so the process for producing a list of crt.sh IDs involves more steps, cross-referencing between two systems, and therefore is more prone to error. Another nice property of serial numbers is that they automatically deduplicate precertificate/certificate pairs. We intend to quote serial numbers in future lists of problematic certificates.
Another nice property of serial numbers is that they automatically deduplicate precertificate/certificate pairs. We intend to quote serial numbers in future lists of problematic certificates.
I believe that this "deduplication" is exactly the reason why a fingerprint or crt.sh ID of the certificate are suggested in the problem reporting wiki: There may be more than one objects signed by a CA with the same serial number, making problem reports with only serial numbers ambiguous.
Feel free to quote serial numbers, but please do so in addition to the fingerprint or crt.sh identifier of the offending (pre-)certificate; not as a replacement of those.
PS. Note that for S/MIME certificates both the certificate serial number and a sha256 fingerprint are requested, not either / or.
|
||
Comment 6•3 years ago
|
||
I believe that this "deduplication" is exactly the reason why a fingerprint or crt.sh ID of the certificate are suggested in the problem reporting wiki: There may be more than one objects signed by a CA with the same serial number, making problem reports with only serial numbers ambiguous.
Prior to the BRs, certificate serial numbers only needed to be unique “for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate)”, so indeed it would have been possible for a CA Owner to issue multiple certificates with the same serial number, each signed by a different CA. However, “Effective September 30, 2016, CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG”, which means that we do not duplicate serial numbers across multiple “objects”, with the (permitted) exception of a precertificate sharing the same serial number as its corresponding certificate.
As a precertificate and its corresponding certificate share identical qualities as it relates to nearly all instances of misissuance, we feel it is wholly appropriate to deduplicate them when reporting. Indeed, RFC6962 explains that ”misissuance of the Precertificate is considered equal to misissuance of the final certificate”. This is true even in the rare cases where a CA issues a precertificate but doesn’t go on to issue a corresponding certificate.
As both https://crt.sh/?id= pages and https://crt.sh/?serial= searches require use of crt.sh to obtain the full details of the referenced certificates, we see no benefit to the former over the latter; in fact, in addition to the benefits to Sectigo that we outlined in comment 4 we also see a number of benefits to the community of CAs reporting serial numbers instead of crt.sh IDs or certificate fingerprints:
-
CT compliance does not require the logging of a leaf certificate if the corresponding precertificate has been logged, which means that the leaf certificate may or may not have been logged by the time of the report. In the event that the leaf certificate is logged later, a https://crt.sh/?serial= search result page mentioned in a report will automatically pick it up. crt.sh IDs and certificate fingerprints do not share this property.
-
Whilst Sectigo is of course hugely in favour of and committed to crt.sh, it’s worth pointing out that crt.sh IDs are entirely specific to crt.sh. They are useful for referring to certificates using short URLs, but you can’t look up a crt.sh ID in other collections of WebPKI certificates (such as Censys). For this reason, as crt.sh author I have contemplated the idea of removing crt.sh IDs from the https://crt.sh/ UI in order to encourage the use of certificate identifiers that aren’t specific to crt.sh.
-
Certificate fingerprints are computed over data that isn’t entirely covered by the CA’s signature. It’s currently impossible to prevent logs (and hence crt.sh) from being polluted by non-canonical fingerprints, because anyone can tamper with the unsigned parts and then submit altered certificates to CT logs. For example:
-
Some CT logs accept modified certificates that have non-compliant signature algorithm parameters (e.g., see ”This is not the certificate you're looking for”, which is a modified version of https://crt.sh/?id=23480479).
-
ECDSA signatures are malleable. Section 4 of "Are Certificate Thumbprints Unique?" explains that “Given an ECDSA signature (r, s) on message m, the value (r, −s (mod n)) is also a valid signature on m.” Using this technique, I was able to create https://crt.sh/?id=5551359038 as a modified version of https://crt.sh/?id=5537768847.
-
The non-canonical fingerprint problems could be avoided by using the fingerprint of the TBSCertificate instead, and indeed that’s what we’ve done for SCTs in CTv2 (aka 6962-bis, which is due to be published imminently as RFC9162). However, I would say that the feasibility of using this approach in incident reports is currently hampered by the general lack of availability of tools to generate the fingerprint of the TBSCertificate component of a certificate.
Another argument in favour of dealing with serial numbers is that this is what most revocation mechanisms use. Tracking the revocation of certificates affected by an incident is a common factor of many CA incident reports, and it ought to be simpler to do this tracking if the incident report and revocation mechanisms are using the same certificate identifiers.
Feel free to quote serial numbers, but please do so in addition to the fingerprint or crt.sh identifier of the offending (pre-)certificate; not as a replacement of those.
We feel that reporting serial numbers is fully in alignment with the spirit and intention of Mozilla’s guidance and for the reasons stated above is in fact better than the options mentioned on the wiki. As Mozilla has offered a recommendation and not stipulated a requirement, we believe it well within scope for a public CA to discern and make this improvement. In the spirit of CAs helping CAs through open communication, we have explained our reasons here.
Therefore, unless someone makes a convincing argument otherwise or we receive specific guidance to the contrary from Mozilla or another major root program, we intend to continue with the policy stated in comment 4.
|
||
Comment 7•3 years ago
|
||
While the explanation is appreciated, it overlooks a critical factor worth considering:
- Multiple CAs have misissued certificates involving reused serial numbers. Sectigo (formerly Comodo) has been involved in helping draw attention to these in the past, but one notable incident involved reuse of a serial in a CA certificate used for MITM. As such, serial numbers should not be considered sufficient to unambiguously identify a certificate, within a single CA, and obviously and certainly not across multiple different CA issuers. The present policy was drafted in light of those specific experiences, and the desire to unambiguously represent the entire certificate data (“complete” certificate data), rather than on a potentially misissued partial amount
Comment #6 rightfully calls out that IDs are a specific implementation detail of crt.sh, but the fact that a serial search can return multiple certificates - even if pre and final - is arguably exactly why it’s inappropriate to use as a representation of a binding commitment by the CA. And while signatures are malleable, that seems irrelevant to the policy objective of such a binding commitment: malleability allows you to create distinct hashes, but as long as the hash is resistant to collisions, it represents an unambiguous commitment to at least that certificate.
I would hope Sectigo reconsider its present strategy, because while I strongly support the desire to avoid coupling to crt.sh, I believe the present approach in Comment #3 fails to comply with the spirit of the current policy, and, arguably, the letter as well.
|
|
||
Comment 8•3 years ago
|
||
Hi Ryan. In comment 6 we said that we would change course if we received “specific guidance to the contrary from Mozilla or another major root program”. We're aware of your recent announcement, but we're not clear if comment 7 was written in a personal capacity or if we were expected to treat it as an official communication from the Chrome Root Authority Program. We've chosen to do the latter.
This week we have created a tool that takes as input a list of certificate IDs (from our CA database) and then automatically creates either a Markdown table or a CSV file of crt.sh links for matched precertificates and leaf certificates, identified by SHA-256 fingerprint and grouped by serial number. To ensure that all of the crt.sh links work, this tool also automatically initiates CT log submission for any affected certificate that we haven't previously submitted to any CT logs. We will use this tool to generate and report future certificate lists on Bugzilla. We believe this addresses your concern as well as automating what had been an error-prone process at our end.
Here's a sample Markdown table produced by the tool, which corresponds to the first three https://crt.sh/?id= links in attachment 9246175 [details]:
| Serial Number | Certificate | Precertificate |
|---|---|---|
| 0096C47DDF14E53B470C8DBAA869B3099A | Certificate | Precertificate |
| 271C5752AE432808CEE6284BE8133516 | Certificate | Precertificate |
| 2C056061557943458C6F6BC7DBDFF5EE | Certificate | Precertificate |
|
|
||
Comment 9•3 years ago
|
||
Written in a personal capacity, as stated both in that message and the Wiki. I’m not sure why Sectigo would chose to selectively ignore that :)
However, regardless of that interpretation, my point was to highlight both the existing guidance and context, to demonstrate how the ambiguity has already been previously addressed: namely, the expectation for complete certificate details.
I agree that your proposed approach seems to match that, by ensuring an unambiguous singular representation for complete details.
|
|
||
Comment 10•3 years ago
|
||
Written in a personal capacity, as stated both in that message and the Wiki. I’m not sure why Sectigo would chose to selectively ignore that :)
Hi Ryan. Thanks for clarifying. When I read "I'm handing off representing the Chrome Root Program" in that message I thought it sounded like an ongoing process that would culminate with the start of your sabbatical. You wrote that you'll "still be around from time to time", but as far as I can see you haven't quite gone anywhere yet! ;-)
Anyway, we at Sectigo wish you all the best for your sabbatical and for the "unique career opportunities at Google" you intend to pursue after that. Thanks for all of the positive change that you've brought to the WebPKI over the past decade+. :-)
|
|
||
Comment 11•3 years ago
|
||
I'm fully on sabbatical now, but that's how troubled I was (and am) by the comments and the direction this bug has taken, given the thoughtful replies in Comment #2 and Comment #5. It was concerning enough interrupt that vacation by virtue of a CA with a long-standing pattern of deeply-concerning issues seemingly deeming the concerns raised in Comment #5 as not "a convincing argument otherwise" (Comment #6). When I reiterated and expanded those concerns in Comment #7, it seems that Comment #8 was still not convinced by the merits, but instead based on a (mistaken) belief that it was "specific guidance to the contrary from Mozilla or another major root program". This is surprising, given given Sectigo's familiarity with the limits of serial numbers, and presumably discussions such as Bug 1731586 (in which serial number is noted as insufficient).
While I'm happy to see that there's a path forward here, reflected in Comment #8 and Comment #9, and appreciate the kind words of Comment #10, I'm personally saddened that the technical merits still weren't enough, either when originally raised or reiterated. I would have hoped by now that CAs would wish to go above and beyond what they believe is necessary to avoid even the slightest hint of impropriety or unaddressed concern. That shouldn't require a clarification or guidance from any root program, and part of why the incident reports have been open: to allow concerns to be voiced and addressed.
|
|
||
Comment 12•3 years ago
|
||
Would it be good or useful to discuss the "right way(s)" to disclose certificates in an mdsp thread? In other words, should the Mozilla incident reporting wiki page be updated to replace "crt.sh ID" with something else? https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report Right now it says, "5. In a case involving TLS server certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem."
|
||
Comment 13•3 years ago
|
||
(In reply to Rob Stradling from comment #6)
Certificate fingerprints are computed over data that isn’t entirely covered by the CA’s signature. It’s currently impossible to prevent logs (and hence crt.sh) from being polluted by non-canonical fingerprints, because anyone can tamper with the unsigned parts and then submit altered certificates to CT logs. For example:
Some CT logs accept modified certificates that have non-compliant signature algorithm parameters (e.g., see ”This is not the certificate you're looking for”, which is a modified version of https://crt.sh/?id=23480479).
ECDSA signatures are malleable. Section 4 of "Are Certificate Thumbprints Unique?" explains that “Given an ECDSA signature (r, s) on message m, the value (r, −s (mod n)) is also a valid signature on m.” Using this technique, I was able to create https://crt.sh/?id=5551359038 as a modified version of https://crt.sh/?id=5537768847.
You are correct that these problems exist, but they are parallel to what we need from fingerprints: We need fingerprints to uniquely identify signed data. As Ryan said in comment #7, multiple CAs have been found signing certificates with duplicate identifiers; and fingerprints over the full signed certificate are the only way to uniquely identify the certificate. Sure, there may be multiple ways to describe a certificate (that will result in multiple fingerprints), but that's not a significant problem for us to worry about:
The CA provides fingerprints in their report; which the community can then match to CT records (assuming no fingerprint collisions). If the community can't find a provided fingerprint, the CA can be asked to provide the missing certificate data, which can then be verified by the community (assuming fingerprint algorithm with strong pre-image attack resistance).
(In reply to Ben Wilson from comment #12)
Would it be good or useful to discuss the "right way(s)" to disclose certificates in an mdsp thread? In other words, should the Mozilla incident reporting wiki page be updated to replace "crt.sh ID" with something else? https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report Right now it says, "5. In a case involving TLS server certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem."
I don't think we need to replace the reference to crt.sh, as that is only a recommendated way of communicating the requested full certificate data. Unless of course we don't trust crt.sh ids to not be a stable identifier of a certificate (where 'stable identifier' includes at least that the id of a certificate does not change, and that crt.sh stays around for long enough to be relevant during all of an incident's lifecycle)
|
||
Comment 14•3 years ago
|
||
[This is my first post on Bugzilla, so please pardon any formatting follies as I get the hang of things!]
A few updates and comments on behalf of Chrome's Root Program:
-
Chrome's Root Program is still in the planning phase, and we will communicate specific requirements related to our incident reporting process at a future date. As a general reminder to those following this thread (and not specifically Sectigo), our transitional policy outlines our expectations for incidents to be reported to chrome-root-authority-program@google.com (Sectigo notified us of this incident on October 18, 2021). We are actively following incident discussions on Bugzilla.
-
We agree with the discussion in Comments #7 and #13 (re: serial numbers do not offer an unambiguous way of identifying problematic certificates). The example reporting approach shared by Rob in Comment #8 is favorable, though, in the long-term, Chrome may require problematic certificate(s) to be directly attached to incident reports. This will allow us to facilitate investigation if crt.sh is unavailable or the corresponding record is missing - or possibly perform additional automated inspection and monitoring.
-
Regarding Ben's question in Comment #12 - it looks like this discussion has shifted to a dedicated thread on MDSP; I'll follow up there.
|
|
||
Comment 15•3 years ago
|
||
[Note: This comment was drafted prior to comment 13. Due to our peer review process, which did not make any substantive changes, I’m only able to post it now.]
(In reply to Ryan Sleevi from comment #11)
I'm personally saddened that the technical merits still weren't enough, either when originally raised or reiterated.
We may have given a false impression in earlier posts about our process in this case. Let us clarify.
In comment 6 we stated,
unless someone makes a convincing argument otherwise or we receive specific guidance to the contrary from Mozilla or another major root program, we intend to continue with the policy stated in comment 4.
This sentence communicates two salient points about our process. The first is that either of these conditions would be sufficient to change our position. We said or, not and. The second is that our focus for this discussion was on our own going-forward policy for reporting certificates, as opposed to attempting to iron out greater policy issues that would apply to all CAs. (Comment 12 and the resulting m.d.s.p. thread are now taking the conversation in that direction, but that's a new development.) In other words, we were extremely pragmatic in our focus.
Once we perceived that one of those conditions had been met, there was no utility in continuing the thread, so we did not. Instead, as described in comment 8, we shifted to quickly creating a tool that would allow us to reliably report certificates and precertificates according to the community’s needs so that we could continue moving forward on other issues.
We now understand that with comment 7 we had not received that direct guidance from a major root program, but we hope comment 10 shows how that wasn’t clear to us at the time. In all honesty, we felt that treating comment 7 as if it was a communication from a root program (even if it turned out that it wasn’t) was the responsible thing to do. (We’ve found that it’s often wise to adopt the most restrictive of multiple potential interpretations, especially when there seems to be little or no downside to doing so). Another factor in that decision was that the Policy Participants wiki page states that it is a “list of...participants in the MDSP mailing list”; since Bugzilla is not the MDSP mailing list, we did not interpret your statement “Posting in a personal capacity, with posts not necessarily representing the views of Google” on that wiki page to also apply here on Bugzilla.
given Sectigo's familiarity with the limits of serial numbers
Thanks for pointing out my earlier posts and research in this space. You may also recall that I was first to publicly propose the idea of a precertificate and the idea of sharing the same serial number between a precertificate and its corresponding certificate. So yes, you're absolutely right that we're familiar with the limits of serial numbers, and indeed it is our confidence that we're handling serial numbers correctly that was the main motivator for the plan we touched on in comment 4 and then sought to defend in comment 6, believing at the time that Mathias's concerns in comment 5 did not apply in our case.
it seems that Comment #8 was still not convinced by the merits
We agree that, for every incident report relating to misissuance, it makes sense to require CAs to disclose "a representation of" every "binding commitment by the CA". When posting comment 6 we felt that providing https://crt.sh/?serial= links did achieve this, albeit indirectly (via a crt.sh search) rather than explicitly (in a Bugzilla comment or attachment). Now, however, we would like to set the record straight regarding our current view.
Setting aside the distraction regarding the capacity in which you wrote it, we are in fact convinced by the merits of comment 7. The example you cited of "reuse of a serial in a CA certificate used for MITM" was not something we'd considered when posting comment 4 and comment 6; and although it would be surprising to find a non-publicly-trusted MITM CA certificate with a reused serial number in crt.sh, it's certainly not impossible: CT logs have been known to accept submissions with invalid signatures, and I am open to manually adding any certificate to crt.sh if it seems to be of interest (e.g., consider these six Kazakh MITM CA certificates that I added at Kathleen's request so that https://crt.sh/mozilla-onecrl would be more informative).
I would have hoped by now that CAs would wish to go above and beyond what they believe is necessary to avoid even the slightest hint of impropriety or unaddressed concern.
This reminder is our key takeway from this discussion, and we will reflect on it deeply. We agree, we endeavour to do exactly this, and we apologize for falling short on this occasion.
Our confidence in our own ability to ensure uniqueness of serial numbers across all the CAs that we operate, combined with our confidence that https://crt.sh/?serial= searches will find at least all of the relevant certificates and precertificates, blinded us to the reasonableness of Mathias's request in comment 5. We recognize that Mathias wants to be able to "Trust, but Verify" rather than have to take our word for it when we say that we're handling serial numbers correctly, and having reflected on this conversation we now concede that it's unreasonable to expect anyone to have to filter the results of a https://crt.sh/?serial= search to determine which of the search results are a "binding commitment by the CA" and which aren't (due to such things as MITM serial number reuse, CT log submission acceptance bugs, non-canonical signature parameters, and malleable ECDSA signatures).
We still feel that it's useful for certificate lists in incident reports to group together each misissued precertificate with its corresponding certificate in the vast majority of cases where the misissuance problem affects both of them in exactly the same way and the revocation fate of both is tied together. However, this is orthogonal to the concerns raised by you and Mathias, which we hope you can now see that we have taken on board. Thanks for engaging and bearing with us in this thoughtful discussion.
|
|
Assignee | |
Comment 16•3 years ago
|
||
On Monday in response to a new query we constructed, we discovered four EV certificates with subject:unstructuredName fields, which are noncompliant with section 9.2.9 of the EVGs. Issued between January 16, 2019 and July 10, 2020, these certificates are:
On November 20 at 23:59 UTC we deployed a programmatic block of subject:unstructuredName fields in Extended Validation certificates.
On the morning of Monday, November 22 we ran a query for EV certificates containing this field. Our query returned results at 15:37 UTC on November 22. We have set them for revocation at 15:00 UTC on Nov 26, 2021. We will follow up on this thread next week to confirm that revocation occurred.
The root cause of this misissuance is similar to what we described in part 6 of comment 1. As mentioned in that comment, our EV systems were built upon the company’s pre-existing certificate issuance software. In May of 2009 Comodo added support for subject:unstructuredName to OV and EV in response to market demand, which at the time the EV Guidelines allowed. The company subsequently failed to identify and remove the possibility of issuing EV certificates with this field when “Other Subject Attributes” became disallowed in 2019.
As with postOfficeBox, this form of misissuance went undetected until now because the overall number of certificates was very low, and it would have required a detailed examination of a specific, affected certificate to figure out that these fields were appearing. In response to the discovered inclusion of postalOfficeBox fields in EV certificates, we conducted code review which revealed that UN fields had this same potential for inclusion. After deploying our programmatic block of UN fields in EV, we searched our corpus of certificates and discovered the four listed here.
So far we are not aware of another Subject field that our systems may inappropriately allow in an EV certificate. To be confident we have addressed the matter completely, we have created a ticket to review and confirm all Subject fields presently allowed in DV, OV, and EV TLS certificates and to remove any inappropriate fields that might remain in the programmatic allow list for each type. We need to size and schedule this task and will follow up with an expected completion date when we have set it. We would like to keep this bug open until we have completed that review and deployed any fixes that may be required and until we have subsequently searched for and revoked any potential affected certificates based on what we might find out.
|
|
Assignee | |
Comment 17•3 years ago
|
||
The certificates listed in comment 16 were revoked November 26 at 15:19:51 UTC.
|
||
Comment 18•3 years ago
|
||
We are moving forward with our ticket of allowed subject fields as mentioned in comment 16 and will provide an update on its schedule once we have a firm date. We are monitoring this bug for any additional questions and comments.
|
|
||
Comment 19•3 years ago
|
||
The initial estimate for deployment of our allowed subject fields ticket targets the second half of January, however no official date has been set. We believe all other questions and comments so far have been addressed.
When we have a firmer target release date we will provide that update. In the meantime, we will continue to monitor this bug for any questions and/or comments.
|
|
Assignee | |
Comment 20•3 years ago
|
||
We will need until early January to settle on a specific target date for our allowed subject fields ticket. Ben, we would like to ask for a Next update on January 7 to share that target date.
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 21•3 years ago
|
||
We require additional investigation to plan and scope our programmatic check of allowed subject fields. We expect to have a firm plan and target date around the beginning of February. Ben, we are requesting a Next Update for February 7 to share our target release date.
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 22•3 years ago
|
||
Our Allowed Subject Fields functionality as described in comment 16 is scheduled for release this weekend.
|
|
Assignee | |
Comment 23•3 years ago
|
||
This last weekend our Allowed Subject Fields release went live. This completes our remediation of this issue. Are there any additional questions regarding this issue?
|
|
||
Comment 24•3 years ago
|
||
If there are no further questions, I'll close this on next Wed. 16-Feb-2022.
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
Description
•