How AWS IoT Core is Helping Customers Navigate the Upcoming Distrust of Symantec Certificate Authorities

NOTE: This blog post describes important public key infrastructure (PKI) issues related to browser and mobile application connectivity to AWS IoT Core. For information about public key certificates and TLS, see Chain of Trust and Certificate Authorities in High Performance Browser Networking.

Overview

Google, Apple, and Mozilla have announced that, starting October, 2018, they will deprecate trust in all Symantec root certificate authorities (CAs), including the VeriSign Class 3 Public Primary G5 root CA used to sign AWS IoT Core server certificates. For information, see the Google announcement, the Apple announcement, and the Mozilla announcement.

The decision to no longer include these CA certificates will disrupt mobile and web applications that rely on the certificate trust stores provided by their mobile operating systems or browsers. Users might see warning notifications in their browsers. Mobile applications might be unable to establish connections to their AWS IoT Core endpoints.

Deprecating trust in a CA is a normal process on the internet. Web servers typically address this by switching to a different trusted CA to sign their server certificates. The process is transparent to end users because browsers include a large trust store with many CAs. In the IoT space, the story is a little bit more complicated. Due to memory constraints, devices might trust only a single CA and it might be difficult to update firmware on those devices to add new CA certificates. Changing the signing CA for a server certificate of an endpoint will prevent those devices from connecting to that endpoint.

The AWS IoT Core solution

AWS IoT now provides additional customer endpoints that present Amazon Trust Services (ATS) signed server certificates. ATS CAs are trusted, by default, in most popular browsers and operating systems, including iOS, Android, Chrome, Firefox, Windows, and most common Linux distributions. Earlier this year, the AWS Security team published a blog post that outlined our efforts to migrate AWS services to ATS signed server certificates. Many AWS services, including Amazon DynamoDB and Amazon EC2, are already presenting these server certificates when customers call their APIs.

To maintain backward compatibility with devices that only trust server certificates signed by the VeriSign Class 3 Public Primary G5 root CA, AWS IoT Core will continue to provide endpoints that authenticate with server certificates signed by that CA. These certificates will continue to be renewed on a regular basis.

We strongly recommend that all customers use the following instructions to get their new Amazon Trust Services endpoint and use it in mobile and browser apps that connect to AWS IoT Core. We also recommend that customers start migrating their device fleets to trust Amazon Trust Services root CAs and connect to Amazon Trust Services endpoints.

Keep these things in mind when you update your mobile or browser app or migrate your fleet:

• You must explicitly request an Amazon Trust Services endpoint for each region in your account. Any existing customer endpoint you have is most likely a VeriSign endpoint. If your endpoint has “-ats” at the end of the first subdomain, then it is an Amazon Trust Services endpoint. For example, ‘asdfasdf-ats.iot.us-east-2.amazonaws.com’ is an ATS endpoint.
• IoT endpoints for jobs and the credentials provider are not affected. They are already serving Amazon Trust Services signed certificates.
• VeriSign and Amazon Trust Services endpoints in the same account and region are interoperable. The only difference between the endpoints is the root CA of the certificate they serve. Devices can switch back and forth (provided they have both certificates) and communicate with each other with no additional changes or registration. This means a phased transition is possible (and recommended).
• New regions launched after May, 2018 serve Amazon Trust Services signed certificates only.

*AWS IoT Core regions added in the future will support the Amazon Trust Services root CA only

How to set up your Amazon Trust Services endpoint

1.  Create your ATS endpoint
   • Call the describe-endpoint API with the endpointType parameter set to iot:Data-ATS. In the AWS CLI, you can use the following command: aws iot describe-endpoint --endpoint-type iot:Data-ATS .
   • If successful, you should receive an endpoint in the form prefix-ats.iot.region.amazonaws.com. This API call is idempotent in the sense that the first call creates an endpoint, and subsequent calls return the same endpoint.
2. Download the ATS root CAs to your devices.
   • Refer to the documentation on Server Authentication in AWS IoT Core and follow the links to the desired Amazon Trust Services CA Certificates (ex. RSA or ECC).
   • Save these certificates as .pem files and copy them to your devices
3. Connect Away!
   • Update your mobile and browser apps and the firmware of your devices with the new endpoint.
   • Test & Deploy!

NOTE:  ATS endpoints are now presented by default in the console.  If you need to get a VeriSign endpoint, simply call the describe-endpoint API with no “–endpoint-type” flag.  

Workaround on Java Development Kit (JDK) distrusting connections to endpoints with server certificates signed by Symantec CA

Oracle and OpenJDK have recently added a policy to distrust connections to endpoints with TLS server certificates issued after April 16, 2019 and anchored by a distrusted legacy Symantec root CA [1,2]. As part of standard security best practices, AWS IoT Core renews all server certificates of its endpoints on a regular basis. As such, all customer endpoints using server certificates signed by the VeriSign Class 3 Public Primary G5 root CA will be rejected by Java clients (8u212 or above, 7u221 or above, 11.0.3 or above), resulting in failure to connect. To continue to be able to connect to customer endpoints using server certificates signed by VeriSign Class 3 Public Primary G5 root CA, the following modifications are required:

• Create a file to override the default JDK security policy and save it in your home folder (for example $HOME) with the name of symantec.policy. The file should contain the following text: jdk.security.caDistrustPolicies=null.
• Reference the policy file when launching your Java virtual machine (JVM): Djava.security.properties=$HOME/symantec.policy where $HOME is the directory containing the symantec.policycreated in the previous step. This should make the JDK ignore the distrust policy set by default.
• Verify that the policy change took place by inspecting the Security property of the same name:

// This variable should be null when the security property is applied to the VM, else it is SYMANTEC_TLS
String policies = java.security.Security.getProperty("jdk.security.caDistrustPolicies");

Note:
Setting caDistrustPolicies=null will also remove any other distrust policies for the JVM. As of now, the only distrust policy supported by the JVM is SYMANTEC_TLS, but additional distrust policies may be added and will require modification. It is strongly recommended to adjust client software to connect to customer endpoints using ATS-signed server certificates instead.