Key authorization file did not match

Certify working beautifully on dev and test servers. So easy!

On production server though, we’re getting Validation of the required challenges did not complete successfully. The key authorization file from the server did not match this challenge [long-key-here] != [different-long-key].

Things we have tried:

  • two domains, same result
  • from outside of firewall, browsed to http://one.example.com/.well-known/acme-challenge/configcheck and get “Extensionless File Config Test - Ok”
  • edited one of the configcheck files to ensure pointing to the correct place
  • Certify Test runs successfully
  • Tried manually setting website root directory, manually setting domain match
  • Tried web.config in acme-challenge folder with mimeMap fileExtension="." mimeType=“text/json” and allow users="*"

Process:

  1. Click New Certificate
  2. Give it a name, select website from select list, ensure domain is checked in list to include
  3. Set Challenge type to http-01
  4. Run Test
  5. Request Certificate

Environment:

  • Windows Server 2012 R2
  • Server has other domains using traditional Comodo certs
  • Certify v. 4.0.10.0

It’s so easy that I can’t tell what I’m doing wrong. Suggestions?

Hi, thanks for getting in touch. There’s a known bug that affects some users related to the Let’s Encrypt account id. Can you try setting your account email again under Settings (you can update it to the same email address), this will reset the Let’s Encrypt account id internally.

By default the app will use the builtin http challenge server, so if that works OK then none of the website directory.web.config setting matter, plus the error message your seeing is that the response doesn’t quite match what’s expected not that it doesn’t get the response at all.

That worked. Thank you very much!

For anyone that finds this on Google, my exact steps were (not sure if all needed):

  1. In Certify app, select Settings, click New Contact, changed email address. I actually changed to a different address and then back, but apparently not necessary.
  2. Restarted Certify service, again, might not be necessary.
  3. Went back to Managed Certificates, selected domain and clicked Request Certificate

All works as expected. So easy.

Thanks @Ted - out of interest did you start on v4.0.10 or were you upgrading from an older version (or had an older version already installed)? I’m keen to track down this accountid bug.

I started with v4.0.10. When comparing the settings to one of the working installations, I noticed that it was 4.0.8.0 so I downgraded the troubled server and got the same result.