So… here’s what I’m getting:
It took me a few minutes because I made sure to fully clear my cache in between.
I am noticing random redirects. Sometimes http won’t redirect to https. Sometimes non-www redirects to www. I think there are a lot of conflicting settings/rewrites happening.
From the images above, you can see that it’s using your old certificate.
@ was taking me to the default site. So, I set the redirect record again redirecting @ to https://fdqn. That could be the reason. But, now the certificate expiration date has gone back. I saw November 10 or so for a short while and even took a screenshot just as a confirmation after all these confusions.
I saw 11/10 as well, on the default nginx instance.
Did you see my long post above though regarding getting a certificate before installing jitsi.
I saw 11/10 and a functional site with redirect working too and took a screen shot.
I previously got the new certificate on the default nginx on non-www and the old certificate on jitsi on www. 
I am not sure whether I would like to restart everything now. The site is working. There must be some minor glitch with the set up.
Be careful though. I get various behavior depending on how recently I've cleared my cache. I also am only getting the OLD certificates now.
Let me hold off on making any changes. Let the system propagate and settle down. After a while, we can check to see what is going on and where things really are. Thanks, Jonathan.
I generally believe that the basis of your install is alright, but your various configs have conflicts. It may be possible to debug them collectively, but I have a feeling that starting fresh and following the install processes referenced above might make your life a lot easier, especially regarding the redirect issues.
It looks like what I am selecting in the options list is affecting the way the certificates are created.
I think selecting the right options for ports 80 and 443 should address this issue while executing the install command. That is why we are seeing different expiration dates.
I see November 10 for www.aioexplorer.com. Could you check to see whether it is the same?
Seems like a plan. My major thought for now was regarding this:
In order to have encrypted communications, you need a TLS certificate.
The best method is to create a certificate that is signed by a Certificate Authority. This way you can avoid problems with a self-signed certificate (see above for details). The easiest way is to use Let's Encrypt.
Simply run the following in your shell:
sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
Note that this script uses the HTTP-01 challenge type and thus your instance needs to be accessible from the public internet on both ports 80 and 443. If you want to use a different challenge type, don't use this script and instead choose I want to use my own certificate during jitsi-meet installation.
I think so too. This is why I think you may be happier with a clean install.
As shared before, I used that script too, but I got a message that the certificate is not up for renewal.
With your wildcard though, that script won’t work per their instructions. My guess is that when you’re installing jitsi-meet and it prompts you about the certificate when you select I want to use my own certificate that it configures your instance differently.
This is because the jitsi script only supports http challenges and not dns challenges like you need.
Personally on my own sites, I always do manual DNS challenge renewals using the web-based-client on my own website. 
I just generate a certificate signing request and private key on my target site, copy and paste the csr to the web client, add the txt records, copy and paste my new cert back to my target site. Done. We’re basically looking for the same concept for you here, just automated (as much as possible) with a script.