Without more details about your specific situation, it’s difficult to address your concern effectively. Please reach out to me personally, and I will do my best to assist you. For others reading this, I want to clarify that this post does not reflect our renewal policies. We are executing a plan to address Chrome's and now Mozilla's announced changes and working closely with our customers to ensure they all have uninterrupted issuance, support, and service of publicly trusted TLS certificates. For more information on these plans, please visit: https://www.entrust.com/tls-certificate-information-center.
On Tuesday, July 30, 2024 at 10:14:17 AM UTC-4 Jonathan Doe wrote: > (Posting anonymously to protect my employer). > > Entrust appear to be threatening existing customers with revocation of > still-valid certs if contracts are not renewed. > > I have seen with our own discussions with Entrust as well as those from > others in my network. We were told we could not get a short-term extension > to the Entrust contract while these issues are ongoing, and if we did not > renew the contract, all active certificates would be revoked. > > I know this isn't a direct violation of any guideline, but it has been > discussed before and was frowned upon by the Chrome team ( > https://www.mail-archive.com/[email protected]/msg13151.html > <https://www.mail-archive.com/[email protected]/msg13151.html> > ). > I cannot imagine Mozilla, Microsoft or Apple would support this. > > Can Entrust comment on why they are holding customers hostage? Especially > with recent webinars telling customers to replace/renew in advance of the > distrust, but now threatening revocation if contracts are not renewed? > > On Thursday, July 25, 2024 at 3:04:43 PM UTC+1 Claves Nostrum wrote: > >> How would that work from an auditing perspective? >> >> Given the minimally accepted period-under-audit for period-over-time >> audits is 3 months it sounds overly ambitious to get all the systemic >> issues that lead to the distrust remediated, execute all controls in an >> orderly fashion, and obtain an unqualified WebTrust for RA period-over-time >> report prior to October 31st 2024. Or are you suggesting that SSL.COM >> would be willing to accept you as an External RA without being able to >> present an unqualified WebTrust for RA period-over-time report? >> >> Would be good to get transparency on the plans and their feasibility, and >> also the acceptance criteria from SSL.COM for Entrust to be an external >> RA. >> >> Op do 25 jul 2024 om 00:10 schreef 'Bruce Morton' via >> [email protected] <[email protected]>: >> >>> Claves, thank you for the question, as I re-read the blog post it seems >>> we could have been clearer. >>> >>> >>> - We are not yet providing certificates issued from SSL.com. Our >>> intent was to announce the partnership with SSL.com and communicate our >>> plan for how we will provide continuity to our customers for public TLS >>> certificates after October 31. Our next step is to do the work necessary >>> to >>> have this capability in place before that time. >>> - Our plan is to serve as an external RA, with SSL.com as the CA, as >>> provided for in the Baseline Requirements, section 1.3.2. Beforehand, we >>> will complete the required reviews and approval from SSL.com, as >>> outlined >>> in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we >>> will undergo a WebTrust Audit for RAs. >>> >>> We are committed to operating under the CA/Browser Forum Baseline >>> Requirements, and completing the improvement plans we’ve communicated to >>> this community. We hope this demonstrates that we are approaching this >>> arrangement with due rigor, and our commitment to improve our compliance >>> and incident handling. >>> >>> On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote: >>> >>> It appears that Entrust is now providing its customers with certificates >>> from SSL.COM: >>> https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/ >>> Given the type of customers that Entrust was serving it must imply they >>> are at least acting as a Delegated Third Party or External RA for those >>> certificates >>> The blogpost also seems to suggest they are acting as an External RA for >>> SSL.COM >>> Could Entrust and SSL.COM provide insights in which construct they are >>> working together (reseller, Delegated Third Party or External RA)? >>> If it is an External RA how did SSL.COM evaluate and accept the risk >>> given the numerous (vetting) compliance incidents Entrust has recently had >>> and their failure to timely replace the certificates? >>> >>> Op do 4 jul 2024 om 18:39 schreef Watson Ladd <[email protected]>: >>> >>> >>> >>> On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via >>> [email protected] <[email protected]> wrote: >>> >>> >>> >>> On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote: >>> >>> While you’re addressing comments, I’d appreciate an answer to my >>> question here: what was the motivation behind redacting that portion of the >>> email to customers, if not to conceal information related to redaction >>> procedures? >>> >>> You want to make it clear that you aren’t concealing anything, but you >>> haven’t given us any reason to believe otherwise. >>> >>> Mike >>> >>> >>> The letter was shared as an example of what was sent from us directly to >>> a subscriber. The question posed was “what was the contents of the email >>> sent to providers asking for revocation to begin with?”. We posted the >>> communication’s contents in the thread and removed the step-by-step >>> instructions and the contact information for support as we didn’t feel that >>> was the request’s focus. It was not redacted to conceal the specific >>> instructions provided and the full letter was shared in its entirety >>> quickly after it was requested. >>> >>> >>> The fact that you literally wrote that you "removed the step by step >>> instructions" than say it wasn't "redacted to conceal the instructions" you >>> removed literally 13 words later demonstrates an astonishing predilection >>> for casuistry. >>> >>> The only interpretation I can come up with is that these words were >>> removed accidentally, showing a profound lack of care in communications >>> with DSP. >>> >>> Sincerely, >>> Watson Ladd >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >>> To view this discussion on the web visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0cnV%2B3b3XM8Xi8r8b5w%2BP3oQ%2BAer_vt8HmZdLyw7QMV5Pw%40mail.gmail.com >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0cnV%2B3b3XM8Xi8r8b5w%2BP3oQ%2BAer_vt8HmZdLyw7QMV5Pw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8b89eed0-98f9-4aff-9133-443d048aea29n%40mozilla.org >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8b89eed0-98f9-4aff-9133-443d048aea29n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/471e40fe-85b0-4306-85a4-7916695a2f66n%40mozilla.org.
