Agreed. I see that now. The www subdomain seems fine. Requests to your apex domain is the only one missing the intermediate chain. Requests to https://preciselyparrots.com will fail. Requests to http://preciselyparrots.com redirect to https://www... so work fine.
The default chain from Let's Encrypt has two paths. Only one needs to be valid. The DST Root CA X3 is provided for compatibility with older Android clients. See topic below. There is considerable talk in this forum about the "long" and "short" chains. SSL Labs is not the easiest to interpret for the default long chain. This forum uses the long chain the same as you are for www parrots. See what this forum domain looks like in SSL Labs.
Yes. I've always redirected the apex domain to the www subdomain. So since no real issue is created by the failing DST Root CA X3 short path, I'll take it to be good enough for now.
The other issue, of course, is the lack of SNI support. Since to my understanding that's only an issue for non-SNI browsers, I suppose it's another low-priority concern. I did try adding the SSLStrictSNIVHostCheck directive to the default vhost (in both off and on states), as well as to some of the other vhosts (in both off and on states). But any combination resulted in ssl labs continuing to report the SNI error. As such, I'm guessing something else needs to be done to resolve the matter. However, since it's no huge issue either, I'm not inclined to waste more time on it for now.
You cannot prevent a client from trying to access your site without SNI. Although, all modern browsers support SNI and have for a long time so you would know if you needed to support non-SNI clients.
The only problem you should correct is your VirtualHost for the apex domain and port 443 (https) so that it uses the proper chain and won't fail a redirect. This is what happens:
curl https://preciselyparrots.com
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
I take your point. But considering that I redirect all requests for the apex to the www subdomain, someone would have to manually change the URL after the redirect loads to encounter that issue. If they're doing that then I won't feel too concerned about any failures they may encounter.
Not necessarily. People try domain names of various kinds. And, some browsers even try several connections at once (http and https for example). And, browsers are moving towards favoring https always.
All your domains should respond in a sensible way.
In the end it's up to you. But it seems a minor thing to correct. It doesn't work right today so no harm in changing it to be more compliant.
Here's a question for you: Considering that running the apex domain name for relay-link.net renders no intermediate link issue reports, why does running the parrot site's apex hang at R3 with the warning "extra download," while running the relay-link site's apex accepts R3 and shows "sent by server" as it should? I'd think both sites should behave the same way since there's parallel similarity among them - especially the fact that they're using the same intermediate certificate (its fingerprint is identical on the reports from both hostnames).
It has me wondering whether some bugs may need to be worked out of Qualy's chain assessment system. They state it's new and experimantal on their description/info page:
They are not the same. parrots is not sending intermediates only the leaf. If you show the Apache VirtualHost for parrots I can advise better.
SSL Labs can be difficult to interpret. The "extra download" is because that's what it had to do to build a chain. And, a browser may be able to find that too if it has one in cache or something but there is no certainty of that.
This SSL Checker is clearer and is mostly just openssl. You can see a clear difference between your two apex domains. I would show you an openssl command but your system is so old I'm not sure of the proper format for that.
Other than their in-line order, their separate documentroot public_html subdirectory paths, and their separate cert and key subdirectory paths, the vhost configurations are exactly the same. But you'll have to take my word for that; I'm not going to paste them here.
The facts I see say your parrots domain is not responding as you expect then. If the cert config is the same perhaps there is another VirtualHost that is responding rather than the one you expect. I think we suggested reviewing apachectl -S earlier.
I'm probably better off stopping comments. I've pointed out something is different using several sources. You insist your server and certs are the same but won't provide details. Not much more I can help with.
openssl from my own test server shows this which is the same as seen by SSL Labs and the other SSL Checker I linked. Note just the one cert and no chain.
One new idea. Perhaps you don't care about this but let's ignore the missing cert intermediates (with the -k). Someone requesting https to your apex domain gets the below page (dated Apr2015) rather than redirecting to your forum page
curl -ik https://preciselyparrots.com
HTTP/1.1 200 OK
Date: Sun, 19 Feb 2023 05:10:07 GMT
Server: Apache/2
Last-Modified: Sat, 04 Apr 2015 20:47:54 GMT
<html><head><title>Secured Home of preciselyparrots.com</title></head>
<body>
<center>Welcome to preciselyparrots.com<br>
To change this page, upload a new index.html to your private_html folder<br></center>
</body>
</html>