Closed Bug 1390988 Opened 7 years ago Closed 6 years ago

Consorci AOC: Non-BR-Compliant Certificate Issuance

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: fferre)

References

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Attachments

(2 files, 1 obsolete file)

BZ1390988_cert_list_summary.v.1.1.xlsx
11.61 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
BZ1390988_cert_list_summary.v.1.2.xlsx
12.26 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details 
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
Attached file BZ1390988_cert_list_summary.xlsx (obsolete) — 

    
    

    
      
  

    
    

    
  
Dear Kathleen,

Comment #2 was incomplete and innacurate. This is the final version of it. If you can delete the #2 it would be less confusing to users I think. 

These are the answers and steps planned:

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.

We became aware of the problem via this Bugzilla bug although we do are subscribed to the mozilla.dev.security.policy and did receive the email with the missued certificates list. We will put additional controls and subscribers to the list in order to become aware of such problems as soon the problem arises.
 
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
 
Yes, we can confirm that the problem has been solved. Additional automatic checks have been added today to the issuance procedures in order to avoid the issuance of certificate without such identified problems. 
 
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.
 
Attached list of affected certificates including Serial Number and FingerPrint. (BZ1390988_cert_list_summary.xlsx). 
 
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
 
Issues identified:
 
** 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
 
Affected CAs and certificates attached.  A total of 11 certificates were misissued within 3-09-2015 and 23-3-2017.
 
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier
 
Although we do perform yearly random audits of issued SSL certificates as the auditor require, these missued certificates were not identified and fixed earlier. This is probably because the sample of checked certificates was too small. 

We were confident also that the technical controls we had into place were effective and not allowing such issuances.
 
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.
 
The steps that we have put into place for this case are:
- Identifying and reporting the misissued certificates.
- Contact the subscribers and require them to request new certificates for their services before September the 30th. By that date, the certificates will be revoked. 
- Enforce and train our RA operators in using the latest RA controls about DNS names properly.
- Enforce and extend the sample of our yearly controls on issued certificates so we can identify such cases.
 
NOTE: The renovation period has been set according to the risk evaluation we have performed given the security risk that we estimate for this 11 particular cases. The BR audit disconformity consist in hat in all cases certificates with no TLD domain names were issued. In particular ".local" name. Given that these domain names cannot be used internet wide, we let users a month and a half for renewing. 
 
7) Regular updates to confirm when those steps have been completed.
 
We will include and review this evidences and reports in our yearly audit as a proof of compliance.  

Hoping that you'll find them fine, we look forward for your reply to our plan and comments. 

Francesc,

    
    

    
  
(In reply to Francesc Ferrer from comment #2)
> We became aware of the problem via this Bugzilla bug although we do are
> subscribed to the mozilla.dev.security.policy and did receive the email with
> the missued certificates list.

I filed a problem report at the website listed as your problem reporting channel in the CCADB, http://suport.aoc.cat (which does not appear to be available in English) at 2017-08-13 04:42 UTC and was assigned ticket number 180314. Can you please investigate and explain why the problem report didn't make it to the right place?

> Attached list of affected certificates including Serial Number and
> FingerPrint. (List_Certificates.xlsx)

Please add all of these certificates to at least one CT log and post the crt.sh IDs or certificate fingerprints.

    
    

    
  
Comment deletion is not enabled; however, I have tagged comment #2 as "obsolete", which will mean it is collapsed by default.

Gerv

    
    

    
  
Thanks for responding. I think it's still necessary to provide additional detail.

That is, we can look at the problem from two dimensions: The problem itself, and the systemic issues that allowed the problem to manifest. Your description focuses on the resolution of the problem, but doesn't indicate any systemic changes have been made. As a consequence, it does not help the community feel that your CA has taken steps to reduce the risk of future violations (of any requirement) in the future. That is, one dimension is "Did you fix the bug", but another dimension is "How was the bug introduced, why was it not detected, and what steps are you taking to prevent future bugs"

To understand how you might approach this problem, consider https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were already in place (and with substantial detail), where there were controls missing or mistakes made, details about the steps being taken (e.g. "We fixed the bug" is not sufficient detail to understand), and a holistic, systemic awareness of how the CA is managed and the opportunities for errors.


(In reply to Francesc Ferrer from comment #3)
> 2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates
> with the problems listed below.
>  
> Yes, we can confirm that the problem has been solved. Additional automatic
> checks have been added today to the issuance procedures in order to avoid
> the issuance of certificate without such identified problems. 

Could you further describe what automated checks you have introduced? This will help the community provide feedback and evaluate the comprehensiveness of these checks.

> 5) Explanation about how and why the mistakes were made, and not caught and
> fixed earlier
>  
> Although we do perform yearly random audits of issued SSL certificates as
> the auditor require, these missued certificates were not identified and
> fixed earlier. This is probably because the sample of checked certificates
> was too small. 
> 
> We were confident also that the technical controls we had into place were
> effective and not allowing such issuances.

This is an excellent opportunity to highlight that you can implement both pre-issuance and post-issuance technical controls to your issuance pipeline, using tools like https://github.com/awslabs/certlint . Several CAs have done this or are in the process of doing so, as described at https://groups.google.com/d/msg/mozilla.dev.security.policy/oTQ9OYgS8D4/KRFUWERDAgAJ

> 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.
>  
> The steps that we have put into place for this case are:
> - Identifying and reporting the misissued certificates.
> - Contact the subscribers and require them to request new certificates for
> their services before September the 30th. By that date, the certificates
> will be revoked. 
> - Enforce and train our RA operators in using the latest RA controls about
> DNS names properly.

Could you expand upon this. It sounds like you're primarily relying on human measures regarding DNS names, but that is generally insufficient.

- Can you please describe what technical controls you have in place to ensure compliance with RFC 5280 and the Baseline Requirements? In particular, the rules around the validity of the domain names (the LDH rule of RFC 1034, referenced by RFC 5280) and of IDNs (as described in Section 7 of RFC 5280)?
- Can you confirm that you will have implemented next month, as required by the Baseline Requirements, checks for CAA records? (As such controls would have prevented this)

> NOTE: The renovation period has been set according to the risk evaluation we
> have performed given the security risk that we estimate for this 11
> particular cases. The BR audit disconformity consist in hat in all cases
> certificates with no TLD domain names were issued. In particular ".local"
> name. Given that these domain names cannot be used internet wide, we let
> users a month and a half for renewing. 

As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1390974#c3 and https://bugzilla.mozilla.org/show_bug.cgi?id=1390974#c6 , these internal names do present risk to the broad Internet community, and not just specific to these customers.

I would encourage you to promptly replace to reduce this risk.

>  
> 7) Regular updates to confirm when those steps have been completed.
>  
> We will include and review this evidences and reports in our yearly audit as
> a proof of compliance.  
> 
> Hoping that you'll find them fine, we look forward for your reply to our
> plan and comments. 
> 
> Francesc,

Broadly speaking, a better understanding of both the timeline of events and more details about your controls would be appreciated, as described above. Your reply suggests that there were a significant number of human factors that are relied upon, and those human factors failed. This is concerning, because it's expected that human factors will fail. For this situation, and for a number of other requirements of the Baseline Requirements, technical controls exist to prevent issuance (prior to signing) and detect issuance (post-signing), and it does not sound like you've incorporated or considered incorporating such changes.

Further, your mitigation largely seems to rely on annual review. As you can see from replies like PKIoverheid, there are opportunities to increase the transparency of your operation (by proactively disclosing to Certificate Transparency) and implement continuous monitoring of issuance. While understandably, audits still play an important role in ensuring compliance, the implementation of technical controls can help reduce the risk of a failure of human controls, much like your human controls can reduce the failure rate of technical controls. By taking a layered, defense in depth approach, we can have greater confidence in the issuance practices.

    
    

    
  
Hi Francesc,

I wanted to follow-up and see if you've had a chance to review and can answer these questions.

    
    

    
  
Hi Ryan,

We are reviewing all your comments and how to deploy an effective way to improve and automate security in our insurance pipeline.

Thanks!

    
  
Flags: needinfo?(fferre)

    
    

    
  
Do you have any updates?

    
    

    
  
Dear all, 

Sorry for my late reply to https://bugzilla.mozilla.org/show_bug.cgi?id=1390988#c6. Here it goes finally:
 
>> 2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates
>> with the problems listed below.
>> 
>> Yes, we can confirm that the problem has been solved. Additional automatic
>> checks have been added today to the issuance procedures in order to avoid
>> the issuance of certificate without such identified problems.
> 
>Could you further describe what automated checks you have introduced? This will help the community provide feedback and evaluate > the comprehensiveness of these checks.

Let me explain more deeply how our validation works.

Our self developed Registration Auhority parses the domain name with PHP Domain Parser (https://github.com/jeremykendall/php-domain-parser), we use it in order to extract the registrable domain name and to verify if the public suffix is valid.

The registrable domain is then checked against the Alexa top one million sites public list. We are using it as a blacklist. If one of our customers is listed in Alexa's top, we have to add it manually to a whitelist.

We have a final manual check where the domain name is approved by a RA user. The RA user is able to check the domain name listed in the common name against the WHOIS record trough the RA.
 
>> 5) Explanation about how and why the mistakes were made, and not caught and
>> fixed earlier
>> 
>> Although we do perform yearly random audits of issued SSL certificates as
>> the auditor require, these missued certificates were not identified and
>> fixed earlier. This is probably because the sample of checked certificates
>> was too small.
>>
>> We were confident also that the technical controls we had into place were
>> effective and not allowing such issuances.
 
>This is an excellent opportunity to highlight that you can implement both pre-issuance and post-issuance technical controls to your issuance pipeline, using tools like https://github.com/awslabs/certlint. Several CAs have done this or are in the process of doing so, as described at https://groups.google.com/d/msg/mozilla.dev.security.policy/oTQ9OYgS8D4/KRFUWERDAgAJ
 
We think that the automatic check that we have added is ok as a pre-issuance control for the type of errors detected. No other errors have been found. Notwithstanding the foregoing we have allocated resources to analyse the impact and work load to add the tool https://github.com/awslabs/certlint, that you mention, since it is useful for detecting several types of errors in an automatic manner and can be used in pre and post issuance.
 
>> 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.
>> 
>> The steps that we have put into place for this case are:
>> - Identifying and reporting the misissued certificates.
>> - Contact the subscribers and require them to request new certificates for
>> their services before September the 30th. By that date, the certificates
>> will be revoked.
>> - Enforce and train our RA operators in using the latest RA controls about
>> DNS names properly.
> 
>Could you expand upon this. It sounds like you're primarily relying on human measures regarding DNS names, but that is generally insufficient.
 
The incident was caused by a bad usage of the parser class, we were extracting the registrable domain extension part, but omitting the suffix validation. The problem was not noticed at development because the regresion tests only included a short extract from Alexa's top sites.
The manual review failed because the reviewer wasn't trained to identify ".local" as a non valid suffix and couldn't automatically test it against the WHOIS.

We added the suffix validation to the production environment on August 18 at 14:42 and introduced invalid public suffixes in our regression tests.

>- Can you please describe what technical controls you have in place to ensure compliance with RFC 5280 and the Baseline Requirements? In particular, the rules around the validity of the domain names (the LDH rule of RFC 1034, referenced by RFC 5280) and of IDNs (as described in Section 7 of RFC 5280)?
 
From CAOC, we do not allow to issue SSL or any other kind of certificate containing a DNS with IDNs.
 
>- Can you confirm that you will have implemented next month, as required by the Baseline Requirements, checks for CAA records? (As such controls would have prevented this)

We will have it implemented, we are actually testing EJBCA Enterprise 6.9.0.1 in our development environment.

>> NOTE: The renovation period has been set according to the risk evaluation we
>> have performed given the security risk that we estimate for this 11
>> particular cases. The BR audit disconformity consist in hat in all cases
>> certificates with no TLD domain names were issued. In particular ".local"
>> name. Given that these domain names cannot be used internet wide, we let
>> users a month and a half for renewing.
> 
>As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1390974#c3 and https://bugzilla.mozilla.org/show_bug.cgi?id=1390974#c6 , >these internal names do present risk to the broad Internet community, and not just specific to these customers.
> 
>I would encourage you to promptly replace to reduce this risk.
 
We are doing our best efforts to shorten the date to revoke these mississued certificates, taking into account not only the risk but also the business impact in our customers. We will update the ticket in case we can shorten up.
 
>> 
>> 7) Regular updates to confirm when those steps have been completed.
>> 
>> We will include and review this evidences and reports in our yearly audit as
>> a proof of compliance. 
>>
>> Hoping that you'll find them fine, we look forward for your reply to our
>> plan and comments.
>>
>> Francesc,
> 
>Broadly speaking, a better understanding of both the timeline of events and more details about your controls would be appreciated, as described above. Your reply suggests that there were a significant number of human factors that are relied upon, and those human factors failed. This is concerning, because it's expected that human factors will fail. For this situation, and for a number of other requirements of the Baseline Requirements, technical controls exist to prevent issuance (prior to signing) and detect issuance (post-signing), and it does not sound like you've incorporated or considered incorporating such changes.
> 
>Further, your mitigation largely seems to rely on annual review. As you can see from replies like PKIoverheid, there are opportunities to increase the transparency of your operation (by proactively disclosing to Certificate Transparency) and implement continuous monitoring of issuance. While understandably, audits still play an important role in ensuring compliance, the implementation of technical controls can help reduce the risk of a failure of human controls, much like your human controls can reduce the failure rate of technical controls. By taking a layered, defense in depth approach, we can have greater confidence in the issuance practices.
 
Thanks for the advices and the approach. As mentioned before we are doing our best efforts to solve the issue, to put in place the measures so this kind of issues do not repeat in the future and to improve the general security and reliability of the issuance pipeline.
 
For sure we are going to implement CT ASAP and always before April 2018.

I am sorry that we still cannot provide an answer to https://bugzilla.mozilla.org/show_bug.cgi?id=1390988#c4. We'll try our best to provide it next week at latest. 

Thank you very much for you patience. 

Francesc,
Flags: needinfo?(fferre)

    
    

    
  
(In reply to Francesc Ferrer from comment #10)
> Let me explain more deeply how our validation works.
> 
> Our self developed Registration Auhority parses the domain name with PHP
> Domain Parser (https://github.com/jeremykendall/php-domain-parser), we use
> it in order to extract the registrable domain name and to verify if the
> public suffix is valid.
> 
> The registrable domain is then checked against the Alexa top one million
> sites public list. We are using it as a blacklist. If one of our customers
> is listed in Alexa's top, we have to add it manually to a whitelist.
> 
> We have a final manual check where the domain name is approved by a RA user.
> The RA user is able to check the domain name listed in the common name
> against the WHOIS record trough the RA.

Thanks for this excellent level of detail. I want to highlight that, as far as I can tell, the PHP Domain Parser does not perform any handling for RFC1034 (and related) regarding the well-formedness of domains.

A suggested modification to your flow might be as follows:
- Canonicalize the domain name as provided
  - If any non-ASCII character as present, then ensure that any U-Labels  are converted to their A-Label equivalent. RFC 5280 references RFC 3490, specifically https://tools.ietf.org/html/rfc5280#section-7.3
  - Ensure that the resulting string conforms to the rules specified in https://tools.ietf.org/html/rfc5280#section-4.2.1.6 (namely, that it's in the preferred name syntax)
    - If the ABNF is properly implemented, this will ensure every domain is well formed - but will also permit the " " domain (used to indicate the root label). As you cannot validate " ", you can reject that as well.
- Determine the registerable domain
  - Use this to highlight domains that may require additional review, per 3.2.2.6 of the BRs (if a wildcard)
  - You can also use this to determine the base/authorization domain name, per 1.6.1 of the BRs
  - You will need a process to ensure you are keeping this list up to date, as new domains are added, and reviewing the implications for any existing certificates that may be affected by changes
- Perform your WHOIS check on the Base/Authorization Domain Name

That is, your process as described would still fail to ensure the IDNA well-formedness or that the A-Labels are well formed. The above is one suggestion on how to do so, based on you mentioning the tool you use (which does not do this automatically)

> The incident was caused by a bad usage of the parser class, we were
> extracting the registrable domain extension part, but omitting the suffix
> validation. The problem was not noticed at development because the regresion
> tests only included a short extract from Alexa's top sites.
> The manual review failed because the reviewer wasn't trained to identify
> ".local" as a non valid suffix and couldn't automatically test it against
> the WHOIS.
> 
> We added the suffix validation to the production environment on August 18 at
> 14:42 and introduced invalid public suffixes in our regression tests.

As you can see from the above, it also highlights that further checks may not be happening, and provides a path to addressing those.



Based on the information provided, can you confirm this is accurate:

1) Invalid dNSNames (Internal server names)
  - See Comment #0, Comment #3, Comment #10
  - Root Cause
    - Implemented the PSL algorithm but allowed the 'wildcard' rule to apply, thus failing to filter out any internal server names
  - Remediation
    - 2017-08-18 - Patch deployed to properly consider disable the implicit '*' rule, thus attempting to determine that all names are registerable (See Comment #10)
    - 2017-09-30 - Revoke all existing certificates
    - TBD - Preissuance certificate linting

Is this correct?

With respect to the revocation timeline, given the risks that local domain names present, the Mozilla Module Peers feel that it is best to revoke within 24 hours, and no further extensions to be allowed. While understandably this may be challenging, the fact that the Baseline Requirements, since their introduction, have placed explicit time limits on when these certificates can be issued, and when they must be revoked, means that there is no ambiguity that this was not permitted. As outlined in https://cabforum.org/internal-names/ , such names do present risk, even when constrained to '.local'. To ensure consistency in application of the appropriate policies, and to avoid the subjectivity of trying to determine when a name such as 'ccbc.local' is more or less risky than a name of 'owaserver' - all such certificates should be revoked promptly.

Please notify this bug when you've done so.
Flags: needinfo?(fferre)

    
    

    
  
Dear all,

As I said last week, here it goes the answer for https://bugzilla.mozilla.org/show_bug.cgi?id=1390988#c4

First of all, apologies for not being aware of the case/ticket you did report when I first replied in Augusth the 16th. You did open the case properly according to the official procedures stated on the CCADB that are extracted from our practices statements and policies. I did look for it in our support system before answering but I couldn’t find it due to the lack of a proper categorization of the ticket and, above all, an unproper treatment as a potential certificate problems report case that would have required a response in 24h. You were given a first response within 26 hours but it was not a final one. Instead of it, it was a response requesting you more information about the case. 

As it appears as a brief description of our mission in the CaInformation Report page of CCADB, we are a the Government CA of the region of Catalunya in Spain and we provide SSL certificates to Catalan government entities. In addition to Certification Services, Consorci AOC provides other several e-government services. This requires our support to organize into several layers and teams which first categorize every request and then escalate it. In this particular case, it took too long to give an appropriate response due to the lack of specialization and number layers of our team. 

In order to solve this, we are going to implement (before the end of this month) a new and dedicated support form for reporting SSL certificate potential problems. This form if going to generate a support request that will be escalated directly to the right team (which operates 24x7) and it will be available in several languages including English. After implementing it, we will update our practices with this new procedure. We are confident about the fact that this new procedure will become really effective in new cases eventually. 

Here you can find the prototype (not final): https://www.aoc.cat/knowledge-base/com-puc-informar-del-mal-us-dun-certificat/idservei/idcat/

As for the CT logs publication comment, we will try to publish all our SSL certificates right after finishing this task of revocation of misissued certificates.

As for https://bugzilla.mozilla.org/show_bug.cgi?id=1390988#c11, we will provide proper response and further details next week about the technical details and questions Mr. Sleevi asked. As for the promptly revocation, we are working hard with our certificate subscribers for having all them revoked next week, which is earlier than stated at first. 

Thank you very much, 

Francesc,

    
    

    
  
Dear All, 
 
As an update of the revocation of the misissued and unexpired certificates, at this moment only one is still not revoked. We are doing our best effort and working with the subscriber of it to have it revoked by next week at most. 
 
As for https://bugzilla.mozilla.org/show_bug.cgi?id=1390988#c11, the domain name validation process you suggest we will be explitly forbidding non-ASCII characters and " " in production on 20/09/2017. We are not issuing wildcard certificates, we have them blocked already in the code. Can you elaborate further the 1.6.1 point? What are you referring to with "to determine"...? Php Domain Parser? In the next point what list? The Public suffix or the Alexa top one?

Thank you very much, 

Francesc,

    
    

    
  
Dear All,

I am happy to anounce that the last misissued certificate has been revoked. 

Thank you very much, 

Francesc,
Flags: needinfo?(fferre)

    
    

    
  
(In reply to Francesc Ferrer from comment #13)
> As for https://bugzilla.mozilla.org/show_bug.cgi?id=1390988#c11, the domain
> name validation process you suggest we will be explitly forbidding non-ASCII
> characters and " " in production on 20/09/2017. We are not issuing wildcard
> certificates, we have them blocked already in the code. Can you elaborate
> further the 1.6.1 point? What are you referring to with "to determine"...?
> Php Domain Parser? In the next point what list? The Public suffix or the
> Alexa top one?

I was attempting to highlight that one can extract the Base/Authorization domain name (per the BRs, this may be different than the 'registerable' domain name extracted by the public suffix list) and then perform the WHOIS check. The benefit of this approach is a stronger technical validation of the well-formedness of the domain. It was merely a suggestion.

The important part, however, is that even forbidding non-ASCII characters and " " in production, it's still possible to end up with invalid domains. For example, "foo_bar.example.com" is an invalid domain (does not conform to the rules of RFC1034's preferred name syntax). Thus, there are still additional checks that would be necessary - which is why I was trying to highlight a programmatic procedure (canonicalize/normalize, validate) to help reduce that risk.

Thus, there is still risk in the proposed remediation.

    
    

    
  
Francesc: I realise things are somewhat busy in Catalonia right now, but it would be useful to know if you have taken on board Ryan's warnings about the problems with your proposed remediation. Have you updated your plans to take into account his concerns?

Gerv
Flags: needinfo?(fferre)

    
    

    
  
(In reply to Gervase Markham [:gerv] from comment #16)
> Francesc: I realise things are somewhat busy in Catalonia right now, but it
> would be useful to know if you have taken on board Ryan's warnings about the
> problems with your proposed remediation. Have you updated your plans to take
> into account his concerns?
> 
> Gerv


We can confirm that we have already implementend the preferred name syntax validation and then rejected the " " domain. 
We are forbbiding any wildcard + public suffix combination, we have a cron job that downloads every day the list from https://publicsuffix.org/list/public_suffix_list.dat
We have another cron job that tests the list against the already issued certificates and notifies an administrator.
The WHOIS check is now done after the above validations and manually accepted by an operator
Flags: needinfo?(fferre)

    
    

    
  
Alex Gaynor filed a report of another certificate issued in July 2016 by Consorci that contains an invalid SAN entry: https://crt.sh/?id=284511547&opt=cablint

Francesc Ferrer responded:
We will perform further investigations in order to see if there are more cases we missed at that moment. We will also check if the conditions that allowed our system to issue this certificate are consistent with the problem and corrective actions already reported in the existing bug. If not, we will file a new bug.

    
    

    
  


  
New version of cert list summary of affected non-BR compliant Certs.

        Attachment #8898764 -
        Attachment is obsolete: true

    
    

    
  
Dear all, 

After reviewing the entire SSL database, another mis-issued certificate with CN "http://www.concactiva.cat" was issued. The revocation of it was been handled already. I've attached a new version of the certificate list to the ticket with the two new certificates detected in total. 

Both two new misissued certificates identified were issued before the controls stated in this ticket were put into place. Therefore, they are related to these weeknesses in the registration process we had. We do not foresee the need of further investigations related to this case. 

Thank you very much, 

Francesc,

    
    

    
  
(In reply to Francesc Ferrer from comment #17)
> We can confirm that we have already implementend the preferred name syntax
> validation and then rejected the " " domain. 
> We are forbbiding any wildcard + public suffix combination, we have a cron
> job that downloads every day the list from
> https://publicsuffix.org/list/public_suffix_list.dat
> We have another cron job that tests the list against the already issued
> certificates and notifies an administrator.

It seems like you are doing some or all of your validation checks post-issuance. If you do that, any failures will still be considered misissuance, as the issuance happened. You are advised to do validations pre-issuance.

You have recently disclosed two more certificates with bad DNS names. Given that both of these are flagged by certlint, how did you not detect them before? Months ago in this bug, you said you were integrating certlint into your validation process. Did you not run certlint over all existing issued certificates? If you did, how were these two missed? How do we know there are not more?

Gerv

    
    

    
  
(In reply to Gervase Markham [:gerv] from comment #21)
> (In reply to Francesc Ferrer from comment #17)
> > We can confirm that we have already implementend the preferred name syntax
> > validation and then rejected the " " domain. 
> > We are forbbiding any wildcard + public suffix combination, we have a cron
> > job that downloads every day the list from
> > https://publicsuffix.org/list/public_suffix_list.dat
> > We have another cron job that tests the list against the already issued
> > certificates and notifies an administrator.
> 
> It seems like you are doing some or all of your validation checks
> post-issuance. If you do that, any failures will still be considered
> misissuance, as the issuance happened. You are advised to do validations
> pre-issuance.
> 
> You have recently disclosed two more certificates with bad DNS names. Given
> that both of these are flagged by certlint, how did you not detect them
> before? Months ago in this bug, you said you were integrating certlint into
> your validation process. Did you not run certlint over all existing issued
> certificates? If you did, how were these two missed? How do we know there
> are not more?
> 
> Gerv

Dear Gerv, 

First of all, sorry for my poor explanation that didn't make it clear for you. I'll try to explain it better now. 

Pre-issuance validations (including certlint) are in place since this bug was reported to us last August. The thing is that these two new disclosed certificates were issued much before August 2017. They were issued in mid 2016 as you can see in the attached list that I updated yesterday (https://bugzilla.mozilla.org/attachment.cgi?id=8941380). This is, much earlier than the pre-issuance validations were in place. Therefore, from our point of view, the new pre-issuance controls are not in doubt given this new disclosure. 

What I think that at this point is generating doubts, is our poor database check performed last August. Given that it didn't disclose these two certificates that have been disclosed now. As far as I've been able to investigate, it all suggests that the problem was that we checked the database for ill-formed DNS names related to local names. We didn't check for other type of ill-formed CN fields like these ones we've found nou (CNs starting with "http"). Hence, from our point of view and given this explanation, the wrong initial list of ill-formed certs has generated bad image and doubts on our issuance pipelane that are not related nor put into compromise the new controls. 

Hoping this explanation will be convincing enough in order to make you agree that this was a problem of initial detection of ill-formed certificates and not a bad implementation of the new pre-issuance controls. 

Thank you,

    
    

    
  
(In reply to Francesc Ferrer from comment #22)
> Hoping this explanation will be convincing enough in order to make you agree
> that this was a problem of initial detection of ill-formed certificates and
> not a bad implementation of the new pre-issuance controls. 

Yes, I always believed that. Apologies if that was not clear. What I want to know is: what procedure was used for the initial detection of ill-formed certificates last August? Was certlint used? If not, why not, and do you have plans to certlint your entire cert database soon? If so, why were these certs not detected?

Gerv

    
    

    
  
Dear Gerv, 

After reviewing in deep last August initial detection (on which certlint was used indeed), only ill-formed certificates related to internal dns names where looked up. Not certificates with IPs nor invalid characters. Therefore, after scaning again the entire database, final results of the scan are now provided, explained and additional measures put in place.  

As stated, a new scan has been run and 6 more certificates with invalid characters in CN have been detected an revoked. Appart from these cases, only other two known (and "acknowledged") problems have been re-detected in a rather big amount of certs in this study. The two problems are listed here https://bugzilla.mozilla.org/show_bug.cgi?id=1321044#c2. The first one is related to a bad encoding in the field jurisdictionOfIncorporation solved in 1/2017 and the other one related to the inclusion of extra fields in SAN of a certificate profile defined in the spanish regulation (sede electronica - https://administracionelectronica.gob.es/pae_Home/dam/jcr:474ae40a-fe06-45fa-aa8f-113049e9c889/2016_Perfiles_de_certificados_1-ed.pdf). For a more detailed explanation, please consult the mentioned bug.

Additional corrective measures will be put into place in the next weeks. These are counter-measures to the fact that another ill-formed certificate was recently issued and detected last January (https://crt.sh/?id=305752164&opt=cablint,ocsp) even though August 2017 controls listed above in this bug were already into place. These are the proposed counter-measures:

- To centralize SSL certificate issuance into only two RAs. These two RAs are the ones with the most well trained and controlled operators.  
- To implement EJBCA 6.11 automatic pre-issuance controls released this january. In order to make the application itself more robust.  
- To put into place a new audit procedure in order to be able to instruct the operators to collect extra data during the validation process in order to ease the audit process during self-assessments. 
- After having these new controls into place and the new procedure, train the rest of RA operators and evaluate to re-open all the RAs or only a few more in order to allow them to issue SSL certs again. 

Looking forward to your comments back, 

Thank you,

    
    

    
  
Francesc: you said "Pre-issuance validations (including certlint) are in place since this bug was reported to us last August", but https://crt.sh/?id=305752164&opt=cablint,ocsp was issued just a month ago. How is this possible?
Flags: needinfo?(fferre)

    
  
QA Contact: gerv → wthayer

    
    

    
  
Statements on Comment 22 related to the number of mississued certificates detected and pre-issuance controls were wrong and replaced by the Statements in Comment 25. Pre-issuance controls based on EJBCA certlint control got finally into place last 14th March. Since Comment 25 though, weekly post-issuance manual controls were in place by reviewing the certificates published in crt.sh (https://crt.sh/?Identity=%25&iCAID=8050).
Flags: needinfo?(fferre)

    
    

    
  
The last misissuance reported by crt.sh is on 12-March: https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2018-03-12

This seems to align with the timing for the implementation of pre-issuance controls. It also shows that Consorci continued to misissue certificates since comment #25 was made on 8-February. None of these recently misissued certificates appear to be revoked.

Francesc: how do you plan to remediate all of the additional certificates that have been misissued since this bug was created, including these: https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 ?
Flags: needinfo?(fferre)

    
    

    
  
> The last misissuance reported by crt.sh is on 12-March: https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2018-
> 03-12

> This seems to align with the timing for the implementation of pre-issuance controls. It also shows that Consorci continued to 
> misissue certificates since comment #25 was made on 8-February. None of these recently misissued certificates appear to be 
> revoked.

All the certificates in https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2018-03-12 are Public Administration SSL certificates, affected by what discuss on bug 1321044 comment 2, that is, they were following a profile in force by Spanish regulation. After the authorization of the Spanish Supervisory Body to deploy the new eIDAS compliant profiles, last March, we have scheduled and publicly announced (see https://www.aoc.cat/2018/04/17/sortida-en-produccio-nous-certificats/ -in Catalan- ) that the deployment will be carried out next May the 9th. 

Best regards,

    
    

    
  
(In reply to Francesc Ferrer from comment #29)
> All the certificates in
> https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2018-03-12
> are Public Administration SSL certificates, affected by what discuss on bug
> 1321044 comment 2, that is, they were following a profile in force by
> Spanish regulation. After the authorization of the Spanish Supervisory Body
> to deploy the new eIDAS compliant profiles, last March, we have scheduled
> and publicly announced (see
> https://www.aoc.cat/2018/04/17/sortida-en-produccio-nous-certificats/ -in
> Catalan- ) that the deployment will be carried out next May the 9th. 

Why has it taken Consorci so long to resolve this problem? It appears that Izenpe, for instance, last issued a certificate with a directoryName in the SAN in 2016 (https://crt.sh/?id=24147673&opt=cablint). When was the regulation changed - the comment from Consorci in bug 1321044 implies that it was sometime in 2016?

    
    

    
  
Yes, you are right, we had a small time-frame to adapt to the new regulation, but once we have asked the Supervisory Body (Spanish Ministry of Energy, Tourism and Digital Agenda) to issue the new profiles pursuing eIDAS we had to wait until its authorization.
As far as we know, not all Spanish CA were fast enough to adapt before eIDAS was in force and the SB had to authorize them.
We would also like to point out that, being a non-compliance, it is related with the format of the certificate, not representing, from our point of view a major risk issue.

Notwithstanding the above we will enter into production next 9th of May with profiles full eIDAS and CA/B Forum compliant.

    
    

    
  
(In reply to Francesc Ferrer from comment #31)
> Yes, you are right, we had a small time-frame to adapt to the new
> regulation, but once we have asked the Supervisory Body (Spanish Ministry of
> Energy, Tourism and Digital Agenda) to issue the new profiles pursuing eIDAS
> we had to wait until its authorization.

Can you specify where in eIDAS or Spanish law you are obligated to wait for Supervisory Body approval before making changes to your certificate profile to conform with industry requirements? Article 24 only requires informing the Supervisory Body of changes at a qualified TSP.

A more detailed explanation about why it is claimed there was only a small timeframe to adapt, or where the relevant legislation is that is being interpreted to require this delay.

Further, it sounds as if Consorci AOC is attempting to suggest that they are bound by some other form of obligation. In which case, it appears that exercising 9.16.3 of the BRs would be appropriate, and the failure to do so thus means that such an explanation is not an acceptable explanation.

    
    

    
  
Find below the way a Supervisory body works:

1) Definition (20) ‘qualified trust service provider’ means a trust service provider who provides one or more qualified trust services and is granted the qualified status by the supervisory body;
2) Article 17.4.(g) to grant qualified status to trust service providers and to the services they provide and to withdraw this status in accordance with Articles 20 and 21;
3) The whole Article 21.

Spanish supervisory body authorization took place in 15th March 2018. 

Additionally, we did not update the profile of the SSL certificate for Spanish Public Administration in that moment (end of 2016, beginning of 2017) although 9.16.3 would have allowed us to do so because we decided to do it by aligning it with eIDAS, having into account that we could put into service the changes as of July 2th, 2017. Yes, we also thought that delivering a positive CAR (Conformity Assessment Report) in time to the Supervisory Body (SB) would be enough, but it wasn't. You can check the Spanish TSL updates during the last 10 months and you will see that authorization has taken a while for many Spanish Qualified TSPs.

IZENPE adapted the service before notifying itself as a Qualified TSP to the Spanish Supervisory Body, and therefore they did not need an authorization. Spanish Law on Digital Signature before eIDAS had an informative approach. After eIDAS it is an authoritative approach (see aforementioned eIDAS sections). 

Nevertheless, if you still think that it is necessary to revoke all previous certificates issued according to the Spanish law, we are open to endeavour a progressive revocation and reissuances of such certificates, from 9th of May on.
Finally, apologies since we thought that this issue was already talked, clarified and closed, considering that ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1321044#c2 was already closed.

Looking forward to any additional clarification we can provide to this topic.
Flags: needinfo?(fferre)

    
    

    
  
(In reply to Francesc Ferrer from comment #33)
> Find below the way a Supervisory body works:
> 
> 1) Definition (20) ‘qualified trust service provider’ means a trust service
> provider who provides one or more qualified trust services and is granted
> the qualified status by the supervisory body;
> 2) Article 17.4.(g) to grant qualified status to trust service providers and
> to the services they provide and to withdraw this status in accordance with
> Articles 20 and 21;
> 3) The whole Article 21.

None of this supports your statement that you were unable to alter your profiles prior to receiving qualified status, or that you required Supervisory Body approval to do so.

That is, what is specifically under question is why, once it was identified that misissued certificates were no longer seen as required under Spanish law, the process did not immediately cease, and switch to a BR-conforming profile. As of yet, there's no evidence that you were obligated to continue such issuance. That is, as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1321044#c2 , the law had been repealed for some time, so no new such certificates should have been issued that were non-compliant.

> Additionally, we did not update the profile of the SSL certificate for
> Spanish Public Administration in that moment (end of 2016, beginning of
> 2017) although 9.16.3 would have allowed us to do so because we decided to
> do it by aligning it with eIDAS, having into account that we could put into
> service the changes as of July 2th, 2017. Yes, we also thought that
> delivering a positive CAR (Conformity Assessment Report) in time to the
> Supervisory Body (SB) would be enough, but it wasn't. You can check the
> Spanish TSL updates during the last 10 months and you will see that
> authorization has taken a while for many Spanish Qualified TSPs.

I can understand that may have prevented delays in being qualified under eIDAS or the Spanish Qualified TSP list. What I do not understand is why that process did not *stop* in 2016, as it did for other CAs.

> IZENPE adapted the service before notifying itself as a Qualified TSP to the
> Spanish Supervisory Body, and therefore they did not need an authorization.
> Spanish Law on Digital Signature before eIDAS had an informative approach.
> After eIDAS it is an authoritative approach (see aforementioned eIDAS
> sections). 

You have not provided any reference to any section in eIDAS that requires that, prior to implementing any such changes, the Supervisory Body must approve such changes. While you have referenced sections on the receipt, review, and approval of audits under the relevant scheme, this does not imply a pre-change approval.

> Nevertheless, if you still think that it is necessary to revoke all previous
> certificates issued according to the Spanish law, we are open to endeavour a
> progressive revocation and reissuances of such certificates, from 9th of May
> on.

There has been no reference to any section indicating such conformance was still in effect. As per previous messages, it was identified that such conformance was repealed in 2016. Because of this, these certificates were not "issued according to the Spanish law" - they were misissued.

    
    

    
  
Dear Mr. Sleevi, 

I am trying to provide some references related to the legal context of our Service in Spain for the last years and speciffically before EIDAS. 

Spanish Government regulated into this document the certificate profile of public employees certificates, eSeals (sello electrónico) and particularly the "government site ssl cert" (CERTIFICADO DE SEDE ELECTRÓNICA ADMINISTRATIVA - pag. 27) around 2012 as it can be seen in this document:

https://administracionelectronica.gob.es/ctt/resources/Soluciones/239/Descargas/Anexo-II--Perfiles-de-certificados-.pdf?idIniciativa=239&idElemento=432

The current document ruling the certificate profiles for the Spanish Public Sector is the following:

https://administracionelectronica.gob.es/ctt/resources/Soluciones/239/Descargas/Perfiles-de-certificados-electronicos-2-0.pdf?idIniciativa=239&idElemento=7073

You can see at page 42 that the "Sede Electrónica" certificate MUST include the following extentions, claiming that it is a "qualified certificate" pursuing eIDAS:
* QcCompliance
* QcEuRetentionPeriod
* QcType- web
* QcPDS

Page 43, again, claiming that it is a "qualified certificate" pursuing eIDAS:

- itu-t(0) identified-organization(4) etsi(0) qualified-certificate-policies(194112) policy-identifiers(1) qcp-web (4)
So, once we claimed to the Ministry to be eIDAS compliant we had to wait until they granted us this claim:
- Article 21.3. Qualified trust service providers may begin to provide the qualified trust service after the qualified status has been indicated in the trusted lists referred to in Article 22(1).

We are afraid that we do not interpret the Roman law-based eIDAS REGULATION in the same way, but we can tell that, after the 1st of July of 2017 we were not able to change or add a new profile that was not qualified before eIDAS and that it is qualified after eIDAS. We aim you to ask for a second opinion on this.

It was also already in place a process of inclusion (Classificacion) to the "national certificate validation" system (called @firma) which was integrated and used in online government processes:

https://administracionelectronica.gob.es/ctt/resources/Soluciones/190/Descargas/Tratamiento%20de%20certificados%20en%20-firma-v-3-8.pdf?idIniciativa=190&idElemento=6868

Non conformance issuance of certificates with the defined profile would result in not being classified and be given no interoperability of the certificates with the national central validation platform. A list of compliance Certification Services Providers and their issuing profiles it's been mantained since then :

https://administracionelectronica.gob.es/ctt/resources/Soluciones/190/Descargas/aFirma-Anexo-PSC.pdf?idIniciativa=190&idElemento=2550

The versions of the last two documents are recent because they have been iterated. Although you can still find the classification of the SEDE Electronica issued by us in "8.3 Certificados publicados en la web de MITYC como de Sede Electrónica (tipo 3 en @firma)". 

This information is provided as a proof of that profile requirements compliance for interoperability were in place in 2012 and until 1st July 2017. We had to do several adjustments to get to this process in particular for those certificates of public employees which, by the way, makes more sense to validate into such systems when integrated into business process instead of SSL certs. 

There is no "Sede Electronica" for IZENPE in this document!. We must say that we ignore if it ever was there and it was ever classified as sede electronica tipo 3. We don't know either if they took the business decision of abanon this type of certs in order to be cabforum compliant. 

We agree that we could have foressen the risk of delays in the process of inclusion into EIDAS and speak to the Ministerio and ponder our decision between being excluded from their classification instead of issue non conforming certs.  Maybe other CA in spain simply stopped issuing them before eidas?. put at risk inclusion into mozilla or law for this small percentatge of our SSL certiificates (less than 4%? of the total?). 

We must insist that that decision was taken by assuming that the conformity would have been reached relatively soon after what was by mid term of 2017. As stated before, we had the comments of https://bugzilla.mozilla.org/show_bug.cgi?id=1321044#c2" into serious consideration for going through this steps for the risk of being excluded from your program. Given that we are a CA limited only to Governemnt entities, it was very important for us not to be in conflict with national schemes.

We will search or try to provide more detail into this discussion why we were not allowed to make changes into certificate profiles after 1st July under EIDAS and without the approval of the Supervisory body in order to put more light into the 10 months delay after 1st July.  

Even taking into account that we still think that we are acting according the Spanish and European law, we can propose to stop the issuance of these certificates until the 9th of May, when we will be able to issue them according to both, Spanish, European and CA/B Forum requirements.

Nevertheless, if you still think that it is necessary to revoke all previous certificates issued according to the Spanish law, we are open to endeavour a progressive revocation and reissuances of such certificates, from 9th of May on.

    
    

    
  
(In reply to Francesc Ferrer from comment #35)

> We must insist that that decision was taken by assuming that the conformity
> would have been reached relatively soon after what was by mid term of 2017.

I interpret this to mean that you could have revised your certificate profiles to become BR compliant any time after the Spanish law was repealed in 2016 and before July 1, 2017, is that correct?
> 
> Nevertheless, if you still think that it is necessary to revoke all previous
> certificates issued according to the Spanish law, we are open to endeavour a
> progressive revocation and reissuances of such certificates, from 9th of May
> on.

I think that would be advisable.

    
    

    
  
Francesc: please provide an update on this issue. Did the profile change go into production on May 9th? Are you revoking all of the misissued certificates?
Flags: needinfo?(fferre)

    
    

    
  
Dear Mr. Thayer,

Migration to the new BR conforming certificate profiles including those of Sede Electrónica was successfully complete as planned by May 9th. Please find real examples below:

https://crt.sh/?id=490598321&opt=cablint,zlint,x509lint
https://crt.sh/?id=490759845&opt=cablint,x509lint,zlint

Revocations of all previsously issued "sedes electrónicas" have already started and are planned be all revoked and re-issued by the end of June. 

Our plan is to provide more feedback by that time and confirm that every misissued certificate has been revoked and renewed. I would like to ask you if there is a way to invoke crt.sh on a single URL call in order to check that they are all revoked. Is there a way to ask crt.sh to inspect only non-revoked certs?. For example, by informing a parameter in the URL (https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2018-01-01) indicating to show only valid non-revoked certificates?. Or this is not possible and it is only possible to check this by entering every into the details of every certificate and check if it is really revoked?. 

Thank you,

    
    

    
  
(In reply to Francesc Ferrer from comment #38)
> 
> Our plan is to provide more feedback by that time and confirm that every
> misissued certificate has been revoked and renewed. I would like to ask you
> if there is a way to invoke crt.sh on a single URL call in order to check
> that they are all revoked. Is there a way to ask crt.sh to inspect only
> non-revoked certs?. For example, by informing a parameter in the URL
> (https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2018-01-
> 01) indicating to show only valid non-revoked certificates?. Or this is not
> possible and it is only possible to check this by entering every into the
> details of every certificate and check if it is really revoked?. 
> 
I am not aware of any way to exclude revoked certificates via that particular crt.sh page. You can log in to the crt.sh database and write SQL queries that do what you want if you have the time to learn the schema. Here is the login information: https://crt.sh/forum?place=msg%2Fcrtsh%2FsUmV0mBz8bQ%2FK-6Vymd_AAAJ
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-July 2018

    
    

    
  
(In reply to Wayne Thayer [:wayne] from comment #28)
....
> Francesc: how do you plan to remediate all of the additional certificates
> that have been misissued since this bug was created, including these:
> https://crt.sh/?CAID=8050&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
> ?

All these certificates issued according to the non BR-conforming profile of "sede electronica" have been revoked and replaced by new and BR-conforming certificates.
Flags: needinfo?(fferre)

    
    

    
  
Remediation completed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] - Next Update - 01-July 2018 → [ca-compliance] [ov-misissuance]

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: