Re: Microsec: Misissuance of 2 CISCO VPN server authentication certificates
See further information in the following Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1676352 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Microsec: Misissuance of 2 CISCO VPN server authentication certificates
### 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.huhttps://crt.sh/?id=3606063415 avpn.mokk.huhttps://crt.sh/?id=360362 - >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** ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: EKU is required in each Subordinate CA certificate
Yes, that date comes from the Mozilla Root Program, but this requirement is new for the other Root Programs and for the BR. The other thing is that without having an indicated effect date, the requirement can be interpreted in that way, that every valid Subordinate CA certificate shall comply this requirement, even if it has been issued years ago. I would just like to get confirmation that this requirement does not mean that all subordinate CA certificates that are currently non-compliant shall be revoked, which were issued prior to the effective date. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
EKU is required in each Subordinate CA certificate
You could find the following requirement in the latest Baseline Requirement: 7. CERTIFICATE, CRL, AND OCSP PROFILES 7.1 Certificate profile 7.1.2 Certificate Content and Extensions; Application of RFC 5280 7.1.2.2 Subordinate CA Certificate ... g. extkeyUsage (optional/required) For Cross Certificates ... For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates: This extension MUST be present and SHOULD NOT be marked critical. ... If I understand this requirement correctly, each Subordinate CA certificate (excluding the above mentioned Cross Certificates) shall contain the EKU extension. Does it mean that all Subordinate CA certificates issued after a specific date shall contain the EKU extension? What is the effect date of this requirement? Is it 20 August 2020, as the issue date of this version of the Baseline Requirement? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
The information has been updated. There is no Microsec Audit Letter Validation Failure in CCADB. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root
The information has been updated. There is no Microsec Audit Letter Validation Failure in CCADB. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
I inform you that Microsec issued the new version of its public documents on 2020-05-26. The information has already been updated in CCADB. The actual links of the most relevant public documents are: CP/CPS: eIDAS conform Qualified Certificate for Website Authentication CP (EV): https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.14.pdf eIDAS conform Qualified Certificate for Website Authentication CPS (EV): https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.14.pdf eIDAS conform Certificate for Website Authentication CP (DV, OV): https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.14.pdf eIDAS conform Certificate for Website Authentication CPS (DV, OV): https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf I also inform you, that our auditor issued the updated version of our Attestation Letter, which contains all the doppelganger certificates of our root certificate "Microsec e-Szigno Root CA 2009". The new Attestation Letter is available on the following link from today: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.2_s.pdf The new audit information will be added to CCADB soon. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root
> Presently Microsec has one ALV failure in the CCADB regarding the earliest > version of the "Microsec e-Szigno Root CA 2009" Root Certificate. > To resolve this warning, Microsec will request a new audit report from the > auditor that includes this third root certificate too. > There is no deadline for this but Microsec will inform Mozilla when the date > is agreed by the auditor. > Until this new audit attestation is uploaded, considering the full > transparency provided by the above detailed investigation and submissions, > Microsec requests Mozilla to disregard this temporary ALV failure. I inform you that the auditor issued the new Attestation Letter which includes all three versions of the "Microsec e-Szigno Root CA 2009" Root Certificate. The report can be downloaded from the following link: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.2_s.pdf We will update the information in CCADB soon. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
I inform you that Microsec activated the IVCP profiles today. It is possible to issue IVCP certificates again. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
We organized the training for our Registration Officers regarding the proper configuration of different TSL profiles today. The IVCP profiles are planned to be reactivated tomorrow. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
I inform you that as planned two days ago, Microsec today activated the new CA software release in the live system. The CA sofware has been improved to support more automatic checking for the presence of SN fields for different certificate profiles. As part of the project, Microsec has developed an automated testing tool that allows for more efficient testing of the CA program. Test inputs and expected CA responses can be given in a configuration file, and the test runs automatically in batch mode. The test was passed without error. The development was approved yesterday and the installation of the new release on the live system was approved. Despite the software upgrade, IVCP profiles are still not active, and Microsec does not issue IVCP certificates. There is no official deadline for activation, but Microsec plans to activate IVCP profiles together with the other profile changes due to the release of new public documents on 2020-05-26. Prior to activation, Microsec will organize a training for Registration Officiers on the proper configuration of different TSL profiles. Microsec will immediately notify the community as soon as any changes occur. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
I give you a brief status report on CA software development. Microsec has already completed the development of CA software and introduced additional automatic checks for the proper configuration of the SN fields in case of different certificate types. A number of internal tests have already been performed on the test system, but the new release is still awaiting final acceptance tests. The new release of the CA software has not been activated in the live system yet, the scheduled activation date is 2020-05-20. IVCP profiles are still inactive, Microsec does not issue IVCP certificates. As Microsec informed the community in its first comment (2020-03-13), there was no deadline for CA software development due to the COVID-19 emergency situation. This information was confirmed in comment 2020-03-19, and the date 2020-04-15 was given as a plan only and not as a strict deadline. Microsec will immediately notify the community in case of any further change in this thread. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
Dear Ben, I confirm that Microsec will correct all issues in the CP and CPS documents as promised during the public discussion. Thanks to everyone who took the time to read Microsec CP and CPS and to comment on them. If there are no more comments on the content of our CP and CPS documents in the public discussion, we will review the thread again and gather all the issues to be resolved. As usual, Microsec will review current versions of all applicable requirements for changes. I confirm that the section 1.5.2 will be changed. The High Priority Certificate Problem Report will be reviewed and will be moved here from section 4.9.3. Other issues I can see after a brief overview: - Preliminary report in case of Certificate problem report in section 4.9.5 - correct the reference to section 1.3.1 instead of 1.2 in section 4.9.5 - review the email address validation rules in case of non-automatic validation procedure in section 3.2.7 I expect that Microsec will be able to do it within one week and will prepare the draft version of the public documents by the end of April. We publish the drafts on our website and send them to the auditor and our supervisory authority at the same time. This is followed by a 30-day commenting period during which anyone can comment on the planned changes. If significant issues arise during this period, the draft shall be amended and the 30 days shall begin again. If there are no significant issues, the new document will enter into force by the end of May 2020. Please let us know if you expect us to take any further steps in this process. Best regards, Sándor dr. Sándor Szőke Microsec deputy director ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root
I summarize the issue in a form of an incident report. 1. 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 presence of the doppelganger CA certificates was known since 2009, and it did not cause problems during the operation. The situation was discussed with Mozilla first in November 2016. The problem came up with the “Audit Letter Validation Failures” in 2019 when new functions were introduced in the CCADB. 2019-11-22 Wayne Thayer wrote the Comment 30 to our root inclusion request bug and mentioned the 9 audit letter validation failures in the CCADB. https://bugzilla.mozilla.org/show_bug.cgi?id=1445364#c30 https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/M7NGwCh14DI/9Go4rOTgBgAJ https://wiki.mozilla.org/CA/Audit_Letter_Validation 2. 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. The following timeline includes the full list of events concerning the doppelganger CA certificates from their issuance to the present day. 2009-03-06 Microsec Ltd. issued the following root certificate: - Microsec e-Szigno Root CA 2009 ( 2370027485 ) Expiry date: 2038-01-18 2009-03-09 Microsec Ltd. issued the following subordinate CA certificates: - Advanced Class 2 e-Szigno CA 2009 ( 2629646531 ) - Advanced Class 3 e-Szigno CA 2009 ( 12726032 ) - Advanced Pseudonymous e-Szigno CA 2009 ( 2629646669 ) - Qualified Pseudonymous e-Szigno CA 2009 ( 2629646659 ) - Qualified e-Szigno CA 2009 ( 2629646584 ) Expiry date of each of these certificates: 2038-01-17 2009-06-16 Microsec reissued the following root certificate: - Microsec e-Szigno Root CA 2009 ( 194998 ) Expiry date: 2029-12-30 In the certificate the following fields were changed: validity notBefore and notAfter dates, and the certificatePolicies extension. Microsec reissued the following subordinate CA certificates: - Advanced Class 2 e-Szigno CA 2009 ( 2629646790 ) - Advanced Class 3 e-Szigno CA 2009 ( 12722207 ) - Advanced Pseudonymous e-Szigno CA 2009 ( 2629646543 ) - Qualified Pseudonymous e-Szigno CA 2009 ( 26312005 ) - Qualified e-Szigno CA 2009 ( 26312004 ) Expiry date of each of these certificates (aligned with the new root): 2029-12-29 In the certificates the following fields were changed: validity notBefore and notAfter dates, and the certificatePolicies extension. 2009-12-02 Microsec reissued the following root certificate: - Microsec e-Szigno Root CA 2009 ( 149444539 ) Expiry date was unchanged: 2029-12-30 The certificatePolicies extension was dropped from the certificate, and the place of the keyUsage extension changed within the ASN.1 structure. Microsec reissued the following subordinate CA certificates: - Advanced Class 2 e-Szigno CA 2009 ( 12625481 ) - Advanced Class 3 e-Szigno CA 2009 ( 194999 ) - Advanced Pseudonymous e-Szigno CA 2009 ( 12716021 ) - Qualified Pseudonymous e-Szigno CA 2009 ( 12716127 ) - Qualified e-Szigno CA 2009 ( 12721748 ) In the certificates the validity notBefore date changed to the issuance date, the certificatePolicies extension changed to anyPolicy, and the URL pointing to the location of CPS documents changed to a uniform value for qualified and non-qualified certificates. In summary, all above certificates were reissued by Microsec two times during 2009. In these two cases each certificate was reissued with an unchanged public key and unchanged Subject DN as compared to the previous corresponding certificate, while some other fields were changed. The CA certificates were published (apart from the website) through the Microsec e-Szigno signature creation and validation application, and were (may have been) also published in the trusted certificate stores of other software. The CA certificates were primarily intended for electronic signatures. It is necessary to be able to validate digital signatures chaining up to these CAs in the long term (50 years). Since electronic signature (end user) certificates only contain the Subject DN of the issuer CA, the reissued (doppelganger) subordinate CA certificates with the same Subject DN and key are equally suitable for certificate chain building. As a consequence, revocation of some subordinate CA certificates might cause validation errors (false negatives) in some signature
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
I have uploaded the Excel sheet to the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1622539#c3 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
> - Microsec will review the CA software looking for possible similar problems > - deadline 2020-03-31 Microsec has completed a detailed review of the automatic controls built into the CA software. The review covered all SSL/TLS certificate types and focused on the presence of required fields in the Subject DN. Microsec first created a table with all possible Subject DN fields based on the current version of the CABF BR, EVG, and Microsec CPS documents. The following certification policies are included in the table: DVCP, IVCP, OVCP, EVCP/QWAC, EVCP/PSD2. Microsec has collected rules for each field and policy combination, which may include: mandatory forbidden optional For optional fields, Microsec also identified dependencies. After completing the complete list of requirements, Microsec reviewed the source code for the CA software. As a result of this review, Microsec determined that the scope of automated checks should be expanded for the IVCP profile, but they are complete for all other certificate profiles. Microsec has created a work item and has already begun to upgrade the CA program with additional controls. There is no specific deadline for completing the development, but Microsec plans to do the development and test the new software version by 2020-04-15. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
Dear All, Microsec Ltd. is dedicated to comply with the standards and industry best practices at all times, including the applicable IETF RFCs, ETSI standards and technical specifications, CA/Browser Forum Baseline Requirements, Extended Validation Guidelines and Network Security Controls, as well as the Mozilla Root Store Policy and other root program policies. Being an EU-based Qualified Trust Service Provider, our trust services are regulated and nationally supervised under the Regulation (EU) No 910/2014 (eIDAS), which mandates the annual conformity assessment by an accredited conformity assessment body. In order to comply with all the latest legal and technical requirements, our CP/CPS documents incorporate all requirements from the above mentioned applicable sources, and we actively monitor the updates of the IETF RFCs, ETSI standards, CA/Browser Forum documents and the Mozilla Root Store Policy and other root program policies. As changes in the totality of requirements occur quite frequently, we regularly update our practices and develop our systems to ensure compliance with the changes too. Our annual conformity assessment, performed by TÜV Informationstechnik GmbH (TÜViT), is always based on the current version of the standards, as detailed in the Audit Attestation. Microsec greatly appreciates the detailed evaluation of our inclusion request, as well as the automated checks in the CCADB, since these enhance transparency and contribute to the security of the ecosystem. We welcome the opportunity to engage in the public discussion, to provide supporting information that none of the findings of the evaluation represent a significant risk for Mozilla users, and to take away any useful advice which might help us further improve our practices and documentation. Regarding the findings, please consider the information and explanations provided in our previous postings to this thread and several other threads, which are summarized in the following: 2020-03-09 - the thread was opened by Kathleen Wilson 2020-03-11 - First responses which were published one day later due to moderator approval delay. At first, Microsec gave some background information regarding the relatively high number of audit findings: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/78T_0HWkAQAJ Then, Microsec uploaded the first answers to the original ===Meh=== and ===Bad=== findings of Wayne: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/xNUov3WkAQAJ 2020-03-12 – Discussion to clarify the proper place of the Private Key Compromise information in CPS https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30 2020-03-13 – Incident report about the Issuance of 2 IVCP precertificates without givenName, surName, localityName fields https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C8YdPLAmCOE The evaluation of the issue runs according to the planned schedule. 2020-03-24 – Discussion: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/QqYm4BhFMHs It is a complex issue and it is probably better to explain it in a separate discussion than as part of the present thread. Wayne asked to transform this information into a formal incident report. Microsec will do it soon. 2020-03-24 - Short explanations for the year 2018 audit findings: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/iiMVWwQGBAAJ 2020-03-27 - Short explanations for the year 2019 audit findings: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/ofERMFLnAQAJ We hope the above information reinforces that our procedures are reliable, and our certificates are trustworthy. We would like to thank Wayne, Matt, Ryan and all members of the forum for your valued feedback, which we can use as input to our continuous efforts to improve the clarity of our documentation and the high quality of our services. We remain open to constructive discussion regarding our inclusion request, as always. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
I provide brief explanations for the 2019 audit findings as follows: > > * The following non-conformities were listed in the 2019 BR attestation > statement [9]: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf This is the latest non-EV report for the ECC root from 2019-12-13 > ** The TSP shall not issue non-compliant test certificates from the live > environment. As this has been occurred in the past, the TSP shall > provide evidences of the changed testing procedures to avoid further > occurrence of such events. [ETSI EN 319 401, REQ-6.1-07] Microsec uses automated tests to monitor the availability of the Web Immediate Suspension service. To perform the tests, Microsec needs one test certificate from each of the subordinate CAs. Private keys are not needed at all so, after the issuance of the test certificates the private keys are destroyed. These test certificates are periodically suspended and then automatically reinstated. On 2019-09-13, new test certificates were issued directly from each CA in the ECC root hierarchy with the following Subject DN data: SERIALNUMBER = 1.3.6.1.4.1.21528.2.2.1.13331 E = i...@..hu CN = Microsec zrt. - Automata Felfüggesztő - ECC 2.5.4.97 = VATHU-23584497 O = Microsec zrt. L = Budapest C = HU 5 of the test certificates were issued to natural persons for electronic signature creation, but this DN does not match the certificate profile for electronic signature certificates. The auditor reported one of the incorrect certificates to Microsec at 2019-10-12 21:23 Microsec processed the report, identified the issue, verified the entire certificate database for similar issues, and revoked all 5 affected certificates with this issue at 2019-10-13 13:19. Following the revocation of the test certificates concerned, new test certificates were issued in accordance with the normal certificate issuance process. Microsec introduced a new process for issuing internal test certificates issued in the live system. All internal test certificates shall be issued from the RA system as part of the normal issuance process. It is now prohibited to issue even test certificates directly from the CA software. The standard certificate issuance process has multiple built-in automatic controls to avoid issuing faulty certificates. The auditor has reviewed the changed testing procedures, accepted the provided evidence, and deemed this finding as resolved. > ** The TSP shall ensure that all issuance of a qualified signature > comply with eIDAS Article 24 in each case. [ETSI EN 319 411-1, > REG-6.2.3-01] Article 24 of eIDAS contains very stringent (stronger than the EVG) requirements for the identity verification before issuing qualified certificates. The basic process requires face-to-face identity verification of the natural person, who can be the Subject in case of a signing certificate or the representative of the Subject in case of seal or website authentication certificate. eIDAS and the ETSI standards do not specify how long this face-to-face verification can be reused or when it shall be repeated. Different EU member states have different interpretations and different practices. Some member states allow the re-use of the verification result in the case of a certificate renewal, but in other member states it has to be repeated in case of issuance of a certificate due to any reason (renewal, rekey, modification). Instead of the face-to-face identity verification, the CA may accept a qualified signature or qualified seal created with the certificate to be renewed. This cannot be done if the certificate cannot be used to create a valid digital signature. The Hungarian requirements are very strict and always require face-to-face verification in each case when a valid digital signature is not available. Microsec CPS did not provide detailed regulation in some of these special cases. Microsec updated its public documents, which are valid from 2019-12-12. The section 3.2 of the CPS was modified. When issuing any certificate, Microsec uses the same identity verification process as used for initial identity verification. In all cases, the procedure for issuing qualified certificates is fully in line with Article 24 of eIDAS. > ** The TSP shall ensure that all issuance of a qualified certificate > comply with eIDAS Article 24 when TSP accepts certificate re-keying > requests as written mail with handwritten (wet) signatures via postal > services and any of the subject’s data is changed. [ETSI EN 319 411-1, > REG-6.2.3-01] It is the same issue as described above. In the event of a lost smartcard, the Subscriber is not able to create a valid digital signature to request a certificate re-key, and it is not possible at all with a website authentication certificate. Microsec had previously accepted the re-key request in a paper and ink based signed document, and Microsec used a
Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root
Investigation of the situation: 2009-03-06 Microsec Ltd. issued the following root certificate: - Microsec e-Szigno Root CA 2009 Expiry date: 2038-01-18 2009-03-09 Microsec Ltd. issued the following subordinate CA certificates: - Advanced Class 2 e-Szigno CA 2009 - Advanced Class 3 e-Szigno CA 2009 - Advanced Pseudonymous e-Szigno CA 2009 - Qualified Pseudonymous e-Szigno CA 2009 - Qualified e-Szigno CA 2009 Expiry date of each of these certificates: 2038-01-17 2009-06-16 Microsec reissued the following root certificate: - Microsec e-Szigno Root CA 2009 Expiry date: 2029-12-30 In the certificate the following fields were changed: validity notBefore and notAfter dates, and the certificatePolicies extension. Microsec reissued the following subordinate CA certificates: - Advanced Class 2 e-Szigno CA 2009 - Advanced Class 3 e-Szigno CA 2009 - Advanced Pseudonymous e-Szigno CA 2009 - Qualified Pseudonymous e-Szigno CA 2009 - Qualified e-Szigno CA 2009 Expiry date of each of these certificates (aligned with the new root): 2029-12-29 In the certificates the following fields were changed: validity notBefore and notAfter dates, and the certificatePolicies extension. 2009-12-02 Microsec reissued the following root certificate: - Microsec e-Szigno Root CA 2009 Expiry date was unchanged: 2029-12-30 The certificatePolicies extension was dropped from the certificate, and the place of the keyUsage extension changed within the ASN.1 structure. Microsec reissued the following subordinate CA certificates: - Advanced Class 2 e-Szigno CA 2009 - Advanced Class 3 e-Szigno CA 2009 - Advanced Pseudonymous e-Szigno CA 2009 - Qualified Pseudonymous e-Szigno CA 2009 - Qualified e-Szigno CA 2009 In the certificates the validity notBefore date changed to the issuance date, the certificatePolicies extension changed to anyPolicy, and the URL pointing to the location of CPS documents changed to a uniform value for qualified and non-qualified certificates. In summary, all above certificates were reissued by Microsec two times during 2009. In these two cases each certificate was reissued with an unchanged public key and unchanged Subject DN as compared to the previous corresponding certificate, while some other fields were changed. The CA certificates were published (apart from the website) through the Microsec e-Szigno signature creation and validation application, and were (may have been) also published in the trusted certificate stores of other software. The CA certificates were primarily intended for electronic signatures. It is necessary to be able to validate digital signatures chaining up to these CAs in the long term (50 years). Since electronic signature (end user) certificates only contain the Subject DN of the issuer CA, the reissued (doppelganger) subordinate CA certificates with the same Subject DN and key are equally suitable for certificate chain building. As a consequence, revocation of some subordinate CA certificates might cause validation errors (false negatives) in some signature validation applications, therefore, Microsec maintained all versions of the CA certificates as valid. This solution worked without problems in the creation and validation of signatures, and Microsec has not received any error reports in relation to this throughout the years. Microsec has always published and promoted the use of the latest version of the CA certificates, but could not prevent the use of the earlier versions. 2016-11 Having set up the CCADB, Mozilla introduced more and more stringent checks, and earlier versions of some of the CA certificates were added to the database. Upon the notification from Mozilla, Microsec investigated the situation, and requested to maintain the validity of the affected CA certificates due to reasons explained above. Mozilla temporarily approved to keep all CA certificate verions valid. 2019-11 In relation to the improvement of the CCADB system Mozilla launched automated tools for audit letter validation (ALV). These controls require each subordinate CA certificate in CCADB to be included in one of the audit letters. The automatic checking is based on the SHA-256 fingerprint of the certificate. During the validation of the Microsec audit letters the ALV tool found 9 discrepancies, which can be categorized in the following types: 1. Formatting problem in the audit letter (5 out of 9) In the audit letters issued near the beginning of 2019 the SHA-256 fingerprint of some certificates were split in two parts by a page break inside the table cell, so the ALV tool was unable to parse
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
I provide brief explanations for the 2018 audit findings as follows: > * The following non-conformities were listed in the 2018 BR attestation > statement [7]. (they are not defined as “major” or “minor”): https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121303_Microsec-eSzignoRoot-CA-2017_nonEV-CAs_s.pdf This is the non EV attestation letter for the new ECC root in 2018-12-13 based on the point in time audit for the new service > ** The TSP shall remove irrelevant and confusing information from each > policy (e.g. explanation of how to create policy codes) [ETSI EN 319 > 401, REQ-6.1-01] Microsec issues several types of certificates based on different certificate policies. One CP and CPS document typically contains the requirements for a number of similar certificate types by using slightly different policies. These policies can be classified by using 5 main parameters. Microsec introduced a five-character short reference code to be able to refer to a given policy easily. This short reference code is used in the CP and CPS documents to mark those requirements, which are related only to a specific policy. This code is used also in the CA system of Microsec to identify configuration settings. The meaning of this classification was included in the CP and CPS documents to help the Subscribers understand it. To fulfil the requirement of the auditor, Microsec terminated the usage of some policies regarding electronic signature and moved this description to the Appendix of the CP and CPS documents. > ** The TSP shall clearly indicate which kind of documents are necessary > for the application procedures of different types of certificates. [ETSI > EN 319 401, REQ-6.1-01] This finding refers to the 2018 version of the webpage of Microsec, which listed all the public documents on one page, like the following list presently: https://e-szigno.hu/en/all-documents.html The names of the documents are meaningful, and the documents are grouped, but due to the high number of the offered services, it was not easy to find all the relevant documents for a specific service or service package based on this page. To fulfil this finding of the auditor, Microsec developed a web page to help the users find the corresponding documents more easily. You can see this page on the following link: https://e-szigno.hu/en/terms-and-informations/ This lists the most frequently used services and service packages. After selecting the proper service or package the web page shows all the corresponding public documents. Example: https://e-szigno.hu/en/terms-and-informations/filtered-versions.html?szolg=minositett_weboldal_hitelesites Clients and relying parties can find all the current and previous versions of our public documents on these sites. If a draft document is available which will take effect soon, it is also indicated by giving the planned effect date. > ** The TSP shall maintain such asset list which can support the daily > operation and does not cover unnecessary elements (e.g. mouse, keyboard) > [ETSI EN 319 401, REQ-7.3.1-01, REQ-7.3.1-02] Microsec has a detailed asset list which contains all of the valuable assets according to the legal and financial requirements in Hungary. This list is maintained by our finance department and each asset is added to the list immediately upon purchase. Of course, this asset list does not contain the low-value assets (such as mouse or keyboard), but contains the computers, screens, all the furniture and other tangible assets. The auditor asked to maintain a shorter asset list, which contains only those IT assets which are essential for the operation of the services (HSMs, routers, switches, servers, desktop computers used for the services, etc.) Microsec now maintains two lists in parallel, which are synchronized regularly. One is the full list and the other is the list of the critical IT devices. The Microsec low level risk analysis is connected to this critical asset list. > ** The TSP shall ensure that > the password policy provisions are applied in all systems in the TSP and > shall review them periodically. [ETSI EN 319 401, REQ-7.4-06] Microsec uses various devices with different operating systems which have different support for forcing the password policies. Microsec typically uses PKI certificate-based authentication between servers and when users log into applications, but in some cases username and password is also used (typically in addition to a PKI-based authentication). Microsec reviewed the abilities of the used servers and the best practices regarding passwords, and changed the password policies accordingly, so that the requirements are now enforced across all used platforms > ** The TSP shall move the videoserver from the secondary data center to > another secure location without IT administrator access and shall review > the records on regular basis. [ISO27001], [ETSI EN 319 401, REQ-7.6-03] In
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
> > - Microsec will check all the issued IVCP certificates looking for similar > issues - deadline 2020-03-20 > Microsec has finished the detailed investigation on the issued TLS IVCP certificates looking for similar issues. The findings are the following: Microsec issued altogether 9 test certificates on 2019-10-01 and 2019-10-02 with 30 days validity. The purpose of the test was to issue DV and IV certificates from each subordinate CA which is used to issue these types of certificates. The test covered both the RSA-based hierarchy and the ECC-based new CA hierarchy. The test certificates were issued directly from the CA software by using the operator interface. The CA software forces the use of dual control. The RSA-based system is configured to use Certificate Transparency to fully comply with the present requirements. 4 of the 9 test certificates were issued in the RSA-based system. The ECC-based system was configured to issue the test certificates without Certificate Transparency, because this root is not trusted yet and none of the log servers issues SCT for this root. 5 of the 9 test certificates were issued in the ECC-based system. The Subject DN fields were configured according to the DV profile requirements, this way the issuance of the DV certificates was successful. The 2 successfully issued RSA-based DV certificates can be found in the crt.sh as https://crt.sh/?q=1947651733 https://crt.sh/?q=1944631156 The issuance of the test IV certificates was done using the same Subject DN fields by mistake. None of the operators identified the missing fields in case of IV certificates. The following RSA-based IV certificates were issued with missing fields in the Subject name: https://crt.sh/?q=1947655126 https://crt.sh/?q=1947655112 They are already included in the incident report and there are no other IV certificates issued under the RSA root with this problem. A similar set of 3 DV and 2 IV test certificates were issued under the ECC root, but without SCT, as explained above. Because of this, they can’t be found in the crt.sh. The 3 DV test certificates were correct. The 2 IV test certificates have the same problem: missing givenName, surName, localityName fields in the Subject DN. These certificates are already expired, so revocation is not possible. Microsec has only issued test TLS certificates under the ECC root so far. The cause of the problem was the same as for the RSA-based test certificates, so the remediation and preventive measures are the same too. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
1. 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. Microsec became aware of the problem from the new discussion at the mozilla.dev.security.policy https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/jRKOr4nvOfY 2. 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. 2019-10-02 2 precertificates were issued for internal testing purposes with short validity 2020-03-10 Microsec was informed about the faulty precertificates 2020-03-10 Microsec checked the faulty precertificates. They were already expired, so revocation was not possible. 2020-03-10 Microsec decided to immediately stop issuance of IVCP certificates until all corrective measures are in place, to prevent similar mistakes in the future 2020-03-10 Microsec decided to develop the CA software by adding further controls regarding the required fields of IVCP certificates to guarantee compliance with the certificate profile in the future 2020-03-13 Microsec deactivated all the IVCP profiles in the CA software to prevent issuance of IVCP certificates until the controls in the CA software are in place 2020-03-13 Microsec opened this incident report 3.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. Two subordinate CA were affected. They haven’t been stopped, but the issuance of IVCP certificates has been suspended by informing the RA operators about the decision and by deactivating all the IVCP certificate profiles. 4. 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. There are 2 certificates involved. They were issued on the same day which was 2019-10-02 5. 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. The problematic certificates are: https://crt.sh/?id=1947655126=zlint,ocsp https://crt.sh/?id=1947655112=zlint,ocsp 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Microsec made an investigation and could find the following: - the certification policy and practice statement contain the proper requirements regarding the content of the IVCP certificates - the problem was caused by human mistakes, the RA operators could not recognize the missing data - the CA software presently does not have automatic controls to check for the existence of the required fields in case of IVCP certificates - the certificates have been checked by cablint, but cablint did not indicate this fault - the certificates have never been published and used, so the fault has not been discovered until now 7. 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. Microsec decided the following measures to avoid having the same problem in the future. - the problematic precertificates were issued for short period and have already expired, so revocation is not necessary - suspended the issuance of the IVCP certificates with immediate effect - decided to develop the CA software to add further controls and checks in case of IVCP certificates - no deadline has been set due to the COVID-19 situation - decided to hold a training about the required IVCP profiles for the RA operators before enabling the issuance of IVCP certificates again - the issuance of IVCP certificates may be continued only after the successful testing of the upgraded CA software - Microsec will check all the issued IVCP certificates looking for similar issues - deadline 2020-03-20 - Microsec will review the CA software looking for possible similar problems - deadline 2020-03-31 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proper place for the Private Key Compromise information in CPS
2020. március 12., csütörtök 18:16:54 UTC+1 időpontban Ryan Sleevi a következőt írta: > On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < > > > So according to the RFC3647 the chapter 1.5.2 shall contain the contact > > person information who is responsible for the management of the CPS, > > but the BR requires, that the chapter 1.5.2 shall contain the information > > regarding the private key compromise. > > > > > > What is your opinion about it? Where to put this information in the CPS? > > Is the chapter 1.5.2 really the correct and expected place for it? > > > > Yes. That is what the BRs say. > > These are not mutually exclusive requirements. You can place the contact > person for the CP/CPS, as well as the contact person for compromises in > that section, and they don't have to be the same person. > > The CP/CPS makes obligations of the CA, and there needs to be a way to > determine how to contact the CA - for example, if the CP/CPS was not > adhered to, if a Subscriber certificate is found to be violating the > CP/CPS, etc. Thanks for the clarification. The RFC 3647 doesn't specify any specific place for this information, so we will move it from the section 4.9.3 to the section 1.5.2 into a subchapter in our CPS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta: > This request is for inclusion of the Microsec e-Szigno Root CA 2017 > trust anchor and to EV-enable the currently included Microsec e-Szigno > Root CA 2009 trust anchor as documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1445364 > > > Wayne performed the detailed review of the CPs, CPSs, BR Self > Assessment, and related information for inclusion of the Microsec > e-Szigno Root CA 2017 and the EV-enablement of the Microsec e-Szigno > Root CA 2009 roots that are being tracked in this bug and he had the > following comments: > Let me answer Wayne's findings in the original text > ==Meh== > * The subordinate CA certificates for this root were created in 2017 and > 2018. None of those intended for serverAuth are constrained by EKU. > Mozilla began requiring this in 2019. The subordinate CA-s already contain EKU which are intended to issue codesigning certificates and certificates for time stamping units. There is not EKU in the subordinate CA certificates which are intended to issue other types of certificates, like website authentication, digital signature, client authentication, encryption etc. These subordinate CAs were created in 2017. > * Microsec issued two certificates in 2018 with 3-year validity periods [1]. The certificates were issued for CISCO VPN servers. After receiving the information about the misissuance the certificates were revoked. > * There are roughly 20 policy documents for this hierarchy [2]. It is > quite challenging to determine which documents apply to which types of > certificates. The upcoming version of Mozilla policy states that “CAs > must provide a way to clearly determine which CP and CPS applies to each > of its root and intermediate certificates.” Microsec already offers a tool on its homepage which filters the corresponding policy documents to a specific type of certificates. The CP and CPS documents contain the policy OID values which are included in the issued certificates. The CP OID contains also the version of the CP so it is evident which version of the CP is relevant. Microsec plans to develop a tool which will help the user to find the proper CP and CPS documents for a specific certificate based on the CP OID included in the certificate. > * CP section 1.3.2 permits 3rd party RAs, but in their BR > Self-Assessment, Microsec states that “The Trust Service Provider do not > apply third parties for RA activities.” Correct, Microsec presently do not apply any third parties for RA activities as it written in the CPS. > * CPS section 4.9.5 provides a detailed explanation of the revocation > process but fails to mention the required preliminary report to the > Subscriber and the entity who filed the Certificate Problem Report. The working process contains the communication with the Subscriber and the entity who filed the Certificate Problem Report. This information will be included in the next version of the CPS. > * CPS section 4.9.1 contains a section titled “Reasons for Revoking a > Subordinate CA Certificate operated by another CA” but in their BR > Self-assessment, Microsec states that “All Subordinate CA-s under the > Microsec roots are operated by Microsec.” Microsec is open for this type of cooperation, but presently Microsec operates all the subordinate CA-s under the Microsec roots. > > ==Bad== > * I was unable to locate the description of email address validation > practices required by Mozilla policy section 2.2. Microsec published new > CPS version adding section 3.2.7 to resolve this issue. Microsec always validates the email address, typically by sending an email containing an unique URL to the email address which has to be used by the Subscriber. The actual CPS contains more detailed description about the validation method of the email addresses. > * Microsec recently issued what appears to be two certificate used for > testing that violate the BRs [3][4]. They are now expired. These were only pre-certificates which were sent to the log servers. These pre-certificates have been issued for internal test purposes only. The live certificates have never been published in our certificate store and never been used in publicly available networks. > * CCADB currently lists 9 audit letter validation failures for Microsec. The CCADB presently contains 0 failure > * The root contains subject L and organizationIdentifier fields which > are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the > subCAs also exhibit this issue. It is a general requirement that CA name shall be detailed enough to allow relatively straightforward identification of the CA. In the EU all of the companies has an official and unique company registration number, and it is a requirement to add this value into the enduser certificates in the organizationIdentifier field. It is
Proper place for the Private Key Compromise information in CPS
The CABF BR section 2.2. PUBLICATION OF INFORMATION contains the following requirement: The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. The CABF BR section 4.9.3. Procedure for Revocation Request contains the following requirement: ... The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS. According to RFC3647 chapter 6 which defines the detailed structure of the CP and CPS documents, the capter 1.5 shall contain the policy administration information as follows: 1.5 Policy administration 1.5.1 Organization administering the document 1.5.2 Contact person 1.5.3 Person determining CPS suitability for the policy 1.5.4 CPS approval procedures So according to the RFC3647 the chapter 1.5.2 shall contain the contact person information who is responsible for the management of the CPS, but the BR requires, that the chapter 1.5.2 shall contain the information regarding the private key compromise. What is your opinion about it? Where to put this information in the CPS? Is the chapter 1.5.2 really the correct and expected place for it? Presently we have this information in the section 4.9.3 in our CPS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta: > This request is for inclusion of the Microsec e-Szigno Root CA 2017 > trust anchor and to EV-enable the currently included Microsec e-Szigno > Root CA 2009 trust anchor as documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1445364 > > Thank you for opening the 3-week comment period for our inclusion request. At first let us give some background information regarding the findings of the auditor. Microsec is a qualified trust service provider in Hungary and operates under strong control and supervision. The yearly regular conformity assessment audit is made by the German TÜViT, which is one of the most stringent and thorough auditor in Europe. Based on that very deep and careful audit TÜViT issues the audit reports and the attestation letters which contain all of the findings. The findings are classified according to their weight. If the auditor finds any major non-conformity, the audit report is not issued at all. In case of minor non-conformity, the audit report is issued, and the CA may continue its services, but the CA shall report the action made to solve the findings within 3 months. In case of recommendation the weight of the problem is low, and the CA shall solve the issue till the next audit (1 year). TÜViT includes both the minor non-conformities and the recommendations in the attestation letter and the classification of the finding is not indicated in the report. There was no major issue during the Microsec audit, so TÜViT issued the certificates and the attestation letters to Microsec. Most of the findings were classified as recommendation. Microsec has applied remediations to all findings in a timely fashion and all the remediations have been accepted by TÜViT. The other reason while Microsec may have longer finding list than usual is, that Microsec offers several types of services and issues several types of certificates for different purposes (webserver authentication, electronic signature, electronic seal, encryption, authentication etc.) on different trust levels (EU qualified and not qualified). All of the certificates are issued under the same root and there are no EKU to constrain most of the subordinate CAs from the BR audit, this way all the certificate types and CA-s shall be covered by the audit, including certificates which are not in the scope of the BR. The higher number of certificate types and services may result more findings during the audit which can be unusual in a CA who offers only one service. The relatively high number of findings doesn't mean that Microsec is a bad CA, but means that TÜViT is a very thorough auditor. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Unretrievable CPS documents listed in CCADB
2019. május 3., péntek 3:53:49 UTC+2 időpontban Corey Bonnell a következőt írta: > 3209, "Microsec Ltd.", "e-Szigno Class2 CA 2017", > https://static.e-szigno.hu/docs/szsz--fok--sea--EN--v2.8.pdf, 404 > 3211, "Microsec Ltd.", "e-Szigno Class3 CA 2017", > https://static.e-szigno.hu/docs/szsz--fok--sig--EN--v2.8.pdf, 404 > 3216, "Microsec Ltd.", "e-Szigno Qualified CA 2017", > https://static.e-szigno.hu/docs/szsz--min--sig--EN--v2.8.pdf, 404 > 3217, "Microsec Ltd.", "e-Szigno Qualified Organization CA 2017", > https://static.e-szigno.hu/docs/szsz--min--sea--EN--v2.8.pdf, 404 The filenames werw incorrect in the CCADB. I have corrected and checked all url-s. Sorry for causing problems. Sándor Szőke Microsec ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
> > Hopefully that made sense? Thanks for the information, the situation is not so bad as we thougth before. If I understand well, the same intermediate CA may issue EV and OV certificates, but the proper CP OID shall be included in the TLS certificate. It menas that the service provider doesn't have to set up a new intermediate CA due to this PSD2 issue. According to the present requirements the CA may issue PSD2 certificates, but instead of the CABF EV CP OID it shall contain the CABF OV CP OID and this shall be clearly stated in the CP and CPS documents too. After having the result of the Ballot SC17 the CA shall review the new requirements and make the necessary changes if there will be any. We hope that it will be possible to issue PSD2 certificates with CABF EV CP OID by the same intermediate CA from June 2019. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
Thank you for the valuable information. I try to summarize the possibilities to issue PSD2 QWAC certificates. - If a CA issues PSD2 QWAC certificate now, it SHALL NOT include the CABF EV CPOID in it, but instead of that the certificate should contain the CABF OV CPOID value. - If the CA issues PSD2 QWAC certificate with CABF OV CPOID, the issuing CA can not be EV enabled by the browsers and it will never be EV enabled because it has already issued not EVG compliant certificate (is it correct?). - If the Ballot SC17 will be accepted it will be possible to issue PSD2 QWAC certificate with the CABF EV CPOID in it, so the issuer CA can be EV enabled AND EU Qualified at the same time. As a consequence, - if a CA issues PSD2 certificate now, it shall set up new intermediate CA-s for the issuance of EV certificates which shall be audited and asked for the EV enabled status It seeems to me that the best would be to wait for the result of the Ballot SC17 voting and not to issue PSD2 certificates now. Do you have any information about the planned date/schedule of the voting? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9
Extended Validation (EV) certificates and EU Qualified certificates for website authentication (QWAC). European Union introduced the QWAC certificates in the eIDAS Regulation in 2014. Technically the QWAC requirements are based on the CABF EVG and intended to be fully upper compatiable with the EV certificates, but ETSI has set up some further requirements, like the mandatory usage of the QC statements. ETSI TS 119 495 is a further specialization of the QWAC certificates dedicated for payment services according to the EU PSD2 Directive. The PSD2 certificates need to consist amoung others the Organization Identifier [(OrgId) – OID: 2.5.4.97] field in the Subject DN field, which contains PSD2 specific data of the Organization. Till yesterday the usage of this field was not forbidden in the EV certificates, altough as I know there has been discussion about this topic due to the different interpretation of the EVG requirements. As I know there is an ongoing discussion in the CABF about the inclusion of the OrgId field in the definitely allowed fields in the Subject DN of the EV certificates. Today morning I got an email from the CABF mailing list with the new version of the BR ver. 1.6.5 and the EVG ver. 1.6.9. The new version of the BR has already been published on the CABF web site but the new EVG version hasn't been published yet. I would like to ask the current status of this new EVG ver 1.6.9. It is very important for us to have correct information because our CA has begun to issue PSD2 certificates to financial institutions which are intended to fulfil also the EVG requirements. The new version of the EVG definitely states that only the listed fields may be used in the Subject DN and the list doesn't contain the OrgId field. We plan to fulfil both the QWAC and the EVG requirements simultaneuosly but after having the change in the EVG requirements it seems to be impossible in case of PSD2 QWAC certificates. The separation of the EV and the QWAC certificates wouldn't be good for the Customers and it would rise several issues. Do you have any idea how to solve this issue? Will the new version of the EVG ver 1.6.9 be published soon? Isn't it possible to wait with the issuance the result of the ballot regarding the inclusion of the OrgId field? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Maximal validity of the test TLS certificate issued by a private PKI system
2018. december 13., csütörtök 7:35:32 UTC+1 időpontban Dean Coclin a következőt írta: > My opinion: > The CA/B Forum Baseline Requirements only apply to certificates which chain > to publicly trusted roots. This is made clear in the preamble of the > document: > > This document describes an integrated set of technologies, protocols, > identity-proofing, lifecycle management, and auditing requirements that are > necessary (but not sufficient) for the issuance and management of > Publicly-Trusted Certificates; Certificates that are trusted by virtue of the > fact that their corresponding Root Certificate is distributed in > widely-available application software. > > The BRs do not apply to certificate issuance from non publicly trusted > hierarchies. > Dean CoclinCA/B Forum Vice-Chair > > Dear All, thank you for your answers. I confirm the followings: - Microsec operates Test hierarchies consisting of test root CA-s and test intermediate CA-s which are used exclusively for test purposes. - Microsec has never issued and will never issue any live certificates from these test systems. - the test root CAs has never been and will never be submitted for inclusion in the Mozilla root program or in any other root programs - Microsec never issues test certificates for the purpose of domain validation according to the BR 3.2.2.4.9 for life TLS certificates By keeping these rules Microsec may issue test certificates with validity exceeding the 30 days. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Maximal validity of the test TLS certificate issued by a private PKI system
2018. december 11., kedd 19:51:45 UTC+1 időpontban Doug Beattie a következőt
írta:
> Option 1 is the intended interpretation. We specified 30 days because the
> tokens used for domain validation (Random Number) need to have a useful life
> of 30 days. The 30-day usage period needed to be put into the definition of
> the Test Certificate, or into Method 3.2.2.4.9, and we selected the validity
> period as the means to convey this requirement.
>
> Note that Method 9 has identified security issues as it relates to shared IP
> addresses, so currently it's not permitted to be used (according to Google),
> even though it remains in the BRs. It should be updated or removed. Method
> 10 has similar issues which are being mitigated with ALPN approach, but no
> work has been done on Method 9 in this regard.
>
> Doug
>
>
> -Original Message-
> From: dev-security-policy On
> Behalf Of Sándor dr. Szoke via dev-security-policy
> Sent: Tuesday, December 11, 2018 1:24 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Maximal validity of the test TLS certificate issued by a private
> PKI system
>
>
> It is not absolutely clear for us how to manage the test certificates which
> were issued by a CA where there are no certificate chains to a root
> certificate subject to the Baseline Requirements (for example an independent
> test CA hierarchy).
>
> The BR wording is as follows:
>
> Test Certificate: A Certificate with a maximum validity period of 30 days
> and which: (i) includes a critical extension with the specified Test
> Certificate CABF OID (2.23.140.2.1), or (ii) is issued under a CA where
> there are no certificate paths/chains to a root certificate subject to these
> Requirements.
>
>
> I can interpret the definition in two different ways:
>
> 1. by using the listing as a parenthesis, so
>
> Test Certificate:
> A Certificate
> {with a maximum validity period of 30 days} AND
> which:
> {
> (i) includes a critical extension with the specified Test Certificate CABF
> OID (2.23.140.2.1), OR
> (ii) is issued under a CA where there are no certificate paths/chains to a
> root certificate subject to these Requirements.
> }
>
> So it means that any test certificate shall have the validity max. 30 days,
> AND we have two possibilities:
> (i) if the test certificate issued under a CA where there is a certificate
> chain to a root certificate subject to the BR, then the test certificate
> shall include the critical extension with the specified Test Certificate
> CABF OID (2.23.140.2.1)
> (ii) if the test certificate is issued under a CA where there are no
> certificate chains to a root certificate subject to the BR, then there is no
> further requirement.
>
> Question:
>
> if this interpretation is correct, then why do we have a requirement to
> limit the validity period of the test certificate for 30 days, if the issuer
> CA is out of the scope of the BR?
>
>
>
> 2. by thinking as an engineer, where the AND operation is higher level than
> the OR, the separation looks like this:
>
> Test Certificate:
> A Certificate
> {
> with a maximum validity period of 30 days AND
> which:
> (i) includes a critical extension with the specified Test Certificate CABF
> OID (2.23.140.2.1), } OR {
> (ii) is issued under a CA where there are no certificate paths/chains to a
> root certificate subject to these Requirements.
> }
>
> So it means, that
> (i) if the test certificate issued under a CA where there is a certificate
> chain to a root certificate subject to the BR, then the test certificate
> shall include the critical extension with the specified Test Certificate
> CABF OID (2.23.140.2.1) AND the validity period of the test certificate is
> maximum 30 days
> (ii) if the test certificate is issued under a CA where there are no
> certificate chains to a root certificate subject to the BR, then there is no
> any further requirement
>
> In this interpretation the wording seems to be strange, but the requirement
> seems to be more realistic and clear.
>
> Which interpretation is correct?
>
> Is it allowed to issue test TLS certificates in an independent test system
> with more than 30 days validity?
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Thank you for the detailed answer, I think that the requirement is clear for us
now.
The misunderstanding was caused by the different usage of the term 'Test
Certificate'.
The 'Test Certificate' in the BR means a certificate, which is used for domain
validation according to the 3.2.2.4.9. This case it is fully understandable to
limit the validity of the test certificate because it is in line with other
validation methods.
Microsec doesn't use this validation method and never issues this type of test
certificates.
The test certificate in our practice means a certificate
Maximal validity of the test TLS certificate issued by a private PKI system
It is not absolutely clear for us how to manage the test certificates which
were issued by a CA where there are no certificate chains to a root certificate
subject to the Baseline Requirements (for example an independent test CA
hierarchy).
The BR wording is as follows:
Test Certificate: A Certificate with a maximum validity period of 30 days and
which: (i) includes a critical
extension with the specified Test Certificate CABF OID (2.23.140.2.1), or (ii)
is issued under a CA where there
are no certificate paths/chains to a root certificate subject to these
Requirements.
I can interpret the definition in two different ways:
1. by using the listing as a parenthesis, so
Test Certificate:
A Certificate
{with a maximum validity period of 30 days}
AND
which:
{
(i) includes a critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1),
OR
(ii) is issued under a CA where there are no certificate paths/chains to a root
certificate subject to these Requirements.
}
So it means that any test certificate shall have the validity max. 30 days,
AND
we have two possibilities:
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate shall
include the critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1)
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
further requirement.
Question:
if this interpretation is correct, then why do we have a requirement to limit
the validity period of the test certificate for 30 days, if the issuer CA is
out of the scope of the BR?
2. by thinking as an engineer, where the AND operation is higher level than the
OR, the separation looks like this:
Test Certificate:
A Certificate
{
with a maximum validity period of 30 days
AND
which:
(i) includes a critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1),
}
OR
{
(ii) is issued under a CA where there are no certificate paths/chains to a root
certificate subject to these Requirements.
}
So it means, that
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate shall
include the critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1) AND the validity period of the test certificate is maximum 30
days
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
any further requirement
In this interpretation the wording seems to be strange, but the requirement
seems to be more realistic and clear.
Which interpretation is correct?
Is it allowed to issue test TLS certificates in an independent test system with
more than 30 days validity?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 6., csütörtök 23:31:42 UTC+1 időpontban Peter Gutmann a
következőt írta:
>
> So just to make sure I've got this right, implementations are needing to add
> dummy TLS EKUs to non-TLS certs in order for them to "work"? In that case why
> not add a signalling EKU or policy value, a bit like Microsoft's
> systemHealthLoophole EKU (I don't know what its official name is, 1 3 6 1 4 1
> 311 47 1 3) where the normal systemHealth key usage is meant to indicate
> compliance with a system or corporate security policy and the
> systemHealthLoophole key usage is for systems that don't comply with the
> policy but that need a systemHealth certificate anyway.
>
> In theory there's the anyExtendedKeyUsage that seems to do something like
> this:
>
>If a CA includes extended key usages to satisfy such applications,
>but does not wish to restrict usages of the key, the CA can include
>the special KeyPurposeId anyExtendedKeyUsage in addition to the
>particular key purposes required by the applications.
>
> but thats vague enough, and little-supported enough, that expecting existing
> implementations to handle it correctly out of the box seems pretty risky.
> Better to define a new EKU, "tlsCompabitility", telling the relying party that
> the TLS EKUs are present for compatibility purposes and can be ignored if it's
> a non-TLS use.
>
> Peter.
Absolutely agree.
The main reason to use EKU values is to define the targeted usage of the
certificate and the belonging keys. The EKU should be clear enough for the
software vendors to be able to select the proper certificate for their
application. The good separation and detailed requirement specification would
help the CAs to issue proper certificates.
If the present EKUs are not enough to fulfil this requirement a possible
solution can be to define further EKU values as you have proposed.
The alternative solution can be the way which was introduced by the European
regulation in the ETSI EN 319 412-5 which defines QCStatements for the
certificate profiles.
They are mandatory in the EU qualified certificates but can be used optionally
in other certificates too.
The existing proper QCStatement for the website authentication (TLS)
certificates is:
0.4.0.1862.1.6.3
id-etsi-qct-web OBJECT IDENTIFIER ::= { id-etsi-qcs-QcType 3 }
-- Certificate for website authentication as defined in Regulation (EU) No
910/2014
I have just asked the registration of this OID in the OID Repository at
oid-info.com
Sándor
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 6., csütörtök 16:12:37 UTC+1 időpontban Jakob Bohm a következőt írta: > On 06/12/2018 12:37, Sándor dr. Szőke wrote: > > 2018. december 5., szerda 20:45:25 UTC+1 időpontban Wayne Thayer a > > következőt írta: > >> .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < > >> dev-security-policy@lists.mozilla.org> wrote: > >> > >>> > >>> 1./ > >>> 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. > >>> > >>> 2018-11-29 20:15 CET > >>> Microsec received a notification email to the central email address from > >>> Alex Gaynor at Mozilla. > >>> > >>> In the email Alex Gaynor reported two misissued certificates: > >>> - > >>> https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE=cablint > >>> - > >>> https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0 > >>> > >>> He requested to > >>> a) revoke these certificates > >>> b) notify the mozilla.dev.security.policy mailing list with > >>> retrospective details as described here: > >>> https://wiki.mozilla.org/CA/Responding_To_An_Incident > >>> > >>> Thank you for posting this incident report. I have created > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1512270 to track this issue. > >> > >>> > >>> 2./ > >>> 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. > >>> > >>> > >>> 2018-11-22 around 16:15 CET > >>> Microsec issued 3 pcs CISCO VPN server certificates. > >>> See details in point 4. > >>> > >>> 2018-11-29 20:15 CET > >>> Microsec received a notification email to the central email address from > >>> Alex Gaynor as described in section 1. > >>> > >>> Why didn't Microsec detect this misissuance? > >> > > > > Microsec managed the CISCO VPN certificates separately from the TLS > > certificates. > > Microsec issued the CISCO VPN server certificates from a separate CA which > > is not used to issue TLS certificates. > > Microsec used separate policy for CISCO VPN server certificates and it was > > not clear that we shall follow the BR or not, because the BR says: > > > > "1.2. DOCUMENT NAME AND IDENTIFICATION > > This certificate policy (CP) contains the requirements for the issuance and > > management of publicly-trusted SSL certificates, as adopted by the > > CA/Browser Forum." > > > > The CISCO VPN server certificate is very similar to the TLS certificate but > > they are not the same. It was not clear for us that the CISCO VPN server > > certificates shall be treated as SSL/TLS certificate. > > > > The CISCO VPN server policy was not changed in March when we changed the > > TLS policies to reduce the lifetime of the TLS certificates to 2 years. > > The issued certificates were checked but to the old policy which allowed > > the issuance for 3 years, so the problem could not been detected. > > > > The Mozilla root program policy, section "1.1 Scope" defines precisely > which certificates are in scope for the Mozilla policy (which in turn > references the BRs for TLS server certificates). > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#11-scope > > The wording there should leave no doubt as to which of the mentioned > certicates, templates and policies need to comply. > > Each of the other root programs (Chrome, Apple, Microsoft, Oracle etc.) > have similar policy documents specifying their scope and additional > requirements. > You are right, the Mozilla Root Store Policy requirement is clear, Mozilla requires the CISCO VPN server certificate to fulfil the BR requirements. Other requirements shall be checked for specific requirements too. > > > > > >> 2018-11-29 20:44 CET > >>> Gergely Vanczák (director of the certification services) forwarded the > >>> email to dr. Sándor Szőke (deputy director of the certification services). > >>> > >>> 2018-11-30 09:27 CET > >>> Gergely Vanczák sent an email to the customer service and ordered to > >>> a) issue new certificates instead of the reported certificates with > >>> two years validity > >>> b) contact the customer regarding the replacement and agree with them > >>> the revocation date of the misissued certificates > >>> > >>> 2018-11-30 10:50 CET > >>> The customer service reported that there were three similar certificates > >>> not only two. > >>> > >>> 2018-11-30 10:55 CET > >>> Gergely Vanczák ordered to replace all three certificates. > >>> > >>> 2018-11-30 11:10 CET > >>> The new certificates has been issued with two years validity. The customer >
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 5., szerda 20:53:31 UTC+1 időpontban Gijs Kruitbosch a következőt írta: > On 05/12/2018 19:45, Wayne Thayer wrote: > > ..On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > 6./ > >> Explanation about how and why the mistakes were made or bugs introduced, > >> and how they avoided detection until now. > >> > >> Microsec manages the CISCO VPN cerver certificates separately from the TLS > >> certificates. The policy of the CISCO VPN servers was not changed when the > >> validity of the TLS certificates changed from 3 years to 2 years in March > >> 2018. > >> > > > > Why wasn't the policy for Cisco VPN servers updated? This points to a > > deeper failure to properly manage all of the profiles used to issue > > certificates that chain to publicly-trusted roots, and I would like to > > better understand what went wrong and how it will be prevented in the > > future? > > Adding some more questions on to this: does Microsec have any other > non-TLS cert policies that they "manage separately" from the TLS ones > (no matter how infrequently used), and if so how many, and have you > verified how any of those might qualify as TLS certs and thus fall under > the BR, and if so, that they abide by this validity BR? > > ~ Gijs We can issue other certificates which are not TLS but they are similar. These are: Domain Controller certificates VPN server certificates In case of these certificates we use only the following EKUs: serverAuth (1.3.6.1.5.5.7.3.1) for both clientAuth (1.3.6.1.5.5.7.3.2) only for Domain controller These are absolutely conformant to the BR requirements, so there is no such a problem with them. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 5., szerda 20:45:25 UTC+1 időpontban Wayne Thayer a következőt írta: > .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > 1./ > > 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. > > > > 2018-11-29 20:15 CET > > Microsec received a notification email to the central email address from > > Alex Gaynor at Mozilla. > > > > In the email Alex Gaynor reported two misissued certificates: > > - > > https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE=cablint > > - > > https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0 > > > > He requested to > > a) revoke these certificates > > b) notify the mozilla.dev.security.policy mailing list with > > retrospective details as described here: > > https://wiki.mozilla.org/CA/Responding_To_An_Incident > > > > Thank you for posting this incident report. I have created > https://bugzilla.mozilla.org/show_bug.cgi?id=1512270 to track this issue. > > > > > 2./ > > 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. > > > > > > 2018-11-22 around 16:15 CET > > Microsec issued 3 pcs CISCO VPN server certificates. > > See details in point 4. > > > > 2018-11-29 20:15 CET > > Microsec received a notification email to the central email address from > > Alex Gaynor as described in section 1. > > > > Why didn't Microsec detect this misissuance? > Microsec managed the CISCO VPN certificates separately from the TLS certificates. Microsec issued the CISCO VPN server certificates from a separate CA which is not used to issue TLS certificates. Microsec used separate policy for CISCO VPN server certificates and it was not clear that we shall follow the BR or not, because the BR says: "1.2. DOCUMENT NAME AND IDENTIFICATION This certificate policy (CP) contains the requirements for the issuance and management of publicly-trusted SSL certificates, as adopted by the CA/Browser Forum." The CISCO VPN server certificate is very similar to the TLS certificate but they are not the same. It was not clear for us that the CISCO VPN server certificates shall be treated as SSL/TLS certificate. The CISCO VPN server policy was not changed in March when we changed the TLS policies to reduce the lifetime of the TLS certificates to 2 years. The issued certificates were checked but to the old policy which allowed the issuance for 3 years, so the problem could not been detected. > 2018-11-29 20:44 CET > > Gergely Vanczák (director of the certification services) forwarded the > > email to dr. Sándor Szőke (deputy director of the certification services). > > > > 2018-11-30 09:27 CET > > Gergely Vanczák sent an email to the customer service and ordered to > > a) issue new certificates instead of the reported certificates with > > two years validity > > b) contact the customer regarding the replacement and agree with them > > the revocation date of the misissued certificates > > > > 2018-11-30 10:50 CET > > The customer service reported that there were three similar certificates > > not only two. > > > > 2018-11-30 10:55 CET > > Gergely Vanczák ordered to replace all three certificates. > > > > 2018-11-30 11:10 CET > > The new certificates has been issued with two years validity. The customer > > has been informed about the replacement due to misissuance. It was on > > Friday, so the customer asked a few days to be able to arrange the > > installation of the new certificates in his IT systems. > > > > 2018-11-30 20:32 CET > > dr. Sándor Szőke informed Alex Gaynor in email about the issuance of the > > new certificates and the planned revocation of the original certificates. > > > > There was a small discussion between them about the reason of the problem > > in a few emails in the following half hour. The summary of the details can > > be seen later. > > > > 2018-12-03 10:28 CET > > Monday morning the customer informed Microsec that he has successfully > > replaced all three certificates in his system. > > The misissued certificates has been revoked. > > > > > > 3./ > > 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. > > > > Our CA issued only those 3 certificates with this problem and it will not > > happen in the future again. > > > > > > 4./ > > A summary of the problematic
