CA/Camerfirma Issues

From MozillaWiki
< CA
Jump to: navigation, search

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.

Contents

Issue B: Delegation of validation to StartCom following Mozilla's distrust of StartCom (March 2017)

In March 2017, following the distrust of WoSign/StartCom, Camerfirma entered into a business relationship with StartCom. As part of that relationship, StartCom's CEO Iñigo 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:

Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017)

Related to Issue B, Camerfirma 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 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 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, security researchers examined Certificate Transparency databases for invalid dNSName Subject Alternative Names. These investigations revealed issues at a number of CAs, 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 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 Camerfirma confirming the issue, yet several weeks after having received a report, Camerfirma misissued 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 PSCProCert, Camerfirma 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 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 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)

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, 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 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 further pressed for details, Camerfirma responded that yes, they should have revoked, but that they had relied on their auditors to detect any issues of non-compliance.

Camerfirma 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 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 specifically asked to do so.

Issue R: Failure to disclose unconstrained sub-CA (DigitalSign) (2018)

In April 2018, Camerfirma 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, 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 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 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 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 provide correct audits for MULTICERT. Their 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 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 previously communicated by Kathleen Wilson.

Issue V: Audit Qualifications (2017 - 2018)

In July 2018, Camerfirma disclosed that they received a 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 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 incident report until 2018-08-29.

In response, Mozilla 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 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 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 misissued 174 certificates with an incorrect qcStatements extension. In response to the report that was provided, MULTICERT revoked the certificates, and then misissued new certificates with a validity period greater than 825 days to replace these the following month.

Further, after reportedly fixing the underlying issue, MULTICERT 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 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 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 would not permit delays in revoking from their sub-CAs.

In 2020, Intesa Sanpaolo has continued to delay revoking certificates that were misissued with invalid stateOrProvinceNames, with an estimate that they will 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 disagreed.

In 2020, the Intesa Sanpaolo sub-CA issued a certificate for a subdomain of com.com, 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 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 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 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 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 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 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, 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 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 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, multiple weeks went by without any updates on remediation efforts. Additionally, for the newly misissued certificates in 2020, Camerfirma again failed to timely revoke certificates, on the basis that their customers asked them to delay. Separately, they communicated to their users Camerfirma's obligations to revoke.

Issue NN: Incorrect OCSP Delegated Responder Certificate (2013 - 2020)

Along with a number of CAs, Camerfirma 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 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 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 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 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 discovered by Mozilla in the course of investigating Issue T.

The following year, Camerfirma failed to 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, 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: Certificate with Incorrect OrganizationName (Nov. 2020)

In 2020, Camerfirma issued a certificate where the Org Name was preceded by a colon ": ". The explanation provided was that validation officer did not notice the incorrect value before approving issuance. Added controls to decrease the likelihood of this happening in the future include additional training and highlighting certificate value fields.

Issue UU: Certificate for unregistered domain (Oct. 2020)

In 2020, Camerfirma issued a certificate to an unregistered domain based on a typo and human error. The proposed remediation was additional training. However, it was noted that the incident also exhibited inadequate domain validation, CAA checking, and certificate revocation, as well as a lack of historic examination of past incidents and meeting incident reporting requirements.

Issue VV: Certificates without CABForum OV Reserved Policy Identifier (Jan. 2021)

286 certificates were issued without the CA/Browser Forum OV policy OID because Quality Department overlooked a certificate profile change.

Issue XX: CP/CPS of Intesa Sanpaolo Sub-CA is Non-Compliant (Jan. 2021)

The CPS for Intesa Sanpaolo lacked specification about how domain validation and CAA checking are performed.

Retrieved from "https://wiki.mozilla.org/index.php?title=CA/Camerfirma_Issues&oldid=1239772"