What web developers should know about HTTPS but probably don't.

The most common questions we get from developers who already know their stuff

January 13, 2026

TL;DR: SSL/TLS is required everywhere now

Whether you’re building a frontend that calls APIs, writing a backend service that talks to third-party endpoints, or deploying anything to production—HTTPS isn’t optional anymore. Browsers block mixed content, APIs reject insecure connections, and mobile apps require certificate validation.

This means you need SSL/TLS to work correctly on both sides: as a client (when your code connects to other services) and as a server (when browsers or other services connect to you). The steps below cover the most common issues developers hit when making this work.

Web developers today understand more about SSL/TLS than ever before. Here’s what you should know:

  • You can get domain validated (DV) certs from Let’s Encrypt for free.
  • The Mozilla SSL Config Generator can set up your server as secure as possible for the browsers you want to support.
  • When you’re done, use SSL Labs to check everything. Make sure you get an A, otherwise people will pick on you.
  • TLS 1.3 is now the standard - it’s faster and more secure than TLS 1.2.
  • TLS 1.0 and 1.1 are deprecated - all major browsers dropped support in 2020.

What about the rest? Here are answers to the most common questions from our customers:

1. Fixing ERR_SSL_VERSION_OR_CIPHER_MISMATCH or ‘obsolete cipher suite’ in Chrome

Both these errors are related, but ERR_SSL_VERSION_OR_CIPHER_MISMATCH has the more obvious fix: update your TLS/SSL versions and ciphers your server is configured to use.

If Chrome complains about:

connection is encrypted using an obsolete cipher suite

The fix is the same, the only difference is that this error doesn’t show up in SSL Labs. You need to put GCM ciphers before CBC ciphers in your web server’s config file.

Fixing either error is easy: the Mozilla SSL Config Generator shows the right config for most web servers. Update your config file, restart your web server and the problem will be resolved.

2. Fixing key / certificate mismatches

If you’ve:

  • Changed your encryption
  • Renewed your certificate
  • Lost your private key and made a new keypair

There’s a good chance you have a bunch of files with the same names, belonging to different keypairs. If your web server tells you something like:

Error: Public Key Certificate and Private Key doesn’t match

This means you’ve made multiple key pairs, and are trying to use the private key from one keypair with the certificate from another.

To check whether a certificate file matches a private key, check the modulus.

# Check the modulus of a certificate
openssl x509 -noout -modulus -in example.com.crt | shasum -a 256
# Check the modulus of a key
openssl rsa -noout -modulus -in example.com.key | shasum -a 256
# Check the modulus of a certificate request
openssl req -noout -modulus -in example.com.csr | shasum -a 256

If the modulus is the same, the private key and certificate match: in other words, they belong to the same pair.

If the modulus is different, the files aren’t part of the same pair and were created independently.

3. Setting up working HTTPS on localhost

Use geolocation? WebRTC? Password and credit card forms? Modern browsers need HTTPS for security-sensitive HTML5 features.

If you have an invalid https:// setup on localhost, you’ll be spending way too much time clicking through HTTPS warnings. The easiest solution is to use mkcert, a simple tool that creates locally-trusted development certificates with no configuration.

4. You probably don’t want a 4096 bit RSA certificate

1024 bit RSA is considered insecure. Nearly every website you visit uses 2048 bit RSA. So why not go the extra mile and get a 4096 bit RSA cert?

The answer is that the additional load can slow down the SSL handshake between browsers and your site. We’ve measured this extensively - 4096-bit handshakes are about 6x slower than 2048-bit, adding roughly 26ms of latency.

Additionally, your CA’s intermediate certificate is likely to be a 2048 bit RSA cert. If you consider 2048 bit RSA to be insufficiently strong, the CA’s 2048 bit intermediate cert could still be attacked and used to issue a fake certificate for your organization. Certificate Transparency now provides protection against this without the risks of the deprecated HPKP standard.

If you’re concerned about strength, try an ECDSA certificate instead of RSA. They’re significantly stronger while using less CPU than RSA - a 256 bit ECC key is equivalent to 3072 bit RSA. In fact, most major sites (Google, Facebook, Apple, Cloudflare) have already moved to ECC.

ECC support is ubiquitous across all modern browsers and cloud providers. If you’re deploying to Heroku, both RSA and ECDSA certificates are fully supported.

5. How to convert between the common SSL file formats

There’s a bunch of file formats related to PKI and SSL, but most server software these days uses just two:

PEM

  • The format used by haproxy, nginx, Apache, node, and everything else that uses openssl.
  • PEM is text based - keys, certificates and CA certificates use the -----BEGIN (TYPE)----- and -----END (TYPE)-----
  • These are typically in separate files, but can also be combined together - either paste them into the same file, or split them into multiple files with a text editor.

PKCS12

  • A binary format used by Windows and Tomcat (in its default configuration), with the extension .pfx or .p12.
  • Combines the private keys, certificates and intermediary certificates into a single file.

You can flip between them easily:

# Convert PEM to PKCS12
openssl pkcs12 -export -inkey privatekey.pem -in cert.pem -certfile cacert.pem -out bundle.p12
# Convert PKCS12 file to PEM
# (you can then chop the files up with a text editor)
openssl pkcs12 -nodes -in bundle.p12 -out bundle.pem

That’s it for now

For Heroku applications, our Expedited SSL service handles most of these configuration complexities automatically. For applications requiring compliance certifications like PCI DSS or HIPAA, proper SSL/TLS configuration is just the beginning—check out our Web Application Firewall for comprehensive protection.