SSL Certificates for APIs and Mobile App Backends

An SSL certificate for API endpoints does the same job as one for a website: it proves to the client that it is talking to your server and encrypts the traffic in transit. If your API is reached by browsers, mobile apps or partner systems you do not control, it needs a publicly trusted certificate. A self-signed or private certificate only works when you also control every client.

Do APIs need a public SSL certificate?

Yes, if public clients call them. Mobile operating systems, browsers and HTTP libraries check the server certificate against their built-in root stores. A certificate from a private CA fails that check unless you ship your own trust anchor in every client – which you cannot do for third-party integrators or browser-based single-page apps.

Internal service-to-service traffic is different. When both ends run inside your network and you control the trust store, a private CA can work. Public CAs also do not issue certificates for internal names or reserved IP addresses, so purely internal hosts are a private-PKI job anyway. For most REST and GraphQL APIs exposed to the internet, domain validated (DV) SSL is the practical fit: the CA confirms you control the domain by email, DNS record or HTTP file, and the encryption strength is the same as with OV or EV.

Which SSL certificate for API hosts like api.example.com?

For one API host, a single-domain certificate is enough. If you run several API subdomains – api.example.com, auth.example.com, sandbox.example.com – a wildcard for *.example.com covers all of them on one subdomain level. A multi-domain (SAN) certificate fits when your endpoints live on different registered domains.

Keep the private key of a wildcard on as few machines as possible. One wildcard key copied across many servers means one leak exposes every subdomain at once.

Should your mobile app pin certificates?

Usually not. Certificate pinning – hard-coding which certificate or public key your app accepts – breaks the app the moment the pinned certificate changes. As of October 2026, public TLS certificates are issued for at most 200 days, falling to 47 days by 2029, so your server certificate will change several times during the life of an installed app version.

Users who do not update their app are then locked out until they do. The OWASP Pinning Cheat Sheet states that the risk of outages almost always outweighs the security gain. Modern clients already validate the full chain, and Certificate Transparency makes mis-issued certificates easier to spot. For the bigger picture on how secure SSL is without pinning, see our security guide.

Tip: If a regulator or customer contract forces you to pin, pin a public key (SubjectPublicKeyInfo) rather than the certificate, include at least one backup pin, and make sure you can update the pin set remotely.

What is mutual TLS (mTLS)?

Mutual TLS means both sides present a certificate: the server proves its identity to the client, and the client proves its identity to the server. It is common for B2B APIs, payment integrations and machine-to-machine traffic where an API key alone is not strong enough.

The client side uses a client authentication certificate. For people, these are sold alongside S/MIME email certificates as personal authentication certificates. For devices and services, most teams run a private CA because they control both ends and need to issue many short-lived certificates.

Note: As of October 2026, public CAs are removing the client authentication purpose (clientAuth EKU) from public TLS server certificates to follow the Chrome Root Program’s rule that server certificate hierarchies serve server authentication only. Do not plan to reuse your API’s server certificate as an mTLS client certificate.

Automating renewals for API endpoints

With lifetimes shrinking towards 47 days, manual renewal does not scale for APIs with several hosts. Paid certificates can be renewed through the same ACME protocol that Certbot and acme.sh use; our guide on ACME with paid certificates shows the setup with External Account Binding.

Two API-specific checks are worth adding. First, serve the full chain (server certificate plus intermediate): browsers often repair a missing intermediate, but many HTTP libraries and app clients do not. Second, test from the client side after each renewal – a mobile app or SDK that worked yesterday can fail on a chain change your browser never notices.