Closed Bug 1676352 Opened 4 years ago Closed 3 years ago

Microsec: Certificate validity period greater than 398 days

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: michel, Assigned: szoke.sandor)

Details

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

Hello,
I found those 2 certificates issued by e-Szigno SSL CA 2014 after 2020-09-01 with a validity of 2 years. Both have been revoked, but I couldn't find any report about them.
https://crt.sh/?id=3609999362
https://crt.sh/?id=3606063415

It appears that this incident was already reported on MDSP (https://groups.google.com/g/mozilla.dev.security.policy/c/FJA4ViMkbvs).

INCIDENT REPORT - Misissuance of 2 CISCO VPN server authentication certificates

I -- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

The Microsec Customer Service Department recovered the misissued certificates during the final internal quality check before delivery.

II -- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

bvpn.mokk.hu

serial : 03549d12dae60ababce088d2210a
hash : ce52002bb9bad4f15f0be21df4de7292c16aa985
issuance : 2020-11-05 10:20:06 UTC
revocation: 2020-11-06 08:17:23 UTC

avpn.mokk.hu

serial : 0354e7785c9a9de1adbc4947c60a
hash : e64f1d0608e6518933a86a7205e1354511903449
issuance : 2020-11-06 07:41:05 UTC
revocation: 2020-11-06 08:16:35 UTC

III -- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

The affected CISCO VPN Server Authentication certificate profile was suspended, the certificate issuance with other certificate profiles has not been stopped.

IV -- A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Two certificates were issued for CISCO VPN servers with longer than 398 days validity
The first certificate was issued on 2020-11-05
The last certificate was issued on 2020-11-06
Booth certificates were revoked on 2020-11-06
The whole problem was solved within 24 hours

V -- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

bvpn.mokk.hu https://crt.sh/?id=3606063415
avpn.mokk.hu https://crt.sh/?id=3609999362

VI -- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

This was the first issuance of CISCO VPN Server Authentication certificates since 2020-09-01.

Microsec has a version management system for the certificate profiles, which is maintained through SVN.
The immediate investigation could find an error in this system, one component of the affected CISCO VPN Server Authentication certificate profile was not covered by the version control, and this way this component left unchanged at 2020-09-01.

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

Immediate actions

Microsec revoked the affected two certificates
The affected certificate profile was suspended
An investigation was made to recover the reason of the misissuance
Microsec identified the root of the problem:

  • one component of the affected certificate profile was not covered by the configuration management system
  • due to this fault this certificate profile left unchanged at 2020-09-01
    Microsec corrected the affected certificate profile component
    Microsec added the missing certificate profile component to the version control system
    The issuance of CISCO VPN Server certificates was enabled again

Further actions

Microsec will review all the certificate profiles for similar problems
Microsec will check the whole certificate profile management system

Planned deadline is 2020-11-20

Assignee: bwilson → szoke.sandor
Status: NEW → ASSIGNED
Whiteboard: [ca-compliance]
Summary: e-Szigno: Validity validity period greater than 398 days → Microsec e-Szigno: Validity validity period greater than 398 days

STATUS REPORT --- Misissuance of 2 CISCO VPN server authentication certificates

REVISION OF ALL CERTIFICATE PROFILES FOR SIMILAR PROBLEMS

  • We have collected all the certificate profiles (active and inactive, private and public) into a common structure.
  • We have verified that both configuration parts exist for each certificate profile.
  • We have verified that each file is included in our SVN-based configuration management system.
  • We have verified the critical settings for each certificate profile.
  • There was no other active policy with a false validity setting.
  • Some minor issue has been fixed in some inactive certificate profiles.

RENEWAL OF THE WHOLE CERTIFICATE PROFILE MANAGEMENT SYSTEM

  • We have moved all private and public certificate profiles to a new common structure so that all certificate profiles are handled the same way in the future, following the same management rules.
    We currently have a total of 273 certificate profiles.
  • We have created a new storage location in SVN for the new certificate profile management system.
    At the same time, we preserve the former places to preserve history.
  • We have retired 58 certificate profiles that we do not plan to use for new certificate issuance in the future.
  • Today we completed the final review of the certificate profiles and the new version control system.
  • Due to our general policies, we do not make any planned significant changes to our systems and services on Friday afternoon, so the activation is scheduled for next week.
  • The following actions will be taken early next week:
    -- The new version of the certificate policy document will take effect.
    -- We will change the certificate policy management to the new system.
    -- We will activate the new certificate profiles.

THE PLANNED DEADLINE IS: 2020-11-23

The exact same problem (with the exact same domain!) already occurred two years ago (https://bugzilla.mozilla.org/show_bug.cgi?id=1512270). As you did not even mention this previous incident in your analysis, there can be no confidence at all that it will be any different next time.

Yes, you are right, we had a similar problem two years ago. Similar, but not the same.

Last time we learned that not only SSL certificates must follow BR rules, but all certificates that can be used on the Internet to authenticate servers, such as CISCO VPN server certificates.

This time this requirement was clear to us, the mis-issuance was due to a missing component in our certificate profile management system.

Thanks to our internal multi-level checks,

the mis-issued certificates were recognized by our RO team prior to the publication of the certificates,

so they were published only to the certificate transparency log servers.

The mis-issued certificates have been immediately revoked internally, within 24 hours of their issuance.

To avoid similar problems, Microsec has reviewed all certificate profiles (not just affected profiles) and improved the entire certificate profile management system.

The changes guarantee, that a similar problem will not occur in the future.

To avoid similar problems, Microsec has reviewed all certificate profiles (not just affected profiles) and improved the entire certificate profile management system.

Did you find https://crt.sh/?id=3573154004&opt=cablint,zlint,ocsp in your review?
(It's a currently-unrevoked 2-year EV cert with notBefore=2020-10-29, issued by "Qualified e-Szigno TLS CA 2018").

Flags: needinfo?(szoke.sandor)

Thank you for reporting this misissued certificate.

We have already revoked this certificate and the corresponding pre-certificate.
We started an investigation why this problem could occur and if there are any other misissued TLS certificates.

We will inform you about the results in this bug.

Flags: needinfo?(szoke.sandor)

INCIDENT REPORT - Misissuance of 1 EV test certificate with 2 years validity

I -- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Rob Stradling commented on the existing Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1676352

II -- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

2020-12-29 11:27 UTC

receive notification email from Mozilla

2020-12-29 11:42 UTC

revocation of the misissued certificate and the corresponding pre-certificate

2020-12-29 11:43 UTC

starting the investigation

III -- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

The quick check confirmed that the certificate profiles are OK and there is no need to stop the certificate issuance.

IV -- A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

2020-10-29

One EV test certificate was issued with longer than 398 days validity.

V -- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

qtlsca2018-valid.e-szigno.hu   	https://crt.sh/?id=3573154004

VI -- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We performed a first verification of our certificate profiles and were able to find the following:

2020-08-26

Microsec prepared the new TLS profiles and uploaded them to the SVN-based certificate profile management system.
All the EV certificate validity was set to 1 year.
All other TLS certificate validity was set to 396 days.

2020-08-31

The new certificate profiles were activated in the CA sytem with the proper validity length values.

2020-10-29

The faulty EV test certificate was issued with 2 years validity, 
although the certificate profile was theoretically correct.

Further investigation could find the real reason of the fault.

from 2020-08-15

This fall we moved some of our CA systems to new hardware and software platforms.
From mid-August we started the migration by cloning the previous CA systems.
This initial configuration contained the old certificate profiles with the longer validity values.
Before migrating to the new platform, system administrators manually updated configuration files.
Due to a human fault, not all the certificate profiles were upgraded.
This time we used the former certificate profile management system which could not find this fault automatically.
We checked all TLS certificates with cablint before issuance, but did not find the error.

So as a summary of the findings we can say, that the fault was caused by the not absolutely correct migration of the CA system to a new platform.

In November we improved our certificate management system that solved this synchronization problem, and this way we did not issue more certificates with this problem.

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

Immediate actions

Microsec revoked the affected EV TLS certificate.
We checked all active certificate profiles, they were OK.
We checked all TLS certificates issued after 2020-08-31 and we could only find this faulty certificate.
An investigation was made to recover the reason for the misissuance.
Microsec identified the root of the problem: 
- the main problem was caused by a human error during the migration of our servers
- the fault was not found by the installed version of cablint
Write this report to the Mozilla bug.

Further actions

We check the used cablint version latest tomorrow (probably not actual).
We also introduce zlint as an additional validation tool.
We write more detailed instructions for the CA migration process.
We organize training for system administrators.

I'm failing to see a response or description about how or why you failed to find the certificate noted in Comment #7.

Thanks to our internal multi-level checks, the mis-issued certificates were recognized by our RO team prior to the publication of the certificates, so they were published only to the certificate transparency log servers.

To be clear, this does not inspire confidence, it actually increases concern. That Microsec e-Szigno believes that this is important to call out is rather significant, in showing that there's a lack of awareness of the expectations or concerns. Beyond this being irrelevant (i.e. the act of publishing to logs is equivalent to publishing the certificates), it highlights an approach that believes that there is a meaningful difference between the act of issuing a certificate and releasing to a customer. This is false, has been repeatedly addressed, and that Microsec still believes this is concerning, because it suggests a systemic failure to follow relevant discussions and CA incidents, where they would have seen this called out in the past.

Equally troubling, in how wrong it is and how it's been repeatedly addressed, is that Microsec believes that root causes are:

  • the main problem was caused by a human error during the migration of our servers
  • the fault was not found by the installed version of cablint

"Human error" is not a root cause, and responses such as "We organize training for system administrators" belie an organization that poses great risk to users. Both of these responses are addressed in https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report , which if Microsec read, would understand that this doesn't even meet the baseline expectations of reasonableness.

Further, to suggest a dependency on tools is to ignore the many other ways to layer in protections.

I'd like to ask Microsec redo this incident report, from the beginning, and taking care to think about root causes in a more systemic way. There's a clear failure to administer systems securely, and honestly, the significance of this failure calls into question the entire operations of the CA. For something like this to happen, and be unnoticed, is exactly the sort of situation that exposes both insider risk and situations like DigiNotar, and it seems a holistic redesign of how Microsec administers its systems is necessary, accompanied by significant transparency in operations. As one of the fewer than a hundred organizations entrusted for the security of billions of users, there is a level of expectation placed here that Microsec is operated at a level beyond a 2-person garage startup, which is the current impression given.

Flags: needinfo?(szoke.sandor)

Dear Ryan,

we appreciate that Google trust us and that we can be among the fewer than 100 selected CAs worldwide.
We feel the responsibility and we strive to provide high quality services according to the expectations.
I would like to inform you that the detailed investigation of the circumstances of the incident is still in progress.
In the meantime, we have made more findings and new developments have taken place on some issues.
I upload the updated report corresponding to the current state.

UPDATED INCIDENT REPORT - Misissuance of 1 EV test certificate with 2 years validity

I -- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Rob Stradling commented on the existing Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1676352

II -- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

2020-12-29 11:27 UTC

  • receive automatic notification email from Mozilla's Bugzilla of the new comment

2020-12-29 11:42 UTC

  • revocation of the misissued certificate

2020-12-29 11:43 UTC

  • initiating an investigation to identify the cause(s) of the error and prevent further similar errors

III -- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

The quick check confirmed that the certificate profiles are OK in both the certificate management system and the live system, and there is no need to suspend the certificate issuance.

IV -- A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

2020-10-29

  • One EV test certificate was issued with a period of validity in excess of 398 days.

V -- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

qtlsca2018-valid.e-szigno.hu   	https://crt.sh/?id=3573154004

VI -- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We performed the verification of our certificate profiles and were able to find the following:

2020-08-26

  • Microsec prepared the new TLS profiles and uploaded them to the SVN-based Certificate Profile Management System.
  • The validity of all EV certificates was set to 365 days.
  • All other TLS certificate validity was set to 396 days.

2020-08-31

  • The new certificate profiles were activated in the live CA sytem with the proper validity length values.

2020-10-29

  • The faulty EV test certificate was issued with a validity of 2 years, although the certificate profile was theoretically correct.

Further investigation could find the cause of the error.

from 2020-08-15

  • This fall, we moved some of our CA systems to new hardware and software platforms.
  • From mid-August, we began preparing for the transition by cloning previous CA systems.
  • This initial configuration contained the old certificate profiles with the longer validity values.

2020-10-15

  • The CA service was migrated to the new server
  • Instead of downloading the proper certificate profiles from the CPMS SVN to the new server, system administrators manually updated the TLS certificate profiles.
  • Due to a human error, not all TLS certificate profiles have been updated.
  • All issued TLS certificates were checked using cablint before publication, but it did not find the error either.
  • One TLS certificate profile was different in the live server and in the Certificate Profile Management System, but our system did not detect this error

Background information about our Certificate Profile Management System and Configuration Management System

** Certificate Profile Management System (CPMS) **
We manage all the certificate profiles in an external SVN (CPMS SVN). 
The profiles are stored in text files in human understandable and editable formats.
When a change is needed we prepare the new profile files and upload them to the CPMS SVN.
We issue a new version of the certificate profile policy document by using LATEX, based on the content of this CPMS SVN.
The system administrator can download the certificate profiles from the CPMS SVN to the live servers and from that time the new certificate profiles are used by the CA software.

** Configuration Management System (CMS) **
Our CMS is also based on SVN but it differs from the previous SVN, it is an internal SVN (CMS SVN).
Each server has its own configuration data in this CMS SVN.
System administrators can upload the proper configuration from the given server to the CMS SVN.
An automated process compares the content of the CMS SVN to the configuration installed on the live server on a daily base.
In case of any incostincency alarm message is sent to the system administrators.

** Activating new certificate profiles **
When a new certificate profile shall be activated, the system administrator shall
- download the new configuration from the external CPMS SVN to the live server at the proper time
- upload the new configuration from the live server to the internal CMS SVN.

Presently we do not have automated tool to compare the certificate profiles stored in the CPMS SVN and the CMS SVN.

Summary of the findings

  • the error was originally caused by the incorrect migration of the CA system to a new platform
  • the difference between the expected configuration in the CPMS SVN and the configuration installed in the live system has not been detected for weeks
  • thus, the live system contained an incorrect TLS certificate profile at the time of issuance

November 2020

  • during November, we migrated to our new Certificate Profile Management System
  • as part of this migration, the correct certificate profiles have been properly copied to the live system from the CPMS SVN and have been updated in the CMS SVN
  • the error disappeared and since that time there was no more faulty issued TLS certificate

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

Immediate actions

  • Microsec revoked the affected EV TLS certificate.
  • We checked all active certificate profiles, they were OK.
  • We checked all TLS certificates issued after 2020-08-31 and we could only find this faulty certificate.
  • A quick initial investigation was made to find out the reason of the misissuance.
  • Microsec identified the causes of the problem:
    • the original problem was caused by a human error during the migration of our CA servers
    • the configuration error has not been detected by the Configuration Management System for weeks
    • the fault was not found by the installed version of cablint either
    • the next quarterly quality control audit is scheduled for January 2021
  • Writing the preliminary incident report to the Mozilla bug.

New findings and actions

checking the cablint version used

  • we found that we are using an earlier version of cablint that still works but is no longer supported
  • we checked which cablint version is used by crt.sh
  • we migrated our development CA system to the cablint version provided by Sectigo
  • the current latest available version is cablint ver. 1.3.0
  • we did some tests with the new cablint version

integrating zlint into our system

  • we checked the availability of zlint and identified the following source: https://github.com/zmap/zlint
  • we migrated our development CA system to the latest zlint version
  • the current latest available version is: zlint ver. 3.0.0
  • we did some tests with the new zlint version

Further planned actions

Deadline: 2021-01-07

cablint

  • After successfully testing the installed new cablint version we migrate our live system to use the new cablint version
  • in the future, we will regularly check the availability of newer versions of cablint and migrate if necessary

zlint

  • After successfully testing the installed new zlint version, we will start using zlint in our live system as a further control tool
  • in the future, we will regularly check the availability of newer versions of zlint and migrate if necessary

Deadline: 2021-01-11

System development, automatization

  • presently we use cablint to confirm the certificates manually after the issuance of the certificate before the publication. This way the possible fault can be recognised only after the issuance and publication of the faulty certificate into the CT log servers.
  • we plan to develop our processes to the following directions
    • we plan to integrate cablint (and zlint the same way) into our CA system and run the control checks automatically
    • we plan to run these tests before the publication of the precert to the CT log servers to prevent the publication of a faulty certificate
  • we develop a process to compare the certificate profiles in the CPMS SVN and in the CMS SVN regularly

Deadline: 2021-01-18

  • We will review our migration process and update it as necessary.

  • We will organize training for system administrators.

Flags: needinfo?(szoke.sandor)

STATUS REPORT 2021-01-07

New findings and actions

2021-01-07

cablint
  • we have successfully tested the new cablint version for all type of our certificates
  • we have integrated the new cablint version into our live system for testing all type of certificates
  • in the future, we will regularly check the availability of newer versions of cablint and migrate if necessary
zlint
  • we have successfully tested the latest zlint version for the TLS certificates
  • we could find some issues with some non TLS certificates, we plan to contact the developers of zlint regarding this
  • we have integrated the latest zlint version into our live system, but only for the TLS certificates
  • in the future, we will regularly check the availability of newer versions of zlint and migrate if necessary

System development, automatization

  • we have already finished the development and activated the automatic cablint and zlint checks into our system
SSL/TLS certificates
  • the CA issues the precertificate
  • the issued precertificate is checked automatically both by cablint and zlint before sending it to the CT log servers
  • in case of any error (ERROR or FATAL ERROR) the process terminates and the precertificate will not be sent to the CT log servers, and the cause of the error is investigated
  • the correct precertificate is sent to the CT log servers
  • the CA collets the necessary amount of SCTs
  • the CA issues the final certificate by integrating the received SCTs
  • the issued final certificate is checked again automatically both by cablint and zlint before publishing it in our certificate repository
  • in case of any error the certificate will be revoked immediately, and the cause of the error is investigated
  • the correct final certificate is published in our certificate repository and the subscriber is informed about the issuance
other type certificates
  • the CA issues the final certificate
  • the issued certificate is checked automatically by cablint before publishing it in our certificate repository
  • in case of any error the certificate will be revoked immediately, and the cause of the error is investigated
  • the correct certificate is published in our certificate repository and the subscriber is informed about the issuance

Further planned actions

Deadline: 2021-01-11
System development, automatization
  • we develop a process to compare the certificate profiles in the CPMS SVN and in the CMS SVN regularly
Deadline: 2021-01-18
  • We will review our migration process and update it as necessary.
  • We will organize training for system administrators.
No deadline
  • we plan to contact the developers of zlint
  • when the recovered issue will be solved we plan to integrate the zlint for all type of certificates

STATUS REPORT 2021-01-11

New findings and actions

2021-01-11

automatic test by using cablint and zlint

  • automatic testing was introduced earlier than the set deadline and has already been reported

System development, automatization

  • we established the process to ensure that the certificate profiles in the live system and in the CPMS SVN match
    • we create the new certificate profiles in the CPMS SVN
    • the modified certificate profiles are checked and shall be approved
    • a new CPMS SVN TAG is created after the modified profiles are approved
    • at the desired time, based on the new CPMS SVN TAG, the certificate profiles are activated in the live system
  • after this, based on the active CPMS SVN TAG, the content of the server configuration in the live system is automatically verified daily

zlint issue

  • we have already started to study the zlint
  • we could find that this issue was already raised by Ryan Sleevi in February 2020

https://github.com/zmap/zlint/issues/424
https://bugzilla.mozilla.org/show_bug.cgi?id=1625421
https://github.com/zmap/zlint/pull/387#discussion_r391935856
https://github.com/zmap/zcrypto/pull/217

  • it is not entirely clear to us whether this issue has already been resolved (in part) or is still open

Further planned actions

Deadline: 2021-01-18

  • we will review our server migration process and update it as necessary
  • we will organize re-training for system administrators

No deadline

  • when the recovered issue will be solved we plan to integrate the zlint for all type of certificates in our system

STATUS REPORT 2021-01-18

New findings and actions

2021-01-15

  • the LATEX based Certificate Profile creation system was updated to comply with the new CPMS
  • a new version of our Certificate Policy document was issued based on the new (SVN TAG based) management system
  • there was no change in the live Certificate Profiles

2021-01-18

  • we globally reviewed our CA installation and server migration processes
    • we made the necessary changes in accordance with the new CPMS
    • we updated the process description and published it internally
  • we organized a re-training for our system administrators based on the updated processes

Further planned actions

No deadline

  • when the recovered issue will be solved we plan to integrate the zlint for all type of certificates in our system

Dear Sándor,
Is there an update on your zlint implementation?
Thanks,
Ben

Flags: needinfo?(szoke.sandor)
Whiteboard: [ca-compliance] → [ca-compliance] Next update 2021-04-01

STATUS REPORT 2021-03-31

Current ZLint usage info

  • Microsec continues to automatically verify all issued TLS certificates using ZLint before publishing.
  • Currently ZLint is not used for non-TLS certificates due to known issues.

New findings and actions

2021-01-11

  • Microsec sent an email to the ZMap Team informing them about the problem related to handling of the ETSI QcStatements
  • Zakir Durumeric responded the same day and asked us to raise this issue via GitHub.

2021-02-14

  • Our automated tool recognised the new version of ZLint (ZLint v3.1.0)
  • We started testing the new version on our development system and later on our test system.

2021-03-02

  • We have found that there has been no change regarding ETSI lints, other lints are working properly with our certificates in our environment.

  • We decided to upgrade to the new version, but we will still use ZLint only for TLS certificates.

  • After successful testing, we upgraded ZLint to the latest version on all affected CA systems.

2021-03-29

  • Microsec had an internal meeting about this topic and decided to be more active in solving the ETSI lint problem.

2021-03-29

2021-03-30

  • Microsec offered its contribution in clarifying of ETSI requirements to improve the corresponding lints.
  • The future support of ETSI lints in ZLint is under negotiations, there is no final decision yet.

Further planned actions

2021-04-15

  • Microsec will test all its certificate types with the latest version of ZLint to see the real weight of the issue.

2021-04-30

  • Based on the result, Microsec plans to make a decision about using ZLint for non-TLS certificates also by excluding problematic lints, or not using it for non-TLS certificates.

No deadline

  • In case of positive feedback, Microsec is ready to contribute to the improvement of the ETSI lints as it was promised on GitHub.
  • When the recovered issue will be resolved, Microsec plans to integrate the ZLint into its system for all type of certificates.
Flags: needinfo?(szoke.sandor)

Based on the result, Microsec plans to make a decision about using ZLint for non-TLS certificates also by excluding problematic lints, or not using it for non-TLS certificates.

Sounds like a good plan. Given the state of the ETSI lints, and their current assumptions, disabling them if you're finding them problematic (but only after careful examination to make sure they are indeed false-positives) seems good, as well as opening issues against ZLint for each scenario or situation you find buggy.

Flags: needinfo?(bwilson)

Sounds like a good plan. Given the state of the ETSI lints, and their current assumptions, disabling them if you're finding them problematic (but only after careful examination to make sure they are indeed false-positives) seems good, as well as opening issues against ZLint for each scenario or situation you find buggy.

Of course, we will carefully examine all WARNING and ERROR messages and report any possible ZLint bug by opening issues on GitHub.

Whiteboard: [ca-compliance] Next update 2021-04-01 → [ca-compliance] Next update 2021-05-01

STATUS REPORT 2021-04-15

Related issues on GitHub

New findings and actions

2021-04-01

  • We collected 86 end-user certificates with different profiles for testing
  • We run ZLint ver.3.1.0 on each certificate
  • We could find several Warning and Error messages that can not be easily analysed individually

2021-04-06

  • We decided to arrange a wider test that focuses not only on ETSI lints
  • We decided to set up a test environment to help test batches of certificates and create a summarized test report for each certificate and lint
  • We decided to carry out the tests systematically step by step for the diferent certificate types
  • To start with, we collected 74 provider certificates that were used during the development of the test tools

2021-04-09

  • Test tools and test environment are ready. We are able to run tests on batch of certificates and produce summarized results relatively easily and quickly.

2021-04-15

  • We begin the real tests whose result is planned to be reported on GitHub
  • At the beginning we tested 71 Provider certificates that may be interesting for several CAs (root CA, intermediate CA, OCSP Responder, Time Stamping)
  • We already have the test results and the summary
  • We begin the deep investigation of the received results

Further planned actions

2021-04-23

  • Microsec will analyze the test results of the first batch in depth and in case of a real finding will open an issue on GitHub.

2021-04-30

  • Based on the results, Microsec plans to make a decision about using ZLint for non-TLS certificates also by excluding problematic lints, or not using it for non-TLS certificates.

No deadline

  • In case of positive feedback, Microsec is ready to contribute to the improvement of ZLint lints by running tests and providing the test results.
  • When the recovered issues will be resolved, Microsec plans to integrate ZLint into its system for all type of certificates.

STATUS REPORT 2021-04-23

Related issues on GitHub

New findings and actions

2021-04-16

  • We identified three potential issues that shall be investigated deeply
    • ZLint ERROR: SAN extension with email address in subordinate CA certificate
    • ZLint ERROR: Key usage conflict in subordinate CA certificates with EKU extension
    • ZLint WARNING: qcstatement_qctype_web warning at time stamping certificates
  • We begin the investigation of the issues

2021-04-21

  • we finished the investigation of the Subordinate CA SAN issue and were able to find a potential issue in ZLint

2021-04-22

Further planned actions

2021-04-30

  • Finish the investigation of the other two issues
  • Based on the results, Microsec plans to make a decision about using ZLint for non-TLS certificates also by excluding problematic lints, or not using it for non-TLS certificates.

No deadline

  • In case of positive feedback, Microsec will continue to contribute to the improvement of ZLint lints by running tests and providing test results.
  • When the recovered issues will be resolved, Microsec plans to integrate ZLint into its system for all type of certificates.
Summary: Microsec e-Szigno: Validity validity period greater than 398 days → Microsec e-Szigno: Certificate validity period greater than 398 days

STATUS REPORT 2021-04-30

Related issues on GitHub

New findings and actions

lint "e_key_usage_and_extended_key_usage_inconsistent" in technically constrained CA certificates

  • During the investigation we realized that this lint has already been removed from the current version (v.3.1.0)
  • We realized that we run the test not on the latest ZLint version, but on an earlier version, probably v.3.0.0
  • It is problematic, that there is no an easy way to identify the running ZLint version and the test result does not contain version information.
  • We decided to upgrade our test system and run all the tests again.

2021-04-30

  • we upgraded our test environment to ZLint v. 3.1.0
  • we confirmed, that our live environment runs the latest ZLint version
  • we run all the tests again with the new ZLint version and created the summarized test result
  • the new ZLint contains 274 lints instead of the former 270 lints
  • based on the new test results we modified our prepared report
  • we opened a new issue on GitHub: ( https://github.com/zmap/zlint/issues/593 )

2021-04-30

  • we made the decision that presently we do not expand using ZLint for non-TLS certificates

Further planned actions

2021-05-15

  • Finish the investigation of the third issue

No deadline

  • Follow comments on the opened issues
  • In case of positive feedback, Microsec will continue to contribute to the improvement of ZLint lints by running tests and providing test results.
  • When the recovered issues will be resolved, Microsec plans to integrate ZLint into its system for all type of certificates.

STATUS REPORT 2021-05-14

Related issues on GitHub

Link Short description
https://github.com/zmap/ZLint/issues/581 non-Qualified certificates with QCStatements extension
https://github.com/zmap/zlint/issues/591 SAN extension in CA certificate
https://github.com/zmap/zlint/issues/593 EKU in CA certificates
https://github.com/zmap/zlint/issues/602 Qualified Time Stamping certificates

New findings and actions

2021-05-14

Further planned actions

No deadline

  • Follow comments on the opened issues
  • In case of positive feedback, Microsec will continue to contribute to the improvement of ZLint lints by running tests and providing test results.
  • When the recovered issues will be resolved, Microsec plans to integrate ZLint into its system for all type of certificates.

I believe that this bug can be closed and plan to do so on or about Friday, 11-June-2021, unless there is reason to believe that keeping this bug open will yield further benefit.

Flags: needinfo?(bwilson)
Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Summary: Microsec e-Szigno: Certificate validity period greater than 398 days → Microsec: Certificate validity period greater than 398 days
Whiteboard: [ca-compliance] Next update 2021-05-01 → [ca-compliance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.