Hi Root Store team and Community members,
We hope this comment finds you well.
We identified that there are some comments which are unattended and we wanted to share the feedback for them.
Comment 43, @Ryan please see feedback on your queries:
[e-Tugra]: CAs from 1 to 6 are sub-CAs managed by SSL.com for e-Tugra handling the certificate life cycle and especially domain validation emails are directly handled by SSL.com to subscribers directly. CAs from 7 to 12 are sub-CAs of e-Tugra Root hierarchies and are not engaged for certificate life cycle activities because these are not fully included in all root programs. For this incident, there is no CA integrated with the exposed application to impact the certificate issuance. As explained above, the template shown in the screenshot was not used for the domain validation process.
As mentioned in comment 12, portal allows the user to reissue certificates for non-expired domains after performing the authentication but the exploited application cannot be helpful to gain privileged access to user credentials because it records the expired codes etc. as archived data.
An authorized user can request for a new domain certificate. The application is sent to SSL.com as explained above, all the domain validation checks are performed directly by SSL.com. There is no involvement from e-Tugra in the domain validation steps.
An authorized user can request to re-issue a certificate for already validated domain information according to CA/B guidelines
An authorized user can request to revoke an active certificate. Once submitted, an operator receives the revocation request and approves/declines the request for certificate revocation.
Comment 44, @Ryan please see our feedback:
[e-Tugra]: We acknowledge that this incident marked our initial encounter, and we accept responsibility for our administrative performance here, which contributed to the identified shortcomings.
We acknowledge that the language barrier has caused confusion, leading to imprecise expression of our statements.
In subsequent comments, we made a concerted effort to provide additional details. Both exploited application and CA systems do not interact for the certificate life cycle operations and have their own boundary while the CA system pushes the logs/notifications after the execution of the operations using a secure flow channel to non-SSL system for archival and business decisions.
We have thoroughly investigated and attempted to address the root cause, documenting it in the incident report based on our understanding. We genuinely value your input and would greatly appreciate it if you could identify any specific points that would assist us in aligning our understanding with yours.
@xiaohui.lam @Ian, we have explained above that domain validation steps are directly performed by SSL.com for DV certificates. E-Tugra is not involved in this process. We have tried to address your points in Ryan’s queries also. In addition, we have already requested SSL.com to give information about it to the community.
@Ben, Regarding your comments numbered 49, 50, 51 & 52. We wish to highlight that we have previously provided feedback on these points in our previous comments. However, we are reiterating our feedback to ensure that none of these comments are overlooked. Our intention is to ensure that all concerns and suggestions receive the necessary attention and consideration they deserve. Please see our feedback:
· List of documents shown in the first image are related to subscribers and resellers. Those documents are not related to domain validation or domain certificates. Ian downloaded documents that were not related to SSL certificates directly.
· The code shown in the image cannot be used as it is valid for 3 minutes only and shown in the application as archived items.
· The third image displays the different operations logs and notifications e.g.; user activity logs, application requests logs etc. These are not related to SSL or certificate life cycle processes.
· The fourth image is the email template. This email template is not being used in sending email to subscribers in the domain validation process as SSL.com directly communicates with subscribers for domain validation.
In summary, it is important to note that the application exploited in this incident was not directly associated with the certificate life cycle process. Its primary purpose revolved around recording user activities, reseller activities, email notifications, and similar logging information. Rest assured, no certificates were affected by this incident, whether they belonged to e-Tugra CAs or SSL.com managed sub-CAs.
We promptly reported the incident through a Bugzilla bug, providing a comprehensive incident report. While we made concerted efforts to address community comments and provide feedback, we acknowledge that there were shortcomings in the execution of our administrative responsibilities in this thread. Unfortunately, this resulted in frustration and non-compliance with root store policies, which was highly regrettable and not in line with our intentions.
To ensure confidentiality, we have provided the requested details to the best of our understanding. Additionally, we have gathered substantial evidence of this incident for our auditors in the upcoming audit. They will thoroughly analyze the evidence and add relevant information into the audit report, reflecting the details surrounding this incident.
We remain committed to closely work and collaborate with all root stores, community members and are pleased to provide the requested information while ensuring confidentiality measures are in place.
We firmly believe that this comment will serve as a valuable contribution for Bugzilla admins, helping them in effectively resolving and closing this bug.