Remote PerformValidation RPC failed after wildcard attemptt

My domain is: lacearte.com (Primary), lifesrain.com & myteck.us (both subdomains)

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

It produced this output: Domain verification results for '*.lifesrain.com': error. During secondary validation: Remote PerformValidation RPC failed
2022/07/12 08:46:22 You can now delete '_acme-challenge.lifesrain.com' 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 _acme-challenge.lifesrain.com
Server:  UnKnown
Address:  103.86.96.100
Non-authoritative answer:
_acme-challenge.lifesrain.com   text =
        "9C4n1W4wV42t7uv2JTzX2HIrDr2fnUr9UG9_uG3BRVM"
C:\Windows\System32>

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.

7 Likes

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.

4 Likes

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