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.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
