SwissSign: Incorrect stateOrProvinceName value (“Some-State”) in one leaf certificate
This case concerns a SwissSign incident where one leaf certificate was misissued with an incorrect subject stateOrProvinceName value of “Some-State”. The issue was triggered by a report posted in mozilla.dev.security.policy that SwissSign said indicated the field was not validated, and SwissSign opened an incident report bug on Bugzilla. SwissSign stated it became aware on May 13, 2019, confirmed the issue, checked for additional affected certificates (none found), and informed responsible management and its auditors. SwissSign reported that the affected certificate (issued Feb 26, 2018) was revoked within 24 hours after recognition, and it provided certificate details and an explanation that the CSR used OpenSSL with the default value for stateOrProvinceName and that the mistake was due to human error. SwissSign said it improved its RAO checklists after mid-2018 to include clearer address/stateOrProvinceName checks and conducted additional awareness training, with head RAO ensuring correct execution. The thread indicates remediation was completed and Mozilla closed the incident as adequately remediated, with the bug marked RESOLVED and resolution FIXED.
- A leaf certificate was issued with an incorrect subject stateOrProvinceName value of “Some-State”.
- SwissSign became aware of the issue via a posting in mozilla.dev.security.policy and began its internal incident management process.
- SwissSign revoked the affected certificate and published the incident report on Bugzilla.
- SwissSign reported that remediation was completed and asked to close the incident.
- Fastly representative — Requested an incident report after noting a SwissSign certificate with stateOrProvinceName “Some-State” was published at misissued.com/batch/53 and cited the relevant Baseline Requirements text.
- SwissSign AG — Submitted an incident report describing how SwissSign became aware, its timeline, confirmation that only one certificate was affected, revocation, the human-error explanation, and remediation steps (checklist improvements and training).
- Community commenter — Asked follow-up questions about specific checklist changes, training scope and sufficiency, possible technical controls, and what caused the human error.
- SwissSign AG — Answered the follow-up questions, describing checklist improvements after mid-2018, training approach, stating there were no technical controls (manual controls used), and discussing the human-error cause.
- SwissSign AG — Reported remediation was completed and asked to close the incident, pointing to a new related Bugzilla topic for the last item.
- Community commenter — Commented that the issue had not re-appeared and that non-technical controls appeared to be functioning correctly, noting technical controls could add assurance but were not required in this context.
- Fastly representative — Agreed the issue was adequately remediated and stated Mozilla was not requiring technical controls at this time.