Issue with Let's Encrypt certificate: https://www.example.com not working with redirection to https://example.com - apache

Question

I have an issue with the certificate that I have generated for a website (dubbed here example.com).
I can type in browser http://www.example.com and successfully redirected to https://example.com as I wanted (with a certificate generated by let's encrypt). I have done this redirection with Rewrite Rules with Apache2. The redirection to https://example.com also works fine when I type http://example.com.
Now, I am face to an issue when I type directly in browser https://wwww.example.com: I get the following error:
To generate let's encrypt certificate, I have executed the following command:
./certbot-auto certonly --no-bootstrap --no-self-upgrade --renew-by-default -a standalone -d example.com --rsa-key-size 4096
I would like to generate a certificate working both for example.com and www.example.com: is the command above with cerbot-auto correct for this?
It seems that before my migration from Debian 7 to Debian 10, I had a *.example.com name in the certificate info window of the browser but I am not sure.
How to type https://www.example.com and to be correctly redirected to https://example.com without having the error illustrated in the figure above?
Update 1
Is a single certificate sufficient to make all the redirections to be performed, I mean in my case only one certificate example.com? This was the case on my previous OS, I think that I had only a unique certificate (for example.com).
I want to have the following redirections:
http://example.com -----> https://example.com
http://www.example.com -----> https://example.com
https://www.example.com -----> https://example.com
except for URL containing the directory podcast where I want to stay in HTTP mode.
So, from Ref: Apache redirect www to non-www and HTTP to HTTPS, I did:
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{REQUEST_URI} !^/podcast [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,NE,R=301]
Does these Rewrite rules seem to be correct?
Unfortunately, if I type directly https://www.example.com, I am not redirected to https://example.com and the Warning window figure above appears, I don't know what to do.
Update 2
1) Does Let's Encrypt offer the possibility to generate a "wildcards" certificate ?, I mean under the form *.example.com when we look at the certificate in browsers.
2) Moreover, Does anyone know how to perform with Apache2 Rewrite rules the rule which allows to redirect https://www.example.com to https://example.com.
To get more information, I am starting a bounty.
At the end of the bounty, I talk about what to do to make a redirection from https://www.example.com to https://example.com (these URL are masked into bounty under the same href tag but they are different).
Update 3
I think my issue is not about wildcards certificates since I just want a redirection from https://www.example.com to https://example.com (don't take into account of the UPDATE 2 above. Surely a simple rewrite rule should be enough. Before my current OS (Debian 10), I was running well all my config files that I try to use again now. Especially, I was using only one certificate generated with the option "-d example.com" (I didn't use a second domain "www.example.com").
I am going to try to modify these rewrite rules to get this redirection without being obliged to generate a www.example.com certificate files.

Answer 1

You could try running this minor update to your original certbot-auto command to get your certificate to include the additional www.example.com domain name
(I believe this is what John Hanley was talking about in his comment on your original question)
Please note, according to one source (letsencrypt community link below) you may have to remove URL rewrite rules if you already have them set up, before the certification process will work. (if you run the command and get an error, that might be why)
./certbot-auto certonly --no-bootstrap --no-self-upgrade --renew-by-default -a standalone -d example.com -d www.example.com --rsa-key-size 4096
references that might be helpful:
command paramter reference for certbot (man page)
https://certbot.eff.org/docs/man/certbot.html?highlight=bootstrap
letsencrypt community discussion of adding a new domain
https://community.letsencrypt.org/t/add-a-domain-using-certbot-auto/33660
letsencrypt documentation for updating an existing certificate
https://certbot.eff.org/docs/using.html#re-creating-and-updating-existing-certificates
note, according to the man page, --renew-by-default implies --expand, which is used in these examples
(--expand just prevents you from having to answer whether you are intentionally updating the existing certificate)
I think your rewrite rule looks mostly fine as it is, as mentioned before it might need to be removed temporarily to get you certificate generated. And you may need "RewriteEngine On" before those rules:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{REQUEST_URI} !^/podcast [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,NE,R=301]
And to the question about wildcard certificates, they are supported but only with the help of additional plugins. See more here:
https://certbot.eff.org/docs/using.html?highlight=wildcard#id14

Answer 2

LetsEncrypt offers wildcard certificates in order to do *.example.com however they can only be issued via DNS-01 level challenges.
You're using HTTP validation, where a specific file is uploaded to prove ownership, however this is insufficient for proving that you have ownership of an entire domain.
Certbot has limited support for being able to issue wildcard certs automatically, but this may be of use to you if you scroll to the wildcard section. It's limited in terms of which OS + Server + DNS provider that you have. Basically you need to be able to automatically create and modify DNS TXT records with your registrar.
I've found that using the acme.sh project to issue wildcard certs is much more flexible and works with more DNS providers, although it's a bit more of a manual process.
If your main DNS provider for your domain isn't supported, you can look into "alias mode" where you can use a subdomain or other domain on another DNS provider that is supported to act as your proxy-domain for validating that you own your main domain.