SwissSign: LDAP URL still in CRL distribution point (CDP)
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: sandy.balzer, Assigned: sandy.balzer)
Details
(Whiteboard: [ca-compliance] [crl-failure])
Attachments
(1 file, 1 obsolete file)
|
496.98 KB,
text/plain
|
Details |
Preliminary Incident Report
Summary
On September 2, 2024, we received a private message through social media recommending we investigate certificates.
While the (vague) description of the issue did not lead to the discovery of mis issued certificates, further internal research discovered additional certificates, accounting for a total of 1071 miss issued certificates (2143 including pre-certificates).
This certificates were issued with the LDAP URL still in CRL distribution point (CDP) but TLS BR changed on 15.09.2023 and since then this is not allowed.
Revocation of these certificates is scheduled for September 8, 2024, 10:00 UTC latest.
Currently our investigation shows that this error only occurred on our old CA software platform, which is not in use anymore, and therefore no further mis issuance can happen and we have not stopped the issuance process from the new CA platform.
Impact
Internal investigation confirmed 1071 TLS certificates (plus 1072 pre-certificates, for a total of 2143 certificates) were affected.
See attached list
Timeline
All times are UTC.
2023-09-15
On this date the TLS BR chapter 7.1.2.11.2 was released, that requires the scheme of each GeneralName MUST be “http”.
2023-09-15,
04:44:10
First mis-issuance
2024-01-31,
07:30:05
Last mis-issuance
2024-09-02,
10:30 Info on possible mis issuance, unconfirmed but further Investigation starts
2024-09-03
10:05 Investigation confirms mis issuance
2024-09-03,
16:00 Posting of this Bugzilla
Root Cause Analysis
RCA is ongoing
Lessons Learned
What went well
RCA ongoing
What didn't go well
RCA ongoing
Where we got lucky
RCA ongoing
Action Items
| Action Item | Kind | Due Date |
|---|---|---|
| revocation of affected certificates | in progress | latest 2024-09-08 at 10:00:00 UTC |
Appendix
Details of affected certificates
See attached list
|
||
Updated•20 days ago
|
|
Assignee | |
Comment 1•19 days ago
|
||
supplying corrected list with the needed columns, nr of certificates stays same
|
||
Comment 2•19 days ago
|
||
|
|
Assignee | |
Comment 3•14 days ago
|
||
Update
All affected certificates have been revoked on time.
RCA is ongoing.
Timeline
All times are UTC.
2023-09-15
On this date the TLS BR chapter 7.1.2.11.2 was released, that requires the scheme of each GeneralName MUST be “http”.
2023-09-15,
04:44:10 First mis issuance
2024-01-31,
07:30:05 Last mis issuance
2024-09-02,
10:30 Info on possible mis issuance, unconfirmed but further Investigation starts
2024-09-03,
10:05 Investigation confirms mis issuance
2024-09-03,
16:00 Posting of this Bugzilla
2024-09-08,
08:59 revocation of affected certificates finished
2024-09-09,
14:00 updating Bugzilla on certificate revocation status
| Action Item | Kind | Due Date |
|---|---|---|
| revocation of affected certificates | mitigate | done 2024-09-08 08:59 UTC |
|
|
Assignee | |
Comment 4•12 days ago
|
||
Update
RCA completed and we are updating this incident report.
Timeline
All times are UTC.
2023-09-15
On this date the TLS BR chapter 7.1.2.11.2 was released, that requires the scheme of each GeneralName MUST be “http”.
2023-09-15,
04:44:10 First mis issuance
2024-01-31,
07:30:05 Last mis issuance
2024-09-02,
10:30 Info on possible mis issuance, unconfirmed but further Investigation starts
2024-09-03,
10:05 Investigation confirms mis issuance
2024-09-03,
16:00 Posting of this Bugzilla
2024-09-08,
08:59 revocation of affected certificates finished
2024-09-09,
14:00 updating Bugzilla on certificate revocation status
2024-09-11,
09:15 updating Bugzilla with RCA
Root Cause Analysis
In 2023, we transitioned to a new Certificate Authority (CA) software, and during the migration, our customers were onboarded in phases. At the time of a regulatory update, we were simultaneously issuing certificates through both the old and new systems. Our error occurred when we mistakenly assumed that only the new system was issuing TLS certificates, which resulted in the updated controls not being applied to the old CA software. Consequently, this led to a mis issuance from the legacy system, while the new CA software followed to the proper issuance processes.
Since we no longer issue certificates from the old CA software, this issue cannot reoccur. The transition to the new system has been fully completed, ensuring compliance with all current regulations.
Lessons Learned
What went well
N/A
What didn't go well
Phaseout of the old CA was not synchronized with regulation changes.
Where we got lucky
N/A
Action Items
| Action Item | Kind | Due Date |
|---|---|---|
| revocation of affected certificates | mitigate | done 2024-09-08 08:59 UTC |
|
|
Assignee | |
Comment 5•4 days ago
|
||
Update 2024-09-19
With the last post, all open Action Items are done.
We will monitor this Bugzilla for further questions from the community.
|
|
||
Comment 6•4 days ago
|
||
Based on the incident and root cause analysis, I believe that there should be more detail in your lessons learned and remediation action items. SwissSign should review its change management and its system maintenance processes, especially when it plans to transition between old and new systems or performs phased transitions to new systems. These steps might include running test plans on both the new and old systems and implementing monitoring and alerting related to issuance of certificates across both systems. SwissSign should take this opportunity to revisit its change management procedures and update its internal policies and procedures to reflect lessons learned when transitioning from one system to another.
Description
•