1390979 - certSIGN: 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 common name and invalid SAN dnsName
https://groups.google.com/d/msg/mozilla.dev.security.policy/ETG72kifv4k/2BD-CVDDAAAJ

Comment 1

[vtlynch]

Hi Kathleen,

certSIGN also mis-issued seven (7) certificates where the common name was not included in the SANs. The three certificates were revoked on August 8th, which was less than two days after the original report was posted to mdsp.


Here are the crt.sh links:
https://crt.sh/?id=165083176&opt=cablint
https://crt.sh/?id=151846309&opt=cablint
https://crt.sh/?id=120613778&opt=cablint
https://crt.sh/?id=110598550&opt=cablint
https://crt.sh/?id=96815816&opt=cablint
https://crt.sh/?id=133478511&opt=cablint
https://crt.sh/?id=84300292&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

[Cristian Garabet]

We acknowledge the issues, were aware of them and are in the process of completing the required report. 

Cristian

Comment 3

[Cristian Garabet]

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.


certSIGN became aware via problem report submmited by email on 7.08.2017

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

We hereby confirm that we have stopped issuing certificates that are not BR-compliant.


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.

In progress

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

In progress


During our internal analysis we have discovered the following problems with the certificates:
•	Common name was not from SAN entries
•	Improper validation of DN/SAN entries leading to malformed DN/SAN entries
•	Insufficient technical control over 7.1.4.2.2 from BR which lead to malformed DN


5)	Explanation about how and why the mistakes were made, and not caught and fixed earlier.

Technical controls regarding BR compliance were not enforced in the registration application. The mistakes were not caught earlier because we were not aware of any misissued certificates before. Currently all problem reporting is  done via [e-mail] which is also used for all official certSIGN communication. Due to the very high number of emails coming through this channel those regarding the misissued certificates were detected too late. Also, we have identified some gaps in the escalation and response procedure regarding the problem reports made via [e-mail].


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.

A.	Create a dedicated email address for problem reporting- 1 September 2017
B.	Update all relevant information, documents and procedures regarding problem reporting and response  - 1 October 2017
C.	Enforce technical controls over BR compliance in the registration application and use cablint to validate compliance of the issued certificates- 1 October 2017 

We have contacted our auditor and when will have his answer will update accordingly our comments.

Comment 4

[Cristian Garabet]

We have also notified Microsoft and Apple.

Comment 5

[Cristian Garabet]

We have contacted our auditor, E&Y ([e-mail]), presented them the situation, the causes and the proposed measures and get their approval.

Cristian

Comment 6

[Cristian Garabet]

Attachment: Complete list of misissued certificates found during the remediation process.

This is the answer to 3, that is all the misissued certificates that we have found during the remediation process.

Comment 7

[Cristian Garabet]

Attachment: Summary of the problematic certificates

Here is the answer to 4.

Comment 8

[Jonathan Rudenberg]

(In reply to Cristian Garabet from comment #6)
> Created attachment 8899797 [details]
> Complete list of misissued certificates found during the remediation process.
> 
> This is the answer to 3, that is all the misissued certificates that we have
> found during the remediation process.

This looks like you ran certlint across all certificates that you've issued? If so, that's great!

It would be useful if you could provide answers to Kathleen's questions for each distinct problem that you identified.

Comment 9

[Jonathan Rudenberg]

(In reply to Cristian Garabet from comment #6)
> Created attachment 8899797 [details]
> Complete list of misissued certificates found during the remediation process.
> 
> This is the answer to 3, that is all the misissued certificates that we have
> found during the remediation process.

These certificates are now tracked at: https://misissued.com/batch/20/

Comment 10

[Cristian Garabet]

(In reply to Jonathan Rudenberg from comment #8)
> (In reply to Cristian Garabet from comment #6)
> > Created attachment 8899797 [details]
> > Complete list of misissued certificates found during the remediation process.
> > 
> > This is the answer to 3, that is all the misissued certificates that we have
> > found during the remediation process.
> 
> This looks like you ran certlint across all certificates that you've issued?
> If so, that's great!
> 
> It would be useful if you could provide answers to Kathleen's questions for
> each distinct problem that you identified.

Yes indeed we ran certlint across all certificates that we've issued . During this process we have identified a common cause for all problems, that is the fact that technical controls regarding BR compliance were not enforced in the registration application. As already stated we propose ourselves to enforce until 1 October 2017 those technical controls over BR compliance in the registration application and use cablint to validate compliance of the issued certificates.

Comment 11

[Cristian Garabet]

(In reply to Jonathan Rudenberg from comment #9)
> (In reply to Cristian Garabet from comment #6)
> > Created attachment 8899797 [details]
> > Complete list of misissued certificates found during the remediation process.
> > 
> > This is the answer to 3, that is all the misissued certificates that we have
> > found during the remediation process.
> 
> These certificates are now tracked at: https://misissued.com/batch/20/

Now, of all the 40 misissued certificates none are still valid, 12 are expired and 28 were revoked.

Comment 12

[Ryan Sleevi]

(In reply to Jonathan Rudenberg from comment #8)
> It would be useful if you could provide answers to Kathleen's questions for
> each distinct problem that you identified.

I agree with Jonathan that this would be useful.

For example, it's not clear why a common name such as "todyro_2017" was accepted by your system. I can understand an absence of technical controls, but understanding a timeline of how this certificate came to be (from request to issuance), along with the changes being made at various steps along the way, is useful.

For example, was this value copied automatically from a CSR? Was it entered by RA staff? How did the space appear in " tody.ro"? How was this domain name validated, given the malformedness?

A more detailed analysis of how this came to be is very useful in understanding how the mitigations address this.

Comment 13

[Cristian Garabet]

(In reply to Ryan Sleevi from comment #12)
> (In reply to Jonathan Rudenberg from comment #8)
> > It would be useful if you could provide answers to Kathleen's questions for
> > each distinct problem that you identified.
> 
> I agree with Jonathan that this would be useful.
> 
> For example, it's not clear why a common name such as "todyro_2017" was
> accepted by your system. I can understand an absence of technical controls,
> but understanding a timeline of how this certificate came to be (from
> request to issuance), along with the changes being made at various steps
> along the way, is useful.
> 
> For example, was this value copied automatically from a CSR? Was it entered
> by RA staff? How did the space appear in " tody.ro"? How was this domain
> name validated, given the malformedness?
> 
> A more detailed analysis of how this came to be is very useful in
> understanding how the mitigations address this.

Hi Ryan,

The DN is constructed by the customer and packaged in the request (CSR).  We add the SAN entries at the RA and DN is taken from CSR.  Our RA/CA system is not connected to internet and validation of the domain " tody.ro" was just fine since rotld.ro responded accordingly. We validate domains in the SAN entries individually and then add them to the certificate. Domain (or content) in the CN was not validated when at least one DNS entry was present in SAN.
Lack of technical controls allowed characters like space to be included in the SAN because the validation against ruling authority in Romania was successful.
We will enforce technical controls in the registration application to validate all DN fields extracted from CSR and add controls to check that the domain from CN is present in SAN.
We will use cablint to double check errors from now on. Also we have planned to add support for Certificate Transparency until April 2018.

Cristian

Comment 14

[Ryan Sleevi]

(In reply to Cristian Garabet from comment #13)
> Hi Ryan,
> 
> The DN is constructed by the customer and packaged in the request (CSR).  We
> add the SAN entries at the RA and DN is taken from CSR. Our RA/CA system is
> not connected to internet and validation of the domain " tody.ro" was just
> fine since rotld.ro responded accordingly. We validate domains in the SAN
> entries individually and then add them to the certificate. Domain (or
> content) in the CN was not validated when at least one DNS entry was present
> in SAN.
> Lack of technical controls allowed characters like space to be included in
> the SAN because the validation against ruling authority in Romania was
> successful.

I see. To make sure I can appropriately summarize your validation method:
- You receive a CSR, along with one or more indicated domains
- Your RA personnel manually contact the domain registry to manually verify the information is correct
  - Or do you use a WHOIS method? Can you expand?
- Your RA personnel then enter the authorized domains themselves
  - Or does this come from the applicant-provided details?
- You then issue the certificate

> We will enforce technical controls in the registration application to
> validate all DN fields extracted from CSR and add controls to check that the
> domain from CN is present in SAN.

This raises concerns/questions I'm hoping you can clarify:

- What process do you have to ensure no unrecognized subject naming attributes are provided?
- What process do you have to ensure that all subject information is appropriately validated?
- What process do you have to ensure that all subject information is appropriately encoded, pursuant to RFC5280 (e.g. that it uses the appropriate string encoding)?

I should note that your reply in Comment #11, indicating you plan to run after issuing, still represents misissuance. To properly prevent misissuance, you need to ensure that you run an analysis prior to issuing the certificate - for example, over the tbsCertificate. Do you plan to do so?

Overall, there's a substantial number of failures here with respect to compliance to the Baseline Requirements. This suggests that, organizationally, strong controls are not in place to ensure both the technical and procedural requirements have met. What remediations have you put in place to ensure your organization appropriately implements the necessary requirements? What steps have been taken with your auditor to ensure this compliance? What analysis have you done to determine why, in the course of an audit, none of these certificates were identified as non-conformant?


In trying to summarize the information to date:

1) Leading spaces in the dNSName (or otherwise technically malformed DNS names)
- See Comment #0, Comment #3, Comment #13
- Planned Remediations
  - 2017-09-01 - Create a dedicated email for problem reporting
  - 2017-10-01 - Create and document procedures for problem reporting response
  - 2017-10-01 - Implement technical controls that:
    - Ensure the dNSName adheres to RFC 1034's "preferred name syntax"

2) commonNames in BR certificates must be from SAN entries
- See Comment #1, Comment #6, Comment #7, Comment #13
- Planned Remediations
  - 2017-10-01 - Implement technical controls that:
     - Ensure that the contents of the commonName field match that of one of the subjectAltName fields, if present (either as an A-Label in the case of dNSName or as the canonical string representation in the case of IP address)

3) BR certificates with organizationName must include either localityName or stateOrProvinceName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

4) Constraint failure in X520OrganizationName: ASN.1 constraint check failed
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

5) Invalid country in countryName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

6) Duplicate SAN entry
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

7) BR certificates without organizationName must not include localityName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

8) BR certificates with organizationName must include countryName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

9) BR certificates without organizationName must not include stateOrProvinceName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

10) BR certificates must have subject alternative names extension
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement certlint based analysis (after issuing)

Comment 15

[Cristian Garabet]

(In reply to Ryan Sleevi from comment #14)
> (In reply to Cristian Garabet from comment #13)
> > Hi Ryan,
> > 
> > The DN is constructed by the customer and packaged in the request (CSR).  We
> > add the SAN entries at the RA and DN is taken from CSR. Our RA/CA system is
> > not connected to internet and validation of the domain " tody.ro" was just
> > fine since rotld.ro responded accordingly. We validate domains in the SAN
> > entries individually and then add them to the certificate. Domain (or
> > content) in the CN was not validated when at least one DNS entry was present
> > in SAN.
> > Lack of technical controls allowed characters like space to be included in
> > the SAN because the validation against ruling authority in Romania was
> > successful.
> 
> I see. To make sure I can appropriately summarize your validation method:
> - You receive a CSR, along with one or more indicated domains
> - Your RA personnel manually contact the domain registry to manually verify
> the information is correct

Yes
>   - Or do you use a WHOIS method? Can you expand?
> - Your RA personnel then enter the authorized domains themselves
>   - Or does this come from the applicant-provided details?

RA personnel enter authorized domains that will appear in SAN and CN is taken from CSR.
> - You then issue the certificate
> 
> > We will enforce technical controls in the registration application to
> > validate all DN fields extracted from CSR and add controls to check that the
> > domain from CN is present in SAN.
> 
> This raises concerns/questions I'm hoping you can clarify:
> 
> - What process do you have to ensure no unrecognized subject naming
> attributes are provided?

An issuance procedure is in place at RA. Until the mentioned technical controls will be implemented, we have improved it by adding more details regarding the verification of CSRs and validation of all subject information. We also added cross-check verification before issuance. We have reviewed our training material for the operators.

> - What process do you have to ensure that all subject information is
> appropriately validated?

An issuance procedure is in place at RA. Until the mentioned technical controls will be implemented, we have improved it by adding more details regarding the verification of CSRs and validation of all subject information. We also added cross-check verification before issuance. We have reviewed our training material for the operators.

> - What process do you have to ensure that all subject information is
> appropriately encoded, pursuant to RFC5280 (e.g. that it uses the
> appropriate string encoding)?

There is a technical control implemented in the application according to RFC 5280.We have identified a software issue regarding the length of the O field. This will be fixed until 1.10.2017.
> 
> I should note that your reply in Comment #11, indicating you plan to run
> after issuing, still represents misissuance. To properly prevent
> misissuance, you need to ensure that you run an analysis prior to issuing
> the certificate - for example, over the tbsCertificate. Do you plan to do so?

Yes.Until 1.10 we will enforce technical controls over BR compliance in the application. Also, we have planned to use a tbsCertificate linter prior to issuing the certificate until 1.11.
> 
> Overall, there's a substantial number of failures here with respect to
> compliance to the Baseline Requirements. This suggests that,
> organizationally, strong controls are not in place to ensure both the
> technical and procedural requirements have met. What remediations have you
> put in place to ensure your organization appropriately implements the
> necessary requirements? 

Until the mentioned technical controls will be implemented, we have improved our issuing procedure by adding more details regarding the verification of CSRs and validation of all subject information. We also added cross-check verification before issuance. We have reviewed our training material for the operators.

> What steps have been taken with your auditor to
> ensure this compliance? 

We have contacted our auditor and when will have his answer will update our comments accordingly.

> What analysis have you done to determine why, in the
> course of an audit, none of these certificates were identified as
> non-conformant?
> 
The audit was based on sampling and the samples taken did not contain any non-conformant certificates.
> 
> In trying to summarize the information to date:
> 
> 1) Leading spaces in the dNSName (or otherwise technically malformed DNS
> names)
> - See Comment #0, Comment #3, Comment #13
> - Planned Remediations
>   - 2017-09-01 - Create a dedicated email for problem reporting
>   - 2017-10-01 - Create and document procedures for problem reporting
> response
>   - 2017-10-01 - Implement technical controls that:
>     - Ensure the dNSName adheres to RFC 1034's "preferred name syntax"

Yes, we have planned to enforce technical controls in the RA application to ensure the dNSName adheres to RFC 1034's "preferred name syntax".
> 
> 2) commonNames in BR certificates must be from SAN entries
> - See Comment #1, Comment #6, Comment #7, Comment #13
> - Planned Remediations
>   - 2017-10-01 - Implement technical controls that:
>      - Ensure that the contents of the commonName field match that of one of
> the subjectAltName fields, if present (either as an A-Label in the case of
> dNSName or as the canonical string representation in the case of IP address)

Yes, we have planned to enforce technical controls in the application to ensure that the contents of the commonName field match that of one of the subjectAltName fields, if present (either as an A-Label in the case of dNSName or as the canonical string representation in the case of IP address).
> 
> 3) BR certificates with organizationName must include either localityName or
> stateOrProvinceName
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)
> 
We have planned to enforce technical control in the application to ensure before issuing that certificates with organizationName will include either localityName or stateOrProvinceName.


> 4) Constraint failure in X520OrganizationName: ASN.1 constraint check failed
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)

We have planned to enforce technical control in the application to ensure before issuing conformity with RFC 5280 regarding upper bounds (ub-organization-name INTEGER ::= 64).
> 
> 5) Invalid country in countryName
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)
> 
We have planned to enforce technical control in the application to ensure before issuing conformity with RFC 5280 regarding the country field.

> 6) Duplicate SAN entry
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)
> 
We have planned to enforce technical control in the application to ensure before issuing that duplicated SAN entries are not permitted.

> 7) BR certificates without organizationName must not include localityName
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)
> 
Currently we issue only OV certificates. We have planned to enforce technical control in the application to ensure before issuing that all SSL certificates will have both O and L/ST fields. 

> 8) BR certificates with organizationName must include countryName
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)
> 
We have planned to enforce technical control in the application to ensure before issuing that all SSL certificates will include countryName field. 

> 9) BR certificates without organizationName must not include
> stateOrProvinceName
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)

Currently we issue only OV certificates. We have planned to enforce technical control in the application to ensure before issuing that all SSL certificates will have both O and L/ST fields. 
> 
> 10) BR certificates must have subject alternative names extension
> - See Comment #6, Comment #7
> - Planned Remediations
>   - 2017-10-01 - Implement certlint based analysis (after issuing)

We have planned to enforce technical control in the application to ensure before issuing that will have subject alternative names extension.

Comment 16

[Cristian Garabet]

As per Comment #3  

"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.

A.	Create a dedicated email address for problem reporting- 1 September 2017
B.	Update all relevant information, documents and procedures regarding problem reporting and response  - 1 October 2017
C.	Enforce technical controls over BR compliance in the registration application and use cablint to validate compliance of the issued certificates- 1 October 2017 "

a dedicated address for problem reporting was due today. We have created [e-mail] and updated our CPS accordingly. Now we have a more explicit procedure for certificate problem report (as per BR) and this new mail address is an important part of it. The new CPS will be published in the next hour or so. We have also taken internal measures to be sure no problem report coming to this address will be missed in the future.

Comment 17

[Ryan Sleevi]

Kathleen: Per Comment #16, it sounds like the CA's Problem Reporting Mechanism can be updated in the CCADB.

Based on Comment #15, I believe the following is the current summary:

1) Leading spaces in the dNSName (or otherwise technically malformed DNS names)
- See Comment #0, Comment #3, Comment #13
- Planned Remediations
  - 2017-09-01 - Create a dedicated email for problem reporting
  - 2017-10-01 - Create and document procedures for problem reporting response
  - 2017-10-01 - Implement technical controls that:
    - Ensure the dNSName adheres to RFC 1034's "preferred name syntax"

2) commonNames in BR certificates must be from SAN entries
- See Comment #1, Comment #6, Comment #7, Comment #13
- Planned Remediations
  - 2017-10-01 - Implement technical controls that:
     - Ensure that the contents of the commonName field match that of one of the subjectAltName fields, if present (either as an A-Label in the case of dNSName or as the canonical string representation in the case of IP address)

3) BR certificates with organizationName must include either localityName or stateOrProvinceName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

4) Constraint failure in X520OrganizationName: ASN.1 constraint check failed
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

5) Invalid country in countryName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

6) Duplicate SAN entry
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

7) BR certificates without organizationName must not include localityName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

8) BR certificates with organizationName must include countryName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

9) BR certificates without organizationName must not include stateOrProvinceName
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

10) BR certificates must have subject alternative names extension
- See Comment #6, Comment #7
- Planned Remediations
  - 2017-10-01 - Implement pre-issuance technical controls to ensure compliance

Comment 18

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #17)
> Kathleen: Per Comment #16, it sounds like the CA's Problem Reporting
> Mechanism can be updated in the CCADB.

It has been updated.

Comment 19

[Cristian Garabet]

We have updated our CPSes with problem reporting and with the [e-mail] email address. Also we have implemented technical controls to ne notified immediately by SMS if an email with relevant keywords was received at the mentioned address and created and documented a procedure for problem reporting response indicating who will do what.
We have enforced technical controls over BR compliance in the registration application and used cablint to validate compliance of the issued certificates. More precisley we have enforced technical controls in the application  to ensure before issuing:
·that the dNSName adheres to RFC 1034's "preferred name syntax"
·that the contents of the commonName field match that of one of the subjectAltName fields, if present (either as an A-Label in the 
  case of dNSName or as the canonical string representation in the case of IP address).
·that certificates with organizationName will include either localityName or stateOrProvinceName.
·conformity with RFC 5280 regarding upper bounds (ub-organization-name INTEGER ::= 64).
·conformity with RFC 5280 regarding the country field.
·that duplicated SAN entries are not permitted.
·that all SSL certificates will have both O and L/ST fields (currently we issue only OV certificates)
·that all SSL certificates will include countryName field.
·that certificates will have subject alternative names extension.

Comment 20

[Ryan Sleevi]

As all planned remediations have been implemented, closing as Resolved/Fixed.