000033062 - RSA SecurID Software Token 2.2 for iOS deployed via CT-KIP fails to import with the error "token import failed"

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000033062
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: SecurID Software Token for iOS
RSA Version/Condition: 2.2
IssueA new software token deployed via CT-KIP fails to import into the RSA SecurID Software Token 2.2 for iOS app.  The following error is seen:

Token import failed. Error communicating with server. Contact your administrator.

Cause
Apple now has a requirement for SHA-256 certificates.  This requirement is documented in the RSA Announces iOS 9 Support for RSA SecurID® Software Token 2.0.1 for iOS and RSA SecurID SDK 2.1 for iOS advisory (5 October 2015):

The iOS 9 App Transport Security (ATS) feature requires a server that supports Transport Layer Security (TLS) protocol version 1.2 or later with forward secrecy ciphers and certificates that are signed using a SHA-256 or later signature algorithm.


RSA Authentication Manager 7.1 does not support the required TLS encryption version. iOS apps that are built with the RSA SecurID SDK 2.1 on Xcode 7 cannot perform CT-KIP provisioning with RSA Authentication Manager 7.1. 


If the SSL certificate that you use to secure your CT-KIP connections does not use SHA-256 or later, then you must replace it. The default RSA Authentication Manager 8.x SSL console certificate does not meet the ATS requirement. For instructions on replacing the RSA Authentication Manager 8.x SSL console certificate, see the RSA Authentication Manager Administrator’s Guide.


For more information on ATS, see the following article on the Apple Developer's site (refer to section titled "Requirements for Connecting Using ATS").


This requirement is also documented on page 13 of the RSA SecurID Software Token 2.2 for iOS Administrator’s Guide:

App Transport Security Requirements for Dynamic Seed Provisioning


Apple introduced the App Transport Security (ATS) feature in iOS 9. This network encryption and security feature requires a server that supports Transport Layer Security (TLS) protocol version 1.2 or later with forward secrecy ciphers and certificates that are signed using a SHA-256 or later signature algorithm. 
RSA Authentication Manager 8.1 or later supports the required TLS encryption version, but you must ensure that the SSL console certificate used by RSA Authentication Manager meets the ATS requirements. 
If the SSL certificate that you use to secure your CT-KIP connections does not use SHA-256 or later, then you must replace it. The default RSA Authentication Manager SSL console certificates do not meet the ATS requirement. For instructions on replacing the RSA Authentication Manager SSL console certificate, see the RSA Authentication Manager Administrator’s Guide.
ResolutionDue to a requirement by Apple, customers must upgrade their certificates used for CT-KIP to SHA-256. Please note this requirement is not from RSA.

Requirements are:


  • Authentication Manager 8.1 SP1 P2 or newer, 
  • Certificates signed with SHA-256, 
  • SSL cipher suites with "Perfect Forward Secrecy," and
  • These apply to the network endpoint servicing the CT-KIP request.
There are four configurations that we have to take into account:
  1. CT-KIP is only used internally with no web-tier deployed.
  2. CT-KIP is used in conjunction with a web-tier.
  3. CT-KIP is used in conjunction with a web-tier(s) which is fronted by a SSL-terminating load balancer/proxy server.
  4. CT-KIP is used in conjunction with a web-tier(s) which is fronted by a load balancer with “SSL Passthrough”.
For all of the scenarios below it would be expected that the SHA-256 cert is from a known/trusted CA.  The RSA Authentication Manager certificate signing request (CSR) does not enforce SHA-256 certificates inside the CSRt.  You MUST tell your Certificate Manager to create a SHA-256 certificate.

Scenario 1


  1. Launch the Operations Console.
  2. Navigate to Deployment Configuration > CertificatesConsole Certificate Management.  
  3. Generate a CSR and send it to the certificate authority (CA).
  4. Receive the SHA-256 certificate and install it under Console Certificate Management.
  5. CT-KIP can now be used with RSA SecurID Software Token 2.2 for iOS.
  6. See the section entitled “Certificate Management for Secure Sockets Layer” in the RSA Authentication Manager 8.2 Administrator's Guide for more information.

Scenario 2


  1. Launch the Operations Console.
  2. Navigate to Deployment Configuration > CertificatesVirtual Host Certificate Management.
  3. Generate a CSR and send it to CA
  4. Receive the SHA-256 certificate and install it under Virtual Host Certificate Management.
  5. CT-KIP can now be used with RSA SecurID Software Token 2.2 for iOS.
  6. See the section on how to “Replace the Default RSA Virtual Host Certificate” in the RSA Authentication Manager 8.2 Administrator's Guide for more information.

Scenario 3


  1. Generate a CSR on the load balancer and send it to CA.  See vendor documentation for details.
  2. Receive the SHA-256 certificate and install it on the load balancer.  See vendor documentation for details.
  3. CT-KIP can now be used with RSA SecurID Software Token 2.2 for iOS.

Scenario 4


These are the same steps as for scenario 2


  1. Launch the Operations Console.
  2. Navigate to Deployment Configuration > CertificatesVirtual Host Certificate Management.
  3. Generate a CSR and send it to the CA
  4. Receive the SHA-256 certificate and install it under Virtual Host Certificate Management.
  5. CT-KIP can now be used with RSA SecurID Software Token 2.2 for iOS.
  6. See the section on how to “Replace the Default RSA Virtual Host Certificate” in the RSA Authentication Manager 8.2 Administrator's Guide for more information.
Keep in mind some older devices that aren’t compatible with SHA-256 will no longer be able to import tokens by CT-KIP. We have received word that certain version of F5 are not compatible with the Apple requirements.  See the article on the F5 site about preparing your F5 for new TLS requirements in Apple iOS 9 and OS X 10.11, specifically the section on how this affects F5 customers.

A useful link for test SSL certificates can be found on the Qualys SSL Labs server test page.  CAUTION:  When using the server test page, be sure to check the box Do not show the results on the boards.  Not checking this option will expose the hostname publicly


  • If you scan your load balancer and see the following error, contact your load balancer vendor:
Apple ATS 9 /iOS 9 R Server sent fatal alert: handshake_failure

  • If you scan an RSA web tier and see the results below, you are not at the latest web tier version and need to upgrade.  See the release notes for Authentication Manager 8.1 SP1 patch 2:
    • This server uses only RC4 suites, which are insecure.
    • This server uses SSL 3, which is obsolete and insecure.
    • The server does not support Forward Secrecy with the reference browsers
    • Protocols
TLS 1.2    Yes
TLS 1.1    Yes
TLS 1.0    Yes
SSL 3   INSECURE    Yes
SSL 2    No

  • Cipher Suites (sorted by strength as the server has no preference; deprecated and SSL 2 suites at the end)
TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE    128
WorkaroundThe work around is to import the software token to the iOS device using the CTF method or by delivering an .sdtid. If implementing file-based distribution, customers should use device binding:
  1. The end user launches the RSA SecurID Software Token for iOS on their device.
  2. With the app open, click on the information button.
  3. Click on the envelope next to Binding-ID and send an email to the RSA admin or help desk staff distributing the token.
  4. The RSA admin/help desk staff launches the Security Console and searches for the user.
  5. The RSA admin/help desk staff assigns a software token to the user.
  6. The RSA admin/help desk staff distributes the token as an sdtid file or CTF link.
  7. In the Device Serial number field, add the binding ID provided by the end user in step 3.  NOTE: Do NOT distribute tokens to users without using device binding.
  8. Unzip the .sdtid zip file and send the token .sdtid file or CTF string to the end-user.
  9. The end user taps on the .sdtid file or taps on CTF link to import the token to the app.
1 person found this helpful

Attachments

    Outcomes