iOS 14.7.1 "The certificate for this server is invalid" for Ubuntu + Nginx server

My domain is:

I ran this command:
Simply attempted to use the site, all requests fail with below output.

It produced this output:
Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “dev.hiwayfms.com”, which could put your confidential information at risk.

My web server is (include version):
daphne 3.0.2 for python and nginx for frontend

The operating system my web server runs on is (include version):
Ubuntu 18.04.3 LTS

My hosting provider, if applicable, is:
AWS

I can login to a root shell on my machine (yes or no, or I don't know):
Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.20.0

/etc/nginx/sites-available/dev.hiwayfms.com

server {
    server_name dev.hiwayfms.com;
    access_log  /var/www/logs/FMS.access.log;
    error_log  /var/www/logs/FMS.error.log error;
    root /var/www/html/FMS-frontend/build;
    index index.html index.htm;

    location / {
      try_files \$uri \$uri/ /index.html =404;
    }

    location /static/ {
      autoindex on;
    }

    location /cdn/ {
      alias   /var/www/html/FMS-backend/backend/static/;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/dev.hiwayfms.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/dev.hiwayfms.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = dev.hiwayfms.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name dev.hiwayfms.com;
    return 404; # managed by Certbot


}

And likewise daphne is also referring to the fullchain.pem:

daphne -e ssl:8000:privateKey=/etc/letsencrypt/live/dev.hiwayfms.com/privkey.pem:certKey=/etc/letsencrypt/live/dev.hiwayfms.com/fullchain.pem backend.asgi:application

But iOS 14, which according to the compatibility chart should be working just fine, is returning the following error to me on every request:

Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “dev.hiwayfms.com”, which could put your confidential information at risk.

openssl can provide this output

openssl s_client -connect dev.hiwayfms.com:443 -servername dev.hiwayfms.com -trusted_first |head

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = dev.hiwayfms.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = dev.hiwayfms.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

I have a newly configured server on AWS, used certbot to get a certificate on October 5th. This and every other server I have configured using certbot isn't accessible using iOS 14 devices.

I tried to re-issue the certificate today but that doesn't seem to have helped anything.

Android, PC, Mac browsers all have no issue with the certificate. So what can I do to get iOS to accept this cert-bot issued certificate?

I would ensure that your iOS 14 has the "ISRG Root X1" cert in the trust store.
If that doesn't help...
Either:

  • remove the cross-signed "ISRG Root X1" cert from the fullchain.pem file.

OR

  • explicitly add the "DST Root CA X3" cert in as "always trusted"
    [there are several topics here about adding certs top MacOS]

OR

  • switch to another (free) ACME protocol compatible CA.

In the end, I followed option 3, and switched to another free ACME protocol compatible CA, ZeroSSL, for now. Will surely come back to LetsEncrypt down the road. Thank you!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.