The CA for the VeriSign Standard SSL Certificates will be rolled over from a single-tier certificate hierarchy to a new, more secure two-tier hierarchy under the Class 3 Public Primary Root Certification Authority (PCA). 

Up until May 2005 all Secure Site Certificates were signed directly by the VeriSign/RSA root. In May 2005 VeriSign introduced a new 2048 bit VeriSign Class 3 Secure Server CA and began using it to sign VeriSign Standard SSL Certificates obtained through www.verisign.com for customers using IIS web servers. The rollout to Microsoft IIS customers went smoothly and customers have seen no change to their SSL security. For more information on this change, click here: http://www.verisign.com/support/ssl-certificates-support/newsecuresiteca.html 

The VeriSign/RSA root expires in January 2010 and it is important that the migration off this root is completed well before that date. VeriSign will be rolling out this new 2048 bit VeriSign Class 3 Secure Server CA to all Standard SSL Certificate customers during 2007. 

Rollout Timeline:

Q1 2007: retail certificate customers: 
Starting Q1 2007 all VeriSign Standard SSL customers obtaining retail certificates will get a certificate signed by the new VeriSign Class 3 Secure Server CA.  

2007: Managed PKI for SSL customers: 
All Managed PKI for SSL Standard SSL Certificates will be migrated from a single-tier certificate hierarchy to a new, more secure two-tier hierarchy under the Class 3 Public Primary Root Certification Authority (PCA).

What you can expect when this is rolled out:

Customers using IIS web servers  
Customers using IIS web servers will receive one file containing their digital certificate and the new VeriSign Class 3 Secure Server CA. IIS processes this file seamlessly. 

Customers using other Web Server  
Customers using other web servers will receive a separate digital certificate file and VeriSign Class 3 Secure Server CA to install. The SSL administrator will have to go through a simple one-time installation of the VeriSign Class 3 Secure Server CA. This is consistent with the way VeriSign has been issuing Secure Site Pro and Premium Certificates for the past 2 years. 

Additional Questions and Answers

1. How can I test this new certificate chain? 
•IIS: A chained test certificate is currently available for customers using IIS from http://www.verisign.com/ssl/buy-ssl-certificates/free-trial/index.html .

2. Does this affect Premium SSL certificates? 
This change does not affect Premium SSL Certificates. These customers will continue to get their certificates signed by the same VeriSign International Server CA used today.  

3. What if I have an application or server does not support certificate chains? 
Some customers may be using legacy applications or servers that may not support chaining. For this reason, we will keep the RSA root available for customers who require unchained certificates. These certificates will only be one year certificates and cannot be issued after September 30, 2008. VeriSign recommends you update your legacy applications before that date and ensure that the RSA root is not hard-coded in your application as a trust point. 

4. Does this affect client certificates issued to individuals? 
This change does not affect client certificates. These customers will continue to get their certificates signed by the same CA used today.

5. Why does VeriSign need to implement an intermediate CA?  Or, why “chained” certificates?

• To offer you the best-in-class SSL services that will keep your costs down in the long term, ensure the continued security of your certificate and protect the integrity and security of the VeriSign Trust Network of which you are a part of.
• Chained certificates are more secure because the root CA is kept “offline” in a highly secure environment that cannot be breached.
• Having shorter-lived (compared to roots) intermediates on-line to sign end entity certificates is best PKI practice since they can be easily replaced in the event (albeit unlikely) of a key compromise.
• One way to control the size of the Certificate Revocation List (CRL) associated with a certificate product is by periodically rolling over the intermediate CA that signs the end entity certificates.  Maintaining optimal CRL sizes ensures that your customers have a smooth and seamless experience visiting your SSL-secured website while full security is maintained transparently to your customer (end user).
• All the popular web servers support chained certificates since this is best practice; in addition we are actively working with these vendors to propagate the new intermediate via server software updates or releases.

6. Why is VeriSign doing this intermediate CA rollover now?

• Current VeriSign/RSA root CA is set to expire in early 2010, so we must migrate this hierarchy to a longer lived hierarchy while keeping current with latest best PKI practices
• We are initiating the migration process 5 years in advance to ensure our customers have adequate time to migrate with minimal “pain” and more importantly, ensure that there is no impact to your business when the current VeriSign/RSA root CA does expire in 2010.
• We are working with server vendors to update the root stores on their software to eliminate or minimize impact to you when we do roll out the new intermediate CA to non-IIS web servers.