403 Forbidden when Registering Certificate

Need some help understanding why I cannot register my certificate. Getting a 403 Forbidden error in the logs, but I can navigate to http://home.geektasticdad.com/.well-known/acme-challenge/configcheck just fine. Any advice would be appreciated.

2018-05-05 21:27:21.816 -07:00 [INF] Performing Config Tests
2018-05-05 21:27:23.296 -07:00 [INF] Beginning Certificate Request Process: Default Web Site
2018-05-05 21:27:23.297 -07:00 [INF] Registering Domain Identifiers
2018-05-05 21:27:23.298 -07:00 [INF] Attempting Domain Validation: home.geektasticdad.com
2018-05-05 21:27:23.300 -07:00 [INF] Registering and Validating home.geektasticdad.com
2018-05-05 21:27:24.587 -07:00 [INF] Performing Challenge Response via IIS: home.geektasticdad.com
2018-05-05 21:27:25.255 -07:00 [INF] Requesting Validation from Let’s Encrypt: home.geektasticdad.com
2018-05-05 21:27:25.998 -07:00 [INF] Domain validation failed: home.geektasticdad.com
[type, urn:acme:error:unauthorized]
[detail, Invalid response from http://home.geektasticdad.com/.well-known/acme-challenge/oWiXYcfl1RbYs17hS4X89h9w49C1PuufU5_lqKWtbe0: "

403 Forbidden

Forbidden

<p"] [status, 403]

Hi,
The error 403 literally means that Let’s Encrypt was not allowed to ask for the file it’s trying to access.

I assume that when you look in your /.well-known/acme-challenge/ folder you just have the ‘configcheck’ file and a web.config, and not the challenge response file oWiXYcfl1RbYs17hS4X89h9w49C1PuufU5_lqKWtbe0 which has probably been clean up by now.

If you copy or rename the configcheck file to a random name can you still access it in a web browser (using the random name)?

I just wondered if you had a web.config rule in the parent app that allowed configcheck to work, but not other file name combinations (‘configcheck’ is just an easy name for us to test with, but the real challenge gets a random file name with no extension).

I do have the same issue. rn:acme:error:unauthorized 403. Please can you help? I have tried to acces /.well-known/acme-challenge/RANDOMNAME and it is not working… I use IIS.

I was able to resolve this, it was firewall configurations that were preventing connectivity I believe. I use a Sophos XG firewall and had to set up Web Server protection and it was able to get the certificate to generate.

Thank you @geektasticdad. Unfortunately, this is not my case. :frowning:

@mv15 here is some supporting documentation: https://docs.certifytheweb.com/docs/http-validation.html

Your website is specifically denying access to the file. This is usually because the parent application has authentication switched on.

Can you look at your web.config that should be in the /.well-known/acme-challenge of your website? It should have an entry like this, to allow any user to access the folder:

<system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>

You may need to add an exception to your parent application web.config like this (the syntax might not be exact but you’ll see the general idea):

   <location path=".well-known/acme-challenge">
      <system.web>
         <authorization>
            <allow users="*"/>
         </authorization>
      </system.web>
   </location>
</configuration>```
1 Like

Thank you @webprofusion, this worked!

1 Like

i have figured out several iis issues that can cause the problem and logged them with some small solutions that can help quickly. watching the info afterwards made me thinking about to share them public.

  1. iis server configuration with web.config file disallows access (403)
    Solution: reconfigure web.config
    exp. /acme-challenge/
<?xml version="1.0" encoding="UTF-8"?>
  1. iis server with .htaccess file in path that denies access (403)
    Solution: reconfigure the htaccess file or if possible shortly remove htaccess it due to the update (be careful! :wink:

  2. iis has configured ssl force (file config) or ssl only setup (exp. plesk) when certificate expires on renew (403)
    Solution: deactivate the redirect only for the moment for the certificate update and then reenable

  3. request limitation under estimated requests from outside
    Solution: deactivate the limiation on requests in case there are multiple domains under the same restrictions

  4. The acme-challenge path owns the wrong path permissions
    Solution: Setup the correct readable path permissions from outside. Allow the lets encrypt app the correct permissions from the manual on windows or linux.

  5. Lets encrypt generates several files after a year the path is full with for example thousends of entries and get problems on list commands in some cases depending on used party apps to control.
    Solution: Delete all old generated files and setup a cron that does it with the old on case the application that manages does perform this automatically.

Hmm, thanks, apart from resurrecting a very old thread most of these recommendations shouldn’t really apply to Certify The Web - we have our own http challenge server so IIS is actually not used unless you have something else consuming port 80 that doesn’t use http.sys (like apache).

Forcing SSL doesn’t prevent http validation working unless you’ve also blocked port 80 - Let’s Encrypt only initate validation from port 80 but will redirect to https/443.