Hello,
First of all thank you for existing!
I am wondering why when asked to create a certificate for a website you do not systematically add both www and non-www as alternative DNS addresses.
Is there a technical reason for this?
Thank you
Philippe
As far as I know, this is simply a decision made by the Let's Encrypt team to not automatically add the www subdomain, but only the requested hostnames. I know some CAs do this automatically, but LE does not.
Hello,
Thank you for your reply.
But it does not explain why they took this decision though.
Have a nice day
Philippe
That's true 
Maybe we'll get lucky and one of the LE staff members can enlighten us
They are different names entirely. There's no reason to make that decision for everyone.
Hello,
This decision mainly penalizes visitors and independent web publishers.
Anyone wishing to use one instead of the other may put it in the .htaccess file that should already exist to prevent simple http connexions.
How are they different names anyway? Please explain.
Philippe
I do not know the answer. However, I could imagine multiple plausible reasons:
interference avoidance: some people may not want the names with www. prefix
transparency: let the people decide what names they want in their certificate
efficiency: the limit of alternate names in a certificate is 100. Including the names with www. prefix would practically cut into half the number of effective names.
Why? The system administrator who managed the certificates can easily add the www subdomain. It's their choice to not add it. Let's Encrypt penalizes nobody.
These all are different FQDN:
example.comfoo.example.comwww.example.combar.example.comfoo.bar.baz.example.comLet's Encrypt simply does what the ACME client asks: it does not change anything with regard to the requested FQDNs.
Makes you wonder why some CAs do it automatically. They have to be stupid...
They probably call it "service".
So, they're different names in the sense that www.example.com and example.com are different, and if you want both names a certificate then you need to validate control over both of them. Even if you're using a CA which defaults to putting both those names in an "order" for you, that CA would still need to confirm that you control both of those names.
If Let's Encrypt somehow automatically added the www. name, if it wasn't set up properly on the web and/or dns server then it wouldn't be able to validate it. So the administrator needs to have it configured on their servers anyway if they want to use it. And most clients (I think), if the www. is set up, would offer to have it on the certificate. (Or at least, if I recall correctly certbot offers to get a certificate for all the names configured on the web server by default when using the apache or nginx plugin.)
According to the Baseline Requirements, I believe if you validate example.com, you're allowed to issue for foo.example.com without an extra validation.
Edit: see below, not for the http-01 challenge.
Um, because they're different? www.domain is not the same name as domain. Neither is mail.domain, ftp.domain, or dev.domain. All of these are distinct names. Any of these may or may not exist in the global DNS system, and may or may not belong to the same system. It's trivially easy for the admin to add whatever names to the cert are desired, but it would be foolhardy for Let's Encrypt to add names the admin didn't ask for (even if some clients do so).
For "3.2.2.4.19 Agreed-Upon Change to Website - ACME", it says "The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method." (And the same text is in the 3.2.2.4.18 non-ACME equivilent.) For some other validation methods though (phone call, email, DNS change, etc.) you're right, though, that they do allow for any "other FQDNs that end with all the Domain Labels of the validated FQDN".
Oooh, so not for the http-01 challenge, I see.. I just remembered the generic statement somewhere else then. I stand corrected.
Just wanted to address something not yet mentioned ...
Let's Encrypt is the ACME Server which issues certs as requested by the ACME Client. The ACME protocol is a fully automated one. Let's Encrypt certs are used in an extremely wide variety of situations and they avoid making the certs larger than necessary which adds traffic to where they are used and the entire internet. LE issues around 4 million certs per DAY so this is no minor concern.
Adding www to every domain would often be wasteful. Many certs are just things like api.example.com or just backendservice.example.com. We also see certs with combinations of various names:
www to each of those?Some hosting providers mix names from multiple customers on one cert and have 100 names. How would LE know which ones to add www to (even ignoring its limit of 100 names per cert).
NOW, could an ACME Client have an option to auto-add www domain to a cert you request? Sure, why not. Many ACME Clients have options to auto-configure web servers, run hooks, interact with DNS systems and so on. They could have an option for choosing names as well.
I don't know of any ACME Client that offers an option to auto-add www though. I'm sure we would see problems posted here saying "hey, the cert failed because a www name could not be authorized but I dont want a www name".
Name calling is not helpful. The situation for some CA in some hosting setup is very different than a fully automated ACME system
It might have changed since you last remembered, too, it looks like it was prohibited in 2021.
To add somethings (possibly) not yet mentioned.
example.com and www.example.com can have two different IPs
[serving different content/purposes from different systems]
things like mail.example.com, ftp.example.com, api.example.com are generally not accessed by adding www to them [only the base domain].
So, there would have to be added logic in the ACME client to only add www when it seems appropriate AND the IPs are the same AND the vhost/content is the same.
And who is to say what is or is not considered a base domain...
-- example.com
-- miami.example.com
-- service.example.com
[How can an ACME client be sure which is being (is to be) used like a base domain?]
Even then, adding anything without specifically being requested would likely add more confusion to the equation than it takes away from the alternative: Someone having to request a second cert with the www when they need it [and then possibly misunderstanding the expiry email when the first cert isn't renewed on time].
Both have pros and cons - I'll stick with the way it is now.
www.example.com and example.com are different hostnames. While they can be alternatives to one another, that is not guaranteed.
Users often have each name pointing to different ip addresses or service providers. Sometimes the bare domain will handled by an in-house IT team, while the www subdomain is handled by a vendor, and the other subdomains are handled by additional vendors.
Increasingly, users only want to host one of the domains.
Years ago, a user would often host both names as an alias for each other. Then the industry started migrating to cloud services, then multiple cloud services, and then search results started to become an issue. So users would have to program the site to use "canonical" urls and also employ redirect systems from one domain to another in order to maintain good results and link equity. This just caused too many problems.
LetsEncrypt operates their CA through a public Server that offers Certificates through the ACME protocol. The Server responds to requests from Clients (on behalf of Subscribers) to generate certificates. It would not be proper for the ACME server to force a www domain onto a certificate that was not requested. A Subscriber/Client must explicitly request this.
To my knowledge, no Clients - there are hundreds now - will default to generating an ACME Order covering both www.example.com and example.com. The most popular clients, such as Certbot, do not do this. They believe this decision is up to Subscriber.
We came close to attempting to do that in the original version of Certbot, but I think some of the considerations mentioned here dissuaded us (like how the www subdomain might not exist in DNS at all!).