Add SI-TRUST root certificate
This case is a root inclusion request to add the “SI-TRUST Root” certificate (CN=SI-TRUST Root; O=Republika Slovenija; C=SI) to Mozilla’s root program. The request was reviewed against Mozilla Root Store Policy and the CA/B Forum Baseline Requirements, and the reviewer asked the CA to provide specific audit statements and BR-related audit statements, English translations of CP/CPS, and to resolve multiple revocation and linting errors. The CA responded with updated audit statement URLs, explanations for revocation-check findings (including CRL/OCSP behavior), and additional details about audit standards and CP/CPS translations, and it stated it would correct the remaining non-conformity related to keeping an email as an additional Subject Alternate Name. The reviewer identified show-stopper problems and denied inclusion, citing continued issuance of non-BR-compliant TLS certificates and a lack of awareness of revocation requirements, as well as intermediate certificates capable of issuing TLS certificates that were not audited according to the required audit criteria. The bug was closed by the reviewer with the decision to deny this root inclusion request, and the CA was invited to re-apply with a new root certificate and hierarchy that is fully compliant from creation. The bug resolution is listed as WONTFIX.
- Aleš Pelan opened a Mozilla CA Program bug to request inclusion of the SI-TRUST root certificate.
- Mozilla’s root program reviewer requested additional information and specific compliance items for the SI-TRUST root inclusion request.
- SI-TRUST provided responses, including updated audit statement URLs and explanations for revocation-check and linting findings.
- Mozilla’s root program reviewer denied the SI-TRUST root inclusion request due to show-stopper compliance issues and indicated the corresponding root inclusion case would be closed.
- SI-TRUST reiterated that the remaining non-conformity would be corrected and provided additional explanation about intermediate certificate auditing.
- Mozilla’s reviewer closed the denial decision, citing unresolved BR commitment concerns and intermediate certificate constraint enforcement issues.
- Community commenter — Kathleen Wilson said the CA update backlog would delay review and that she would add another comment after performing the review.
- Community commenter — Kathleen Wilson provided a verified-information link and requested specific clarifications, including audit statements, BR audit statement, English CP/CPS translations, and resolution of revocation and lint errors.
- Gov representative — Aleš Pelan provided explanations and updated audit statement URLs, addressed revocation-check items, and described how certain lint findings were interpreted.
- Community commenter — Kathleen Wilson stated there were two show-stopper problems (non-BR-compliant TLS issuance with revocation-awareness concerns, and intermediate certificates not audited to required criteria) and denied inclusion, closing the corresponding root inclusion case and inviting re-application with a compliant new hierarchy.
- Gov representative — Aleš Pelan responded that the remaining non-conformity (email in additional SAN) would be corrected and discussed why certain intermediate certs were not audited to ETSI EN 319 411-2 QCP-w.
- Community commenter — Kathleen Wilson reiterated the denial, stating the CP/CPS lacked a required BR commitment to comply and explaining why intermediate-certificate intended usage cannot replace technical constraints like EKU.