Symantec: Non-BR-Compliant Certificate Issuance

RESOLVED FIXED

Status

RESOLVED FIXED
a year ago
10 months ago

People

(Reporter: kwilson, Assigned: steve_medin)

Tracking

trunk

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ca-compliance])

Attachments

(8 attachments)

569.65 KB, application/vnd.ms-excel
Details
1.80 MB, application/vnd.ms-excel
Details
880.47 KB, application/vnd.ms-excel
Details
218.56 KB, application/vnd.ms-excel
Details
40.26 KB, application/vnd.ms-excel
Details
6.57 KB, application/vnd.ms-excel
Details
9.58 KB, application/vnd.ms-excel
Details
148.28 KB, application/vnd.ms-excel
Details
(Reporter)

Description

a year ago
** This bug applies to all Symantec brands, including VeriSign, Thawte, and GeoTrust.

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.

** Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case. 

** 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

** Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ
Additionally, I was unable to find a public incident report sent to Mozilla for certificates with invalid dnsNames containing "double dots"  detailed and listed in the links below.

https://groups.google.com/d/topic/mozilla.dev.security.policy/5bpr9yBgaYo/discussion
https://misissued.com/batch/13/
(Assignee)

Comment 2

a year ago
I acknowledge this bug and confirm that we have been working on resolution of the issues and preparing information to share with the community since the issues were posted in m.d.s.policy, which several of us monitor daily. Further detail to come.

Kathleen, I'd like further guidance on Jonathan's #1 above from your perspective, please.
(Reporter)

Comment 3

a year ago
(In reply to Steven Medin from comment #2)
> I acknowledge this bug and confirm that we have been working on resolution
> of the issues and preparing information to share with the community since
> the issues were posted in m.d.s.policy, which several of us monitor daily.
> Further detail to come.
> 
> Kathleen, I'd like further guidance on Jonathan's #1 above from your
> perspective, please.

There is a report of the double-dot certs here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/5bpr9yBgaYo/U-vZ3NNoBgAJ

We are just looking for answers to the questions above regarding this double-dot incident as well -- mostly what measures have been put into place to ensure it doesn't happen again.
(Assignee)

Comment 4

a year ago
** Failure to respond within 24 hours after Problem Report submitted

1. Bugzilla, 2017-08-16
2. Not applicable
3. Not applicable
4. Not applicable
5. As written, the Baseline Requirements currently state in 4.9.5 that a CA must begin an investigation of a certificate problem report within 24 hours. The CA then has an unrestricted period of time to conduct said investigation, during which, as they become aware of violations of 4.9.1.1, they must then revoke within 24 hours. Our 24/7 technical support team monitors our SSL certificate problem intake and typically starts action immediately, often in 15 minutes or less. Based on the investigation required, we do not send a confirming reply to the problem reporter until we confirm the legitimacy of the report. We receive, research, and disqualify bogus reports daily. Because we protect our intake from most types of bogus reports using Captcha, the quality of reports we receive is high and we do not need to apply aggressive spam filters that might quarantine valid reports.
6. Not applicable, we comply with BR 4.9.5 and Mozilla Root Policy 2.5
7. Not applicable


** Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)

1. 2016-08-09, m.d.s.policy
2. We confirm that we stopped issuance of TLS certificates with metadata-only DN attributes on 2017-06-08. Certificate requests presented to our APIs and user interfaces have been subject to two compliance scans. On 2016-04-28, we added a metadata check for mandatory attributes of subject DNs. On 2017-01-13, we extended the check to include all subject DN attributes we permit. On 2017-06-08, we added subject DN attribute checking for single characters, leading/trailing spaces, and we fully duplicated cablint’s compliance checks into our compliance engines.
3. Not applicable, Mozilla does not seek historical remediation for this issue.
4. Not applicable
5. Before we enhanced our compliance engine and our knowledge base, we permitted metadata in the organizational unit field of certificates we issued. 
6. We consider the automation, training, and KB documentation improvements complete and total.
7. We consistently review both CABF and specific browser policy changes and enhance our compliance automation. We have cablint-identical rule enforcement, preventing issuance if a certificate request does not meet all rules implemented in our compliance engine.  We welcome suggestions for further actions we might take.


** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)

1. 2017-08-12, problem report
2. We confirm that we stopped issuance of TLS certificates with malformed wildcards on 2016-04-28. In the case of the certificate for nic.mutuelle, IANA reports that TLD as active from 2015-10-19 to 2016-12-15. That certificate was issued on 2015-12-16.
3. In addition to the problem certificates reported at https://misissued.com/batch/8/, we identified 13 additional valid certificates with malformed wildcards. In each of the 13 cases, these certificates were issued before we required CT logging for all certificates, part of which includes getting explicit customer permission to log. For these 13, we list the issuer and serial number.
   a. Symantec Class 3 Secure Server SHA256 SSL CA
      i. 63b6fa7a8a114bec54923b68384b8a8c
   b. Symantec Class 3 Secure Server CA - G4
      i. 410587fa355406575530bf009ee02014
     ii. 2dad43dfaabf2d9ef062c38d2180e198
    iii. 438b854c40e5a2f16f853126c95bb076
     iv. a1449f26b8e44fa1bdcc497e0f9197e
      v. 7cf9bdef07722a242b6ae0c101e941b2
     vi. 78b0ca5b7529b5e532f3271c92a9fdd
    vii. 2849d80957e71fa4e7ac4d192ca8f641
   viii. 16a9710d9d6a7e6f478b030df6f59af4
     ix. 30ce678d8ff0a72dfcd641a21ec85ab9
      x. 5c65332c26e6787a2258b021b05cd820
   c. RapidSSL SHA256 CA - G3
      i. 037c11
   d. GeoTrust SSL CA
      i. 02c875
4. We have revoked the 4 certificates with the original problem report (3 with malformed wildcards and one in a TLD that IANA revoked). Of the 13 additional certificates that we identified with malformed wildcards, 8 have been revoked and we are working with the customer owning the other 5 to complete their replacement and revoke these certificates.  The problem certificates were issued between 2014-03-23 and 2016-04-07.
5. Prior to 2016-04-28, malformed wildcard certificates were issued in enterprise accounts because our compliance engine did not examine the FQDN prefix of a validated Authorization Domain Name in these enterprise accounts. For this type of account, our validation analysts complete proof of domain control at an Authorization Domain Name level, then the enterprise account administrator is permitted to approve certificate requests within that restricted namespace until the data reuse rules per BR and EVG expire or our validation analysts revalidate the ADN and extend the data reuse expiration date.
6. For wildcards, we consider our prevention action complete as of April 2016. For TLDs revoked by IANA, we block new certificate issuance using our compliance engine, even in the case of enterprise accounts where ADN validation is considered reusable until BR or EVG specified expiry. Our compliance engine is a per-certificate check, not a per-validation check.
7. Not applicable.


** Common Name not in SAN

1. 2017-08-06, m.d.s.policy
2. Not applicable, as we explained in the result of our certificate problem report investigation posted by Jonathan Rudenberg to the discussion of this issue at https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/rxEptYe7BwAJ 
3. Not applicable
4. Not applicable
5. Not applicable, we consider the puny-coded SAN and the Unicode CN to be equals that can be proven by common algorithms.
6. No actions planned.
7. No actions planned.


** Double dot dnsNames

1. 2017-07-18, m.d.s.policy
2. We confirm that we stopped issuance of TLS certificates with double-dot malformed FQDNs on 2016-04-28.
3. The relevant certificates are documented at https://misissued.com/batch/13/
4. Fourteen certificates, including 11 already expired at the time that we enhanced our compliance engine to block these problem certificates were issued between 2010-11-18 and 2016-04-06. The three valid certificates were revoked on 2016-08-08, 2016-09-12, and 2016-09-28.
5. Prior to 2016-04-28, malformed FQDN certificates were issued in enterprise accounts because our compliance engine did not examine the FQDN prefix of a validated Authorization Domain Name in these enterprise accounts. For this type of account, our validation analysts complete proof of domain control at an Authorization Domain Name level, then the enterprise account administrator is permitted to approve certificate requests within that restricted namespace until the data reuse rules per BR and EVG expire or our validation analysts revalidate the ADN and extend the data reuse expiration date.
6. Necessary blocking action was taken 2016-04-28 and revocations were performed in September 2016.
7. No further action planned.

Comment 5

a year ago
(In reply to Steven Medin from comment #4)
> ** Failure to respond within 24 hours after Problem Report submitted
> 
> 1. Bugzilla, 2017-08-16
> 2. Not applicable
> 3. Not applicable
> 4. Not applicable
> 5. As written, the Baseline Requirements currently state in 4.9.5 that a CA
> must begin an investigation of a certificate problem report within 24 hours.
> The CA then has an unrestricted period of time to conduct said
> investigation, during which, as they become aware of violations of 4.9.1.1,
> they must then revoke within 24 hours. Our 24/7 technical support team
> monitors our SSL certificate problem intake and typically starts action
> immediately, often in 15 minutes or less. Based on the investigation
> required, we do not send a confirming reply to the problem reporter until we
> confirm the legitimacy of the report. We receive, research, and disqualify
> bogus reports daily. Because we protect our intake from most types of bogus
> reports using Captcha, the quality of reports we receive is high and we do
> not need to apply aggressive spam filters that might quarantine valid
> reports.
> 6. Not applicable, we comply with BR 4.9.5 and Mozilla Root Policy 2.5
> 7. Not applicable

Note that this interpretation is not consistent with how Mozilla is/has been viewing this requirement.

That is, upon submission of potential evidence of misissuance, the CA is considered to be made aware of a violation of 4.9.1.1 (if the information is correct). Thus, there is a total of 24 hours from report to revocation in the case of misissuance.

If the CA determines it is not misissuance, then the CA is not obligated to revoke. However, if either an auditor or, on subsequent examination (such as by a root store), it is determined to be misissuance, then the CA has failed to uphold the Baseline Requirements.

For this reason, the CA MUST take prompt action to review and come to a conclusion, to ensure that any violations are revoked within 24 hours of report.

This is consistent with how past incidents and misissuances from other CAs have been treated. Further discussion in the CA/Browser Forum is continuing, on allowing a bounded time for investigation (not unlimited) and a bounded time for revocation (not unlimited). Under the present language, a total of 24 hours from report to revocation is required.

> ** Certificates with metadata-only subject fields (at least one subject
> field that only contains ASCII punctuation characters)
> 
> 1. 2016-08-09, m.d.s.policy
> 2. We confirm that we stopped issuance of TLS certificates with
> metadata-only DN attributes on 2017-06-08. Certificate requests presented to
> our APIs and user interfaces have been subject to two compliance scans. On
> 2016-04-28, we added a metadata check for mandatory attributes of subject
> DNs. On 2017-01-13, we extended the check to include all subject DN
> attributes we permit. On 2017-06-08, we added subject DN attribute checking
> for single characters, leading/trailing spaces, and we fully duplicated
> cablint’s compliance checks into our compliance engines.
> 3. Not applicable, Mozilla does not seek historical remediation for this
> issue.

As Symantec has indicated they have already completed remediation, please list all certificates that were detected with this issue prior to remediation efforts.

> 4. Not applicable

While it is laudable that Symantec detected and resolved this issue prior to public comment, in order to assess the completeness and thoroughness of Symantec's response, please provide the relevant information. This is consistent with the request of all CAs that have had issues filed against them regarding these incidents, regardless of the completion of their remediation efforts (prior to or following notification), to ensure the necessary public review and completeness of the remediation in the absence of a self-reported problem report.

> 6. We consider the automation, training, and KB documentation improvements
> complete and total.

While you noted some remediations in Step 2, you did not list anything regarding the steps taken with respect to training or KB documentation. Please provide details about the steps you took to remedy this issue, in total.


> ** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards
> in the wrong position)
> 
> 1. 2017-08-12, problem report
> 2. We confirm that we stopped issuance of TLS certificates with malformed
> wildcards on 2016-04-28. In the case of the certificate for nic.mutuelle,
> IANA reports that TLD as active from 2015-10-19 to 2016-12-15. That
> certificate was issued on 2015-12-16.
> 3. In addition to the problem certificates reported at
> https://misissued.com/batch/8/, we identified 13 additional valid
> certificates with malformed wildcards. In each of the 13 cases, these
> certificates were issued before we required CT logging for all certificates,
> part of which includes getting explicit customer permission to log.

The request was to ensure these certificates are logged and appropriately publicly disclosed. Symantec appears to be requesting that they not be required to do so, despite all other CAs complying.

Kathleen, Gerv: As module owner & peer, I feel this would be appropriate for you to determine whether or not this constitutes an appropriate response. In the spirit of openness and transparency, I believe that the Mozilla requirements supercede those of requiring permission, and should be treated as not an appropriate response.

> 4. We have revoked the 4 certificates with the original problem report (3
> with malformed wildcards and one in a TLD that IANA revoked). Of the 13
> additional certificates that we identified with malformed wildcards, 8 have
> been revoked and we are working with the customer owning the other 5 to
> complete their replacement and revoke these certificates.  The problem
> certificates were issued between 2014-03-23 and 2016-04-07.

When do you expect revocation to be completed?

> 6. For wildcards, we consider our prevention action complete as of April
> 2016. 

You have not described what prevention steps you have taken that you completed by April 2016.

> ** Common Name not in SAN
> 
> 1. 2017-08-06, m.d.s.policy
> 2. Not applicable, as we explained in the result of our certificate problem
> report investigation posted by Jonathan Rudenberg to the discussion of this
> issue at
> https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/
> rxEptYe7BwAJ 
> 3. Not applicable
> 4. Not applicable
> 5. Not applicable, we consider the puny-coded SAN and the Unicode CN to be
> equals that can be proven by common algorithms.

Please detail the algorithms you believe these can be proven by.

> 6. No actions planned.
> 7. No actions planned.

Note that such certificates pose risk to Mozilla users, by bypassing the policies and controls Mozilla has implemented with respect to the display of IDNs. Please consider this a request to provide a timeline for revoking these certificates, or what steps have been taken to prevent further issuance of these certificates.


> 
> 
> ** Double dot dnsNames
> 
> 1. 2017-07-18, m.d.s.policy
> 4. Fourteen certificates, including 11 already expired at the time that we
> enhanced our compliance engine to block these problem certificates were
> issued between 2010-11-18 and 2016-04-06. The three valid certificates were
> revoked on 2016-08-08, 2016-09-12, and 2016-09-28.

https://crt.sh/?id=12104207&opt=cablint lists revocation on 2016-08-18. Can you explain this discrepancy?

> 6. Necessary blocking action was taken 2016-04-28 and revocations were
> performed in September 2016.

Please describe what steps you took to block such certificates.
Please explain how the blocking action (taken on 2016-04-28) and the revocation action (taken on 2016-09) is consistent with the answer in 1, which suggests that you first became aware of the issue on 2017-07-18.
Flags: needinfo?(kwilson)
Flags: needinfo?(gerv)
(Reporter)

Comment 6

a year ago
(In reply to Steven Medin from comment #4) 
> ** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards
> in the wrong position)
> 
> 1. 2017-08-12, problem report
> 2. We confirm that we stopped issuance of TLS certificates with malformed
> wildcards on 2016-04-28. In the case of the certificate for nic.mutuelle,
> IANA reports that TLD as active from 2015-10-19 to 2016-12-15. That
> certificate was issued on 2015-12-16.
> 3. In addition to the problem certificates reported at
> https://misissued.com/batch/8/, we identified 13 additional valid
> certificates with malformed wildcards. In each of the 13 cases, these
> certificates were issued before we required CT logging for all certificates,
> part of which includes getting explicit customer permission to log. For
> these 13, we list the issuer and serial number.
>    a. Symantec Class 3 Secure Server SHA256 SSL CA
>       i. 63b6fa7a8a114bec54923b68384b8a8c
>    b. Symantec Class 3 Secure Server CA - G4
>       i. 410587fa355406575530bf009ee02014
>      ii. 2dad43dfaabf2d9ef062c38d2180e198
>     iii. 438b854c40e5a2f16f853126c95bb076
>      iv. a1449f26b8e44fa1bdcc497e0f9197e
>       v. 7cf9bdef07722a242b6ae0c101e941b2
>      vi. 78b0ca5b7529b5e532f3271c92a9fdd
>     vii. 2849d80957e71fa4e7ac4d192ca8f641
>    viii. 16a9710d9d6a7e6f478b030df6f59af4
>      ix. 30ce678d8ff0a72dfcd641a21ec85ab9
>       x. 5c65332c26e6787a2258b021b05cd820
>    c. RapidSSL SHA256 CA - G3
>       i. 037c11
>    d. GeoTrust SSL CA
>       i. 02c875
>  ...
>  The problem certificates were issued between 2014-03-23 and 2016-04-07.
>

(In reply to Ryan Sleevi from comment #5)
> Kathleen, Gerv: As module owner & peer, I feel this would be appropriate for
> you to determine whether or not this constitutes an appropriate response. In
> the spirit of openness and transparency, I believe that the Mozilla
> requirements supercede those of requiring permission, and should be treated
> as not an appropriate response.

My initial request was:
"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."

As you can see, I unfortunately did not specify what data needed to be in the "complete list of certificates". And the second sentence was stated as a recommendation. In the spirit of openness and transparency, I would like to have the certs fully disclosed. But I did not clearly state that in my original request.

Steve, was it your intention to not fully disclose the problematic certificates? If yes, why?
Flags: needinfo?(kwilson)

Comment 7

a year ago
(In reply to Kathleen Wilson from comment #6)
> As you can see, I unfortunately did not specify what data needed to be in
> the "complete list of certificates". And the second sentence was stated as a
> recommendation. In the spirit of openness and transparency, I would like to
> have the certs fully disclosed. But I did not clearly state that in my
> original request.

So far, only one CA that I can tell has understood "certificates" to mean anything other than the DER-encoded Certificate structure, as specified in RFC 5280. What has been provided here is a complete list of certificate hashes :)

Thank you for clarifying the intent to provide the actual certificates, either through logging (and a reference to their disclosed information) or through providing an attachment of the certificates to this bug.
Flags: needinfo?(gerv)
Steve: there are open questions here (e.g. from comment #5) which have been open almost a month. When can we expect responses and an update on progress?

Gerv
Flags: needinfo?(steve_medin)
(Assignee)

Comment 9

a year ago
(In reply to Ryan Sleevi from comment #5)
> (In reply to Steven Medin from comment #4)
> > ** Failure to respond within 24 hours after Problem Report submitted
> > 
> > 1. Bugzilla, 2017-08-16
> > 2. Not applicable
> > 3. Not applicable
> > 4. Not applicable
> > 5. As written, the Baseline Requirements currently state in 4.9.5 that a CA
> > must begin an investigation of a certificate problem report within 24 hours.
> > The CA then has an unrestricted period of time to conduct said
> > investigation, during which, as they become aware of violations of 4.9.1.1,
> > they must then revoke within 24 hours. Our 24/7 technical support team
> > monitors our SSL certificate problem intake and typically starts action
> > immediately, often in 15 minutes or less. Based on the investigation
> > required, we do not send a confirming reply to the problem reporter until we
> > confirm the legitimacy of the report. We receive, research, and disqualify
> > bogus reports daily. Because we protect our intake from most types of bogus
> > reports using Captcha, the quality of reports we receive is high and we do
> > not need to apply aggressive spam filters that might quarantine valid
> > reports.
> > 6. Not applicable, we comply with BR 4.9.5 and Mozilla Root Policy 2.5
> > 7. Not applicable
> 
> Note that this interpretation is not consistent with how Mozilla is/has been
> viewing this requirement.
> 
> That is, upon submission of potential evidence of misissuance, the CA is
> considered to be made aware of a violation of 4.9.1.1 (if the information is
> correct). Thus, there is a total of 24 hours from report to revocation in
> the case of misissuance.
> 
> If the CA determines it is not misissuance, then the CA is not obligated to
> revoke. However, if either an auditor or, on subsequent examination (such as
> by a root store), it is determined to be misissuance, then the CA has failed
> to uphold the Baseline Requirements.
> 
> For this reason, the CA MUST take prompt action to review and come to a
> conclusion, to ensure that any violations are revoked within 24 hours of
> report.
> 
> This is consistent with how past incidents and misissuances from other CAs
> have been treated. Further discussion in the CA/Browser Forum is continuing,
> on allowing a bounded time for investigation (not unlimited) and a bounded
> time for revocation (not unlimited). Under the present language, a total of
> 24 hours from report to revocation is required.
> 

We agree with the intent of completing investigations as quickly as possible, however the BRs are silent on the timeframe for investigation. They only specify the timeframe for remediation once a problem has been verified.

> > ** Certificates with metadata-only subject fields (at least one subject
> > field that only contains ASCII punctuation characters)
> > 
> > 1. 2016-08-09, m.d.s.policy
> > 2. We confirm that we stopped issuance of TLS certificates with
> > metadata-only DN attributes on 2017-06-08. Certificate requests presented to
> > our APIs and user interfaces have been subject to two compliance scans. On
> > 2016-04-28, we added a metadata check for mandatory attributes of subject
> > DNs. On 2017-01-13, we extended the check to include all subject DN
> > attributes we permit. On 2017-06-08, we added subject DN attribute checking
> > for single characters, leading/trailing spaces, and we fully duplicated
> > cablint’s compliance checks into our compliance engines.
> > 3. Not applicable, Mozilla does not seek historical remediation for this
> > issue.
> 
> As Symantec has indicated they have already completed remediation, please
> list all certificates that were detected with this issue prior to
> remediation efforts.
> 

Attached, as follows:
File name: MetaSpecialCharacter.csv (3,078 certificates): One or more fields in the Subject DN contains a special character like “-“, “ “ or “.” to indicate that the value is absent, incomplete, or not applicable.
File name: MetaNonApplicable.csv (10,367 certificates): One or more fields in the Subject DN contains “Not Applicable”, “n/a”, or similar to indicate that the value is not applicable.
File name: MetaSingleCharacter.csv (5,105 certificates): One or more fields in the Subject DN contains a single character 
File name: MetaSpaces.csv (1,208 certificates): One or more fields in the Subject DN contains leading or trailing spaces.

> > 4. Not applicable
> 
> While it is laudable that Symantec detected and resolved this issue prior to
> public comment, in order to assess the completeness and thoroughness of
> Symantec's response, please provide the relevant information. This is
> consistent with the request of all CAs that have had issues filed against
> them regarding these incidents, regardless of the completion of their
> remediation efforts (prior to or following notification), to ensure the
> necessary public review and completeness of the remediation in the absence
> of a self-reported problem report.
> 

See above.

> > 6. We consider the automation, training, and KB documentation improvements
> > complete and total.
> 
> While you noted some remediations in Step 2, you did not list anything
> regarding the steps taken with respect to training or KB documentation.
> Please provide details about the steps you took to remedy this issue, in
> total.
> 

Due to the software changes applied, the scope of training and KB documentation was to explain why the automated compliance engine was blocking issuance and how to correct the request so that it would be accepted. Our internal KB was updated. Training on this topic was included in a broader set of topics.

> 
> > ** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards
> > in the wrong position)
> > 
> > 1. 2017-08-12, problem report
> > 2. We confirm that we stopped issuance of TLS certificates with malformed
> > wildcards on 2016-04-28. In the case of the certificate for nic.mutuelle,
> > IANA reports that TLD as active from 2015-10-19 to 2016-12-15. That
> > certificate was issued on 2015-12-16.
> > 3. In addition to the problem certificates reported at
> > https://misissued.com/batch/8/, we identified 13 additional valid
> > certificates with malformed wildcards. In each of the 13 cases, these
> > certificates were issued before we required CT logging for all certificates,
> > part of which includes getting explicit customer permission to log.
> 
> The request was to ensure these certificates are logged and appropriately
> publicly disclosed. Symantec appears to be requesting that they not be
> required to do so, despite all other CAs complying.
> 
> Kathleen, Gerv: As module owner & peer, I feel this would be appropriate for
> you to determine whether or not this constitutes an appropriate response. In
> the spirit of openness and transparency, I believe that the Mozilla
> requirements supercede those of requiring permission, and should be treated
> as not an appropriate response.
> 

From the point that we started logging to CT, we have committed to the requirement. Prior to that point, we are subject to agreements that require us to protect subject data as confidential information. In order to enable any action Mozilla desires to take, we attach the following issuer and serial details for those certificates where we cannot provide CT links:
File name: MalformedWildcard.csv (239 certificates): One or more fields in the CN and/or SAN extension contains a malformed wildcard
File name: InternalHostname.csv (39 certificates): One or more fields in the CN and/or SAN extension contains an internal hostname
File name: DoubleDots.csv (48 certificates): One or more fields in the CN and/or SAN extension contains double-dots
File name: InvalidFQDNOther.csv (890 certificates): One or more fields in the CN and/or SAN extension contains a leading or trailing space, period or hyphen; or invalid characters like colon, forward slash, quotes, ampersand, pound sign, angle bracket.


> > 4. We have revoked the 4 certificates with the original problem report (3
> > with malformed wildcards and one in a TLD that IANA revoked). Of the 13
> > additional certificates that we identified with malformed wildcards, 8 have
> > been revoked and we are working with the customer owning the other 5 to
> > complete their replacement and revoke these certificates.  The problem
> > certificates were issued between 2014-03-23 and 2016-04-07.
> 
> When do you expect revocation to be completed?
> 

Revocations were completed minutes after midnight PDT 2017-08-21 (2017-08-21 0800 UTC) once we received confirmation that replacement certificates were operational in a critical application.

> > 6. For wildcards, we consider our prevention action complete as of April
> > 2016. 
> 
> You have not described what prevention steps you have taken that you
> completed by April 2016.
> 

Same as prior topic, software prevention implemented 2016-04-28 adding metadata checking of mandatory attributes also addressed malformed wildcards in our pre-issuance compliance engine. 

> > ** Common Name not in SAN
> > 
> > 1. 2017-08-06, m.d.s.policy
> > 2. Not applicable, as we explained in the result of our certificate problem
> > report investigation posted by Jonathan Rudenberg to the discussion of this
> > issue at
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/
> > rxEptYe7BwAJ 
> > 3. Not applicable
> > 4. Not applicable
> > 5. Not applicable, we consider the puny-coded SAN and the Unicode CN to be
> > equals that can be proven by common algorithms.
> 
> Please detail the algorithms you believe these can be proven by.

http://www.rfc-editor.org/rfc/rfc3492.txt

> 
> > 6. No actions planned.
> > 7. No actions planned.
> 
> Note that such certificates pose risk to Mozilla users, by bypassing the
> policies and controls Mozilla has implemented with respect to the display of
> IDNs. Please consider this a request to provide a timeline for revoking
> these certificates, or what steps have been taken to prevent further
> issuance of these certificates.
> 

Given an RFC for punycode as a method available to CAs to follow, absence of comment in Mozilla policy 2.5 and absence of guidance at https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices, we adopted the RFC and provide a punycode version of the CN in the SAN as an interoperable value to evaluate against the URL hostname.

> 
> > 
> > 
> > ** Double dot dnsNames
> > 
> > 1. 2017-07-18, m.d.s.policy
> > 4. Fourteen certificates, including 11 already expired at the time that we
> > enhanced our compliance engine to block these problem certificates were
> > issued between 2010-11-18 and 2016-04-06. The three valid certificates were
> > revoked on 2016-08-08, 2016-09-12, and 2016-09-28.
> 
> https://crt.sh/?id=12104207&opt=cablint lists revocation on 2016-08-18. Can
> you explain this discrepancy?

Human error in the documentation provided in this bug response. The revocation date noted on the crt.sh entry is the correct date.

> 
> > 6. Necessary blocking action was taken 2016-04-28 and revocations were
> > performed in September 2016.
> 
> Please describe what steps you took to block such certificates.
> Please explain how the blocking action (taken on 2016-04-28) and the
> revocation action (taken on 2016-09) is consistent with the answer in 1,
> which suggests that you first became aware of the issue on 2017-07-18.

Software blocking was implemented 2016-04-28. Scans for offending certificates resulted in 3 revocations. We became aware of Mozilla’s interest in the matter 2017-07-18. We became aware of problem certificates in June 2016 when we ran database scans to find problem certificates.
Flags: needinfo?(steve_medin)
(Assignee)

Comment 10

a year ago
Created attachment 8920238 [details]
MetaSpecialCharacter.csv
(Assignee)

Comment 11

a year ago
Comment on attachment 8920238 [details]
MetaSpecialCharacter.csv

One or more fields in the Subject DN contains a special character like “-“, “ “ or “.” to indicate that the value is absent, incomplete, or not applicable.
Attachment #8920238 - Attachment description: One or more fields in the Subject DN contains a special character like “-“, “ “ or “.” to indicate that the value is absent, incomplete, or not applicable. → MetaSpecialCharacter.csv
(Assignee)

Comment 12

a year ago
Created attachment 8920239 [details]
MetaNonApplicable.csv

One or more fields in the Subject DN contains “Not Applicable”, “n/a”, or similar to indicate that the value is not applicable
(Assignee)

Comment 13

a year ago
Created attachment 8920240 [details]
MetaSingleCharacter.csv

One or more fields in the Subject DN contains a single character
(Assignee)

Comment 14

a year ago
Created attachment 8920242 [details]
MetaSpaces.csv

One or more fields in the Subject DN contains leading or trailing spaces
(Assignee)

Comment 15

a year ago
Created attachment 8920243 [details]
MalformedWildcard.csv

One or more fields in the CN and/or SAN extension contains a malformed wildcard
(Assignee)

Comment 16

a year ago
Created attachment 8920244 [details]
InternalHostname.csv

One or more fields in the CN and/or SAN extension contains an internal hostname
(Assignee)

Comment 17

a year ago
Created attachment 8920245 [details]
DoubleDots.csv

One or more fields in the CN and/or SAN extension contains double-dots
(Assignee)

Comment 18

a year ago
Created attachment 8920246 [details]
InvalidFQDNOther.csv

One or more fields in the CN and/or SAN extension contains a leading or trailing space, period or hyphen; or invalid characters like colon, forward slash, quotes, ampersand, pound sign, angle bracket
It appears that all action items are completed and questions answered, so I am marking this resolved.
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.