The short answer: your iOS or Android app does not need an SSL certificate of its own. Apps are not servers. SSL certificates authenticate servers, not clients. What your app needs is for its backend API and any other servers it communicates with to have valid SSL certificates.
That distinction matters because it changes what you need to do. Mobile app SSL is primarily a backend infrastructure concern, not an app development concern. The certificate lives on the API server. The mobile platform (iOS and Android) enforces that connections to that server meet specific TLS requirements. The app itself is affected when those requirements are not met.
There is one significant exception: certificate pinning, which is an app-level mechanism where the app itself validates the server’s certificate against a hardcoded value. Pinning is a security measure that some apps implement deliberately, and it has specific operational implications that every mobile developer and backend team should understand before implementing it.
This guide answers the questions mobile developers, product managers, and backend engineers actually face when thinking about SSL in the context of mobile apps.
Where SSL Lives in a Mobile App Architecture
A typical mobile app communicates with one or more backend services over HTTPS. The app makes API calls to your servers. Those servers present SSL certificates. The iOS or Android TLS stack validates those certificates. If validation succeeds, the connection proceeds. If it fails, the connection is blocked and the app receives a network error.
The SSL certificate you need is on the server, not in the app. If your API runs at api.yourdomain.com, you need a valid SSL certificate on that server for that hostname. The exact same certificate you would use for a website. The same issuance process, the same validation levels (DV is sufficient for API servers in most cases), the same renewal requirements.
The difference from website SSL is in the enforcement. Browsers give users a warning screen with an option to proceed despite certificate errors. Mobile platforms do not. When an iOS or Android app encounters a certificate error, the connection is blocked, and the app receives a generic network error. The user sees a message like ‘Connection failed’ or ‘Could not connect to server.’ There is no option to accept the risk and proceed. The app is simply broken until the certificate issue is resolved.
A backend API certificate expiry in a mobile app context is significantly more severe than in a website context. Website users can sometimes click through certificate warnings (though they should not). Mobile app users cannot. When your API certificate expires, your app stops working entirely for all users until the certificate is renewed and deployed. This is why certificate monitoring and automated renewal for API backends are critical, not optional, for any mobile app with active users.
iOS App Transport Security: What Apple Requires
App Transport Security (ATS) is Apple’s framework for enforcing secure network connections in iOS and macOS apps. It has been active by default since iOS 9 (2015) and enforces minimum TLS requirements on all connections made by apps that use the standard networking APIs.
What ATS requires by default
All connections must use HTTPS. TLS 1.2 is the minimum supported protocol version (TLS 1.3 is preferred and widely supported). The server’s certificate must chain to a trusted root in Apple’s root certificate program. Forward secrecy cipher suites are required, specifically ECDHE key exchange. Certificates must use SHA-256 or stronger for their signature hash. RSA keys must be at least 2048 bits. ECC keys must use at least 256-bit curves.
These requirements are evaluated per connection at runtime. When your app attempts a network connection, the iOS TLS stack checks whether the destination server meets all ATS requirements. If any requirement is not met, the connection is blocked before any data is exchanged.
ATS exceptions and App Store review
Apps can declare ATS exceptions in their Info.plist file to allow connections that would otherwise be blocked. Common exception types include allowing arbitrary loads (disabling ATS for all connections), allowing cleartext HTTP to specific domains, or allowing connections to servers with minimum TLS versions below the default.
The App Store review process scrutinizes ATS exceptions. Apps that include NSAllowsArbitraryLoads (disabling ATS entirely) are required to provide a justification. Exceptions for specific named domains are more likely to pass review than blanket exceptions. Apple’s guidance is that exceptions should be temporary while the underlying server issue is fixed, not a permanent solution.
For apps that need to connect to third-party servers with SSL issues (for example, an app that embeds content from third-party URLs that the developer does not control), specific domain exceptions with appropriate justification are the accepted approach. The developer’s own API servers should not require ATS exceptions if properly configured.
Android Network Security Configuration
Android’s equivalent of ATS is the Network Security Configuration, introduced in Android 7.0 (API level 24) and enforced at the system networking layer. Since Android 9 (API level 28), cleartext HTTP traffic is blocked by default for all apps.
Google Play requires apps to target API level 34 (Android 14) as of 2024. The combination of targeting a modern API level and Android 9’s cleartext blocking means virtually all apps distributed through Google Play must use HTTPS for their network communications.
Android’s trust store
By default, Android apps trust the system CA trust store, which is maintained and updated through the Android operating system. Certificates that chain to a root in the system trust store are accepted. Certificates from a private CA (not in the system trust store) are rejected unless the app explicitly adds that CA to its trust configuration.
Android also separates the system trust store from the user trust store. By default in Android 7.0 and later, apps do not trust certificates installed in the user trust store (certificates users can install manually on their device). This prevents corporate MitM proxies from intercepting app traffic without specific app configuration. Apps can opt in to trusting user CAs via the Network Security Configuration file, which is sometimes done in debug builds for testing with a proxy.
Configuring Android Network Security
The network_security_config.xml file allows apps to customize TLS behavior: pinning certificates or public keys for specific domains, adding CAs to the trust configuration for specific domains or debug builds, controlling cleartext traffic permissions per domain, and configuring minimum TLS version requirements. This configuration is referenced from the AndroidManifest.xml and applied at the system networking layer.
iOS ATS vs Android Network Security: Key Differences
| Property | iOS ATS | Android Network Security Config |
| Default enforcement | On by default since iOS 9 | Cleartext blocked by default since Android 9 (API 28) |
| Minimum TLS version | TLS 1.2 (TLS 1.3 preferred) | TLS 1.0 by default (can restrict to 1.2+ in config) |
| Forward secrecy requirement | Required by default | Not required by default; configurable |
| User-installed CA trust | Trusted by default | Not trusted by default since Android 7.0 |
| Exception mechanism | Info.plist NSAppTransportSecurity exceptions | network_security_config.xml |
| App store review of exceptions | Yes: Apple scrutinizes broad exceptions | Less formal; Google Play policies focus on API level targets |
| Certificate pinning mechanism | App-level, via TrustKit or NSURLSession delegate | Network Security Config file or custom TrustManager |
Certificate Pinning: What It Is and Whether You Need It
Certificate pinning is a security technique where an app is configured to accept only a specific certificate or public key when connecting to a server, rather than accepting any certificate that chains to a trusted root CA. A pinned app does not simply check ‘does this certificate chain to a trusted root?’ It checks ‘does this certificate or key match the specific value I was configured to accept?’
What pinning protects against
Standard TLS validation trusts any certificate from any CA in the platform’s trust store. There are hundreds of trusted CAs globally. A compromised CA could theoretically issue a fraudulent certificate for your domain, which would pass standard TLS validation. Nation-state actors are known to have compromised or coerced CAs in some jurisdictions. Corporate IT environments often install root CAs in the system trust store to intercept HTTPS traffic for inspection (a legitimate use case that nevertheless allows decryption of app traffic).
Certificate pinning defeats all of these scenarios. Even if a certificate chains to a trusted root, if it does not match the pinned value, the connection is rejected. An attacker who obtains a fraudulent certificate from a CA cannot intercept pinned connections. A corporate proxy that terminates and re-encrypts TLS cannot intercept pinned connections.
The operational risk that makes pinning dangerous without preparation
Certificate pinning is the SSL practice most likely to break a mobile app in production. The risk: when you rotate or renew the backend certificate, users running app versions that pin the old certificate or old key immediately lose connectivity. They see a connection error with no explanation and no recourse except to update the app. If a significant portion of your user base is on an older app version, a certificate rotation becomes a breaking change.
This risk is severe enough that Google removed HTTP Public Key Pinning (HPKP) from Chrome in 2018, citing the risk of misconfiguration causing widespread access breakage. Mobile app pinning carries the same risk in a context where you control the app but not how quickly users update.
Public key pinning vs certificate pinning
The most important decision in implementing pinning is whether to pin the certificate itself or the certificate’s public key hash.
Certificate pinning pins the exact certificate: the certificate’s SHA-256 hash is hardcoded in the app. When the certificate expires and is replaced (even with the same key), the new certificate has a different hash. All pinned app versions immediately break.
Public key pinning pins the public key hash: the SHA-256 hash of the certificate’s SubjectPublicKeyInfo. The public key does not change when the certificate is renewed if you use the same key pair. Certificate renewal with the same key (which is supported by Let’s Encrypt and most CAs) does not break public key pinned connections. Only a key rotation breaks them.
For any production implementation, public key pinning is strongly preferred over certificate pinning. It allows normal certificate renewal cycles without breaking pinned app connections, reducing the operational risk to only the scenario where you intentionally rotate the key pair.
The standard operational pattern for safe pinning: pin two public key hashes. The primary key (the one currently in use) and a backup key (a different key pair whose certificate has not been issued yet, but whose public key hash is already pinned in the app). When you need to rotate the primary key, issue a certificate for the backup key, promote it to primary, generate a new backup key, and ship an app update that updates the pins. This two-pin approach ensures continuity: the backup pin is always valid for the transition period.
Should your app pin certificates?
For most apps, pinning is not necessary. Standard TLS validation with a certificate from a public CA provides adequate security for the vast majority of use cases. The CA ecosystem has significant checks and balances (Certificate Transparency logging, browser and OS root programs with strict requirements, incident response processes for compromised CAs).
Pinning is appropriate for: apps handling very high-value transactions where MitM even by a rogue CA is a significant threat model, apps used in environments where corporate proxy interception is a specific concern, financial apps, healthcare apps with sensitive data, or any app where the security engineering team has assessed that the additional protection justifies the operational complexity.
If you do implement pinning, the operational process for managing it must be established before the first pinned app ships. Unplanned certificate rotation after deployment is the specific scenario that has broken high-profile apps in the past.
Common Scenarios and What to Do
| Scenario | What to do |
| Building a new app with a backend API | Obtain a standard DV certificate for the API domain. Let’s Encrypt with Certbot (free) or a managed certificate service. Set up automated renewal. No pinning needed unless your threat model specifically requires it. |
| App is getting connection errors after backend changes | Check the API server’s SSL certificate: has it expired? Is the certificate chain complete (intermediate included)? Does the hostname match? Run SSL Labs on the API domain. Check that TLS 1.2+ is supported with forward secrecy cipher suites. |
| Need to inspect app traffic in development (proxy like Charles or mitmproxy) | iOS: install the proxy CA certificate in device Settings and add an ATS exception or Network Security Config entry for debug builds. Android: add a network_security_config.xml that trusts user CAs in debug builds only. Never include proxy trust in production builds. |
| Planning a certificate rotation on a pinned app | If public key pinning: renew the certificate with the same key pair. No app update needed. If certificate pinning: ship an app update with the new certificate hash before rotating the certificate on the server. Stage the rollout to minimize the window between server rotation and user update. |
| Users on old app versions after a certificate rotation with certificate pinning | You cannot fix the old app versions. Those users must update the app. Consider urgent app update notifications. This is why public key pinning is strongly preferred over certificate pinning. |
| App connects to third-party APIs with SSL issues | If you control the third-party: fix their SSL configuration. If you don’t: add specific ATS domain exceptions (iOS) or domain-specific Network Security Config (Android) with App Store/Play Store justification. Avoid broad exceptions. |
Frequently Asked Questions
Does my mobile app need an SSL certificate?
Not directly. Mobile apps are not servers and do not present SSL certificates. What your app needs is for the backend API and any other servers it communicates with to have valid SSL certificates. The certificate is installed on the server, not in the app. iOS App Transport Security and Android Network Security Config both require HTTPS for app connections and enforce minimum TLS requirements. If your API server has a valid certificate meeting these requirements, your app connects successfully.
What happens when my API certificate expires if users are on my mobile app?
All users lose connectivity to your app immediately and cannot override it. Unlike browsers, which can show a warning that users click through, mobile platforms block connections to servers with certificate errors with no user override option. Users see a generic connection error, the app stops working, and the only fix is renewing and deploying the new certificate on the API server. This is why automated certificate renewal and certificate expiry monitoring are essential for any production mobile app backend.
What is certificate pinning in mobile apps?
Certificate pinning is an app-level security technique where the app is configured to accept only a specific certificate or public key when connecting to a server, rather than accepting any certificate that chains to a trusted CA. It protects against MitM attacks that use fraudulent certificates from compromised CAs, and prevents corporate proxies from intercepting app traffic. The risk is that it breaks app connectivity if the server certificate is rotated without updating the pinned value in the app. Public key pinning (pinning the key hash rather than the certificate hash) is safer than certificate pinning because certificate renewals with the same key do not break pinned connections.
What TLS certificate does an iOS app require from its API server?
App Transport Security requires: HTTPS (no HTTP), TLS 1.2 minimum (TLS 1.3 preferred), certificate chaining to a root in Apple’s root program, forward secrecy cipher suites using ECDHE key exchange, SHA-256 or stronger certificate signature hash, and RSA keys of at least 2048 bits or ECC keys of at least 256 bits. A standard DV certificate from any major public CA (Let’s Encrypt, DigiCert, Sectigo, etc.) issued with modern defaults satisfies all of these requirements. Self-signed certificates and certificates from private CAs do not chain to Apple’s trusted roots and will be rejected unless an ATS exception is configured.
Can I test my app with HTTP during development?
Yes, with platform-specific configuration. For iOS, add an ATS exception in Info.plist for the specific development hostname or for localhost. For Android, create a debug network_security_config.xml that allows cleartext or trusts user-installed CAs, referenced only in debug builds. Both platforms support debug-specific security configurations that should never be included in production builds. Never ship production apps with broad ATS or Network Security Config exceptions that would allow insecure connections to production servers.
