KeyHelp Community

I'm sure the cause of the problem is within KeyHelp
(Problems not related to KeyHelp belong in the Offtopic forum)
I did not touch the letsencrypt process, so it should be KH.


Server operating system + version
Debian 10


Server virtualization technology used
KVM


KeyHelp version + build number
22.0.1 (Build 2660)


Problem description / error messages
For some time now (2+ weeks) KeyHelp keeps failing to renew LE for a specific subdomain of a domain hosted on this keyhelp server as well.

Expected result
Renew the certificate.

Actual result
Failed to aquire a Let's Encrypt certificate for subdomain.domain.com.
Local resolving checks failed for domain "subdomain.domain.com". Please ensure that your domain is locally resolvable!

Steps to reproduce
Run keyhelp? Nothing to do it's an automated task.

Additional information
No changes, the A record for subdomain.domain.com is the same as domain.com which is the server's own IP. If I dig subdomain.domain.com from CLI it is able to resolve it, so this is an internal keyhelp specific failure. I think it's an incorrect interpretation of a domain lookup in your scripts.
DNS Server in use is google's 8.8.4.4

The LE specific LOG states http://sudomain.domain.com/.well-known/ ... 3.82670472 returns a 404 error. I don't know how it gets that because curling the URL from within the server or externally I still get a regular response. The only time a 404 is returned when the URL is requested via httpS. Is your script mistakenly doing that and then spitting our the error with a regular http ?

Hallo,


have you check the logs that LE resolves the subdomain to the correct IP. Often domains also point to an IPv6 that is not running on the server

Not sure if this helps.

But I see everywhere that you need to set an CAA-dns-record for your subdomain.domain.com

Even Let'sEncrypt talks about it in their FAQ's.

I'm not familiar with this, but you may need it.

Just trying to help, don't shoot me if I'm wrong

Bas.

Hallo,

the CAA is not necessary for getting the LE certificate. There must be definitely something worng with teh resolving of the main and/or the subdomain.

You can provide login to the server and the affected domain and subdomain via PM

Hi there

I know this topic is very old. But i wanted to share my recently made experience with some similar problems i had.

After setting up a new Keyhelp server, which should be the Nameserver for example.de, i also could not get any Lets Encrypt Cert.
I got the following Error:

Failed to aquire a Let's Encrypt certificate for www.example.de. Local resolving checks failed for domain

and

Failed to aquire a Let's Encrypt certificate for example.de. Local resolving checks failed for domain

I literally made not many steps until here:

1. SetUp the Server (4 IP addresses. 2x IPv4 | 2x IPv6).
2. Added 1 User to Keyhelp and added the domain example.de including www. subdomain (no SSL yet).
3. Ordered the Domain | Set Glue-Records | Set external Nameservers.
4. Waited until everything was refreshed (took about 10h).
5. Checked back in Keyhelp which was then of course reachable with the domain instead of the IP and also had its Server LetsEncrypt Cert (so at the login the certificate was already OK).
6. After all seems connected and OK. I added a new Keyhelp User to change the panel domain (just my way to do it...). Added the domain i want to use for the panel and everysthing is fine with this Domain. LE SSL was obtained, all happy.
7. I enabled the Lets Encrypt Cert in the domain. But a few mins later i unfortunately had to see, that the domain example.de / www.example.de had a red triangle and in the logs i saw the mentioned error. I was very confused.
8. Then i went to the kitchen and made me a cup of coffee, because otherwise i would be too sad, again something is not working correctly.
9. Double checked i connected to the server and checked if all domain names are resolvable and checked if all IPs are pingable (which was the case).
10. I thought: Man, the server even could get its certificate, whats wrong with you. But then i thought, maybe there is something wrong with the added domain, because i had to add it before it was even reachable, so that denic accepts the nameservers.
11. That finally did it. I removed the example.de domain and added it again to the server immediately. Directly activated Lets Encrypt and everything worked out well...

To be honest i absolutely dont kow why this happened. The records were default. But hey, anyway. Its working fine now.
So if anyone else face a similar problem but made sure all settings have to be correct, then just try to re add the domain to keyhelp.

Hope it helps someone.

Have a nice Day ,
Luuk

For my own reference and also if someone else might run into that issue again:
I had this week the same problem with two subdomains.
What fixed it for me was:
- Setting "No certificate" on the security tab of the domain
- rm -rf /etc/ssl/keyhelp/letsencrypt/<user>/<domain>
- Setting back to "Let's Encrypt certificate" on the security tab of the domain

I had this regularly when creating a subdomain and checking the LE SSL-Certificate option during creation already. Might be some race condition. The next cron job will have to create the subdomain and also the LE certificate. LE might check if it is resolvable before everything is completely set up and activated for the subdomain.

My workaround since years is to first create the domain/subdomain without checking the LE option, then wait for the next cronjob to run and completely create/set up everything belonging to the (sub-)domain, then check the LE-option and wait until the next cronjob will create the LE certificate.

I guess this is the equivalent to the workaround given by @fishbone222, but without needing to manually delete the files for the domain (rm -rf ...). As I do it, there is no need to delete something, because it's not created during the setup of the (sub-)domain in the first place. The creation of all needed structures for the subdomain (without LE) is done during one cron job, the creation of the LE certificate is done during the next cron job one minute later. The one minute break is all that is needed to make things work. I guess even some seconds would be sufficient, but this is not possible to do for a user (or admin) within Keyhelp, so I have to live with the additional minute.