Remote PerformValidation RPC failed after wildcard attemptt

My domain is: (Primary), & (both subdomains)

I ran this command: le64 --key account.key --email "" --csr lifesrain.csr --csr-key lifesrain.key --crt lifesrain.crt --generate-missing --domains "*" --handle-as dns

It produced this output: Domain verification results for '*': error. During secondary validation: Remote PerformValidation RPC failed
2022/07/12 08:46:22 You can now delete '' DNS record
2022/07/12 08:46:22 All verifications failed

My web server is (include version): Apache 2.4.54

The operating system my web server runs on is (include version): CloudLinux 6.x

My hosting provider, if applicable, is: Namecheap (+10 yrs)

I can login to a root shell on my machine (yes or no, or I don't know): No

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): cPanel 102.0.18

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Crypt::LE client v0.38

I've been performing manual cert generation/installation using the DNS approach (because I couldn't get default http to work) for over a year. Now I'm trying to replace "www.<domain.ext>, <domain.ext>, mail.<domain.ext>" with *.<domain.ext>. I'm getting the result noted above.

The command/output noted above is for a subdomain but I've also tried it with the primary domain and got the identical result. nslookup was used to confirm the dns txt record [1] can be found & [2] contains correct "validation key":

C:\Windows\System32>nslookup -q=TXT
Server:  UnKnown
Non-authoritative answer:   text =

Using the wildcard would cut copy/paste time (and commensurate potential errors due to current manual process) by 2/3. Why does the ownership verification fail when replacing identification of each domain with the wildcard?

1 Like

Welcome to the community @Art.H

Thanks for nice trouble report. You might have to wait for better DNS expert than me. But, a couple things ...

Should I be seeing a TXT value of "tbd" right now? Because that's what I get.

Also, could you try adding -live to the le64 command? Isnt' that what you need for production certs with le64? Using staging is great for testing and thanks for trying that. But, we've had a number of reports this morning about something wrong in staging so I would like to exclude that.

I'll add that the "secondary validation" means the primary worked but one of the other Let's Encrypt server sites could not see it. So, waiting a bit longer for your authoritative domain servers to sync may be needed.


Mike - thanx much for the very useful response. I was suspecting something in the Let's Encrypt environment might be temporarily malfunctioning based on some related posts I browsed.

Yes "tbd" is what you should see as I deleted the validation key content from the dns record after the failure message. It's just normal practice so I don't inadvertently re-use an old key.

Good news -- It went through fine on the live server so it appears the culprit was indeed the staging environment.

Thanx again.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.