Ask a Question

General Information ID : INFO3542

Symantec Managed PKI Web Services: SHA2 Migration FAQ and Test Instructions

Description

(continued from https://support.symantec.com/en_US/article.INFO3528.html)

Will Symantec PKI Web Services be interrupted during the migration?

No. As a migration is performed on one node, traffic will be re-directed and balanced across other nodes, and repeated until the migration is complete.  

NEW! Real-time migration updates here:  id=INFO3872

Is my organization affected by this migration?

In the Symantec PKI 8 Manager, check the enrollment method of the certificate profile you created. A Microsoft Authoenrollment and/or PKI Web Services profile will show as the enrollment method, and affected by this migration:


All non-auth services have been previously migrated to SHA2, such as the SSP and enrollment pages. 

We use an MDM and\or a LKMS to manage certificates on devices. Do we need to make any changes?

The VeriSign Class 3 Public Primary Certificate Authority - G5 (or verisignclass3g5ca) must be present in the root store. This is the same CA used before Phase 1. Refer to: https://support.symantec.com/en_US/article.INFO3528.html

Do our end-users need to take any action?

No updates are required from your end-users. The renewed SSL/TLS certificate is used to establish a secure connection between our Symantec Web Services server, and your server running the applications using our APIs. You only need to ensure the G2 root is present in the trust store of your server machine.

What will the new G5 cert chain look like?

 
Certificate Algorithm Notes
↓ VeriSign Class 3 Public Primary Certification Authority - G5

 

SHA-1 This is the same root as all other PKI Service SSL certificates.

 Symantec Class 3 EV SSL CA - G3

SHA-2

 

 End-Entity Auth Web Service Certificate
pki-ws-test.symauth.com/

SHA-2

 

For organizations using pinning, the root and intermediate cert chain (PKI_SHA-2_CA_Certs.rar) is attached to this article. 

Has Phase 1 already occurred? When will Phase 2 and 3 happen?

Please refer to https://support.symantec.com/en_US/article.INFO3528.html
 

How do I test a SHA-2 end-point using the G5 root CA before the migration?

Symantec has created live, SHA2 end-points for testing purposes. These URLs chain to the G5 root CA that will be used after the migration. Symantec recommends using Symantec mPKI components version 8.10 or later. 

mPKI 8: https://pki-ws-test.symauth.com/
mPKI 7 Pilot: https://pilot-pkiservices-test.verisign.com
mPKI 7 Production: https://https://pkiservices-test.verisign.com

Please perform the getPolicy operation to test SHA-2 connectivity prior to the Phase 2 or 3 migration:

mPKI 7:

  • Download and unzip Managed PKI Web Services 1.0.3 from the Download>Software>Software and Toolkits section of Managed PKI Control Center to your environment where the runtime environment is installed. Documentation (PKIWebSrv.pdf) is included in download. PKI WS Java Utility is available under mpki7_webservices_1_0_3\tools\clientApp.
  • It is not necessary to obtain a new RA certificate to perform SHA2 SSL testing. The existing RA should be used.
  • If you don’t already have the java key stores created for your production account, create a Java key store with the production RA certificate by referring to “Obtaining Your Registration Authority Certificate” section  of the PDF to generate required java key stores.
  • To perform a getPolicy web service call, update the clientConfig.txt. policy file under pkiclient/sampleClient/tools/clientApp to include the following:
    host=https://https://pkiservices-test.verisign.com
    ssl.keystore=<Path to java key store containing the RA certificate>

    ssl.keystorepass=<Password for above key store>
  • Make the call using the following command:  jjava -jar pkiwebserviceclient.jar -config <config file> -operation <operation> [-input <input file>]
  • The response on the console should be the same as when pointing to https://pki-ws.symauth.com.
  • If the connection is successful, a SHA-256 connection has been established using the G5 root CA chain. https://pki-ws.symauth.com will use this same chain after Phase 2 and no further action is required.
  • If the connection is not successful and returns SSL/TLS handshake errors, check that all of the following apply:
    • Does my client runtime support the SHA2 signature algorithm?
    • Is my client runtime connecting with a cipher suite no longer supported by SHA2 certificate? 
    • Is my client runtime connecting using TLS1.0 or 1.1 or 1.2, and not SSLv3?​

mPKI 8:

  • Download and unzip symantec-pki-webservices-1-16.zip from the Resources>Symantec PKI Web Services section of PKI Manager to your production environment where the Java Runtime (JRE) is installed to. Documentation is available under pkiclient/documentation/MPKIWebSrv.pdf. PKI WS Java Utility is available under pkiclient/sampleClient/tools/clientApp/pkiwebserviceclient.jar.


  • Please refer to chapter 3 "PKI Web Service Java Utility" of the MPKIWebSrv.pdf as a reference when performing this test. It is not necessary to obtain a new RA certificate to perform SHA2 SSL testing. The existing RA should be used.
  • If you don’t already have the java key stores created for your production account, create a Java key store with the production RA certificate by  referring to “Obtaining an RA Certificate to Store in a Java Keystore File” section  of the PDF to generate required java key stores.
  • To perform a getPolicy web service call, update the clientConfig.txt.onePolicy file under pkiclient/sampleClient/tools/clientApp to include the following:

    host=https://pki-ws-test.symauth.com
    s
    sl.keystore=<Path to java key store containing the RA certificate>
    ssl.keystorepass=<Password for above key store>
    g
    etpolicy.policyOid=<Policy Oid. For ex : 2.16.840.1.113733.1.16.1.2.5.2.1.615619177>
  • Make the call using the following command:  java -jar pkiwebserviceclient.jar -config clientConfig.txt.onePolicy -operation getpolicy
  • The response on the console should be the same as when pointing to https://pki-ws.symauth.com.
  • If the connection is successful, a SHA-256 connection has been established using the G5 root CA chain. https://pki-ws.symauth.com will use this same chain after Phase 2 and no further action is required.
  • If the connection is not successful and returns SSL/TLS handshake errors, check that all of the following apply:
    • Does my client runtime support the SHA2 signature algorithm?
    • Is my client runtime connecting with a cipher suite no longer supported by SHA2 certificate? 
    • Is my client runtime connecting using TLS1.0 or 1.1 or 1.2, and not SSLv3?

Do you have a list of operating systems, browsers, and servers that support SHA-2 for SSL/TLS certificates?

For a list of operating systems, browsers, and servers that support SHA-2 for SSL/TLS certificates see  https://casecurity.org/wp-content/uploads/2014/09/SHA-256-Support-List.pdf
 

What changes are being made to the cipher suites?

All network communications from clients (web service clients and web browsers) to the mPKI Service’s servers use the SSL/TLS secure protocol, which supports multiple cryptographic algorithms (cipher suites).

When a client attempts to establish an SSL/TLS connection to a server, the client presents a list of the cipher suites it supports and the server picks a cipher suite on the list presented by the client. If the client does not support at least one cipher suite strong enough that the server will accept it, the client will be unable to establish a network connection to the server.

The PKI Web Service will be removing support for cipher suites that are no longer considered cryptographically strong. This change should not affect organizations other than to improve overall network security - any web service client capable of supporting SHA-2 SSL certificates is also capable of supporting strong cipher suites.

Cipher Suites no longer supported

TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_SEED_CBC_SHA

Cipher Suites that will continue to be supported

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA

Cipher Suites that are being added

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Why is the Secure Sockets Layer (SSL) 3.0 protocol being disabled?

This change is required in response to a vulnerability in the SSL 3.0 protocol that makes it vulnerable (i.e., POODLE attack). Additional information is available at US-CERT: https://www.us-cert.gov/ncas/alerts/TA14-290A

If you experience SSL/TLS handshake errors after following the test steps, contact Symantec Technical Support

To contact technical support: https://support.symantec.com/en_US/contact-support.htmlCollect the following data before contacting technical support:

  • Client runtime name and version (e.g. Java 1.7.0_31 or .NET 4.5)
  • If applicable client libraries used and its version (e.g. Axis 2.0)
  • Operating System name and version (e.g.: Windows 2012 Server R2)
  • SSL debug output logs captured in a file (e.g: In Java, SSL debug can be turned on by passing -Djavax.net.debug=ssl to client JVM)
Attachments

PKI Web Svc SHA2 Certs