1391054 - Izenpe: Non-BR-Compliant Certificate Issuance

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

** Serial Numbers less than 64-bit entropy 
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ

Comment 1

[vtlynch]

Hi Kathleen,

Izenpe also mis-issued three (3) certificates where the common name was not included in the SANs. The three certificates were revoked on August 10th, which was 4 days after the original report was posted to mdsp.


Here are the crt.sh links:
https://crt.sh/?id=56951679&opt=cablint
https://crt.sh/?id=58473404&opt=cablint
https://crt.sh/?id=179810182&opt=cablint

Here is the original thread where the issue was reported:
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ


-Vincent

Comment 2

[Oscar Garcia]

Hi Kathleen, I'll try to answer to all your questions:

1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.

- Common Name not in SAN: reported to Izenpe via the Mozilla Dev Security Policy Forum on August 6th, 2017
- Invalid DNS name: reported to Izenpe via the Mozilla Dev Security Policy Forum on August 13th, 2017
- Serial Numbers less than 64-bit entropy: reported to Izenpe via the Mozilla Dev Security Policy Forum on August 10th, 2017

2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.

All issues have been addressed

3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.

- Common Name not in SAN (1 precertificate, and 2 certificates):

https://crt.sh/?id=56951679&opt=cablint
https://crt.sh/?id=58473404&opt=cablint
https://crt.sh/?id=179810182&opt=cablint

- Invalid DNS name (1 certificate):

https://crt.sh/?id=6182380&opt=cablint

- Serial Numbers less than 64-bit entropy (61 certificates):
 
https://misissued.com/batch/6/

I'll attach in next notes a CSV with the complete list 

4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.

Common Name not in SAN (1 precertificate, and 2 certificates):

   Date first: November 18, 2016
   Date last: December 1, 2016

Invalid DNS name (1 certificate): 

   Date first: December 17, 2014
   Date last: December 17, 2014

Serial Numbers less than 64-bit entropy (61 certificates): 

   Date first: September 2016
   Date last: May 2017
 
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.

- Common Name not in SAN: in the first certificate we had a technical problem and our software didn't add the CN to the SAN. This problem didn't affect to any other certificate. In the second certificate the technical request file (CSR) we received included a blank space, and unfortunately we didn't see it. Both of them are revoked
 
- Invalid DNS name: this certificate included a DNS name in the SAN that we didn't verify correctly. It's already revoked
 
- Serial numbers with <64 bits of entropy: we made that change to EV certificates in 2014, when it was not mandatory. More than three years ago we have been issuing certificates with more than 64 bits of entropy. But in case of the CA that issues OV and DV certificates, it issues more than just SSL certificates, so that change was not so easy. We had to verify that all problems were solved before putting in the production environment, and our software provider had to modify their product. Finally we put that change in production in May, from that date all certificates have a serial number with more than 64 bits.

6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

- Common Name not in SAN: we are modifying our application to detect CNs not included in SAN before issuing any SSL certificate. We expect to have it in production in 2 months. Until then we'll add a double validation to all our SSL certificates, like we actually do with EVs. All affected certificates are revoked

- Invalid DNS name: we are modifying our application to detect invalid DNS names before issuing any SSL certificate. We expect to have it in production in 2months. Until then we'll add a double validation to all our SSL certificates, like we actually do with EVs. All affected certificates are revoked

- Serial Numbers less than 64-bit entropy: all OV and DV certificates issued after May 17th have the correct serial number. We are developing a plan to revoke all certificates issued before that date (61). Most of these entities are public administration, and revocation of those certificates is not so easy. 


7) Regular updates to confirm when those steps have been completed.

We'll work with our internal and external audit providers to include all these issues in their next review

Comment 3

[Ryan Sleevi]

(In reply to o-garcia from comment #2)
> Hi Kathleen, I'll try to answer to all your questions:

Thanks for structuring your responses to the questions, and for responding with the details requested.

I have a few questions regarding your proposed mitigations for the issue

> 5) Explanation about how and why the mistakes were made, and not caught and
> fixed earlier.
> 
> - Common Name not in SAN: in the first certificate we had a technical
> problem and our software didn't add the CN to the SAN. This problem didn't
> affect to any other certificate. In the second certificate the technical
> request file (CSR) we received included a blank space, and unfortunately we
> didn't see it. Both of them are revoked

Based on this description, it sounds like your system allows manual entry of the common name (in the first case), or copies data from the CSR (in the second case).

Either of these designs would be very error prone, and may result in future errors. Could you confirm if this is the case?

> - Serial numbers with <64 bits of entropy: we made that change to EV
> certificates in 2014, when it was not mandatory. More than three years ago
> we have been issuing certificates with more than 64 bits of entropy. But in
> case of the CA that issues OV and DV certificates, it issues more than just
> SSL certificates, so that change was not so easy. We had to verify that all
> problems were solved before putting in the production environment, and our
> software provider had to modify their product. Finally we put that change in
> production in May, from that date all certificates have a serial number with
> more than 64 bits.

It sounds like you were aware of non-conformance to the Baseline Requirements, as part of your production rollout, and did not complete this until May. Was this communicated with Mozilla (and any other root stores). If so, can you reference this communication (e.g. CA Communication response, email headers, etc) to allow this notification to be found?

An important part of being a globally trusted CA is operating with transparency, particularly when non-compliance is known or anticipated. By being transparent about the issue and the remediation plan, the broader Internet community can participate in discussions of risks and concerns, while also being confident that the CA is aware of the issues and proceeding with a reasonable plan.

> 6) List of steps your CA is taking to resolve the situation and ensure such
> issuance will not be repeated in the future, accompanied with a timeline of
> when your CA expects to accomplish these things.
> 
> - Common Name not in SAN: we are modifying our application to detect CNs not
> included in SAN before issuing any SSL certificate. We expect to have it in
> production in 2 months. Until then we'll add a double validation to all our
> SSL certificates, like we actually do with EVs. All affected certificates
> are revoked

Could you explain why this check may take up to 2 months? That is, can you share more about your timeline, which presumably involves development, testing, and deployment?

Understanding how quickly your CA can respond to changes in the ecosystem, and develop, test, and deploy necessary changes is critical to understanding any risks associated with such a CA. For example, a security-critical change taking 2 months to deploy would be unacceptable, so understanding the factors contributing to this change (which one might expect to be 'simple') is very important.

> - Invalid DNS name: we are modifying our application to detect invalid DNS
> names before issuing any SSL certificate. We expect to have it in production
> in 2months. Until then we'll add a double validation to all our SSL
> certificates, like we actually do with EVs. All affected certificates are
> revoked

Similarly, can you share more about the timeline?

> 7) Regular updates to confirm when those steps have been completed.
> 
> We'll work with our internal and external audit providers to include all
> these issues in their next review

As you've proposed two months to deploy these compliance changes, the goal of this item is to ensure regular updates (on this bug) about your progress on the remediation steps you've proposed, so that the community can be confident you are continuing to make progress on this matter. Weekly updates, for example, would be entirely appropriate.

Comment 4

[Jonathan Rudenberg]

I sent problem reports via email for these three issues, can you please confirm that you received them? The message headers are below.

  From: Jonathan Rudenberg <[e-mail]>
  Subject: Misissuance - Common Name not in SAN
  Message-Id: <[e-mail]>
  Date: Mon, 7 Aug 2017 22:52:13 -0400
  To: [e-mail]

  From: Jonathan Rudenberg <[e-mail]>
  Subject: Misissuance - serial numbers with <64 bits of entropy
  Message-Id: <[e-mail]>
  Date: Thu, 10 Aug 2017 13:42:03 -0400
  To: [e-mail]

  From: Jonathan Rudenberg <[e-mail]>
  Subject: Misissuance - invalid dnsNames 
  Message-Id: <[e-mail]>
  Date: Sun, 13 Aug 2017 00:44:23 -0400
  To: [e-mail]

Comment 5

[Oscar Garcia]

Hi Ryan, 

About manual entry of the common name (in the first case), or copies data from the CSR (in the second case)-> Our system actually allows manual entry, that's something we were going to fix in the upgrade of our application, something that we already had planned. That includes validation of CSR file, but some other things like authomatic CAA validation, TLD validation, documents management, evidences collection, etc. You must keep in mind that we are a small CA, and don't issue thousands of SSL certificates, so until now it's been enough for us. 

About being aware of non-conformance -> We have been aware of this issue this month, when it appeared in the mdsp. This bullet was approbed by CABForum in July of 2016, and published in September. As you probably know we changed our CTO (and contact in CABForum) in september, and looking at the issue of serial numbers the transfer of knowledge did not occur under the best conditions. We have passed three audits (internal by provider, external by CAB, and internal by us) since the ballot was approbed and published, and no one found that issue. Obviously we'll have to improve it. 

About timeline -> The timeline of two months is the time we had planned to implement all changes in our application, including documents management, CAA validation, etc. It's clear that we have to fix critical issues first, so we'll change our project to implement these issues first (CN -> SAN, CSR check, DNS name check). Therefore time to fix these issues will be 1 
month (including development, test, and deployment), and you'll be informed regurarly every week. Until then there will be people validating all certificates (before and after it's been issued).

Jonathan, I confirm you that we have received first two messages, but not the last one. 

Best regards

Comment 6

[Ryan Sleevi]

(In reply to o-garcia from comment #5)
> Hi Ryan, 
> 
> About manual entry of the common name (in the first case), or copies data
> from the CSR (in the second case)-> Our system actually allows manual entry,
> that's something we were going to fix in the upgrade of our application,
> something that we already had planned. That includes validation of CSR file,
> but some other things like authomatic CAA validation, TLD validation,
> documents management, evidences collection, etc. You must keep in mind that
> we are a small CA, and don't issue thousands of SSL certificates, so until
> now it's been enough for us. 

Unfortunately, because you have effective keys to the Internet, it's critical to treat that with the necessary care, diligence, and trustworthiness necessary.

For example, you mention that you had planned these things. That's great, but in order to provide the community the assurance that it benefits from granting Izenpe the capabilities it has, we need a more thorough understanding.

For example, when did you develop these plans? When were they scheduled? Why were they not implemented yet? When will they be implemented? The thoroughness and transparency of your response will help the community better understand and assess the risk of continued trust, and Izenpe's commitment to honor that trust.

> About being aware of non-conformance -> We have been aware of this issue
> this month, when it appeared in the mdsp. This bullet was approbed by
> CABForum in July of 2016, and published in September. As you probably know
> we changed our CTO (and contact in CABForum) in september, and looking at
> the issue of serial numbers the transfer of knowledge did not occur under
> the best conditions. We have passed three audits (internal by provider,
> external by CAB, and internal by us) since the ballot was approbed and
> published, and no one found that issue. Obviously we'll have to improve it. 

It's useful in the process to better understand the factors here, and what steps Izenpe has taken to mitigate this risk. For example, the community has no assurance that Izenpe may change contacts again, and similarly misissue.

Systemically, we'd like to understand why three audits failed to detect this, and what steps have been taken to ensure future audits detect both this, and other changes. Providing a holistic plan for remediation, detection, and mitigation is an important step towards demonstrating Izenpe's committment.

> About timeline -> The timeline of two months is the time we had planned to
> implement all changes in our application, including documents management,
> CAA validation, etc. It's clear that we have to fix critical issues first,
> so we'll change our project to implement these issues first (CN -> SAN, CSR
> check, DNS name check). Therefore time to fix these issues will be 1 
> month (including development, test, and deployment), and you'll be informed
> regurarly every week. Until then there will be people validating all
> certificates (before and after it's been issued).

Note that some of these changes - CAA - are required within two weeks. Are you indicating that you do not plan to have CAA checking deployed by the time required, and thus expect another audit qualification?

Comment 7

[Oscar Garcia]

Hi everyone,

We are currently performing the most urgent tasks from the initial list. Due to the period of year we are in, it's been quite diffcult to revoke all the certificates required in a desirable and short time (and renew them at the same time). So far, from the initial 61 certificates with a "short" serial number,
we have already revoked 11 of them and got in touch with most of the rest of our clients to warn them that they certificates will be revoked and the need to issue a new one.

The next week we will start analyzing all the certificates once they are issued and before being sent to the costumer. We will automatize this task using the certlint util from the GitHub. In case there would any problem with it, we would revoke it inmmediatly.

We are also planning to perform a batch process to analyze all of our currently active certificates to foresee incoming problems.

Our current planification will remain as follows:

                * Certificate control with certlint: before August the 31st

                * SANs-CN control problem: before September the 15th

                * PKCS10 character control automation: before September the 30th

                * Serial numbers >64 bits: Already done

                * Assign an other person from our staff to the CABForum list : before August the 31st

 

                Appart from this, we would like to clarify that CAA controls have been doing for a long time, but not in automatic way, that's something that will be done

in the next update od our software.

 

Regards

Comment 8

[Ryan Sleevi]

(In reply to o-garcia from comment #7)
> The next week we will start analyzing all the certificates once they are
> issued and before being sent to the costumer. We will automatize this task
> using the certlint util from the GitHub. In case there would any problem
> with it, we would revoke it inmmediatly.

While this is an important and valuable detection mechanism for misissuance, it is important to note that to serve as a mitigation mechanism, they must be run before the certificate is issued.

For example, after your system has produced a tbsCertificate (but before it has been signed), you can run certlint over the contents. This ensures that you do not actively misissue (that is, misissuance == signing, not delivery)

To do so, take the tbsCertificate (what you would normally sign), wrap it in a Certificate structure with the same algorithm ID as the final certificate, and a zero-byte length signature (e.g. don't actually sign it; just make it look like a DER-encoded certificate with an invalid signature). You can run this through certlint and other similar tools (x509lint) to detect any non-conformance, prior to the actual issuance.

> We are also planning to perform a batch process to analyze all of our
> currently active certificates to foresee incoming problems.
> 
> Our current planification will remain as follows:
> 
>                 * Certificate control with certlint: before August the 31st
> 
>                 * SANs-CN control problem: before September the 15th
> 
>                 * PKCS10 character control automation: before September the
> 30th
> 
>                 * Serial numbers >64 bits: Already done
> 
>                 * Assign an other person from our staff to the CABForum list
> : before August the 31st

Thank you for clarifying what steps you're taking, and for the improved timeline for deploying these remediations. For example, the questions in Comment #6 are still important to address to ensure the root and contributory issues have been addressed.

Comment 9

[Oscar Garcia]

Hi again,
first of all, thanks Ryan for the recommendation about testing certificates previous issuance. We will discuss it with our PKI provider to evaluate the effort required.

Following our planification, we can say that:
 * We are already checking all the new certificates with the cablint/certlint tool.
 * An other member of our staff ([e-mail]) is also following the CABForum lists.

We keep working on revoking certificates with "short" serial numbers https://misissued.com/batch/6/#revoked . All the clients have been notified and we hope to have all them revoked within two weeks if not earlier.

Besides, we have detected more certificates with the problems listed  below that are not in such list. We will start manually publishing them by tomorrow in the CT and as soon as we publish all of them we will provide the link in crt.sh.

Regards,

Comment 10

[Oscar Garcia]

Hi everyone,
As we said yesterday, we have published all the active certificates with the short serial number and not in the misissued list in Google's CT. We would have to add the following certificates to the list:
https://crt.sh/?id=202499440
https://crt.sh/?id=202500345
https://crt.sh/?id=202500426
https://crt.sh/?id=202500540
https://crt.sh/?id=202500676
https://crt.sh/?id=202500704
https://crt.sh/?id=202500739
https://crt.sh/?id=202500768
https://crt.sh/?id=202500820
https://crt.sh/?id=202500826
https://crt.sh/?id=202500872
https://crt.sh/?id=202500891
https://crt.sh/?id=202500909
https://crt.sh/?id=202500920
https://crt.sh/?id=202500942
https://crt.sh/?id=202500952
https://crt.sh/?id=202500970
https://crt.sh/?id=202500975
https://crt.sh/?id=202500995
https://crt.sh/?id=202501050
https://crt.sh/?id=71491683
https://crt.sh/?id=128963434
https://crt.sh/?id=202501093
https://crt.sh/?id=202501108
https://crt.sh/?id=20209658

We are working on the revokation of these certificates and we wiil keep on sharing our progress.
Regards,

Comment 11

[Ryan Sleevi]

(In reply to o-garcia from comment #9)
> Hi again,
> first of all, thanks Ryan for the recommendation about testing certificates
> previous issuance. We will discuss it with our PKI provider to evaluate the
> effort required.
> 
> Following our planification, we can say that:
>  * We are already checking all the new certificates with the
> cablint/certlint tool.
>  * An other member of our staff ([e-mail]) is also following
> the CABForum lists.
> 
> We keep working on revoking certificates with "short" serial numbers
> https://misissued.com/batch/6/#revoked . All the clients have been notified
> and we hope to have all them revoked within two weeks if not earlier.
> 
> Besides, we have detected more certificates with the problems listed  below
> that are not in such list. We will start manually publishing them by
> tomorrow in the CT and as soon as we publish all of them we will provide the
> link in crt.sh.

Note the questions in Comment #6 are still applicable, as highlighted in Comment #8

Comment 12

[Oscar Garcia]

Status of actions performed:

Certificates issued with short serial number:

 * From misissued finding (62 certs) ->  24 are already revoked, and 38 are still pending to revoke
 * From Izenpe finding (23) ->  11 are revoked and 12 are still pending to revoke

We also have updated our application to validate CSR in our development environment, and we are making all checks before moving to the test and production environments. 

Finally we have updated our human resources procedure, to improve our personnel change process

Best regards

Comment 13

[Oscar Garcia]

State of changes:

- We have put in production the application that validates CSRs
- We have finished revoking all pending certificates in https://misissued.com/batch/6/

Regards

Comment 14

[Oscar Garcia]

Attachment: PKI software manufacturer compromise Letter.pdf

Attached is a letter with a compromise of our PKI software manufacturer to implement by itself all the validations made by tools like certlint. It's planned to have it ready next December.

Best regards

Comment 15

[Gervase Markham [:gerv]]

(In reply to Ryan Sleevi from comment #11)
> Note the questions in Comment #6 are still applicable, as highlighted in
> Comment #8

This remains true. The delay in addressing these issues is concerning.

Gerv

Comment 16

[Oscar Garcia]

Gervase, could you please give us more detail about what remains true?. We have exposed our plan of actions to apply, and (as Ryan proposed), we have posted every week all actions we have taken. In summary:

Already done:

- Revoke all misissued certificates
- Certificate control with certlint
- SANs-CN control
- CSR character control automation
- Issue certificates with serial numbers >64 bits of entropy
- Assign more people from our technical staff to the CABForum and mozilla.dev.security.policy lists
- Update our human resources procedure to improve the personnel change process

Scheduled:

- Compromise of our PKI software manufacturer to implement by itself all the validations made by tools like certlint => December
- Work with our internal and external audit providers to include all these issues, and to enforce the technical aspects of the audit => next review

Thanks

Comment 17

[Gervase Markham [:gerv]]

Sample questions from comment #6 which are still unanswered:

> When did you develop these plans? When were they scheduled? Why were they not implemented yet? When will they be implemented? 

> What steps [has] Izenpe taken to mitigate this risk?

> Why [did] three audits fail to detect this, and what steps have been taken to ensure future audits detect both this, and other changes?

> Please provide a holistic plan for remediation, detection, and mitigation.

I think Ryan's underlying point is that not enough information has been provided to give confidence that there will not be another bug like this in six months. And it's not clear enough why the things that went wrong were not detected before by the existing controls such as audit.

Gerv

Comment 18

[Oscar Garcia]

We are sure that this will answer to all questions:

> When did you develop these plans? When were they scheduled? Why were they not implemented yet? When will they be implemented? 

Plans to upgrade our web application were initially developed in January, and were scheduled to put in production in March. This development included documents management, CAA validation, TLD validation, evidences collection, etc. After this incidence we have divided this project into two different phases: the first one to include all automatic validations (CAA, CSR, etc.), and the second one to add the documents management. 
The first phase was already implemented and put in production in September. We hope the second phase will be implemented and put in production in December.

> What steps [has] Izenpe taken to mitigate this risk?

Already done:

- Revoke all misissued certificates
- Certificate control with certlint
- SANs-CN control
- CSR character control automation
- Issue certificates with serial numbers >64 bits of entropy
- Assign more people from our technical staff to the CABForum and mozilla.dev.security.policy lists
- Update our human resources procedure to improve the personnel change process

Scheduled:

- Compromise of our PKI software manufacturer to implement by itself all the validations made by tools like certlint => December
- Work with our internal and external audit providers to include all these issues, and to enforce the technical aspects of the audit => next review

All of these measures are implemented to mitigate the risk of certificate misissuance.

> Why [did] three audits fail to detect this, and what steps have been taken to ensure future audits detect both this, and other changes?
We make annually the following audits:
- Internal(made by a provider): surveillance audit
- External(provided by accredited CAB): full audit under the ETSI EN 319 411-1 scheme, as specified in CABForum Baseline Requirements 
- Self-audits: quarterly against a randomly selected sample of three percent of issued certificates 

We already make a full audit according to CABForum BRs, so we can’t include more thinks to review. These are the actions we have planned:

- Review the agreement with our CAB
- Make mandatory during both the internal and external audit the review of all changes made by CABForum since las audit

> Please provide a holistic plan for remediation, detection, and mitigation.

All actions proposed (most of them are already implemented) are part of a holistic plan to mitigate the risk:

- Prevention controls:
Technical: SANs-CN control
Technical: CSR character control automation
Human Resources: assign more people from our technical staff to the CABForum and mozilla.dev.security.policy lists
Human Resources: update our human resources procedure to improve the personnel change process
Human Resources: training of personnel when any significant change is made in BRs or EVGs  

- Detection controls:
Technical: certificate control with certlint
	
- Corrective controls:
Technical: issue certificates with serial numbers >64 bits of entropy
Technical: revoke all misissued certificates
	 
Best regards

Comment 19

[Gervase Markham [:gerv]]

(In reply to o-garcia from comment #13)
> - We have put in production the application that validates CSRs
> - We have finished revoking all pending certificates in
> https://misissued.com/batch/6/

That doesn't seem to be true; 23 are listed as still valid, as of today.

Please can you give a list of remediation actions which are not yet implemented, and the date by which you plan to implement them?

Gerv

Comment 20

[Oscar Garcia]

As we indicated in Comment #13 all certificates are revoked. There's no Izenpe certificate in the "Still valid" section of https://misissued.com/batch/6/.

According to the remediation plan, we are meeting the deadlines indicated in Comment #18

Regards

Comment 21

[Oscar Garcia]

We have updated our PKI software to automatically verify all CSRs using same specifications of certlint. Regards