Chrome & Safari - Your connection is not private ERROR

Help
21

Hi @poldi171254,

The problem in your case is

If you can't upgrade to Certbot 1.12, you could manually edit the chain file in /etc/letsencrypt/live to remove the X3 certificate if users have a conflict with that. This is not a particularly elegant or convenient solution compared to running a newer Certbot.

It's important to understand that the "long chain" (containing the expired certificate, which is recommended by default for compatibility with older Android clients) does cause compatibility problems with some other systems, which may be fixable by changing to the "short chain" (excluding the X3 certificate from the chain). But this will not in any case restore compatibility with clients running macOS prior to 10.12.1; Let's Encrypt is now permanently incompatible with these clients, regardless of which chain you use, unless end-users manually install the ISRG X1 root certificate or switch to Firefox, or unless Apple decides to issue a software update for these otherwise-out-of-support OSes. See Certificate Compatibility - Let's Encrypt for more details.

3 Likes
22

Thanks for that

2 Likes
23

Thanks.
Installed the latest certbot and was able to set the preferred-chain.
That fixed access for the Chrome Browser, but I have users who say they their Safari runs on the latest MacOS version and they still get the security warning. I don't have any apple gear so can't check.
Mind you the site still fails server tests (ie. SSL Server Test (Powered by Qualys SSL Labs)) with an invalid license, but now works on Firefox and Chrome Browser

1 Like
24

You might be misunderstanding, or over emphasizing, the message shown for Path #2.

2 Likes
25

Not sure I follow.

The screenshot shows that the certificate isn't trusted

L1
L11006×796 75 KB

Not sure what this looked like before the end of september
Sorry, should have mentions this before.
The site is running on the latest Ubuntu LTS server and Apache with all up to date.
And the certificate is wildcard

1 Like
26

I would start to unravel that Apache mess with the output of:
sudo apachectl -t -D DUMP_VHOSTS

OR
are you trying to connect to: https://zudiewiener.com/ ?
If so, the wildcard cert doesn't cover that name.
It only covers name that end with ".zudiewiener.com" (notice the leading dot)
[note: they also won't cover name that have more dots than the ones shown in the cert name]

2 Likes
27

Apologies.
The screenshot was for a different site with the same issue

L2
L21148×672 67.6 KB 

llist@mail:~$ sudo apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80                   www.dragonclaw.net (/etc/apache2/sites-enabled/dragonclaw-net.conf:1)
*:443                  is a NameVirtualHost
         default server www.dragonclaw.net (/etc/apache2/sites-enabled/dragonclaw-net-ssl.conf:2)
         port 443 namevhost www.dragonclaw.net (/etc/apache2/sites-enabled/dragonclaw-net-ssl.conf:2)
                 alias dragonclaw.net
1 Like
28

Try (with "www"):
SSL Server Test: www.dragonclaw.net (Powered by Qualys SSL Labs)

If you want the apex domain, you need to include it in the HTTP vhost config:

And in the cert too.

4 Likes
29

@rg305 is exactly right here: Safari and Chrome disagree about whether a certificate for *.example.com also covers example.com or not. Chrome believes it does; Safari believes it doesn't. Safari is more correct according to Internet standards.

3 Likes
30

Dohhhh.
Thanks

2 Likes
31

Safari may be more correct, just not sure what's going on.
I understand the inital issue with the expiry of the root certificate.
Not sure why after fixing the original problem, Safary still doesn 'work', when it previosuly happily worked with a wildcard certificate

1 Like
32

Is it clear that people were accessing https://dragonclaw.net/ with Safari, as opposed to https://www.dragonclaw.net/? If people went to http://dragonclaw.net/ (not HTTPS), they would have been redirected to https://www.dragonclaw.net/.

2 Likes
33

Just confirmed with a user that everything works as expected if they use www.dragonclaw.net

Knowing the users, they would have accessed the site with just dragonclaw.net before, but not sure why that would have worked.

1 Like
34

My solution is to proxy through cloudflare.

2 Likes
35

just be sure Cloudflare SSL cert is provided by Digicert and not Letsencrypt Cloudflare Universal SSL switch Letsencrypt to Digicert CA :slight_smile:

2 Likes
36

FYI: This is typically not an issue caused by users, but deliberate planned obsolescence by Apple in search of increased profits. Apple made a business decision to prohibit legacy hardware from running newer operating systems; third party tools must be used to patch OS X installers (10.11-10.15) to run on a range of older Macs that have more than enough computing power to run them. They've also limited their support windows for operating system updates to around 3 years - which is rather short for commercial products when compared to 5 year active windows (and longer security updates) for FOSS.

Apple should have supported upgrading the OS of older machines; and Apple should have continued issuing Trust Store updates for older operating systems.

7 Likes
37

True true. I'd need to add "In an ideal world, software is supported longer than just a few years."

4 Likes
38

It would have worked if they just typed "dragonclaw.net" and not "https://dragonclaw.net/" into their browsers, because "http://dragonclaw.net/", which doesn't need a certificate, would have generated an automatic redirect to "https://www.dragonclaw.net/", which has a valid certificate. That's my best guess so far.

3 Likes
39

You are correct.
After fixing the initial issue, I found out that some users go to https://dragonclaw.net, which of course doesn't have a cert.
dragonclaw.net, www.dragonclaw.net, https://www.dragonclaw.net
all (now) work as expected.
Thanks for your help

3 Likes
40

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