Ask a Question

General Information ID : INFO3528

Symantec Managed PKI Web Services: Migration to a SHA-2 (SHA-256) SSL Certificate

Description

PKI MIGRATION TESTING PROCEDURES AND ADDITIONAL FAQ: https://support.symantec.com/en_US/article.INFO3542.html 

What is happening?

Symantec will be expiring the current SHA1 SSL/TLS certificate used by PKI Web Services, and will be migrating to an SSL/TLS certificate signed with the SHA-2 algorithm. Symantec has determined that many customers are still using configurations that support only SHA-1 algorithm signing. To minimize the impact of this migration, the migration process will happen in two phases:

Phase 1 (Completed April 4, 2016 and April 28, 2016)

The expired SHA-1 PKI Web Services SSL/TLS certificate on all PKI Web Services end-points was replaced with a new SHA-1 SSL/TLS certificate that chains up to the Class 3 Public Primary Certificate Authority – G2 Root CA. The expired SSL certificate chained up to VeriSign Class 3 Public Primary Certificate Authority - G5 Root CA.

Phase 2 (To be completed August 1, 2016 for Symantec mPKI 8.x)

PKI Web Services SSL/TLS certificates will migrate to a new SHA-2 SSL/TLS certificate that chains up to the VeriSign Class 3 Public Primary Certificate Authority - G5 Root CA. This is the same Root CA the original, expired SHA-1 SSL/TLS certificates chained up to.  

Phase 3 (To be completed August 8, 2016 for Symantec mPKI 7.x and earlier)

PKI Web Services SSL/TLS certificates will migrate to a new SHA-2 SSL/TLS certificate that chains up to the VeriSign Class 3 Public Primary Certificate Authority - G5 Root CA. This is the same Root CA the original, expired SHA-1 SSL/TLS certificates chained up to.  

Why is this happening?

The National Institute of Standards and Technology (NIST) has determined that the SHA-1 algorithm cryptographic algorithm could be vulnerable to attacks in the near future. At present, SHA-1 is considered safe and there are no reported critical breaches with SSL/TLS certificates signed with the SHA-1 algorithm. However, Symantec is committed to the security of all of its products, partners, and customers.

Am I affected?

The following Symantec PKI Web Services URLs are affected:

  • mPKI 8:
    • pki-ws.symauth.com (PKI web services and Microsoft Auto-enrollment)
       
  • mPKI 7:
    • pkiservices.symauth.com
    • pkiservices.verisign.com 
    • pilot-pkiservices.symauth.com
    • pilot-pkiservices.verisign.com 

These URL end-points are used by developers to integrate Managed PKI certificate lifecycle tasks into their RA (Registration Authority) applications through the Symantec cloud. mPKI 8 Microsoft auto-enrollment server also used this URL to communication to Symantec. If your organization has implemented mPKI web service and\or mPKI 8 Microsoft Auth-enrollment, you are affected. Please refer to: https://support.symantec.com/en_US/article.INFO3542.html

What action should I take?

If you are affected, do the following:

 Verify the presence of the VeriSign Class 3 Public Primary Certificate Authority - G5 Root CA in the trusted root store on your server. (Note: This CA was previously used before the phase 1 migration on April 4th. The new SHA-2 SSL/TLS certificate being migrated to in Phase 2 uses the same certificate chain.)

 Follow the test procedures found in https://support.symantec.com/en_US/article.INFO3542.html to ensure connectivity and SHA2 capability. 

How do I determine if the Root CA's are present in my root certificate store?

  • If PKI Web Services is functioning in your environment after April 4th, the G2 root required for Phase 1 is likely installed correctly. If not, download here: G2 Root CA
  • If PKI Web Services was funtioning prior to phase 1, the G5 root likely exists in the root store. If not, download here: G5 Root CA
  • To verify the presence of the Class 3 Public Primary Certificate Authority – G2 Root CA (or verisignclass3g2caand VeriSign Class 3 Public Primary Certificate Authority - G5 (or verisignclass3g5ca), check the certificate trust store:

For example, to check for the presence of the G5 root:

  • If using a standard Java trust store, run the following command:
    <JRE>/bin/keytool –v -list -keystore | grep "Verisign Class 3 Public Primary Certification Authority – G5"
  • If using a custom Java trust store, run the following command:
    <JRE>/bin/keytool –v -list -keystore | grep "Verisign Class 3 Public Primary Certification Authority – G5"
  • If using a trust store other than Oracle or Java, refer to your trust store provider documentation for instructions on how to check for the presence of a certificate/CA.

If necessary, install the appropriate Root CA. Once completed succesfully, no further action is necessary. 

Note: If you are using the trust store available in the Symantec PKI Web Service client sample package and installed the new G2 root CA during phase 1, this did not affect the existing G5 root CA.
 

What if I have additional questions?