Let's encrypt certificate not accepted by Safari and Chrome on iOS 16.2

Help
1

Multiple people reported an issue to me, all owning Apple devices (iPhone, iPad and Mac).
I myself can reproduce it with my MacBook (and Safari 16.0). The Mac has both ISRG Root X1 and ISRG Root X2 installed in the keychain. Chrome also does not work, Firefox does (but i guess because they do not use the OS cert store but instead their own built in cert store.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
cloud.alexh.rocks

I ran this command:
https://www.ssllabs.com/ssltest/analyze.html?d=cloud.alexh.rocks
It says the iOS handshake is fine.

It produced this output:
Grade A, everything ok

My web server is (include version):
Nginx (controlled by https://nginxproxymanager.com/

The operating system my web server runs on is (include version):
debian 11

My hosting provider, if applicable, is:
self hosted VM

I can login to a root shell on my machine (yes or no, or I don't know):
yep
nginx access log:
"GET /s/XYZ HTTP/1.1" 200 10078 "-" "Mozilla/5.0 (iPad; CPU OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1

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

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

1 Like
2

I agree that it looks like your server is sending the correct certificate & chain, though I don't have an Apple device to test, connecting via openssl on a Linux system is working fine. Can you describe more specifically what the error is when you say "an issue" and "doesn't work", exactly what the error is along with any details you can get about it?

4 Likes
3

It looks like your server might not be working when a client is connecting using HTTP 2.

curl -v --http1.1 https://cloud.alexh.rocks gives me a 302 Found redirect to https://cloud.alexh.rocks/login

But curl -v --http2 https://cloud.alexh.rocks gives me

curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

So I think there's something wrong with your server's handling of HTTP 2, but I don't think it's related to your certificate at all.

4 Likes
4

These seem confusing:
#1
image
#2
image

3 Likes
5

Safari on MacOS threw this error at me, but i couldn't find any information on that
NSURLErrorDomain: -1017

Digging into the curl output myself, looks like server is providing a header field "upgrade" which is fine for HTTP/1 but ILLEGAL in HTTP/2
http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [upgrade], value: [h2]

Definitely not a certificate issue.
Thank you guys for your quick help!

3 Likes
6

Confirmed fix:
told nginx proxy (that applies the ssl cert) to NOT pass the HTTP/1 upgrade header towards the client.
Apparently, the proxy talks HTTP/1.1 to the service and is not clearing invalid headers before sending it to the actual client via HTTP/2

3 Likes
7

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