Confirm
344
edits
Changes
Initial page
This page lists all confirmed or suspected issues involving Camerfirma. It will be updated by Mozilla as more information becomes available. Note that the presentation of issues below is not strictly chronological. Also, the lettering used for this outline of issues skips every other letter to provide gaps in between, for possible future expansion. Please do not edit this page yourself; if you have proposed changes, email certificates@mozilla.org.
==Issue B: Delegation of validation to StartCom following Mozilla's distrust of StartCom (March 2017)==
In March 2017, following the [https://wiki.mozilla.org/CA:WoSign_Issues distrust of WoSign/StartCom], Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1350615 entered into a business relationship with StartCom]. As part of that relationship, StartCom's CEO Iñigo Barreira underwent training as an RA for Camerfirma. As described, Iñigo performed organizational and domain validation for customers of StartCom, and then instructed Camerfirma to issue the certificates. Camerfirma was not directly involved in the validation except for EV certificates, and Iñigo's description of the domain validation steps were that they were performed under the "any other method" allowance that existed in the Baseline Requirements, as well as functioning as a Delegated Third Party for domain validation.
At the time of adopting this practice, the CA/Browser Forum had already attempted to remove the "any other method", as acknowledged by StartCom, but that had been complicated by IP issues.
As a result of this disclosure, Mozilla took the following actions:
* Mozilla requested that Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1350615#c7 perform all domain validations directly], and not delegate to StartCom
* Mozilla proposed a [https://cabforum.org/2017/07/11/ballot-204-forbid-dtps-domainip-ownership/ ballot to forbid the delegation of domain validation] to the CA/Browser Forum, which was unanimously adopted in July 2017.
==Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017)==
Related to Issue B, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 misissued 162 certificates] at the direction of StartCom. These certificates lacked required fields, such as localityName and stateOrProvinceName, and also contained duplicated entries within the subjectAlternativeName extension.
Both issues were the result of Camerfirma, related to the RA interface provided to StartCom, which omitted required fields and duplicated certain fields.
StartCom and Camerfirma were informed on 2017-04-17, which Camerfirma reportedly discovered on 2017-04-14. Camerfirma did not revoke these certificates on a timely basis; the majority were not replaced until 2017-04-25, although some certificates were not revoked for even longer.
==Issue F: Ignoring CAA based on another CA's Certificate Transparency disclosure (Nov. 2017)==
In 2017, it was revealed that Camerfirma had [https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 bypassed CAA checking] for a domain that restricted issuance to Let's Encrypt. Camerfirma revealed that they had misunderstood the Baseline Requirements ("BRs"), and thought it was permissible to bypass CAA checks for any domain which had a certificate disclosed via Certificate Transparency. Camerfirma's explanation of the issue is that they were hurried when they read the requirements, and overlooked the explicitly stated requirement for the CA to check CAA.
==Issue H: Non-compliant OCSP Responders by Third-Party Subordinates (Dec. 2017)==
In 2017, two separate sub-CAs of Camerfirma, Intesa Sanpaolo and InfoCert, both [https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 had non-compliance issues] in which their OCSP responders did not support the GET method, as required by the Baseline Requirements, and which responded "good" to unknown serial numbers. Based on this and responses from Camerfirma, it appeared that both sub-CAs had the same provider for their OCSP responder systems.
In response, Camerfirma updated their supervision of sub-CAs to additionally require their sub-CAs to provide BR self-assessments, rather than simply relying on audits. They also designated an employee to be responsible for following CA/B Forum, m.d.s.p., CCADB, and CA communications.
==Issue J: Invalid DNS names within certificates (August 2017)==
In 2017, [https://groups.google.com/g/mozilla.dev.security.policy/c/CfyeeybBz9c/m/lmmUT4x2CAAJ security researchers] examined Certificate Transparency databases for invalid dNSName Subject Alternative Names. These investigations revealed issues at a number of CAs, [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 including Camerfirma].
When this was reported to Camerfirma, it was originally not responded to, as problem reports went to a single individual. As a result, these certificates were not revoked until after Mozilla had filed the incident for Camerfirma. Mozilla noted that Camerfirma had failed to respond within 24 hours after a problem report had been submitted and that approximately 15 certificates had been misissued with internal server names or a full URI in the CN or SAN field. Camerfirma's response was that, at the time of the incident, there were no technical controls over the contents of the DNS name. Camerfirma relied solely upon the RA operators, which are external, third-party entities, to correctly enter the value for the fields.
Per BR section 7.1.4.2.1, certificates with internal names, such as https://crt.sh/?q=8680123, were supposed to have been revoked as of 1 October 2016. However, during the bug investigation, it was revealed that Camerfirma had intentionally further failed to [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c16 revoke some such certificates], on the basis that their customer would not permit them to revoke. Camerfirma stated their remediation was to update their contract to clarify that they would revoke on time.
Camerfirma stated they would deploy pre-issuance linting, using cablint and x509lint, in February 2018.
Note: One day prior (2017-08-23) to [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c12 Camerfirma confirming the issue], yet several weeks after having received a report, Camerfirma misissued [https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 additional certificates with an invalid domain], which they did not discover until March 2018 when they ran an automated analysis that replaced a manual review of crt.sh. See also Issue P.
==Issue L: Invalid subjectAlternativeName within certificates (July 2017)==
Related to Issue J, in July 2017, it was discovered that, along with the now-distrusted [https://wiki.mozilla.org/CA:PROCERT_Issues PSCProCert], Camerfirma [https://groups.google.com/g/mozilla.dev.security.policy/c/etp2Yz2fmM4/m/ayBTsfJnBgAJ had issued certificates] with an invalid subjectAlternativeName, using the X.500 dirName within the SAN. The Baseline Requirements prohibited the use of subjectAlternativeNames other than dNSName and iPAddress.
Camerfirma stated [https://groups.google.com/g/mozilla.dev.security.policy/c/etp2Yz2fmM4/m/vAE4lyFMAAAJ they were required to do] so according to local regulation, but had failed to follow the requirements set forth in the Baseline Requirements to do so, and failed to provide supporting evidence of this requirement. No further information was provided by Camerfirma regarding this, either within the thread or within the [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 related Bugzilla issue], nor was an incident report provided for this.
This was reported to Camerfirma on 2017-07-19, but they did not take action to revoke until 2017-08-17, with the explanation that they would not revoke until they had contacted the customer.
==Issue N: Improper issuance and failure to revoke intranet certificates (2015 - 2017)==
[https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 Bugzilla #1390977] is a good illustration of Mozilla's concerns about systemic issues at Camerfirma, which have diminished its confidence in Camerfirma as a CA. During the course of investigating Issues J and L, [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13 it was discovered] that Camerfirma had failed to revoke two certificates for non-assigned domain names ("intranet certificates").
Such certificates were prohibited from having expiry dates after 2015-11-11; however, Camerfirma had issued these with validity periods into 2018 (the first issue), and failed to revoke them as required by the BRs on 2016-10-1 (the second issue).
Camerfirma's [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c23 explanation] was that they had not implemented the necessary controls to limit the validity period, and subsequently, not implemented the necessary controls to revoke them. When [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c24 further pressed] for details, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c25 responded] that yes, they should have revoked, but that they had relied on their auditors to detect any issues of non-compliance.
Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 described their approach] to compliance as using an in-house CA platform that, for 17 years, had not had problems, and that they relied on the training of their RA operators to prevent issues. A growth in popularity for Camerfirma caused their controls to fail, and they would work to implement technical controls in the future.
==Issue P: Invalid characters within the OU field (2018)==
In January 2018, a month prior to when the technical controls from Issue J were to be deployed, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 misissued a certificate] that violated the ASN.1 field requirements, by including non-printable control characters. While Camerfirma confirmed the certificate was revoked in January, they failed to respond with the necessary incident report, despite being [https://bugzilla.mozilla.org/show_bug.cgi?id=1431164#c3 specifically asked] to do so.
==Issue R: Failure to disclose unconstrained sub-CA (DigitalSign) (2018)==
In April 2018, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1455147 failed to disclose an unconstrained sub-CA], despite Mozilla requiring in November 2017 that such disclosures be complete by 2018-04-15.
No explanation was provided by Camerfirma as to the cause of this omission nor were effective controls provided that would prevent such Mozilla policy violations in the future.
==Issue T: Failure to disclose unconstrained sub-CA (MULTICERT) (2018 - 2020)==
In the course of resolving Issue R, [https://bugzilla.mozilla.org/show_bug.cgi?id=1455147#c5 it was further discovered] in July 2018 that Camerfirma had failed to disclose two additional sub-CA certificates, operated by MULTICERT. Mozilla Policy required that such sub-CAs be disclosed within one week of creation.
Camerfirma's [https://bugzilla.mozilla.org/show_bug.cgi?id=1455147#c6 explanation at the time] was that they failed to consider that the person responsible for disclosing into CCADB would be unavailable, and that the backup for that person would be unavailable. They resolved this by adding a backup to the backup, in case the backup fails.
However, the disclosure in the CCADB [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 turned to be incorrect and misleading], as Camerfirma disclosed that they operated the sub-CA, when in fact it was externally operated. At the time, this was only detected because Microsoft had disclosed the CP/CPS they had for MULTICERT's root, which participated in Microsoft's root program. Camerfirma's [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957#c5 explanation] was that the person responsible for disclosing was overloaded, and that three people would be responsible for disclosures going forward.
In 2019, Camerfirma failed to [https://bugzilla.mozilla.org/show_bug.cgi?id=1549861 provide correct audits] for MULTICERT. Their [https://bugzilla.mozilla.org/show_bug.cgi?id=1549861#c7 explanation] was that they only had one person responsible for communicating with their sub-CAs, and had failed to consider that the person responsible for communicating with sub-CAs and disclosing into CCADB would be unavailable. They stated that they intended to prevent such issues from recurring in the future by purporting to implement additional steps.
In 2020, Camerfirma again [https://bugzilla.mozilla.org/show_bug.cgi?id=1672029 failed to properly disclose] sub-CAs operated by MULTICERT, erroneously reporting them as covered by Camerfirma's CP/CPS. Their stated reason was because these new sub-CAs were not covered by a new audit from MULTICERT yet, although the expectations for how to disclose that had been [https://groups.google.com/g/mozilla.dev.security.policy/c/p_6fiJ_FTug/m/f_1L6fDuDAAJ previously communicated by Kathleen Wilson].
==Issue V: Audit Qualifications (2017 - 2018)==
In July 2018, Camerfirma disclosed that they received a [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 qualified audit] for the period 2017 - 2018. The following qualifications were noted that were not addressed in previous issues.
* Conflicting information between CP/CPS around minimum key lengths, contact information, and key reuse.
* Failure to disclose required information within their CP
* Statements within their CP that information existed in supporting documents that did not exist.
* Misissuance of qualified certificates according to the eIDAS profile
* OCSP and CRL revocation instances returning different responses
* OCSP services responding good for affirmatively-revoked certificates in the CRL
* Failure to maintain evidence of routine self-assessment of Delegated Third Parties
This was reported on 2018-07-27, and despite a [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c7 request for an incident report] on 2018-07-30, Camerfirma did not address that request until 2018-08-24, stating that they were busy due to vacations and trying to remediate the issue, and did not provide an [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c11 incident report] until 2018-08-29.
In response, Mozilla [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c12 required] that a Point in Time assessment be completed no later than 2018-10-31, and the new audit period must not exceed 2019-04-13.
In the process of updating their CP/CPS, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c16 failed to comply] with Mozilla policies, which had to be pointed out by Mozilla, and was subsequently corrected.
==Issue X: MULTICERT Misissuance (2018 - 2019)==
In August 2018, within weeks of having received a cross-signed sub-CA from Camerfirma (Issue T), MULTICERT misissued several certificates that [https://bugzilla.mozilla.org/show_bug.cgi?id=1481862 violated the ASN.1 constraint] for organizationName field length. Camerfirma's response was that both they, and MULTICERT, would regularly check crt.sh for certificate lint violations.
In October 2018, it was discovered that MULTICERT had [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 misissued 174 certificates] with an incorrect <code>qcStatements</code> extension. In response to the report that was provided, MULTICERT revoked the certificates, and then misissued new certificates [https://bugzilla.mozilla.org/show_bug.cgi?id=1509002 with a validity period greater than 825 days] to replace these the following month.
Further, after reportedly fixing the underlying issue, MULTICERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1509002#c3 again misissued] another certificate with a validity period greater than 825 days.
During the course of this investigation, MULTICERT also failed to revoke on the timeline required by the BRs, in order to give the customer more time to replace certificates.
In March 2019, it was discovered that MULTICERT's certificates also had [https://bugzilla.mozilla.org/show_bug.cgi?id=1534429 insufficient entropy], containing only 63 bits of entropy, rather than the required 64.
==Issue Z: Intesa Sanpaolo Misissuance (2017 - 2020)==
In 2019, Camerfirma reported several incidents they had [https://bugzilla.mozilla.org/show_bug.cgi?id=1557085 reportedly detected in 2018] regarding misissuance by a subordinate CA, Intesa Sanpaolo. These violations included violations of both RFC 5280 and of the Baseline Requirements. In the course of providing an incident report for these events, Camerfirma clarified that Intesa Sanpaolo had delayed revocation beyond the time required by the Baseline Requirements. In the incident report, and in light of repeated past delays, Camerfirma stated that it had established a new policy that [https://bugzilla.mozilla.org/show_bug.cgi?id=1557085#c5 would not permit delays in revoking] from their sub-CAs.
In 2020, Intesa Sanpaolo has continued to [https://bugzilla.mozilla.org/show_bug.cgi?id=1668331 delay revoking certificates] that were misissued with [https://bugzilla.mozilla.org/show_bug.cgi?id=1667430 invalid stateOrProvinceNames], with an estimate that they will [https://bugzilla.mozilla.org/show_bug.cgi?id=1668331 complete revocation in 2021-01-15] for an incident they detected/resolved on 2020-09-25. Also, despite this issue being reported to Camerfirma, Infocert, its parent firm, misissued certificates for a number of days, because they [https://bugzilla.mozilla.org/show_bug.cgi?id=1667430#c15 disagreed].
In 2020, the Intesa Sanpaolo sub-CA issued a [https://bugzilla.mozilla.org/show_bug.cgi?id=1672409 certificate for a subdomain of <code>com.com</code>], revoked five days after issuance. Camerfirma stated that this was the result of human error and that they have been retrained. Despite having committed to ensure Camerfirma performed domain validation in Issue B, and despite concerns around delays in reporting in Issue DD, Camerfirma did not ensure their sub-CA promptly reported this misissuance or ensure an incident report was filed.
==Issue BB: Failure to revoke underscores (2019)==
CA/Browser Forum [https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/ Ballot SC12] clarified expectations around RFC 5280 compliance by making it unambiguous to CAs that underscores were not part of the "preferred name syntax" of domain names, with an expectation that any previously-issued certificates would be revoked by 2019-01-15.
Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1524871 failed to revoke] several certificates, as a result of human error examining the certificates they had issued. A total of three certificates were disclosed, two from Camerfirma, one from a sub-CA of Camerfirma, Intesa Sanpaolo.
For Camerfirma, although they had implemented tools to block new issuance of underscores, human error failed to properly query the certificates they had issued to detect the two problematic certificates.
For Intesa Sanpaolo, they had failed to implement controls to prohibit the use of underscores, despite the requirements of SC12.
In response, Camerfirma stated that for examining certificates they issue, they will add a backup team to check the work of the primary team. For their sub-CAs, they will require that sub-CAs improve how they report to Camerfirma regarding compliance with the Baseline Requirements.
==Issue DD: Infocert Misissuance (2017 - 2020)==
Camerfirma's process for examining their sub-CAs' issued certificates via crt.sh led them to detect a number of misissued certificates in February and April 2018, which they did not report until June 2019. Like Camerfirma in Issue J and Issue P, the sub-CA had included improper domain names and improper organizationUnit names.
Camerfirma described the [https://bugzilla.mozilla.org/show_bug.cgi?id=1556806#c9 set of controls] they had enacted to supervise sub-CAs, including requiring all sub-CAs use Camerfirma's lint service, and examining post-issuance lints on a daily basis. Further, as follow-up on the issue, although Issue H highlighted that audits alone are insufficient to assess compliance, Camerfirma revealed that they were still largely relying on audits. In response, they also required [https://bugzilla.mozilla.org/show_bug.cgi?id=1556806#c13 additional disclosures] for their sub-CAs.
==Issue FF: Intentional unrevocation of externally-operated sub-CA (2019)==
In 2019, Camerfirma accidentally revoked a sub-CA for MULTICERT. MULTICERT had two sub-CAs from Camerfirma, and Camerfirma staff was confused by the similarity of serial numbers and subject names, and chose to revoke the wrong certificate.
After publishing this revocation in CRLs, Camerfirma realized their mistake. They then decided to "un"revoke the sub-CA, removing it from the CRL. RFC 5280 does not permit unrevocation, and the Baseline Requirements do not support certificate suspension. During the course of this event, it was discovered that the OCSP service did not match the CRL. Camerfirma had previously received qualified audits (Issue V) in 2018 for this inconsistency, so this was a repeat incident.
In the incident, Camerfirma stated their plan to reduce situations like this was to migrate to EJBCA from their internal sub-CA, with a target of September 2019, confirming they were on track for this in August 2019. However, in January 2020, Camerfirma communicated that they decided not to implement this solution, based on a change in company direction, developing an in-house tool that they claim provides the same features as EJBCA.
In light of concern for not providing updates, Camerfirma stated they have daily internal meetings, beginning in January 2020, to manage all open bugs and ensure timely communication.
==Issue HH: EV Certificates with wrong businessCategory (2018 - 2019)==
In 2019, DigiCert proactively contacted a number of CAs, highlighting misissuance by those CAs in the businessCategory field of EV certificates. Among the CAs affected, Camerfirma had also used the [https://bugzilla.mozilla.org/show_bug.cgi?id=1600114 incorrect businessCategory] for a number of certificates, failing to adhere to the EV Guidelines' requirements.
On further investigation, Camerfirma determined they had misissued additional certificates, not reported by DigiCert.
Camerfirma's response to this is to update their documentation and retrain their RA staff on the correct businessCategory to use.
==Issue JJ: Unresolvable Gap in Audits (Camerfirma) (2018 - 2019)==
For the period of 2018 to 2019, Camerfirma transitioned from using AUREN for WebTrust audits to using AENOR for eIDAS audits. In the course of this transition, a [https://bugzilla.mozilla.org/show_bug.cgi?id=1583470 gap between the two audits was introduced], covering the period 2018-04-14 to 2018-05-08, a 25-day period.
Camerfirma stated that the cause of the gap was due to differences in the audit approaches used by WebTrust and ETSI, and the failure of Camerfirma to design for that. In the WebTrust-based approach, which is an attestation engagement, management states how operations were for a period of time. In the ETSI-based approach, which is a compliance approach, the auditor states that a CA is certified compliant as of a particular date.
In the course of transitioning to ETSI, there were major non-conformities identified by the auditor that the auditor required Camerfirma to resolve prior to certifying Camerfirma. This delay introduced a gap within the respective periods. Camerfirma first became aware of these non-conformities based on the auditor's investigation, as shared 2018-03-23.
Camerfirma decided not to pursue both audits in parallel in order to save on expenses, and did not consider beginning the audit sooner, which would have provided time to address non-conformities. They stated that there were several sub-CAs still using the WebTrust audit scheme, even as they were using ETSI, and would consider this as part of the sub-CA transition plan.
==Issue LL: Invalid authorityKeyIdentifier (2003 - 2020)==
Mozilla Policy has, [https://wiki.mozilla.org/CA:CertificatePolicyV1.0 since Version 1.0], restricted authority key IDs to including either the key ID or the issuer name and serial, explicitly prohibiting the use of both sets of fields. Every certificate issued by Camerfirma since 2003 violated this.
In response, Camerfirma acknowledged that they had misunderstood the Mozilla Requirement in light of RFC 5280, and stated that as of 2019-10-25, all new certificates would not demonstrate this problem, although it was not actually completed until 2019-11-18.
Despite Mozilla's policy requiring revocation of certificates that do not comply with Mozilla's policies, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1609828 decided not to revoke] these certificates. Camerfirma's statement was that clients would not be prepared for revocation on the timelines required, despite Issue J stating their contract was modified to permit this, and Issue Z stating they would not permit delays from sub-CAs in revoking either. The primary difference here is that some of the certificates are used directly by users, particularly S/MIME, and not just servers.
Despite committing to have this issue fixed, in 2020, it was noticed that [https://bugzilla.mozilla.org/show_bug.cgi?id=1623384 Camerfirma had repeated the same issue]. Camerfirma's explanation was that they had a large number of certificate profiles, and in the process of creating the scope of work to resolve the first issue, they overlooked a set of misconfigured profiles, and thus repeated. This was not caught by the automated linting that they had deployed, because they had not updated it to detect this issue.
Despite having a daily review process, identified in Issue BB, [https://bugzilla.mozilla.org/show_bug.cgi?id=1623384#c9 multiple weeks went by] without any updates on remediation efforts. Additionally, for the newly misissued certificates in 2020, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1647099 again failed to timely revoke] certificates, on the basis that their customers asked them to delay. Separately, they [https://bugzilla.mozilla.org/show_bug.cgi?id=1624658#c4 communicated to their users] Camerfirma's obligations to revoke.
==Issue NN: Incorrect OCSP Delegated Responder Certificate (2013 - 2020)==
Along with a [https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13493.html number of CAs], Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1649944 issued three sub-CAs] that had the ability to provide OCSP responses for Camerfirma.
Camerfirma stated that the cause was that they were unaware of the interaction of this EKU, and in response, introduced controls to prevent this EKU from sub-CAs. As with many other CAs, Camerfirma was [https://bugzilla.mozilla.org/show_bug.cgi?id=1652603 not able to revoke] these sub-CAs in a timely fashion, as required by the BRs.
Camerfirma's explanation for the delay is that one of the sub-CAs was used within the health sector for smartcards, and required the replacement of smart cards. Additionally, they stated that changes required the approval of their National Supervisory Body before they would be able to make them. Camerfirma stated that the keys were destroyed on 2020-10-02, but did not have that ceremony witnessed by a qualified auditor or independent third-party, only witnessed by Camerfirma staff.
==Issue PP: Failure to disclose unconstrained Sub-CA (Government of Andorra) (2013 - 2019)==
Camerfirma disclosed that, until 2018, they had not [https://bugzilla.mozilla.org/show_bug.cgi?id=1575530 audited an S/MIME sub-CA] controlled by the Government of Andorra. Upon receiving the audit report in 2019, multiple non-conformities were identified.
In response, Camerfirma stated that they would revoke the old certificate in October 2019, replacing it with a new intermediate for the Government of Andorra following a Point-in-Time assessment, and to be followed up with a Period of Time report in February 2020.
Camerfirma's explanation was that because this sub-CA was not intended to issue TLS certificates, they had not considered it in scope. However, Mozilla's policy has required, since 2014, that CAs capable of TLS be audited and disclosed, and since 2017, that S/MIME capable CAs be audited and disclosed. Despite Issue H regarding the supervision of CAs in 2017, this was not detected until 2018, and not reported to Mozilla until the audit received was qualified, in 2019. Previously, in Issue R, the expectation for disclosure of S/MIME CAs had been communicated to Camerfirma.
Camerfirma's explanation for this oversight is that they had an insufficient number of people working on this, and appointed a [https://bugzilla.mozilla.org/show_bug.cgi?id=1575530#c21 backup], a response they'd previously taken two years in a row, as captured in Issue T.
Despite receiving the first audit report on 2019-07-29, Camerfirma declined to revoke this CA for several months, due to the [https://bugzilla.mozilla.org/show_bug.cgi?id=1575530#c18 potential disruption]. They stated they had made their clients sign an agreement entitling Camerfirma to revoke in the event of misissuance.
==Issue RR: Failure to disclose unconstrained Sub-CA (Intesa Sanpaolo and Infocert) (2018 - 2020)==
In 2018, Camerfirma allowed two sub-CAs to be unconstrained and unaudited for 6 months, which was [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957#c12 discovered by Mozilla] in the course of investigating Issue T.
The following year, Camerfirma failed to [https://bugzilla.mozilla.org/show_bug.cgi?id=1549861 disclose audits for their sub-CAs]. After they were contacted by Mozilla, they updated the audits, 3 months after they were due. The explanation provided by Camerfirma was, as discussed in Issue T and Issue PP, that they had only one person responsible for this.
In 2019, Camerfirma again failed to properly disclose a sub-CA operated by Intesa Sanpaolo, by stating that its CP/CPS was Camerfirma's, [https://bugzilla.mozilla.org/show_bug.cgi?id=1672562 despite the audit stating otherwise]. Camerfirma's explanation for this was that it was human error, and attributed it to CCADB likely not saving correctly. In the future, they promised to check to make sure the information is correct.
==Issue TT:==
==Issue B: Delegation of validation to StartCom following Mozilla's distrust of StartCom (March 2017)==
In March 2017, following the [https://wiki.mozilla.org/CA:WoSign_Issues distrust of WoSign/StartCom], Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1350615 entered into a business relationship with StartCom]. As part of that relationship, StartCom's CEO Iñigo Barreira underwent training as an RA for Camerfirma. As described, Iñigo performed organizational and domain validation for customers of StartCom, and then instructed Camerfirma to issue the certificates. Camerfirma was not directly involved in the validation except for EV certificates, and Iñigo's description of the domain validation steps were that they were performed under the "any other method" allowance that existed in the Baseline Requirements, as well as functioning as a Delegated Third Party for domain validation.
At the time of adopting this practice, the CA/Browser Forum had already attempted to remove the "any other method", as acknowledged by StartCom, but that had been complicated by IP issues.
As a result of this disclosure, Mozilla took the following actions:
* Mozilla requested that Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1350615#c7 perform all domain validations directly], and not delegate to StartCom
* Mozilla proposed a [https://cabforum.org/2017/07/11/ballot-204-forbid-dtps-domainip-ownership/ ballot to forbid the delegation of domain validation] to the CA/Browser Forum, which was unanimously adopted in July 2017.
==Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017)==
Related to Issue B, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 misissued 162 certificates] at the direction of StartCom. These certificates lacked required fields, such as localityName and stateOrProvinceName, and also contained duplicated entries within the subjectAlternativeName extension.
Both issues were the result of Camerfirma, related to the RA interface provided to StartCom, which omitted required fields and duplicated certain fields.
StartCom and Camerfirma were informed on 2017-04-17, which Camerfirma reportedly discovered on 2017-04-14. Camerfirma did not revoke these certificates on a timely basis; the majority were not replaced until 2017-04-25, although some certificates were not revoked for even longer.
==Issue F: Ignoring CAA based on another CA's Certificate Transparency disclosure (Nov. 2017)==
In 2017, it was revealed that Camerfirma had [https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 bypassed CAA checking] for a domain that restricted issuance to Let's Encrypt. Camerfirma revealed that they had misunderstood the Baseline Requirements ("BRs"), and thought it was permissible to bypass CAA checks for any domain which had a certificate disclosed via Certificate Transparency. Camerfirma's explanation of the issue is that they were hurried when they read the requirements, and overlooked the explicitly stated requirement for the CA to check CAA.
==Issue H: Non-compliant OCSP Responders by Third-Party Subordinates (Dec. 2017)==
In 2017, two separate sub-CAs of Camerfirma, Intesa Sanpaolo and InfoCert, both [https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 had non-compliance issues] in which their OCSP responders did not support the GET method, as required by the Baseline Requirements, and which responded "good" to unknown serial numbers. Based on this and responses from Camerfirma, it appeared that both sub-CAs had the same provider for their OCSP responder systems.
In response, Camerfirma updated their supervision of sub-CAs to additionally require their sub-CAs to provide BR self-assessments, rather than simply relying on audits. They also designated an employee to be responsible for following CA/B Forum, m.d.s.p., CCADB, and CA communications.
==Issue J: Invalid DNS names within certificates (August 2017)==
In 2017, [https://groups.google.com/g/mozilla.dev.security.policy/c/CfyeeybBz9c/m/lmmUT4x2CAAJ security researchers] examined Certificate Transparency databases for invalid dNSName Subject Alternative Names. These investigations revealed issues at a number of CAs, [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 including Camerfirma].
When this was reported to Camerfirma, it was originally not responded to, as problem reports went to a single individual. As a result, these certificates were not revoked until after Mozilla had filed the incident for Camerfirma. Mozilla noted that Camerfirma had failed to respond within 24 hours after a problem report had been submitted and that approximately 15 certificates had been misissued with internal server names or a full URI in the CN or SAN field. Camerfirma's response was that, at the time of the incident, there were no technical controls over the contents of the DNS name. Camerfirma relied solely upon the RA operators, which are external, third-party entities, to correctly enter the value for the fields.
Per BR section 7.1.4.2.1, certificates with internal names, such as https://crt.sh/?q=8680123, were supposed to have been revoked as of 1 October 2016. However, during the bug investigation, it was revealed that Camerfirma had intentionally further failed to [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c16 revoke some such certificates], on the basis that their customer would not permit them to revoke. Camerfirma stated their remediation was to update their contract to clarify that they would revoke on time.
Camerfirma stated they would deploy pre-issuance linting, using cablint and x509lint, in February 2018.
Note: One day prior (2017-08-23) to [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c12 Camerfirma confirming the issue], yet several weeks after having received a report, Camerfirma misissued [https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 additional certificates with an invalid domain], which they did not discover until March 2018 when they ran an automated analysis that replaced a manual review of crt.sh. See also Issue P.
==Issue L: Invalid subjectAlternativeName within certificates (July 2017)==
Related to Issue J, in July 2017, it was discovered that, along with the now-distrusted [https://wiki.mozilla.org/CA:PROCERT_Issues PSCProCert], Camerfirma [https://groups.google.com/g/mozilla.dev.security.policy/c/etp2Yz2fmM4/m/ayBTsfJnBgAJ had issued certificates] with an invalid subjectAlternativeName, using the X.500 dirName within the SAN. The Baseline Requirements prohibited the use of subjectAlternativeNames other than dNSName and iPAddress.
Camerfirma stated [https://groups.google.com/g/mozilla.dev.security.policy/c/etp2Yz2fmM4/m/vAE4lyFMAAAJ they were required to do] so according to local regulation, but had failed to follow the requirements set forth in the Baseline Requirements to do so, and failed to provide supporting evidence of this requirement. No further information was provided by Camerfirma regarding this, either within the thread or within the [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 related Bugzilla issue], nor was an incident report provided for this.
This was reported to Camerfirma on 2017-07-19, but they did not take action to revoke until 2017-08-17, with the explanation that they would not revoke until they had contacted the customer.
==Issue N: Improper issuance and failure to revoke intranet certificates (2015 - 2017)==
[https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 Bugzilla #1390977] is a good illustration of Mozilla's concerns about systemic issues at Camerfirma, which have diminished its confidence in Camerfirma as a CA. During the course of investigating Issues J and L, [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13 it was discovered] that Camerfirma had failed to revoke two certificates for non-assigned domain names ("intranet certificates").
Such certificates were prohibited from having expiry dates after 2015-11-11; however, Camerfirma had issued these with validity periods into 2018 (the first issue), and failed to revoke them as required by the BRs on 2016-10-1 (the second issue).
Camerfirma's [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c23 explanation] was that they had not implemented the necessary controls to limit the validity period, and subsequently, not implemented the necessary controls to revoke them. When [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c24 further pressed] for details, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c25 responded] that yes, they should have revoked, but that they had relied on their auditors to detect any issues of non-compliance.
Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 described their approach] to compliance as using an in-house CA platform that, for 17 years, had not had problems, and that they relied on the training of their RA operators to prevent issues. A growth in popularity for Camerfirma caused their controls to fail, and they would work to implement technical controls in the future.
==Issue P: Invalid characters within the OU field (2018)==
In January 2018, a month prior to when the technical controls from Issue J were to be deployed, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 misissued a certificate] that violated the ASN.1 field requirements, by including non-printable control characters. While Camerfirma confirmed the certificate was revoked in January, they failed to respond with the necessary incident report, despite being [https://bugzilla.mozilla.org/show_bug.cgi?id=1431164#c3 specifically asked] to do so.
==Issue R: Failure to disclose unconstrained sub-CA (DigitalSign) (2018)==
In April 2018, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1455147 failed to disclose an unconstrained sub-CA], despite Mozilla requiring in November 2017 that such disclosures be complete by 2018-04-15.
No explanation was provided by Camerfirma as to the cause of this omission nor were effective controls provided that would prevent such Mozilla policy violations in the future.
==Issue T: Failure to disclose unconstrained sub-CA (MULTICERT) (2018 - 2020)==
In the course of resolving Issue R, [https://bugzilla.mozilla.org/show_bug.cgi?id=1455147#c5 it was further discovered] in July 2018 that Camerfirma had failed to disclose two additional sub-CA certificates, operated by MULTICERT. Mozilla Policy required that such sub-CAs be disclosed within one week of creation.
Camerfirma's [https://bugzilla.mozilla.org/show_bug.cgi?id=1455147#c6 explanation at the time] was that they failed to consider that the person responsible for disclosing into CCADB would be unavailable, and that the backup for that person would be unavailable. They resolved this by adding a backup to the backup, in case the backup fails.
However, the disclosure in the CCADB [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 turned to be incorrect and misleading], as Camerfirma disclosed that they operated the sub-CA, when in fact it was externally operated. At the time, this was only detected because Microsoft had disclosed the CP/CPS they had for MULTICERT's root, which participated in Microsoft's root program. Camerfirma's [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957#c5 explanation] was that the person responsible for disclosing was overloaded, and that three people would be responsible for disclosures going forward.
In 2019, Camerfirma failed to [https://bugzilla.mozilla.org/show_bug.cgi?id=1549861 provide correct audits] for MULTICERT. Their [https://bugzilla.mozilla.org/show_bug.cgi?id=1549861#c7 explanation] was that they only had one person responsible for communicating with their sub-CAs, and had failed to consider that the person responsible for communicating with sub-CAs and disclosing into CCADB would be unavailable. They stated that they intended to prevent such issues from recurring in the future by purporting to implement additional steps.
In 2020, Camerfirma again [https://bugzilla.mozilla.org/show_bug.cgi?id=1672029 failed to properly disclose] sub-CAs operated by MULTICERT, erroneously reporting them as covered by Camerfirma's CP/CPS. Their stated reason was because these new sub-CAs were not covered by a new audit from MULTICERT yet, although the expectations for how to disclose that had been [https://groups.google.com/g/mozilla.dev.security.policy/c/p_6fiJ_FTug/m/f_1L6fDuDAAJ previously communicated by Kathleen Wilson].
==Issue V: Audit Qualifications (2017 - 2018)==
In July 2018, Camerfirma disclosed that they received a [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 qualified audit] for the period 2017 - 2018. The following qualifications were noted that were not addressed in previous issues.
* Conflicting information between CP/CPS around minimum key lengths, contact information, and key reuse.
* Failure to disclose required information within their CP
* Statements within their CP that information existed in supporting documents that did not exist.
* Misissuance of qualified certificates according to the eIDAS profile
* OCSP and CRL revocation instances returning different responses
* OCSP services responding good for affirmatively-revoked certificates in the CRL
* Failure to maintain evidence of routine self-assessment of Delegated Third Parties
This was reported on 2018-07-27, and despite a [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c7 request for an incident report] on 2018-07-30, Camerfirma did not address that request until 2018-08-24, stating that they were busy due to vacations and trying to remediate the issue, and did not provide an [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c11 incident report] until 2018-08-29.
In response, Mozilla [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c12 required] that a Point in Time assessment be completed no later than 2018-10-31, and the new audit period must not exceed 2019-04-13.
In the process of updating their CP/CPS, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c16 failed to comply] with Mozilla policies, which had to be pointed out by Mozilla, and was subsequently corrected.
==Issue X: MULTICERT Misissuance (2018 - 2019)==
In August 2018, within weeks of having received a cross-signed sub-CA from Camerfirma (Issue T), MULTICERT misissued several certificates that [https://bugzilla.mozilla.org/show_bug.cgi?id=1481862 violated the ASN.1 constraint] for organizationName field length. Camerfirma's response was that both they, and MULTICERT, would regularly check crt.sh for certificate lint violations.
In October 2018, it was discovered that MULTICERT had [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 misissued 174 certificates] with an incorrect <code>qcStatements</code> extension. In response to the report that was provided, MULTICERT revoked the certificates, and then misissued new certificates [https://bugzilla.mozilla.org/show_bug.cgi?id=1509002 with a validity period greater than 825 days] to replace these the following month.
Further, after reportedly fixing the underlying issue, MULTICERT [https://bugzilla.mozilla.org/show_bug.cgi?id=1509002#c3 again misissued] another certificate with a validity period greater than 825 days.
During the course of this investigation, MULTICERT also failed to revoke on the timeline required by the BRs, in order to give the customer more time to replace certificates.
In March 2019, it was discovered that MULTICERT's certificates also had [https://bugzilla.mozilla.org/show_bug.cgi?id=1534429 insufficient entropy], containing only 63 bits of entropy, rather than the required 64.
==Issue Z: Intesa Sanpaolo Misissuance (2017 - 2020)==
In 2019, Camerfirma reported several incidents they had [https://bugzilla.mozilla.org/show_bug.cgi?id=1557085 reportedly detected in 2018] regarding misissuance by a subordinate CA, Intesa Sanpaolo. These violations included violations of both RFC 5280 and of the Baseline Requirements. In the course of providing an incident report for these events, Camerfirma clarified that Intesa Sanpaolo had delayed revocation beyond the time required by the Baseline Requirements. In the incident report, and in light of repeated past delays, Camerfirma stated that it had established a new policy that [https://bugzilla.mozilla.org/show_bug.cgi?id=1557085#c5 would not permit delays in revoking] from their sub-CAs.
In 2020, Intesa Sanpaolo has continued to [https://bugzilla.mozilla.org/show_bug.cgi?id=1668331 delay revoking certificates] that were misissued with [https://bugzilla.mozilla.org/show_bug.cgi?id=1667430 invalid stateOrProvinceNames], with an estimate that they will [https://bugzilla.mozilla.org/show_bug.cgi?id=1668331 complete revocation in 2021-01-15] for an incident they detected/resolved on 2020-09-25. Also, despite this issue being reported to Camerfirma, Infocert, its parent firm, misissued certificates for a number of days, because they [https://bugzilla.mozilla.org/show_bug.cgi?id=1667430#c15 disagreed].
In 2020, the Intesa Sanpaolo sub-CA issued a [https://bugzilla.mozilla.org/show_bug.cgi?id=1672409 certificate for a subdomain of <code>com.com</code>], revoked five days after issuance. Camerfirma stated that this was the result of human error and that they have been retrained. Despite having committed to ensure Camerfirma performed domain validation in Issue B, and despite concerns around delays in reporting in Issue DD, Camerfirma did not ensure their sub-CA promptly reported this misissuance or ensure an incident report was filed.
==Issue BB: Failure to revoke underscores (2019)==
CA/Browser Forum [https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/ Ballot SC12] clarified expectations around RFC 5280 compliance by making it unambiguous to CAs that underscores were not part of the "preferred name syntax" of domain names, with an expectation that any previously-issued certificates would be revoked by 2019-01-15.
Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1524871 failed to revoke] several certificates, as a result of human error examining the certificates they had issued. A total of three certificates were disclosed, two from Camerfirma, one from a sub-CA of Camerfirma, Intesa Sanpaolo.
For Camerfirma, although they had implemented tools to block new issuance of underscores, human error failed to properly query the certificates they had issued to detect the two problematic certificates.
For Intesa Sanpaolo, they had failed to implement controls to prohibit the use of underscores, despite the requirements of SC12.
In response, Camerfirma stated that for examining certificates they issue, they will add a backup team to check the work of the primary team. For their sub-CAs, they will require that sub-CAs improve how they report to Camerfirma regarding compliance with the Baseline Requirements.
==Issue DD: Infocert Misissuance (2017 - 2020)==
Camerfirma's process for examining their sub-CAs' issued certificates via crt.sh led them to detect a number of misissued certificates in February and April 2018, which they did not report until June 2019. Like Camerfirma in Issue J and Issue P, the sub-CA had included improper domain names and improper organizationUnit names.
Camerfirma described the [https://bugzilla.mozilla.org/show_bug.cgi?id=1556806#c9 set of controls] they had enacted to supervise sub-CAs, including requiring all sub-CAs use Camerfirma's lint service, and examining post-issuance lints on a daily basis. Further, as follow-up on the issue, although Issue H highlighted that audits alone are insufficient to assess compliance, Camerfirma revealed that they were still largely relying on audits. In response, they also required [https://bugzilla.mozilla.org/show_bug.cgi?id=1556806#c13 additional disclosures] for their sub-CAs.
==Issue FF: Intentional unrevocation of externally-operated sub-CA (2019)==
In 2019, Camerfirma accidentally revoked a sub-CA for MULTICERT. MULTICERT had two sub-CAs from Camerfirma, and Camerfirma staff was confused by the similarity of serial numbers and subject names, and chose to revoke the wrong certificate.
After publishing this revocation in CRLs, Camerfirma realized their mistake. They then decided to "un"revoke the sub-CA, removing it from the CRL. RFC 5280 does not permit unrevocation, and the Baseline Requirements do not support certificate suspension. During the course of this event, it was discovered that the OCSP service did not match the CRL. Camerfirma had previously received qualified audits (Issue V) in 2018 for this inconsistency, so this was a repeat incident.
In the incident, Camerfirma stated their plan to reduce situations like this was to migrate to EJBCA from their internal sub-CA, with a target of September 2019, confirming they were on track for this in August 2019. However, in January 2020, Camerfirma communicated that they decided not to implement this solution, based on a change in company direction, developing an in-house tool that they claim provides the same features as EJBCA.
In light of concern for not providing updates, Camerfirma stated they have daily internal meetings, beginning in January 2020, to manage all open bugs and ensure timely communication.
==Issue HH: EV Certificates with wrong businessCategory (2018 - 2019)==
In 2019, DigiCert proactively contacted a number of CAs, highlighting misissuance by those CAs in the businessCategory field of EV certificates. Among the CAs affected, Camerfirma had also used the [https://bugzilla.mozilla.org/show_bug.cgi?id=1600114 incorrect businessCategory] for a number of certificates, failing to adhere to the EV Guidelines' requirements.
On further investigation, Camerfirma determined they had misissued additional certificates, not reported by DigiCert.
Camerfirma's response to this is to update their documentation and retrain their RA staff on the correct businessCategory to use.
==Issue JJ: Unresolvable Gap in Audits (Camerfirma) (2018 - 2019)==
For the period of 2018 to 2019, Camerfirma transitioned from using AUREN for WebTrust audits to using AENOR for eIDAS audits. In the course of this transition, a [https://bugzilla.mozilla.org/show_bug.cgi?id=1583470 gap between the two audits was introduced], covering the period 2018-04-14 to 2018-05-08, a 25-day period.
Camerfirma stated that the cause of the gap was due to differences in the audit approaches used by WebTrust and ETSI, and the failure of Camerfirma to design for that. In the WebTrust-based approach, which is an attestation engagement, management states how operations were for a period of time. In the ETSI-based approach, which is a compliance approach, the auditor states that a CA is certified compliant as of a particular date.
In the course of transitioning to ETSI, there were major non-conformities identified by the auditor that the auditor required Camerfirma to resolve prior to certifying Camerfirma. This delay introduced a gap within the respective periods. Camerfirma first became aware of these non-conformities based on the auditor's investigation, as shared 2018-03-23.
Camerfirma decided not to pursue both audits in parallel in order to save on expenses, and did not consider beginning the audit sooner, which would have provided time to address non-conformities. They stated that there were several sub-CAs still using the WebTrust audit scheme, even as they were using ETSI, and would consider this as part of the sub-CA transition plan.
==Issue LL: Invalid authorityKeyIdentifier (2003 - 2020)==
Mozilla Policy has, [https://wiki.mozilla.org/CA:CertificatePolicyV1.0 since Version 1.0], restricted authority key IDs to including either the key ID or the issuer name and serial, explicitly prohibiting the use of both sets of fields. Every certificate issued by Camerfirma since 2003 violated this.
In response, Camerfirma acknowledged that they had misunderstood the Mozilla Requirement in light of RFC 5280, and stated that as of 2019-10-25, all new certificates would not demonstrate this problem, although it was not actually completed until 2019-11-18.
Despite Mozilla's policy requiring revocation of certificates that do not comply with Mozilla's policies, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1609828 decided not to revoke] these certificates. Camerfirma's statement was that clients would not be prepared for revocation on the timelines required, despite Issue J stating their contract was modified to permit this, and Issue Z stating they would not permit delays from sub-CAs in revoking either. The primary difference here is that some of the certificates are used directly by users, particularly S/MIME, and not just servers.
Despite committing to have this issue fixed, in 2020, it was noticed that [https://bugzilla.mozilla.org/show_bug.cgi?id=1623384 Camerfirma had repeated the same issue]. Camerfirma's explanation was that they had a large number of certificate profiles, and in the process of creating the scope of work to resolve the first issue, they overlooked a set of misconfigured profiles, and thus repeated. This was not caught by the automated linting that they had deployed, because they had not updated it to detect this issue.
Despite having a daily review process, identified in Issue BB, [https://bugzilla.mozilla.org/show_bug.cgi?id=1623384#c9 multiple weeks went by] without any updates on remediation efforts. Additionally, for the newly misissued certificates in 2020, Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1647099 again failed to timely revoke] certificates, on the basis that their customers asked them to delay. Separately, they [https://bugzilla.mozilla.org/show_bug.cgi?id=1624658#c4 communicated to their users] Camerfirma's obligations to revoke.
==Issue NN: Incorrect OCSP Delegated Responder Certificate (2013 - 2020)==
Along with a [https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13493.html number of CAs], Camerfirma [https://bugzilla.mozilla.org/show_bug.cgi?id=1649944 issued three sub-CAs] that had the ability to provide OCSP responses for Camerfirma.
Camerfirma stated that the cause was that they were unaware of the interaction of this EKU, and in response, introduced controls to prevent this EKU from sub-CAs. As with many other CAs, Camerfirma was [https://bugzilla.mozilla.org/show_bug.cgi?id=1652603 not able to revoke] these sub-CAs in a timely fashion, as required by the BRs.
Camerfirma's explanation for the delay is that one of the sub-CAs was used within the health sector for smartcards, and required the replacement of smart cards. Additionally, they stated that changes required the approval of their National Supervisory Body before they would be able to make them. Camerfirma stated that the keys were destroyed on 2020-10-02, but did not have that ceremony witnessed by a qualified auditor or independent third-party, only witnessed by Camerfirma staff.
==Issue PP: Failure to disclose unconstrained Sub-CA (Government of Andorra) (2013 - 2019)==
Camerfirma disclosed that, until 2018, they had not [https://bugzilla.mozilla.org/show_bug.cgi?id=1575530 audited an S/MIME sub-CA] controlled by the Government of Andorra. Upon receiving the audit report in 2019, multiple non-conformities were identified.
In response, Camerfirma stated that they would revoke the old certificate in October 2019, replacing it with a new intermediate for the Government of Andorra following a Point-in-Time assessment, and to be followed up with a Period of Time report in February 2020.
Camerfirma's explanation was that because this sub-CA was not intended to issue TLS certificates, they had not considered it in scope. However, Mozilla's policy has required, since 2014, that CAs capable of TLS be audited and disclosed, and since 2017, that S/MIME capable CAs be audited and disclosed. Despite Issue H regarding the supervision of CAs in 2017, this was not detected until 2018, and not reported to Mozilla until the audit received was qualified, in 2019. Previously, in Issue R, the expectation for disclosure of S/MIME CAs had been communicated to Camerfirma.
Camerfirma's explanation for this oversight is that they had an insufficient number of people working on this, and appointed a [https://bugzilla.mozilla.org/show_bug.cgi?id=1575530#c21 backup], a response they'd previously taken two years in a row, as captured in Issue T.
Despite receiving the first audit report on 2019-07-29, Camerfirma declined to revoke this CA for several months, due to the [https://bugzilla.mozilla.org/show_bug.cgi?id=1575530#c18 potential disruption]. They stated they had made their clients sign an agreement entitling Camerfirma to revoke in the event of misissuance.
==Issue RR: Failure to disclose unconstrained Sub-CA (Intesa Sanpaolo and Infocert) (2018 - 2020)==
In 2018, Camerfirma allowed two sub-CAs to be unconstrained and unaudited for 6 months, which was [https://bugzilla.mozilla.org/show_bug.cgi?id=1502957#c12 discovered by Mozilla] in the course of investigating Issue T.
The following year, Camerfirma failed to [https://bugzilla.mozilla.org/show_bug.cgi?id=1549861 disclose audits for their sub-CAs]. After they were contacted by Mozilla, they updated the audits, 3 months after they were due. The explanation provided by Camerfirma was, as discussed in Issue T and Issue PP, that they had only one person responsible for this.
In 2019, Camerfirma again failed to properly disclose a sub-CA operated by Intesa Sanpaolo, by stating that its CP/CPS was Camerfirma's, [https://bugzilla.mozilla.org/show_bug.cgi?id=1672562 despite the audit stating otherwise]. Camerfirma's explanation for this was that it was human error, and attributed it to CCADB likely not saving correctly. In the future, they promised to check to make sure the information is correct.
==Issue TT:==
