Certificate suddenly not work on IOS devices

Hi all,please forgive my bad english,I come from HK.thanks.

I have a site https://proxy.i553041.ml,suddenly not work in IOS,it really suddenly,I didn’t touch any server settings,In few days ago,use ios browser (safari、 chrome) access my site (https) suddenly not work,ios Chrome show ERR_CONNECTION_FAILED,ios safari show “Safari cannot open the page because it could not connect to the internet.”

but in Mac,I use 4 browsers (Safari、 Chrome、Opera、Microsoft Edge),access my site,it don’t have any problem,but firefox still fail,the error is “The connection was reset”

I don’t have Android & Windows PC,so I can’t make a test.

I’ve tried many ios device,use ios access my site,all fail

Again,this problem is suddenly happen,I don’t know why.

I already google,this user exactly same as my case:

Some issue with Apple device

But use his method add this line in Nginx cannot solve my problem:

ssl_session_cache shared:SSL:10m;

because my site config file already have this line.

I’m using Ubuntu 18.04.2,nginx 1.17.3,here is my sites settings:

server {
listen 443 ssl;
listen [::]:443 ssl;
server_name proxy.i553041.ml;
root /var/www/proxy.i553041.ml;
index index.html;
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519:P-256:P-384:P-224:P-521;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE+A$
ssl_certificate /etc/xxx/wildcard.crt;
ssl_certificate_key /etc/xxx/wildcard.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;

location = /favicon.ico {
    log_not_found off;

}
}

==================

Please help!

thank you!

I have another site(it’s my friends site),I help him make up a web server,also use ubuntu / nginx / use same settings(just difference domain),use IOS access his site (https) also suddenly not work.

1 Like

it works from firefox here, but it looks like your domain’s dns is broken (like it timeouts half of the time)

1 Like

Hi @i553041

checking your site there are Cloudflare ip addresses - and one old ip - https://check-your-website.server-daten.de/?q=proxy.i553041.ml

Host T IP-Address is auth. ∑ Queries ∑ Timeout
proxy.i553041.ml C i553041.ml yes 1 0
A 104.31.90.126 Ashburn/Virginia/United States (US) - Cloudflare, Inc. No Hostname found yes
A 104.31.91.126 Ashburn/Virginia/United States (US) - Cloudflare, Inc. No Hostname found yes
AAAA 2606:4700:30::681f:5a7e Ashburn/Virginia/United States (US) - Cloudflare, Inc. yes
AAAA 2606:4700:30::681f:5b7e Ashburn/Virginia/United States (US) - Cloudflare, Inc. yes
www.proxy.i553041.ml Name Error yes 1 0
proxy.i553041.ml A 138.19.40.117 Central/Central and Western District/Hong Kong (HK) - Hong Kong Broadband Network Ltd No Hostname found no

All Cloudflare addresses are working, ipv4 and ipv6.

Only the old ip address doesn't work. May be only a problem with that old, not longer working ip address.

What says

ping proxy.i553041.ml

from one not working device? If you see the 138.* ip address, ignore the problem.

What's the ip address of your server? Check your ip address directly, then you see, if it works.

1 Like

there is a site behind it, but it just redirects to main one immediately.

That's not a http redirect, the http status is 200. Instead, it's a meta refresh.

<!DOCTYPE html> <html> <head> 
<meta http-equiv="Refresh" content="0; url=//www.i553041.ml" />
 </head> <body> 
<p>Please follow <a href="//www.i553041.ml/">this link</a>.</p> 
<script defer src="https://static.cloudflareinsights.com/beacon.min.js" data-cf-beacon='{"rayId":"53dd8682590cd125","version":"2019.10.2","startTime":1575124291525}'>
</script> </body> </html> 
2 Likes

Thank you for reply,I use cloudflare CDN,
www.i553041.ml <—use cloudflare CDN and cloudflare certificate,the sites works

proxy.i553041.ml <—I didn’t use cloudflare CDN,In cloudflare DNS setting page,I make a CNAME record point to my domain “i553041.ml”,and “i553041.ml” have A record,point to my IP address 138.19.40.117,I use letsencrypt certificate on this domain

138.19.40.117 is my server IP address

Yes,just make a small test,create a redirect index.html

Mac (Computer browser),Safari,chrome,Opera,Microsoft edge,access https://proxy.i553041.ml can redirect to https://www.i553041.ml (except firefox,firefox fail)

but use IOS browser, access https://proxy.i553041.ml,I can’t connect the site anymore.

I’ve already tried to use 3 iPhone to test,also fail.

that redirect make debug harder, just remove it and print “hello world” or something

1 Like

Thanks,please wait a second,I make a simple index.html again.

I already change the index.html to hello world.

I noticed your site uses HSTS, but not preloaded to browsers(has preload tag, but not requested to list),

Status: i553041.ml is not preloaded.

Eligibility: i553041.ml is eligible for the HSTS preload list.

and you are not listening on port 80. then first connect will fail unless you add https in front of it because it can't ever see HSTS tag. (try http:80 and nothing reply, end of story)
open port 80 and add 301 redirect to it.
if you ever visited i553041.ml then it will see it's hsts with includesubdomain, so proxy.i553041.ml will work because browser remembers it.

2 Likes

Thanks,let me try,and I will update the result

keep mind you need to clear hsts cache for real test, or use curl which ignore hsts.

1 Like

It works

but can I ask why it suddenly happen?because my site didn’t listen port 80 very long time already.my site always listen port 443.

I didn’t touch the server settings.

1 Like

you: most likely visted i553041.ml, so it remembers HSTS header with includesubdomain, so when visit proxy. subdomain, it remembers hsts and go straight to https -> succeed.
new device: never visited i553041.ml, so it never saw HSTS header. it tried new site with http because without schema it assumes it. and you have no http host, so it fails.

1 Like

Thanks and very clear.

1 Like

If your proxy... has a CNAME to your main domain and if your main domain uses Cloudflare, your proxy... uses Cloudflare, because the same ip addresses are used.

Checking your ip there is only Tls.1.3 active.

P https://138.19.40.117/ 138.19.40.117
-10
Error creating a TLS-Connection: TLSv1.3 found, but no connection via TLSv1.2 possible. Please activate TLSv1.2

That's bad, Tls.1.2 should be active, that's not a deprecated protocol.

2 Likes

That's what I want to ask the other question,yesterday I found that my hostname proxy.i553041.ml only can run TLS1.3,but my nginx config file set it run TLS 1.2 / 1.3

I've tried many setting,I want the hostname can also run TLS1.2,but no luck,use SSL Server test / curl -kVI .... it also run TLS 1.3 only

I want my host run 1.2 & 1.3

so today,I remove the proxy.i553041.ml,and create a new hostname,use certbot generate a new certificate.

The hostname call h2.i553041.ml

Here is my nginx settings:

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name h2.i553041.ml;
root /var/www/h2.i553041.ml;
index index.html;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519:P-256:P-384:P-224:P-521;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE+AES128:RSA+AES128:ECDHE+AES256;
ssl_certificate /etc/letsencrypt/live/h2.i553041.ml/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/h2.i553041.ml/privkey.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;
}
location = /favicon.ico {
log_not_found off;
}
}

but it is the same,use curl -kvI https://h2.i553041.ml , it show TLS1.3 only.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; <---I already set do not use TLS 1.3 only

ssl_ciphers <---I already set TLS1.2 & TLS 1.3 ciphers

but my hostname still only can use TLS 1.3

I really don't know what happen.

curl -kvI https://h2.i553041.ml

  • Rebuilt URL to: https://h2.i553041.ml/

  • Trying 138.19.40.117...

  • TCP_NODELAY set

  • Connected to h2.i553041.ml (138.19.40.117) port 443 (#0)

  • ALPN, offering h2

  • ALPN, offering http/1.1

  • successfully set certificate verify locations:

  • CAfile: /etc/ssl/certs/ca-certificates.crt

CApath: /etc/ssl/certs

  • TLSv1.3 (OUT), TLS handshake, Client hello (1):

  • TLSv1.3 (IN), TLS handshake, Server hello (2):

  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):

  • TLSv1.3 (IN), TLS handshake, Unknown (8):

  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):

  • TLSv1.3 (IN), TLS handshake, Certificate (11):

  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):

  • TLSv1.3 (IN), TLS handshake, CERT verify (15):

  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):

  • TLSv1.3 (IN), TLS handshake, Finished (20):

  • TLSv1.3 (OUT), TLS change cipher, Client hello (1):

  • TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):

  • TLSv1.3 (OUT), TLS handshake, Finished (20):

  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

  • ALPN, server accepted to use h2

  • Server certificate:

  • subject: CN=h2.i553041.ml

  • start date: Dec 1 13:08:22 2019 GMT

  • expire date: Feb 29 13:08:22 2020 GMT

  • issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3

  • SSL certificate verify ok.

  • Using HTTP2, server supports multi-use

  • Connection state changed (HTTP/2 confirmed)

  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0

  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):

  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):

  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):

  • Using Stream ID: 1 (easy handle 0x1cfa750)

  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):

HEAD / HTTP/2

Host: h2.i553041.ml

User-Agent: curl/7.58.0

Accept: /

  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

  • TLSv1.3 (IN), TLS Unknown, Unknown (23):

  • Connection state changed (MAX_CONCURRENT_STREAMS updated)!

  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):

< HTTP/2 200

HTTP/2 200

< server: nginx/1.17.3

server: nginx/1.17.3

< date: Mon, 02 Dec 2019 16:08:04 GMT

date: Mon, 02 Dec 2019 16:08:04 GMT

< content-type: text/html

content-type: text/html

< content-length: 205

content-length: 205

< last-modified: Sat, 30 Nov 2019 10:59:17 GMT

last-modified: Sat, 30 Nov 2019 10:59:17 GMT

< vary: Accept-Encoding

vary: Accept-Encoding

< etag: "5de24b85-cd"

etag: "5de24b85-cd"

< strict-transport-security: max-age=31536000; includeSubDomains

strict-transport-security: max-age=31536000; includeSubDomains

< accept-ranges: bytes

accept-ranges: bytes

<

  • Connection #0 to host h2.i553041.ml left intact
1 Like

If you use Cloudflare, there is an option: Tls.1.3, 1.2 ... - check, if Tls.1.2 is activated.

Sometimes only Tls.1.3 is allowed.

But checking your raw ip https://check-your-website.server-daten.de/?q=138.19.40.117 - there is only Tls.1.3

What says

nginx -T
1 Like

But checking your raw ip https://check-your-website.server-daten.de/?q=138.19.40.117 - there is only Tls.1.3 <-----That’s why I don’t understand,my nginx setting is set it to run TLS1.2 and 1.3,but actually the site only run on 1.3.

Minimum TLS Version <-----I set 1.2 and shutdown TLS 1.3 on cloudflare already,but use curl -kvl to check,no change,the site cannot run TLS1.2

nginx -T <—it show all my nginx config file’s content.

1 Like