Let's Encrypt Failing For WWW

I am unsure as to why but I have started running into this issue with all of my domains recently. When trying to create an ssl certificate with let's encrypt I get this error:

------
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying www.domain.com...
Traceback (most recent call last):
  File "/usr/share/webmin/webmin/acme_tiny.py", line 235, in <module>
    main(sys.argv[1:])
  File "/usr/share/webmin/webmin/acme_tiny.py", line 231, in main
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, args.dns_hook, args.cleanup_hook, log=LOGGER, CA=args.ca)
  File "/usr/share/webmin/webmin/acme_tiny.py", line 184, in get_crt
    domain, challenge_status))
ValueError: www.domain.com challenge did not pass: {u'status': u'invalid', u'keyAuthorization': u'dv00KuvgwayCwD_-Y8ELNtV66qciuEm9rSJiFl1-7aU.izFzKUdQw8Iogo6Mh6HF2dJit-lVUek24wQ8bJyRGD4', u'uri': u'https://acme-v01.api.letsencrypt.org/acme/challenge/-ZizEd17w9PNZh-dB3JINZM58Of7QOwZx882b4l1XFM/1199763595', u'token': u'dv00KuvgwayCwD_-Y8ELNtV66qciuEm9rSJiFl1-7aU', u'error': {u'status': 400, u'type': u'urn:acme:error:connection', u'detail': u'DNS problem: NXDOMAIN looking up TXT for _acme-challenge.www.domain.com'}, u'type': u'dns-01'}
--------


This is happening with 4 different domains on my server. I can leave out the www and it will create a certificate without any issues, it only shows up with the www.

Also checked after requesting the certificate failed and it only creates one _acme-challenge dns record for the main domain but not www. I am running the latest virtualmin version.

Anyone know what may be causing this issue?

Status: 
Active

Comments

Howdy -- thanks for contacting us!

Just to verify, are you able to access your website using both the domain.tld and www.domain.tld names?

Also, is your Virtualmin server acting as the nameserver and hosting the DNS records for these domains?

xkodyhuskyx's picture
Submitted by xkodyhuskyx on Sun, 05/21/2017 - 09:41

Hey! Thank you for the reply.

I am able to access my website using both domain.tld and www.domain.tld.

I do have virtualmin set up as the nameserver and it is hosting the dns records for all the domains.

Helium Five's picture
Submitted by Helium Five on Mon, 05/22/2017 - 01:46

I am getting exactly the same error / output as xkodyhuskyx when I request a certificate. I am also running the latest version of Virtualmin.

Okay thanks for all the info!

Next question for you -- are you by chance using Nginx?

I'm using Apache on Debian 8

Helium Five's picture
Submitted by Helium Five on Mon, 05/22/2017 - 09:06

I am using Apache on Ubuntu 16.04.

I have the same error. But it worked when I removed the system hostname from the Lets Encrypt Cert request List.

My system hostname is server1.mydomain.com. The list for cert request is: mydomain.com, www.mydomain.com, mail.mydomain.com and server1.mydomain.com (removed this one)

And everything went fine.

I'm having the same exact issue as well, but really need to get this to work because we've got sites going into production that need SSL certificates. I am running the latest version of CentOS 7.3 x64 and the latest version of Virtualmin and Webmin. I can have Let's Encrypt request a certificate for tld.com but not www.tld.com. I get the same DNS record error as the original poster. But this used to work just fine before the most recent Virtualmin update that introduced support for requesting Let's Encrypt certificates via DNS instead of via the old webroot plugin.

It would be nice to perhaps switch between which plugin we use for certificat requests (DNS or the old webroot plugin) so as to still be able to generate certificates even if things like this arise. And yes, I am hosting my own DNS with four name servers (one Virtualmin-managed BIND installation and four Virtualmin-managed slave DNS servers running BIND).

Is there any progress on this issue? After several months of Let's encrypt auto-renewals running without incident, I suddenly got spammed with Let's encrypt renewal failure e-mails every five minutes for every enabled domain (retrying every five minutes seems aggressive? ...and leads to throttling/temporary ban very quickly).

It seems VirtualMin changed from http verification to "dns-01", and this caused the problems? Can we revert to the previous functioning method? And is there a way to temporarily disable the retry-every-five-minutes function? Even selecting to manually renew the certificates does not stop the retries and subsequent mail spam.

Thanks in advance.

Things seem to work for me now even though no Virtualmin update was ever introduced to fix this issue, so I'm not exactly sure what changed. But as long as the DNS zone exists, the certificate will now be requested successfully.

Having the same problem with apache2

happens on a sub-server that has a manually set home directory.

it worked 3 months ago, but now it seems that the acme challenge txt files are not written into it, tho the directories have all needed write/read permissions

Manually setting the home directory could cause problems - was this done within Virtualmin, or by directly editing the Apache config?

It was done within the Virtualmin environment and it worked for several months. I did the latest updates, problem still existing:

Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying www.support.****HIDDEN BY AUTHOR****.com...
Traceback (most recent call last):
  File "/usr/share/webmin/webmin/acme_tiny.py", line 235, in <module>
    main(sys.argv[1:])
  File "/usr/share/webmin/webmin/acme_tiny.py", line 231, in main
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, args.dns_hook, args.cleanup_hook, log=LOGGER, CA=args.ca)
  File "/usr/share/webmin/webmin/acme_tiny.py", line 184, in get_crt
    domain, challenge_status))
ValueError: www.support.****HIDDEN BY AUTHOR****.com challenge did not pass: {u'status': u'invalid', u'keyAuthorization': u'****HIDDEN BY AUTHOR****', u'uri': u'****HIDDEN BY AUTHOR****', u'token': u'****HIDDEN BY AUTHOR****', u'error': {u'status': 403, u'type': u'urn:acme:error:unauthorized', u'detail': u'No TXT records found for DNS challenge'}, u'type': u'dns-01'}

So maybe its because No TXT records found for DNS challenge ... I wonder how they should be set hummmmmm :/

TXT records should be added to your DNS zone, as long as it is hosted on your Virtualmin system.

munsking's picture
Submitted by munsking on Wed, 07/05/2017 - 20:18

I'm using ubuntu 16.04.02 LTS and i'm having the same issue, i can manually fix this issue by modifying the sites-available/${dom} to use <VirtualHost *:443> instead of <VirtualHost $ip:443>. as far as i can see there's no option for virtualmin to do this by default, should be an easy fix.

Also, @JamieCameron, could you provide a sample TXT record? i'm horrible at DNS(or networking in general)

I'm having the same problem. How can I find out that TXT record to add it to my domain? I've checked in the DNS records of virtualmin but is not there.

The TXT record is dynamically generated for each renewal request, so you can't really just pre-create it.

Regarding the Virtualhost , using a * should only be necessary if your site is behind a proxy.

What is the time limit before you can retry? I've tried waiting up to 20 minutes after getting this TXT DNS error but am still seeing, "Error creating new authz :: Too many invalid authorizations recently.",

You generally need to wait 24 hours for the rate limiting to expire.

Is there a way to temporarily disable rate limiting so that Virtual min can, for example, renew a large number of certificates? We've got about 160 domains that use Let's Encrypt certificates and they are all set to automatically renew but they aren't able to because Let's Encrypt sees us as spam due to how many domain certificates we are trying to renew at once.

I wish we could!

Unfortunately, the rate limiting is on Let's Encrypt's end. There are details about how it all works here:

https://letsencrypt.org/docs/rate-limits/

It sounds like there should be minimal rate limiting for renewing certs, the issues come up with creating new certs, or if an error comes up during the renewal process. It appears that a certain number of failures can trigger the rate limiting.

It does look like they offer a form you can submit (linked to at the bottom of the page above) that you can use to ask for a higher limit.