Trust issues on safari for iOS

Server
1

Hi all,

Thanks in advance for supporting this. I really appreciate the help and the product in the first place.

I am running a self configured server with Apache2 on an EC2 instance on AWS and I am tearing my hair out with weird issues on the site.

In the beginning it there was plain http. This worked well on the desktop with chrome and Firefox (didn’t test safari desktop), but had a really aggravating white screen of nothing when I tried to use my ipad or iPhone. Also, (and I have no clue why this was) it seemed like it was sending an initial request to the server, then showing a white screen of death, then if I refreshed the page or cleared the cache and refreshed the page, it wouldn’t even make a new request to the server. There was nothing in the Apache access logs and I couldn’t find any trace of the ipad actually looking for the website. I spoke to some friends who said that China might be injecting some mess into the site as they sometimes do (I’m in China - Server’s in Japan) so I decided to try ssl.

Enter Let’s Encrypt. With ease (thank you), I installed the certificate using certbot and added a virtual host on port 80 at the top of the file that does nothing but redirect traffic to https://my-site.

But… the certificate isn’t trusted. It’s not trusted in safari or in chrome on iOS, and it sometimes comes up with that horrible warning sign in chrome on desktop that will make visitors think your website has been taken over by anonymous or something (The “This website is not secure/might be under attack/etc” one). Weirdly, though, it’s only sometimes.

If anyone’s got any clue what I’ve misconfigured, I’d be really grateful.
It’s a Ubuntu 16 server on EC2 running Apache2.4.18 with mod_wsgi enabled.

https://www.ssllabs.com/ssltest/analyze.html?d=sq-research.com

<VirtualHost *:80>
	Redirect / https://sq-research.com
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
### Commented stuff at the head of the file I've deleted

        ServerAdmin tom@sq-research.com
        ServerName sq-research.com
        ServerAlias www.sq-research.com
        LogLevel debug

### In this space goes stuff to serve files for django and mod_wsgi setup

SSLCertificateChainFile /etc/letsencrypt/live/sq-research.com/chain.pem
SSLCertificateFile /etc/letsencrypt/live/sq-research.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/sq-research.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
2

Hi @staneslevski,

I notice that a dig for sq-research.com returns two A records:

$>dig +short sq-research.com
13.115.254.226
192.64.119.50

The first IP 13.115.254.226 serves a valid seeming chain with a Let’s Encrypt leaf certificate on port 443.
The second IP 192.64.119.50 refuses to connect on port 443.

This doesn’t explain an intermittent certificate validation failure, but the “white screen” behaviour you mentioned may be related. It does seem like this will cause reachability issues for any clients that try the 192 address.

If you remove the problematic A record does the issue persist?

EDIT: The linked ssl labs report also shows the same thing RE: two A records, one unreachable.

3

Yeah, that confused me too… because I don’t have another A Record setup in the DNS. I checked the Whois on the address and it’s registered to namecheap (my domain registrar). Is it possible that it’s something set up by them as a redirect?

4

Very mysterious! That hypothesis seems plausible to me but I'm not very familiar with Namecheap's systems.

5

Okay. After a little bit of DNS magic and searching through Namecheap’s settings I found that they had very kindly set up a redirect of www.my-site to http://mysite… which is helpful, except that it was also the cause of the problem. So I removed it and now it’s almost solved.

The certificate is now trusted by the browser but I think I only set up the sq-research.com domain when I ran certbot. Could you explain how I could add www variant as well?

6

Awesome! That's progress! :tada:

I believe you can simply re-run Certbot with the same arguments you used as before (with a -d sq-research.com), but also adding -d www.sq-research.com --expand. The --expand part is the key bit. The full documentation for this feature is here.

7

Amazing. Thank you so much for your help. I think the CNAME record redirecting www to the bare domain is functioning now so all is well and all is trusted.

Thank you so much! My hair is safe once more.

1 Like
8

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