Let's Encrypt renewal error, but not the usual one I think


I’ve gotten this with one of the websites I’m hosting, and, I may be mistaken of course, but I don’t think it’s the usual error we see in the virtualmin forums.

Please, may I humbly ask if you have an idea or a suggestion to make it work? Frankly, all I care is to get my friend’s website to keep on working without issues, even if this is not a purely virtualmin method, as long as it works with Debian, I’m all ears.

Here’s the log that’s shown in virtualmin > edit server > ssl certificate > let’s encrypt:

Requesting a certificate for [the website's].com, www.[the website's].com from Let's Encrypt ..
.. request failed : Web-based validation failed : Failed to request certificate :

    Traceback (most recent call last):
      File "/usr/share/webmin/webmin/acme_tiny.py", line 198, in <module>
      File "/usr/share/webmin/webmin/acme_tiny.py", line 194, in main
        signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
      File "/usr/share/webmin/webmin/acme_tiny.py", line 143, in get_crt
        raise ValueError("Wrote file to {0}, but couldn't download {1}: {2}".format(wellknown_path, wellknown_url, e))
    ValueError: Wrote file to /home/[the website's]/public_html/.well-known/acme-challenge/hEy_fWjLypek1sBDrz1f0asHZlWmebWT3HtVogO4vGE, but couldn't download http://[the website's].com/.well-known/acme-challenge/hEy_fWjLypek1sBDrz1f0asHZlWmebWT3HtVogO4vGE: Error:
    Url: http://[the website's].com/.well-known/acme-challenge/hEy_fWjLypek1sBDrz1f0asHZlWmebWT3HtVogO4vGE
    Data: None
    Response Code: None
    Response: <urlopen error [Errno 1] _ssl.c:504: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure>

    DNS-based validation failed : Failed to request certificate :

    usage: acme_tiny.py [-h] --account-key ACCOUNT_KEY --csr CSR --acme-dir
                        ACME_DIR [--quiet] [--disable-check]
                        [--directory-url DIRECTORY_URL] [--ca CA]
                        [--contact [CONTACT [CONTACT ...]]]
    acme_tiny.py: error: argument --acme-dir is required

My last idea was a faulty .htaccess, but, no, none of that.

At this point, I have ran out of ideas, at worst I’m turning SSL off for that website, it won’t be the end of the world. But, hey, maybe there’s a simple explanation out of this one.

Thank you very much if, by luck, you can help with a suggestion, an idea, or the official solution! (hey, one may always dream, huhu.)

Thank you, but I’m ashamed to say I don’t get what the way to fix the problem was, in that other thread O_o

Try just installing certbot package?

Oh, then, apply the Let’s Encrypt certification, outside of virtualmin, then?

Thank you Ilia!

May I ask if that does not risk to cause conflicts with the other virtualmin virtual domains, on the server, for whom there is an active and perfectly fine letsencrypt certificate?

No, it will work just fine inside of Virtualmin!

May I ask if that does not risk to cause conflicts with the other virtualmin virtual domains, on the server, for whom there is an active and perfectly fine letsencrypt certificate?

It shouldn’t.

Are you having an issue only with this one domain?

What happens, if you try to visit from your browsers this link:

http://[the website's].com/.well-known/acme-challenge/hEy_fWjLypek1sBDrz1f0asHZlWmebWT3HtVogO4vGE

Thank you very much for your advice, Ilia!

I did some probing and testing around, and at some point I realized I forgot one of the usual suspects: the rest of the internet, not my server. The domain in question was behind cloudflare, and apparently there was a sort of issue, cloudflare was forcing the redirect to https, while the website’s ssl was already obsolete and thus any https /.well-known/anything was bound to fail.
Asking the website owner to temporarily turn SSL off in cloudflare for that domain did the trick, now, it works.

I apologize for wasting your time on a problem that was not caused by virtualmin, Ilia!

At least, maybe, if other visitors face the same issue in the future, and you come here after a google search, and that’s a domain behind cloudflare, try this guys: in cloudflare, SSL/TLS icon in the admin, untick “Strict” and temporarily tick “Off”, and then, back in virtualmin, re-run the let’s encrypt renewal. Make sure to tick “Strict” again afterwards in cloudflare.

About the inside/outside of virtualmin, my point was, if I were to use certbot, then it would mean I would, indeed, be using a non-virtualmin solution to fix an issue, by installing the certificate, by myself, and not with virtualmin.
That’s the way I understood it, at least.

Following this, as virtualmin would “see” a certificate installed by something other than itself, I was wondering if it may, or may not, cause issues in the future, either for the current domain, or the other domains for which the certificate was installed with virtualmin.
How to say… I was unsure if it was possible to have to at the same time, on the same server, 2 letsencrypt installation methods, one coming from the virtualmin panel, one from certbot. And, if it was possible, would it cause hiccups with virtualmin.

Anyway, case closed and, again, I’m sorry for taking time from helpers with a non-virtualmin issue, good day to everyone!

1 Like

This is most common issue.

You are welcome.

No, no Virtualmin just knows how use certbot.

1 Like