The common name is just a field of the certificate and doesn't represent the actual URL used in the address bar or the result from the redirect.
As far as I know, it's the first hostname you've entered when getting this new certificate. Also, the common name has been deprecated and should be ignored anyway.
root 75016 0.0 0.0 9032 724 pts/0 S+ 13:20 0:00 grep --color=auto -i apache
Frankly I don't know how to interpret this result but is it possible this is the problem?
No that is the running grep process looking for anything containing apache.
If that is all that you found, then it found nothing.
This is what a find looks like:
root 1187 0.0 1.0 143868 6972 ? Ss Jan13 0:29 /usr/sbin/apache2 -k start
www-data 35518 0.0 0.9 1656392 6768 ? Sl 06:25 0:00 /usr/sbin/apache2 -k start
www-data 35519 0.0 0.9 1656392 6768 ? Sl 06:25 0:00 /usr/sbin/apache2 -k start
root 36629 0.0 0.1 13144 1040 pts/0 S+ 21:27 0:00 grep --color=auto -i apache
Or in a narrower view:
ps -ef |grep -i apache
root 1187 1 0 Jan13 ? 00:00:29 /usr/sbin/apache2 -k start
www-data 35518 1187 0 06:25 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 35519 1187 0 06:25 ? 00:00:00 /usr/sbin/apache2 -k start
root 36631 1977 0 21:27 pts/0 00:00:00 grep --color=auto -i apache
Got it, in this case then nothing was found when I stopped apache2 and entered that command. Hopefully this helps rule out possible problems.
Yes, that is pretty much ruled out at this point.
Another user has received the error as of 10 minutes ago and attached this:
And you don't use any kind of load balancer, reverse proxy, or CDN?
It also doesn't seem like something that occurs randomly for some percent of connections, because I just used a script to make several hundred fresh HTTPS connections to your site in a row (over both IPv4 and IPv6), and not a single one showed an invalid certificate!
That is correct!
Re script: haha! Thank you @schoen, this community is amazing, I appreciate everyone's replies, and willingness to help, yours especially.
I think the problem may be described by this overly exaggerated example:
I think it has something to do with how PFS "works" and session resumption requests are processed.
But I don't have the time nor the effort in me to dissect this problem that deeply.
[There is still much GME to be bought - LOL]
That suggestion is also plausible, but in that case, why wouldn't we see lots of site administrators on here every week with that same issue? It seems like it would apply equally to every HTTPS web site!
Maybe...
Or maybe it's just something in the way Apache implements certain things.
Again that was an:
The error continues to occur for many users, unfortunately.
Based on the comments above, it sounds like a caching/cdn/something issue. Sometimes this happens on specific client platforms, other times it can happen because the client uses some network (not just a VPN, but Amazon/ATT/etc often have settings to "optimize" traffic through their systems by doing a lot of browsing in the cloud, then sending a streamlined package to a device)
When this happens, ask your users:
You said your hosting provider is "VPN" is that a company? If so, which one. Or are you somehow hosting through a VPN system? that can introduce some caching issues itself.
Sorry, that was my mistake -- using a VPS with Linode.
Weirdly enough, I've been able to reproduce itâwith IPv6 but not IPv4âtoday for the first time.
I thought there could be an issue about IPv6 vs. IPv4 (which could explain why some users see something different from other users, since not all users have IPv6 connectivity), but it worked correctly for me in IPv6 when I tried it the other day. At the moment, it's consistently giving me the wrong certificate in IPv6 and the right certificate in IPv4.
@net, this might be something else to check on somehow: how is your IPv6 setup working? Is your IPv6 address correct in DNS? Are you using any special kind of proxy or anything to provide IPv6 support?
Also, the therathink.com and www.therathink.com now have different IPv6 addresses (from one another) for me, but the same IPv4 addressâthat seems fishy.
(But again, the IPv6 connectivity worked the other day, so maybe different DNS servers that you use have different views of what records they should be serving or something?)
They are different machinesâthe v6 server is running Apache/2.4.18 and the v4 server is running Apache/2.4.41!
I think this is going to be the underlying basis of the problem somehow. 
(though I'm still not sure why it worked for me in v6 before, except for the hypothesis of inconsistent DNS replies from different DNS servers)
@schoen When I query the authorative DNS servers of both hostnames (ns[1..5].linode.com.), I'm getting the same IPv6 address 10 (2x5) times? Perhaps some caching issue at your resolver?
Oh )(#*(#)*, just when I typed this, one of the resolvers (ns5) responds with 2600:3c01::f03c:91ff:fe7b:c177 out of the blue for the apex domain.. It was sending 2600:3c01::f03c:92ff:fe48:b16e earlier, just like every other DNS servers and is sending 2600:3c01::f03c:92ff:fe48:b16e now again.
It seems all 5 resolvers return two IP addresses in a random fashion for the apex domain, with a preference for the ~:b16e address (I think, didn't measure it). This randomness isn't observed by me for the www subdomain.
All authorative resolvers only have a single IPv4 or IPv6 address and the randomness of the apex domain isn't due to one address or the other. It really seems to be random.
It's the 2600:3c01::f03c:91ff:fe7b:c177 address returning the expired certificate by the way.
So the question is: why are the linode DNS servers returning, seemingly at random, an erroneous IPv6 address? And why does it only happen for the apex domain and not www subdomain?
This is very strange -- all are set to the new IPv6 address. Attaching our DNS records below:
Maybe I should contact Linode.com directly as we're using their nameservers?
@schoen THANK YOU for catching this.
