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 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








Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to