RE: Symantec migration update
Yeah - these types of weird continuity requirements are all over the place and the reason the consolidation has taken this long. A lot of the effort has been trying to figure out how to replace things tied to old hardware with updated systems, essentially rebuilding things (like the timestamp service) so it can scale better and use more current technology. -Original Message- From: dev-security-policy On Behalf Of Jakob Bohm via dev-security-policy Sent: Thursday, August 29, 2019 8:26 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Symantec migration update Note that while not used by Mozilla, the Time Stamping Authority services formerly owned by Symantec have some unique business continuity requirements: 1. Time stamp signatures, by their very purpose, need to remain valid and trusted for decades after signing, even if no more signatures are generated. This means keeping up private key protection and revocation checking. 2. The specific Symantec time stamping URLs are baked into thousands of scripts, as they have remained the same since before Symantec acquired VeriSign's CA business. But nothing prevents pointing them to equivalent DigiCert servers, as Symantec had already pointed them to Thawte servers. 3. The unique protocol for generated Microsoft-compatible SHA-1 time stamp signatures remain important as long as there are still Vista, Windows 7, Server 2008 and older machines around (even though Microsoft support for those is going away, that hasn't historically stopped users from keeping stuff running and asking 4th party vendors for fresh application updates, thus causing those 4th party vendors to need old form signatures trusted by those old systems). CAs would instead need to take additional precautions to guard against SHA-1 weaknesses. On 29/08/2019 00:58, Jeremy Rowley wrote: > Hey – I realized it’s been a long time since I posted an update about where > we are at on shutting down the legacy Symantec systems. I thought the > community might find it interesting on what we’re doing to consolidate all > the system. > > > When we bought the Symantec CA business, we promised to bring the systems up > to modern compliance standards and deprecate systems or improve the customer > experience by consolidating storefronts. We soon realized that we may have > underestimate the scope of this promise as the systems were a bit old. As > soon as we gained access to the legacy Symantec systems, we audited the > systems for features use and functionality and the legal business agreements > requiring certain things. From this list, we created a migration roadmap that > ensured we could support customer needs and maintain their certificate > landscapes without extensive interference, prioritizing systems based on > complexity and risk. > > > > Once we had a preliminary list, engineering started developing solutions to > to migrate customers to our primary certificate management system, > CertCentral. This was a necessary foundational step to moving customers off > legacy Symantec storefronts and APIs, so that we can shut down the old > Symantec systems. As everyone knows, we did the migration of all validation > first (per the browser requirements), followed by the migration of org > details, and other information. We are still working on some migration tools. > > > > Migration to a new system is complicated for customers, and we’ve tried to > take an approach that would accommodate their needs. To do this, we’re > migrating customers in a staged approach that allows us to target groups as > soon as we have system readiness for different customer subsets. We began > migration efforts with small accounts and accounts who had outgrown the > performance of their old Symantec console. Moving these customers first > allowed us to learn and adapt our migration plan. Next, we began targeting > larger enterprise customers and partners with more complicated, business > integrations. Finally, we have begun targeting API integrated customers with > the most difficult migration plans. We’re working with these customers to > provide them the resources they need to update integrations as soon as > possible. > > > > Of course, on the backend, we already migrated all legacy Symantec customers > to the DigiCert validation and issuance systems for TLS and most code > signing. We’re still working on it for SMIME. > > > > To date, we’ve migrated a total of about 50,000 legacy accounts. This is > important progress towards our goal of system consolidation since we need to > move customers off legacy systems before we turn them off. This isn’t the > half-way point, but we’ve been ramping up migration as new portions of the > co
Symantec migration update
Hey – I realized it’s been a long time since I posted an update about where we are at on shutting down the legacy Symantec systems. I thought the community might find it interesting on what we’re doing to consolidate all the system. When we bought the Symantec CA business, we promised to bring the systems up to modern compliance standards and deprecate systems or improve the customer experience by consolidating storefronts. We soon realized that we may have underestimate the scope of this promise as the systems were a bit old. As soon as we gained access to the legacy Symantec systems, we audited the systems for features use and functionality and the legal business agreements requiring certain things. From this list, we created a migration roadmap that ensured we could support customer needs and maintain their certificate landscapes without extensive interference, prioritizing systems based on complexity and risk. Once we had a preliminary list, engineering started developing solutions to to migrate customers to our primary certificate management system, CertCentral. This was a necessary foundational step to moving customers off legacy Symantec storefronts and APIs, so that we can shut down the old Symantec systems. As everyone knows, we did the migration of all validation first (per the browser requirements), followed by the migration of org details, and other information. We are still working on some migration tools. Migration to a new system is complicated for customers, and we’ve tried to take an approach that would accommodate their needs. To do this, we’re migrating customers in a staged approach that allows us to target groups as soon as we have system readiness for different customer subsets. We began migration efforts with small accounts and accounts who had outgrown the performance of their old Symantec console. Moving these customers first allowed us to learn and adapt our migration plan. Next, we began targeting larger enterprise customers and partners with more complicated, business integrations. Finally, we have begun targeting API integrated customers with the most difficult migration plans. We’re working with these customers to provide them the resources they need to update integrations as soon as possible. Of course, on the backend, we already migrated all legacy Symantec customers to the DigiCert validation and issuance systems for TLS and most code signing. We’re still working on it for SMIME. To date, we’ve migrated a total of about 50,000 legacy accounts. This is important progress towards our goal of system consolidation since we need to move customers off legacy systems before we turn them off. This isn’t the half-way point, but we’ve been ramping up migration as new portions of the code come into completion. Most of the migration has completed since June. Now that we’re nearly product ready for all customer types to migrate, we have a line of sight for end of life of the Symantec systems that I thought would be useful to share: **Timeline of migration events** November 2017: purchased Symantec December 1 2017: Began revalidation of Symantec certificates December 2017-December 2018: Symantec business migration (transition service agreement exits) January 2018: Symantec product audit February-November 2018: Required TSA exits and internal process updates to absorb additional business February 2018: Began planning massive effort to shut down legacy systems February 2018-December 2019: Developing required customer functionality for all markets January 2018? -April 2019: Data center migrations February 2019 -November 2019: Developing a means to migrate active certificate data into April 2019: Began migrating retail customers June 2019: Began migrating Enterprise customers and Partners August 2019: Completed DigiCert MPKI migration August 2019: Begin DigiCert Retail migration for domain validation consolidation (target completion Oct 31) **Coming next** Q4 2019: End of sale of Symantec Enterprise solutions Q4 2019: End of life of Symantec Encryption Everywhere, a service for hosting providers Q1 2020: We will begin the shutdown process for legacy systems Q3 2020: Target completion for all account migrations Q3 2020: Target for system shut down for legacy storefronts, including migration of legacy DigiCert and Symantec systems. We aim to shut down systems sooner, but this largely depends on how the shutdown process proceeds. We’re currently evaluating any additional time required to migrate API customers. We are constantly working towards these dates and will post updates as things change. ** Note that this plan excludes QuoVadis; we will be posting updates on the QuoVadis system migration later once we free up resources from the Symantec migration. Looking forward to the questions! Jeremy ___ dev-security-policy mailing list
