Hi,
I am trying to get a password on a Windows Server. I am running Win-Acme tool.
My domain is: app.home.tilsch.it
I ran this command: using win-acme tool with remote file storage for authantication
It produced this output:
[INFO] Authorize identifier: app.home.tilsch.it
[INFO] Authorizing app.home.tilsch.it using http-01 validation (FileSystem)
[INFO] Answer should now be browsable at http://app.home.tilsch.it/.well-known/acme-challenge/QE7Km8paWonguwybZYRtNMNjSoKXz_kLy-3p5pPF_l0
[INFO] Preliminary validation looks good, but ACME will be more thorough…
[EROR] Authorization timed out
[EROR] Create certificate failed: Authorization failed
My web server is (include version):
IIS 8.5
The operating system my web server runs on is (include version):
Windows Server 2012 R2
My hosting provider, if applicable, is: n/a
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): win-acme v2.0.4.227
I am getting the same timeout, when I choose the DNS method.
What is it checking more thoroughly?
Thanks in advance
Micha
Hi, if you try out https://letsdebug.net you have something wrong with your DNS setup:
https://letsdebug.net/app.home.tilsch.it/28717
The CAA servfail error means Let's Encrypt can't check whether they are allowed to issue cert for your domain or not (a CAA record may specify which authorities are allowed to issue).
That said, the error could be masking some other problem as otherwise it seems ok.
Good catch @webprofusion-chrisc, but I think you're right that there is more to it than just the CAA. app.home.tilsch.it doesn't seem to have a public A record, suggesting it's some kind of internal domain.
@snudel: HTTP validation only works for publicly accessible websites. If you want to have a certificate for an internal application, you have to use DNS based validation.
Just to add to this - we had the same issue earlier and I managed to fix it by forwarding port 80 TCP traffic on our router to our web server. We originally only forwarded 443 traffic as we did not server an unsecured HTTP site.
Most helpful comment
Just to add to this - we had the same issue earlier and I managed to fix it by forwarding port 80 TCP traffic on our router to our web server. We originally only forwarded 443 traffic as we did not server an unsecured HTTP site.