1625767 - Microsec: Audit Letter Validation Failures

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Dr Sandor Szoke posted the following incident report to the mozilla.dev.security.policy mailing list on 24-March 2020:

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 the SHA-256 value. The affected certificates were flagged with ALV failures.
    Microsec contacted its auditor about this problem. As a result, the new audit letters issued near the end of 2019 did not have this problem, the ALV tool could parse all certificate fingerprints, so the ALV failures disappeared.
   

2.  Subordinate CA certificates without audit letters (4 out of 9)
    The earlier versions of the above mentioned doppelganger subordinate CA certificates were not included in the audit letters (always the latest certificate fingerpring was included), so these (4 cases) were flagged as ALV failures.
    Microsec contacted Mozilla again in this matter, referring to the earlier approval. Mozilla answered that the approval granted 3 years before could not remain valid indefinitely, so considering the recent changes in the automated checks, it was required that each valid subordinate CA certificate should be covered in an audit letter.
    Microsec had two options:
    - revoke the earlier versions of the affected (doppelganger) subordinate CA certificates, or
    - include them in the scope of the audit and have them appear in the audit letter.
    As 10 years have elapsed since the deprecation of those certificates and Microsec did not want to have them added to the audit letters, Microsec decided to revoke the certificates in question.
   

2019-11-29
All earlier versions of the subordinate CA certificates were revoked.
The revocation caused errors in the systems of some clients, but all of those problems were successfully solved by changing the software configuration.
Microsec registered the revocations in the CCADB system, and the corresponding ALV failures disappeared.

3.  Doppelganger root certificate
    CCADB contains one of the earlier versions of the "Microsec e-Szigno Root CA 2009" certificate, which is now deprecated and not used. Since root certificates cannot be revoked, following a discussion with Mozilla experts Microsec requested the auditor to include both certificates of the root CA in the audit letter.
    The latest audit attestation contains both root CA certificates, so the corresponding ALV failures disappeared.
   
    As a result, the CCADB currently displays no ALV failures.
   

2020-03-17
In order to clarify the situation, Microsec made an assessment of all affected certificates.

    As a result of the in-depth investigation, Microsec has determined that 7 of the subordinate certificates, which have been issued from the "Microsec e-Szigno Root CA 2009" root and have already been revoked, are not in the current CCADB registry.
    It was also found that the unused version of the "Microsec e-Szigno Root CA 2009" Root Certificate of 2009-03-06 is not in the CCADB registry either.

202-03-24
Microsec uploaded the missing subordinate certificates to the CCADB registry.

    Microsec uploaded also the "Microsec e-Szigno Root CA 2009" Root Certificate to the CCADB registry as a doppelganger subordinate certificate.
    This will result in an ALV failure (reporting lack of certification) as the root certificate cannot be revoked and it is not included in the current audit attestation letters.
    To resolve this warning, Microsec shall request a new audit report from the auditor that includes this third root certificate too.
    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.

Comment 1

[Wayne Thayer]

Please provide a full incident report as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report.

Please update this bug when the new audit report referenced above has been uploaded to the CCADB and ALV has passed.

Comment 2

[dr. Sándor SZŐKE]

We will provide a full incident report soon on https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/QqYm4BhFMHs as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report.

We will update this bug also when we will have the new audit report and it has been uploaded to the CCADB with ALV passed status.

Comment 3

[Ben Wilson]

Hi Sándor,
Have you had a chance yet to review the ALV results for your CAs?
Thanks,
Ben

Comment 4

[dr. Sándor SZŐKE]

Dear Ben,

we still have one open ALV issue in the CCADB regarding the doppelganger root CA certificate, which shall be included into the Attestation Letter.

I have already approved the draft Attestation Letter, and now we are waiting for the issuance of the new Attestation Letter.

I will contact our auditor again and ask them about the planned date of the issuance of the missing document.

Comment 5

[dr. Sándor SZŐKE]

I got the information from our auditor that they are working on the finalization of our new attestation letter.
We should receive the new documents beginning of next week at latest.

Comment 6

[dr. Sándor SZŐKE]

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 from today:
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.

Comment 7

[dr. Sándor SZŐKE]

The information has been updated.

There is no Microsec Audit Letter Validation Failure in CCADB.

Comment 8

[Ben Wilson]

In Comment 1 and Comment 2, you and Wayne agreed that you would provide an incident report, which I'm waiting on in order to close this bug.

Comment 9

[dr. Sándor SZŐKE]

The incident report can be found at the following link:

https://groups.google.com/d/msg/mozilla.dev.security.policy/QqYm4BhFMHs/d87IKLttAwAJ

Comment 10

[Ben Wilson]

I am going to close this on or after 5-Aug-2020 unless other comments or issues are raised.