SSL Requirements for Buyers

Detailed technical requirements for supporting secure connections from iOS and Android devices.

The adoption of secure connections is increasing among app developers on both Android and iOS operating systems. As of January 1, 2017 Apple requires app submissions on iOS 10 to use secure connection (ATS), therefore, buyers on the Exchange must be capable of supporting the server requirements described below to ensure the successful display of advertisements.

Server Requirements

  1. TLS v1.2
  2. Forward secrecy
  3. The server certificate must meet at least one of the following trust requirements:
    • Issued by a certificate authority (CA) whose root certificate is incorporated into the operating system
    • Issued by a trusted root CA and installed by the user or a system administrator
  4. The leaf server certificate must meet the following requirements:
    • Certificate must be signed with either a Rivest-Shamir-Adleman (RSA) key with a length of at least 2048 bits or an Elliptic-Curve Cryptography (ECC) key with a size of at least 256 bits
    • In addition, the leaf server certificate hashing algorithm must be Secure Hash Algorithm 2 (SHA-2) with a digest length of at least 256 (that is, SHA-256 or greater).
  5. OpenSSL ciphers required for Android and iOS support:
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Resources

  • Android Documentation
  • iOS Documentation
  • RTB Bid Request Documentation (internal) 
    The "nex_secure" extension to the "imp" object is sent to OpenRTB 2.1 bidders to indicate if the impression requires secure HTTPS URL creative assets and markup, where 0 = non-secure, 1 = secure. If omitted, the secure state is unknown. This is conveyed to OpenRTB 2.2+ bidders in the "imp.secure" attribute.
Have more questions? Submit a request