Sectigo acquires Entrust business

[Jeremy Rowley]

News of the acquisition is here: 

https://www.entrust.com/company/newsroom/entrust-sells-public-certificate-business-to-sectigo

I am a bit disappointed that there was not a public announcement on the forum as was requested with other transactions. Will Sectigo be sharing the details of the acquisition? Specific questions that were asked during the Symantec acquisition included:

1) Will Entrust leadership be involved in Sectigo? This was a no-go during the Symantec acquisition and was specifically forbidden by Mozilla.

2) Was notice given to Mozilla? If so, why wasn't this shared with the public? Sectigo isn't publicly traded so I'm surprised the notification was missed. Granted this is not a written requirement - just notice to Mozilla - but given Mozilla's dedication to public discussion, I am very interested to know why this wasn't shared. 

3) What are the plans for the platform? Note that during the Symantec transition, DigiCert was required to file a bug and track migration of customers off the legacy Symantec roots and systems (including the front-ends). Where is this plan disclosed? 

4) Will Sectigo be filing a bug to provide community updates? This was required during the Symantec acquisition to keep the public informed on progress and issues found with the Symantec environment.  If Entrust was distrusted partly because of how archaic its systems are, then there should be equal concern about Sectigo operating those systems without proper public communication.

Glad to see Sectigo acquired the business, but I'm concerned that the processes Mozilla required of DigiCert during Symantec are not being addressed here. 

[Wayne]

I completely agree Jeremy, the lack of information in all the current press releases by both parties is disheartening. We have statements to customers and partners on the contractual terms being the same for the time being, but nothing on the leadership changes. The plan for the platform going forward is most concerning as its the most immediately impactful and each root store will have to make considerations for potential fresh inclusion of roots.

We do have precedence for this historically, and it would be wise for any CA buying or selling to disclose in advance for public interest. The oversights in place aren't enough if a silent leadership change occurs that changes who controls the roots, and there is no clear intent for public disclosure. While I don't see Mozilla placing any specific policy in place regarding this, I believe it reflects on the transparency of each organization in question and their commitment to the WebPKI as an open and transparent process.

I sincerely hope the drafts are already prepared and both Entrust and Sectigo's PR departments got ahead of the game on announcing the acquisition. What would a timely response to informing relevant parties of this entail?

- Wayne

[Nick France]

Jeremy, Wayne:
For clarity, the acquisition was of customers and customer contracts. Sectigo is not taking over or transferring any systems, infrastructure or staff from Entrust as part of this deal.
This is different to the transition of Symantec back in 2017/2018.
The recently-announced reseller integration will continue (which was discussed in advance with relevant parties) with customers obtaining certificates via Entrust systems utilising that integration.
The distrusted roots remain with Entrust with no current plans to move them - should that change, notice will be given as required to trust-store operators and browsers.
 
All certificates will be issued from Sectigo CA systems, using Sectigo roots and issuing CAs, Sectigo policies and practices.

Tim or I are happy to answer any further questions on-list or privately via email if required (nick@ and tim.callan@).

Thanks,
Nick

[Jeremy Rowley]

Thanks Nick - that makes sense. One question though - who is maintaining the front end systems? Will Entrust still be supporting those with Sectigo issuing? If they fall apart, will Sectigo be maintaining them or Entrust?

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6af59737-bc8f-4484-a406-537a1009987bn%40mozilla.org.

[Bruce Morton]

While we are developing the future customer experience plans with Sectigo and until issuance of publicly trusted certificates has transitioned to Sectigo, Entrust is committed to continuing to all operations in accordance with the applicable requirements. 

[Jeremy Rowley]

Thank you for the carefully crafted corporate message that didn't actually answer the question. I think MDSP deserves more details than being presented. For example, in the Symantec acquisition, none of the front-ends managed compliance. Yet, DigiCert was required to submit a plan to deprecate those to ensure simplicity and remove potential pathways through the system even though Symantec's systems were not doing the validation or issuance. Can you provide some details here about the proposed structure and integration? This seems appropriate given past acquisitions.  

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/140feddb-9f09-4376-8ddd-a04015bc3007n%40mozilla.org.

[Nick France]

Thanks Jeremy,

 

Again, to be clear - this is a very different situation than Symantec. As stated before, we are not acquiring staff, systems, infrastructure, or the roots.

Entrust roots have already been distrusted - unlike with Symantec when there had to be a transition plan for that distrust.

 

Entrust are operating today as a reseller, of both Sectigo and SSL.com. This is no different to how we and other CAs already operate resellers today.

Specific plans on any transition of customers from the Entrust platform to Sectigo is still being discussed and developed.

 

 

Nick

[Dimitris Zacharopoulos]

Hi Nick,

I guess the concern is about the management of the NSS-included Entrust Roots, since they are distrusted in a "NOT_AFTER" fashion while there are other Browsers and Certificate Consumers that do not support that type of distrust.

In any case, I believe Bruce Morton's response was clear that Entrust will continue to manage their existing Roots according to the applicable requirements, and IMHO that addresses these concerns.

On that end, perhaps the public announcement could be a bit more clear about which parts of the "Public Certificate Business" are moving to SECTIGO and which parts remain to ENTRUST (and for how long).


Dimitris.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/eb2b6a5e-6dac-4e7f-ac02-682267e9912bn%40mozilla.org.

[Phillip Hallam-Baker]

One aspect of this discussion that is plain weird is the notion that a group that holds public discussion on a subject can get any sort of advance notice.

Entrust is a public company with stock traded on US exchanges that must therefore comply with US disclosure requirements. Entrust execs would be going to jail if they allowed public announcements that didn't go through the required processes.

So perhaps a little less of the indignation about not being notified and complaining about corporate speak?

[Mike Shaver]

Mozilla at least used to routinely get advanced notice of things like coordinated-embargo security issues, including those that affected publicly-traded entities, and managed to keep them appropriately private. Mozilla could be notified without it being via the MDSP channel, and in fact I believe that's exactly what happened with the Symantec events. I don't believe that it happened in this case, presumably because neither Entrust nor Sectigo believed that there was a material change to the relevant root operations of either, but rather simply a bulk migration of customers. (I agree with that position, for what little that's worth.)

Mike

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwgzJL%3DF5QXpwynoZackdSiCiG5iiRRprg%2BwzMpvY5BrQg%40mail.gmail.com.

[Arabella Barks]

I think the information disclosed by Sectigo in this acquisition case is too unclear.
The main concern is how Sectigo intends to deal with the brand and assets of Entrust.
For example:

1. How will the Entrust Roots be used in the future? (As the Sectigo employee has already stated in the previous discussion that the acquisition does not include the Roots, so this issue is resolved.)

2. Will the Entrust subCAs under SSL.com continue to be used after the acquisition? If not, what is the retirement plan? And what is the retirement plan for the CAA flags of entrust.net / affirmtrust.com authorized for use by SSL.com?

3. Will the Entrust subCAs under Sectigo continue to be used after the acquisition? If not, what is the retirement plan?

[Nick France]

Hi Arabella,

Sectigo has nothing to do with the brand or assets of Entrust. They remain with Entrust and were not part of this acquisition, as previously stated.

For 2 and 3 - those timelines are being discussed between Sectigo, SSL.com and our customers.

The Entrust-branded CAs operated by SSL.com and Sectigo are fully managed and controlled by the respective CAs and not by Entrust.

Sectigo also have permission to use Entrust domains for CAA, and this was added to our CPS last year. Sectigo have no current timeline to retire this.

Thanks,

Nick

[Bastian Blank]

On Mon, Feb 03, 2025 at 12:17:27AM -0800, 'Nick France' via dev-secur...@mozilla.org wrote:
> Sectigo has nothing to do with the brand or assets of Entrust. They remain
> with Entrust and were not part of this acquisition, as previously stated.

However you clearly re-use some of the systems. From the Sectigo page,
it is clear that the Entrust management frontend is still in use:

| Once the integration is in place later this year, you will be able to
| order Sectigo certificates directly from Entrust, and Sectigo will issue
| the certificates directly to you through Entrust Certificate Services
| (ECS).

> Sectigo also have permission to use Entrust domains for CAA, and this was
> added to our CPS last year. Sectigo have no current timeline to retire this.

Actually the section about CAA was completely removed from the latest
version (1.3.5). Could you please point us to it?

https://www.sectigo.com/uploads/files/Sectigo_WebPKI_CP_v1_3_5.pdf

The previsous version does not list "entrust.com" as valid.

https://www.sectigo.com/uploads/files/Sectigo_WebPKI_CP_v1_3_4.pdf

Bastian

--
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, "The Omega Glory", stardate unknown

[Nick France]

Hi Bastian,

Again - you're talking about Entrust systems, not Sectigo. We did not acquire any Entrust systems - Entrust still own and operate those.

As previously stated, Entrust are operating as a reseller of both Sectigo and SSL.com today, via their own platforms.

Regarding CAA - I specifically mentioned our CPS. The latest version can be found on sectigo.com/legal (as 'TLS Certification Practice Statement', currently version 6.0.1), and you'll need to look at section 4.2.4.

Thanks,

Nick

[Mike Shaver]

On Mon, Feb 3, 2025 at 10:12 AM Bastian Blank <bbl...@thinkmo.de> wrote:

On Mon, Feb 03, 2025 at 12:17:27AM -0800, 'Nick France' via dev-secur...@mozilla.org wrote:
> Sectigo has nothing to do with the brand or assets of Entrust. They remain
> with Entrust and were not part of this acquisition, as previously stated.

However you clearly re-use some of the systems.  From the Sectigo page,
it is clear that the Entrust management frontend is still in use:

| Once the integration is in place later this year, you will be able to
| order Sectigo certificates directly from Entrust, and Sectigo will issue
| the certificates directly to you through Entrust Certificate Services
| (ECS).

Isn't this just a basic certificate reseller setup, like Entrust had with SSL.com already?

"Use our system to order their certs" is generally how it works because "our web front end" is the only real value that can be added by a reseller (other than rolodex, I suppose).

I entirely approve of scrutiny being applied to Entrust's relationship with certificate issuance, but I think this matter seems pretty clearly settled at this point until there is any actual evidence of misuse or imminent risk.

Mike

[Peter Bowen]

+1; this seems no different than what companies like NameCheap
(https://www.namecheap.com/security/ssl-certificates/), Gandi
(https://www.gandi.net/en-US/security), and SSLs.com
(https://www.ssls.com/) offer. They are not CAs, they do not operate
HSMs for the WebPKI, they do not control issuance of WebPKI
certificates. Historically, there are multiple prior cases of a
company that formerly operated a publicly trusted CA switching to
become a reseller of certificates from other publicly trusted CAs.
This seems to just be another case of that model.

Thanks,
Peter

[Arabella Barks]

Hello, Nick,

As I understand it, the Sectigo's acquisition deal of Entrust does not include Entrust Root's PKI. However, I noticed that on https://crt.sh/?Identity=%25&iCAID=1671, Entrust's PKI hierarchy continues to issue certificates.

Could you please clarify whether these requests are issued by Entrust Company or Sectigo company? And what the root caused the issuance?

Thank you.
Ara Barks

[Nick France]

Hi Arabella,

"Sectigo's acquisition deal of Entrust does not include Entrust Root's PKI" - that is correct. No keys or certificates were transferred as part of the agreement.

Entrust may continue to issue certificates, and while the roots are widely-distrusted, there's no reason they cannot continue to do this as they see fit.

I will defer to Entrust if they wish to add comment here.

Thanks,

Nick

[Jeffrey Walton]

On Fri, Feb 7, 2025 at 6:42 AM 'Nick France' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:
>

> "Sectigo's acquisition deal of Entrust does not include Entrust Root's PKI" - that is correct. No keys or certificates were transferred as part of the agreement.
>
> Entrust may continue to issue certificates, and while the roots are widely-distrusted, there's no reason they cannot continue to do this as they see fit.
> I will defer to Entrust if they wish to add comment here.

I don't think Entrust roots are widely distrusted. The DistrustAfter
only works in some places, like browsers. Other projects and tooling,
like Alpine and cURL, gave up trying to make it work. See:

* Alpine: <https://gitlab.alpinelinux.org/alpine/ca-certificates/-/issues/6>
* curl: <https://curl.se/mail/lib-2025-01/0019.html>,
<https://github.com/curl/curl/pull/15552>

I think the CA/BF handled this poorly when it used DistrustAfter to
address the problem. The CA/BF introduced non-standard extensions to
something that it claims is a subset or profile of RFC 5280. And I
have not seen work on getting it standardized. (Corrections, please).

Jeff

[Matthew McPherrin]

On Fri, Feb 7, 2025 at 8:44 AM Jeffrey Walton <nolo...@gmail.com> wrote:

I think the CA/BF handled this poorly when it used DistrustAfter to
address the problem. The CA/BF introduced non-standard extensions to
something that it claims is a subset or profile of RFC 5280. And I
have not seen work on getting it standardized. (Corrections, please).

I have no particular comment about how this distrust incident was handled, but do have some technical notes here. And a disclaimer that these are my own opinions, not that of my employer.

The "distrust after" dates are specific to root programs like Mozilla, and not a CA/B Forum thing at all. There's no "non-standard extensions" ... because there's no extensions at all. It is not represented in X509, or in any format beyond Mozilla's internal ones.

The fact that Linux distributions and other software like Alpine and curl are "copying Mozilla's homework" and not getting the full metadata is a problem, but I don't think the fault lies at Mozilla's feet here.

Linux is a bit unique in that it doesn't really have a "platform verifier" in the way other OSes that ship trust stores do, so it's difficult to enforce changes in code. I think there's a series of other related problems (like sharing OCSP/CRL caches, for example) that also happen as a result of this situation. I do think Linux likely needs some sort of platform verifier, but given the state of the current software world, I'm not sure how we get from here to there. Perhaps a new systemd component, or other IPC service that can act as a validator, or just perhaps a standardized root store format with more metadata than a bundle of PEM gets you.

[Mike Shaver]

On Fri, Feb 7, 2025 at 10:29 AM 'Matthew McPherrin' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

The "distrust after" dates are specific to root programs like Mozilla, and not a CA/B Forum thing at all. There's no "non-standard extensions" ... because there's no extensions at all. It is not represented in X509, or in any format beyond Mozilla's internal ones.

The fact that Linux distributions and other software like Alpine and curl are "copying Mozilla's homework" and not getting the full metadata is a problem, but I don't think the fault lies at Mozilla's feet here.

Hear, hear. These distributions are free to maintain their own CA lists if they would like, or copy Chrome/Microsoft/Apple/Cisco's homework instead. Or they can do the work to actually process the NSS internal root store in a way that's semantically-consistent with Firefox's use of it.

Mike

[Ben Wilson]

All,

I'll start looking at when we will remove the websites trust bit, the email trust bit, and/or the Entrust roots from certdata.txt.

Thanks,

Ben

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsSMVs7NuOMWMFydF_68Nrb6iYhOTWZLceGZn9ubEXpCQ%40mail.gmail.com.

[Jeremy Rowley]

I actually think the transparent and reusable root store is a huge value that Mozilla provides. Others are free to use it and can rely on Mozilla to do the due diligence on who they add/remove from the root store. As long as their values, align with Mozilla, they get a transparent and robust process for evaluating roots and root operators. It's great!

--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/gLhzSzo-XFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsSMVs7NuOMWMFydF_68Nrb6iYhOTWZLceGZn9ubEXpCQ%40mail.gmail.com.

[Rob Stradling]

> The fact that Linux distributions and other software like Alpine and curl are "copying Mozilla's homework" and not getting the full metadata is a problem, but I don't think the fault lies at Mozilla's feet here.

It's also worth noting that Mozilla has gone out of its way to try to address this problem:

https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla's_set_of_CA_certificates?

---

From: 'Matthew McPherrin' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: 07 February 2025 15:28
To: nolo...@gmail.com <nolo...@gmail.com>
Cc: Nick France <ni...@sectigo.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Sectigo acquires Entrust business

 

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKh5S0YmSTwEpZ2Fm%2BkGErkpsnF5TrwRwjeH-PDiApY%2Bg-1cjA%40mail.gmail.com.