As Jürgen says, all three options are available. There is a policy difference from Let's Encrypt's side about issuing the wildcard certificate—if you want a wildcard certificate, you'll have to use the DNS challenge method to prove your control over the domain name.
For non-wildcard certificates, you can also use other challenge types instead.
Certbot will tell you the DNS TXT records to create to satisfy the challenges, and ask you to press Enter to continue when ready.
This is not great because this can only be renewed by re-running the same command. (The automated renewal command certbot renew will give a note that a certificate obtained with --manual can't be renewed with certbot renew, because the renewal requires human intervention.) You will have a nicer experience if your DNS provider lets you make DNS updates from software via an API, and you can find Certbot integration for that API.
e[31mClient with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.e[0m
That's probably because your original cert has an authentication plugin which uses the http-01 challenge configured.
I think you should get the wildcard cert without specifying the previous cert with --cert-name. You'll get a new certificate, but that doesn't matter. Then, re-configure your webserver to use the new wildcard certificate. After that you may choose to remove the old www certificate.
Also, please be aware that your current commands, as said earlier, won't include the apex or "base" domain mydomain.com and as such, your cert won't be valid for that hostname. You should specify the apex domain too by adding a second -d option with that hostname.
Here you'll need to specify an authenticator (like apache or nginx or webroot -w /path/to/your/webroot or standalone) and an installer (like apache or nginx or null for none):
certbot run --cert-name mydomain.com -a authenticator -d "mydomain.com,www.mydomain.com,sub1.mydomain.com,sub2.mydomain.com,..." -i installer --keep
Here you'll need need to specify a DNS authenticator (DNS plugin or manual as schoen was mentioning above) and an installer (like apache or nginx or null for none):
certbot run --cert-name mydomain.com -a authenticator -d "mydomain.com,*.mydomain.com" -i installer --keep
There are more complex mechanisms (like using various "hooks"), but the commands above usually suffice for most people.
In the commands I gave I actually did specify a --cert-name for a very good reason. It enables knowing exactly under which certificate name the active certificate resides, which allows the use of certbot certificates to discover the names of all the cruft certificates and certbot delete --cert-name name to properly delete them in order to prevent massive headaches when certbot renew attempts to renew the cruft. The only problem I could foresee is if the specified --cert-name has other parameters tied to it. It is for this exact reason that I suggested the addition of a clear command here.
Unfortunately, I don’t have easy access to the DNS server, just have access to the server where are installed the sites. And as I understood to request a wildcard certificate, I need to have access to the DNS server, right?
So, for now I will create a certificate for the main domain and for the 2 subdomains.