On August 1, 2018 Okta will no longer support Transport Layer Security (TLS) 1.0 or 1.1 protocols due to known security vulnerabilities. In keeping with industry standards and best practices, Okta will migrate to TLS 1.2 for all components, and will deploy the new functionality according to the schedule below. This change affects inbound connections to Okta only. Provisioning connections continue to support TLS 1.0, 1.1, and 1.2.
This document contains all the information you need to be prepared for this upgrade.
What You Need to Do
You must take action if you are in any of the following situations:
The rest of this section contains instructions and links for addressing these three situations: browsers, agents or other downloaded software, and integrations.
1. Test Your Browser
2. Update Okta Components
Use the following list to verify that you've updated all the Okta components that you use, and to find new versions if you need to update. You can check the version number of your Okta agent here: How do I check the version number of my Okta agents?.
*released after March 30, 2018
The following items are available from the Apple Store or Google Play Store:
3. Test Your Integrations
API Integrations are interfaces or applications–including mobile apps and desktop clients–that are separate from Okta, but use Okta data. If you have any API Integrations, please ensure that the TLS 1.2 encryption protocols are enabled in those integrations.
Why Okta is Migrating
While the DSS 3.1 allows TLS 1.1 if configured properly, Okta has chosen the safest route. We are migrating all customers to TLS 1.2.
Okta API and web connections, email delivery, and other components use TLS as a key part of their security. HTTPS (web) and STARTTLS SMTP (email) also use TLS for security.
When Okta deprecates support for the TLS 1.0 and 1.1, you will no longer be able to access any Okta resources using these protocols. Connections, inbound to your Okta org or outbound from it, will fail if they rely on TLS 1.0 or 1.1.
TLS is similar to SSL (Secure Sockets Layer). The latter was developed by Netscape and ensures message integrity while guaranteeing server identity. The Internet Engineering Task Force (IETF) created TLS as the successor to SSL. It's used most often as a setting in email programs, but, like SSL, can be used in any client-server transaction. TLS ensures that a connection to a remote endpoint is the intended endpoint with encryption and endpoint identity verification.
The PCI Council released version 3.1 of their Data Security Standard (DSS), which states that SSL 3.0 and TLS 1.0 are no longer supported. This is a response to the POODLE exploit in SSL and other security vulnerabilities. (Details are available, among other places, in this Acunetix article.)