Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command:sudo certbot --nginx -d *.africstac.com
It produced this output:Client 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.
My web server is (include version): Nginx
The operating system my web server runs on is (include version): Ubuntu 20.04
My hosting provider, if applicable, is: DigitalOcean
I can login to a root shell on my machine (yes or no, or I don't know):yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):1.70
I think @Rip was a little incautious in describing this certificate crt.sh | 4612964719 as covering "www and *.africstac.com". It covers only www.africstac.com and africstac.com, which is different from *.africstac.com.
Do you specifically need a certificate for *.africastac.com? (A wildcard certificate that matches any subdomain.)
This Certbot error that you ran into
relates to a Let's Encrypt certificate authority policy which makes wildcard certificates more difficult to obtain compared to non-wildcard certificates. This is described in
The summary is that non-wildcard certificates can be obtained just by creating a text file on your web site to prove that you have control over that site. (This is called the HTTP-01 challenge method.) But wildcard certificates can be obtained only by creating a DNS record to prove this. That requires access to your DNS zone. Usually, this should be done by giving Certbot, or other Let's Encrypt software, some kind of access to a DNS server API, so that it can make these changes automatically in software. Do you know if you have access to an API for DNS records updates?
Should I create an A record using the wildcard rule on my hosting provider? Please pardon my seeming lack of understanding of what to do, I am new to the server.
example an A record like *.africstac.com and then configure my Nginx to have its Server_NAme= *.africstac.com with.
Those are all examples of DNS records, but the one that Let's Encrypt will require is another type of DNS record called TXT. It could be created by the same method, but the required contents are different every time you renew your certificate, so it's very annoying if you can't get software to do this for you automatically.
The record you need for the Let's Encrypt certificate will be a TXT record rather than an A record, but ideally you wouldn't be doing this by hand.
(You might also need a wildcard A record in order to allow people to connect to subdomains of their choice—but that's separate from what Let's Encrypt needs in order to issue a wildcard certificate for HTTPS.)
In order to find out the name and contents of the TXT record, you would have to use --manual instead of --nginx in your Certbot command line. It's different every time and different for every user. It's not like your A records, where the content is chosen by you; the content here is chosen randomly by the certificate authority.
OK! I get it. Please one more question, sorry for bugging you, in creating a TXT record, there is a field that says a should put a text string, is this is a random text string or some text from somewhere? Thank you
It might be possible to use the certbot-dns-digitalocean DNS plugin for certbot to do the DNS challenge automatically in stead of using "manual", which is, although you're on the right track (nearly there!), quite cumbersome. If you could automate it with the DNS plugin, it would be way easier.
Thanks for your time. It has finally generated the cert for the wildcard subdomain.
Congratulations! Your certificate and chain have been saved at:
Your key file has been saved at:
Your cert will expire on 2021-08-30. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew all of your certificates, run
Before your certificate expires, you should repeat this process by running the same certonly command that you used to request the certificate.
(If you use certbot renew for this certificate, you'll receive an error about how the manual authenticator can't be used for a non-interactive renewal, and nothing will happen. Maybe that means that Certbot shouldn't suggest it to you in this case, since it knows it won't work. )