SSL.com reseller/SubCA relationship and follow-up guidance after e-Tugra incident
This case was opened by Chris Clements to understand SSL.com’s relationship with e-Tugra after issues raised in Bug 1801345. SSL.com explained that e-Tugra was a reseller customer using hosted SubCA services, not a cross-signing partner, and that SSL.com retained control over key materials, validation, and issuance. SSL.com also clarified that reseller accounts could submit certificate orders and revocation requests, but domain validation and document verification were performed by SSL.com. In response to follow-up questions, SSL.com said it had no indication that e-Tugra generated private keys for subscribers, and it described the Certificate Services account as a username/email and password used to access the SSL.com certificate portal. SSL.com committed to create reseller guidance, revise agreement documents, and produce a white paper on lessons learned and good practices for branded SubCAs. The reseller guidance was published on 2023-10-12, and the white paper was later published on 2024-05-28. The bug was resolved FIXED.
- Chris Clements opened a case about SSL.com’s reseller/SubCA handling in connection with issues from Bug 1801345.
- SSL.com stated that e-Tugra was a reseller customer using hosted SubCA services under SSL.com control.
- SSL.com said it had no indication that e-Tugra generated private keys for subscribers.
- SSL.com published its reseller security best-practices guide.
- SSL.com published the Lessons Learned White Paper for branded SubCAs.
- The bug was resolved FIXED.
- Google representative — Chris Clements opened the report and asked how SSL.com ensures continued compliance for managed SubCAs and reseller systems in light of Bug 1801345.
- SSL.com — SSL.com explained that e-Tugra was a reseller customer, that SSL.com controlled the hosted SubCA, and that validation and issuance were not delegated to the reseller.
- Google representative — Chris Clements asked follow-up questions about reseller evaluation, agreement terms, and guidance SSL.com would provide to resellers.
- SSL.com — SSL.com described its reseller model, its RVP program, and how larger customers can use branded SubCAs.
- Google representative — Chris Clements asked for more detail on Certificate Services accounts, subscriber identity, and reseller agreement terms.
- SSL.com — SSL.com said it had no indication e-Tugra generated private keys and that e-Tugra had never generated or stored private keys for SSL.com subscribers in its portal.
- SSL.com — SSL.com defined a Certificate Services Account as a username/email and password used to access the SSL.com certificate portal and said password reset codes were sent directly by SSL.com.
- Google representative — Chris Clements thanked SSL.com for the responses and asked to be notified when the planned guidance and agreement updates were completed.
- SSL.com — SSL.com said it had scheduled a meeting to decide timelines for the guidance and agreement work and would post them by June 23.
- SSL.com — SSL.com announced timelines for reseller guidance, agreement updates, and a collaborative white paper on branded SubCAs.
- Google representative — Chris Clements said the plan was reasonable and suggested the bug be moved to Resolved/Invalid while progress continued to be tracked.
- SSL.com — SSL.com said the reseller guidance article was in final review and would be publicly released by the end of the week.
- SSL.com — SSL.com said the reseller guidance article had been published and that the other initiatives were still progressing.
- SSL.com — SSL.com reported progress on the white paper, including CCADB analysis, a survey, and a draft of good practices.
- SSL.com — SSL.com invited the community to review the Lessons Learned Whitepaper draft and later corrected the publication timeline.
- SSL.com — SSL.com announced publication of the final Lessons Learned White Paper.
- Mozilla representative — Ben Wilson said he saw no need to keep the bug open and suggested closing it.