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: In CertifyTheWeb Certificate Manager, after setting my TXT records, I pressed Request Certificate
It produced this output:
2023-01-17 15:18:52.534 -06:00 [INF] ---- Beginning Request [VIMAboard SSL Certificate] ----
2023-01-17 15:18:52.740 -06:00 [INF] BeginCertificateOrder: creating/retrieving order. Retries remaining:2
2023-01-17 15:18:52.740 -06:00 [INF] Created ACME Order: https://acme-v02.api.letsencrypt.org/acme/order/82420684/156396696767
2023-01-17 15:18:53.973 -06:00 [ERR] Could not begin certificate order: No order for ID 156396696767
2023-01-17 15:18:53.973 -06:00 [INF] Could not complete authorization for domain with the Certificate Authority: [*.vimaboard.com] Could not register domain identifier
2023-01-17 15:18:53.973 -06:00 [INF] Could not complete authorization for domain with the Certificate Authority: [vimaboard.com] Could not register domain identifier
My web server is (include version): IIS 8
The operating system my web server runs on is (include version): Windows Server 2012 R2 Standard
My hosting provider, if applicable, is: hostwinds.com
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): NO
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): CertifyTheWeb - Certify SSL/TLS Certificate Manager 5.6.8.0
It's asking for the version of your client. Your client is CertifyTheWeb. So the answer is applicable. Especially as, to me, this could be a bug in the client.
Thanks, @Osiris - I will edit the initial post to add the version.
LATER UPDATE -- When I clicked the "Request Certificate" button again (after waiting about a half hour), instead of generating the error, it came up with instructions for me to change the TXT records to new values. I have done that and am waiting for the TTL to expire, then will press the button again and will hope all is well. If so, I will advise here that no help is needed after all.
Your Authoritative DNS Name Servers here DNS Spy report for vimaboard.com shows a Performance: 0%.
Since the DNS-01 challenge utilizes DNS Records and the DNS Name Servers have poor performance I can see that potentially presenting Validation Issues. And Wildcard Certificates are only able to be Validated with the DNS-01 challenge.
Interesting. I have been renewing this certificate regularly for many years now.
The two records you see are the NEW values given me by the Certificate Manager, as described in my LATER UPDATE above (after initially changing them to the values that I was told on January 3 that they would need to be, before the January 21 expiration, and experiencing the error I first reported).
Although you are seeing the new values, I will continue to wait out the TTL before trying the Cert Request again using the Certificate Manager, but am hopeful.
Perhaps dnsspy.io measures different things, but when I chatted with hostwinds about how it says my server is not performant (as you pointed out, 0% performance -- ouch!), their response was to send me to this page which calls it 100% performant: Archived Performance Report for: http://vimaboard.com/ | GTmetrix
Again, I don't know enough to know if they're measuring completely different things, so I thought I'd mention it here, even if just so I can get a bit smarter.
LATER UPDATE: Yeah, it looks like gtmetrix measures my website itself, and I'm a good enough coder that I get 100%. And dnsspy is measuring my hosting company's dns servers, which are slower to respond than dnsspy would like. Got it.
Oh, thanks! Good to know, @Osiris ! I will go ahead and request the certificate again now that I've changed the TXT records as (most recently) directed, and see if all is well....
The issue is resolved. The second attempt to request the certificate (after changing the TXT records a second time to new values that CertifyTheWeb came up with after starting a request again after the first failure) succeeded without issue.