HTTPS Security Certificate Change from SHA-1 to SHA-256 hash algorithms
|Knowledge Article Number||000206493|
What is changing?
To maintain alignment with security best practices and the industry-wide shift to use more complex algorithms for HTTPS certificates, Salesforce will be replacing the current HTTPS certificates, which are signed with the SHA-1 hash algorithm, with new certificates signed with the SHA-256 hash algorithm. Additionally, Salesforce will be consolidating our trusted third-party certificate authorities (CA) to leverage only Symantec-issued certificates.
HTTPS certificates are reflected in the browser’s URL bar to indicate a secure connection while accessing secure websites, including Salesforce.
What action do customers need to take?
In order for users to continue to have access to Salesforce, customers need to ensure their Operating Systems, browsers, and middleware are capable of accepting HTTPS certificates with the SHA-256 hash algorithm.
Ensure that the list of trusted certificate authority (CA) certificates in your software includes the newer, self-signed, root version of the "VeriSign Class 3 Public Primary Certification Authority - G5" certificate. This certificate can be downloaded from Symantec here. Up-to-date software since approximately 2010 typically trusts this certificate already. Older software might not already trust this newer Verisign root certificate.
What will happen if my operating systems, browsers, middleware, and integrations are not capable of accepting these new HTTPS certificates?
If your operating systems, browsers, middleware, and integrations cannot validate the new HTTPS certificates, those operating systems, browsers, middleware, and integrations will not be able to access Salesforce. Users operating on those operating systems, browsers, middleware, and integrations will also not be able to access Salesforce.
When will the new certificates be implemented?
Salesforce plans to implement the new certificates in Sandbox and Production instances according to the following phased schedule:
If you do not know what instance you are on, access the “What instance am I using” Knowledge article.
If you locally cache certificates, please join the Certificates Changes Community Group to obtain the required certificates and get notified about the exact certificate update times on these dates.
Is there a way to test if I am prepared for this change?
Yes. We have established this test page to quickly check if your operating systems, browsers, middleware, and integrations accept HTTPS certificates with the SHA-256 hash algorithm. Instructions covering how to use this test page are farther below in the “How can I leverage the Test Site to check compatibility in my environment” section of this Knowledge article.
Additionally, if you have a sandbox available, we strongly recommend that you test your operating systems, browsers, middleware, and integrations using your sandbox. Sandbox certificates were updated earlier this year.
Why is Salesforce not changing the HTTPS certificates sooner?
The HTTPS certificates that Salesforce uses today are secure. However, it is a best practice to continuously increase the complexity of security encryption protocols and tools. We designed the timeline to give customers time to prepare for this change while maintaining a secure environment.
How will the consolidation of trusted third party certificate authorities by Salesforce affect me?
Moving forward, Salesforce will use certificates issued by Symantec. Salesforce's older certificates used multiple vendors. The new certificates chain up to the same "VeriSign Class 3 Public Primary Certification Authority - G5" root certificate instead of chaining up to more than one root certificate. The test site uses a certificate issued by Symantec.
What if we use middleware that requires us to upload the certificate into the middleware (i.e. locally cached)?
If your organization is running middleware that requires the server and/or intermediate certificates to be locally cached, you will need to update the cached certificates as a result of this change. This is not typical in most software, but some API middleware systems do have this requirement. To learn more about this how this information will be communicated, please join the customer Success Community group, Official: Certificate Changes.
Which Operating Systems and browsers are compatible with SHA-256?
The table below outlines the minimum requirements for certificates with the SHA-256 hash algorithm. If your Operating Systems (OSs) and browsers meet or exceed the minimum requirements, they will be able to access and validate certificates with the SHA-256 hash algorithm.
Minimum version requirements for Operating Systems (OS)
Minimum version requirements for Salesforce Supported Browsers
How can I leverage the Test Site to check compatibility in my environment?
To test the compatibility of an API client that uses SOAP to communicate with Salesforce:
To test the compatibility of an API client that uses REST to communicate with Salesforce:
What is the impact of this change to users using certificate authority (CA) signed certificates for webservice callouts & SSO users?
Apex callouts, delegated authentication, and workflow outbound messaging should not be affected by Salesforce's change to the [instance].salesforce.com (e.g. na7.salesforce.com), [instance].force.com, [mydomain].my.salesforce.com, login.salesforce.com, test.salesforce.com, and www.salesforce.com certificates. Salesforce itself is already compatible with SHA-256 signed certificates, which means that calling out to another Salesforce organization or to an endpoint that uses a SHA-256 signed certificate is supported.
The proxy.salesforce.com certificate is not included in this switchover to SHA-256, but it might be updated to SHA-256 before its October 2017 expiration date. Advance notice will be given if that happens via the Certificates Changes Community Group.
Some SAML configurations use Salesforce's proxy.salesforce.com certificate, and that certificate is not being changed by Salesforce at this time. Customers are free to use their own certificate for SAML assertions, and those can be signed with SHA-256 if it's signed by a certificate authority (including one's own certificate authority). It is recommended to use a certificate that is specific to your organization for SAML.
What do I need to do to make Apex Data Loader, versions 13 through 23, compatible with Salesforce's SHA-256 signed certificates?
Salesforce generally recommends using the newest version of the Apex Data Loader. If that is not possible in your integration, then it is possible to make versions 13 through 23 work by following these steps:
What are the minimum requirements for the Java Virtual Machine?
Different versions of Java have their own requirements. Check the version of Java that you are running with the java -version command within Java's bin folder and follow the advice below for your particular Java version:
Earlier than 1.4.2
1.4.2 to 1.4.2_19
1.5.0 to 1.6.0_18
1.6.0_19 and higher
Sample Errors from Common Middleware Applications
Weblogic 10.3.3 and SHA-256
Customers that use Oracle Weblogic 10.3.3 may encounter an inability to call out successfully to Salesforce when the callout target has a SHA-256 signed server certificate. The following error might appear:
General runtime error: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received
To remedy this, Java secure sockets extension (JSSE) must be enabled in Oracle Weblogic.
If an older version of the JDK is used, such as JDK 1.6.0_20, then enabling JSSE might result in an error that resembles the following:
General runtime error: Cannot get fd for sock=Socket[addr=our.proxy.server/xx.xxx.xxx.xxx,port=8080,localport=56174]:
If you encounter that or a similar error while using JSSE in Oracle Weblogic, then upgrading Java to 1.6.0_45 or newer should help make the connection work properly.