The CA was unable to validate the file you provisioned

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: docs.gluapi.com

I ran this command: I use le.register api

It produced this output:
The CA was unable to validate the file you provisioned.

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

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):

2

Hi @pjoshi

if I understand it correct, you use the api with own parameters.

This

means: There is the correct file. But the content of this file is empty. Instead, it must be a combination of the token, a dot and a hash value of your account key.

Perhaps your api needs an update. Or you are using the functions with wrong parameters.

3

Hi @JuergenAuer This API is returning the error for this specific domain. For other domains its working fine. So API update won’t be an issue I guess. I am using http-01 acme challenge to register the cert.

4

Yes, this is your http-01 - challenge.

https://acme-staging.api.letsencrypt.org/acme/challenge/awIlDlGUntFvOm2YDcFJixMcQ4hS_SwHJ367qJcf6pw/147456321

But your file

http://docs.gluapi.com/.well-known/acme-challenge/Xj0dxuyZd5xiMMgJlCvn_yhVLA9JqPd6eI132y2lw9I

is empty. Your filename is correct, but your filecontent is wrong.

But:

http://docs.gluapi.com/.well-known/acme-challenge/Xj0dxuyZd5xiMMgJlCvn_yhVLA9JqPd6eI132y2lw

(removed the last two characters) produces also a file. It should produce a 404.

So your webserver returns the wrong data. You should only send a http-status 200, if the filename is correct.

It's not a problem of using the api. It's a problem, that your webserver sends wrong data.

How do you create this special file?

5

@JuergenAuer We don’t create these files we are using SNI callback to generate certs on the fly. LetsEncrypt is creating all these files. We are using leStrore to store the generated certs and challanges

6

Which node library are you using to perform the certificate orchestration? Can you show a minimal standalone piece of code that exhibits the issue? There’s not a lot to go on here, because it comes down to your usage of the library.

7

we are using letsencrypt@2.1.9 npm module for this.
For challenge creation, we are using letsencrypt.create for creating certificates like this

LE.create({
      server: LE.productionServerUrl,
      debug: false,
      store: LeStoreService,
      challenges: { 'http-01': LeChallengeService },
      challengeType: 'http-01'
    })

we are usng letsencrypt.middleware api and then for registering domain we are using letsencrypt.register API which sends the challange to the domain and genrate the cert for this domain.

Hope that is helpful for you.

8

Then this component

may have the wrong informations. So it creates the wrong file.

Edit: Or it creates the correct file, but the webserver doesn't handle this file correct. So the file-content is wrong.

9

@JuergenAuer The logs I got while running letsEncypt in debug mode is this

[le/lib/core.js] checkAsync failed to find certificates
[le/lib/core.js] calling le.acme.getCertificateAsync [ 'docs.gluapi.com' ]
[le/lib/core.js] setChallenge called for 'docs.gluapi.com'
[le/lib/core.js] removeChallenge called for 'docs.gluapi.com'

This log indicates that challenge was successfully created and removed. This log is the same for successful cert generation and for this domain. After this, we get an error as mentioned in the above comments. I checked the challenge token and secret too for both successful and this domain, there is nothing different same strings are generated as token and secret.

10

Yes - and this may be the problem. Your program / API use may be correct. But your webserver sends the wrong content:

From your first post:

[Xj0dxuyZd5xiMMgJlCvn_yhVLA9JqPd6eI132y2lw9I.ZfeL86GSKOypsQmBSNW_Q8ng0-h-CWQdEBSsLqi4LNY] !=

The Letsencrypt-Check wants a file

/.well-known/acme-challenge/Xj0dxuyZd5xiMMgJlCvn_yhVLA9JqPd6eI132y2lw9I

with the content

Xj0dxuyZd5xiMMgJlCvn_yhVLA9JqPd6eI132y2lw9I.ZfeL86GSKOypsQmBSNW_Q8ng0-h-CWQdEBSsLqi4LNY

(Token, Dot and hash from your account-key)

But your webserver sends the wrong content (String.Empty). And your webserver sends always 200, also, if I fetch a file with another random filename.

It's not the use of the API direct, it's a combination of API and settings of your webserver.

11

@JuergenAuer Just one more question if the parent domain gluapi.com doesn’t contain an A record then this will cause an issue while generating the cert from letsEncrypt :thinking:

12

No, I think, this would not be a problem.

Your challenge-file reports an error:

https://acme-staging.api.letsencrypt.org/acme/challenge/awIlDlGUntFvOm2YDcFJixMcQ4hS_SwHJ367qJcf6pw/147456321

...

Oh, wait: Your challenge-file says:

addressesResolved
0 "52.71.176.187"
1 "107.23.26.132"
addressUsed "52.71.176.187"

There are two ipv4-addresses. Does your api store the challenge-file, so that it is visible using both ip-addresses?

13

@JuergenAuer No, we don’t store any challenge files. We just store token and secret in LeChallenge store which is the database in our case. And the entries from database gets deleted with each cert registration attempt.

14

@JuergenAuer Also these IP address will not cause any issues as the cname to this domain is pointed to one of the machines. So this domain docs.gluapi.com just have CNAME pointed to some service and there is no A record to this or its parent domain (gluapi.com). Just want to confirm I can generate the certificate using letsEncrypt for this situation?

15

You have 5 certificates created 2018-07-11:

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:docs.gluapi.com&lu=cert_search

So this part works.

16

Hi @JuergenAuer Thanks for providing this information. This removed lot of confusion. I want to know if it is possible to get information from which account these certs have been created. Can we get that information?

Thanks

17

Perhaps @jsha can see that.

18

I’m afraid we can’t offer that level of hands-on help in this case. I would recommend adding more logging to your client, so you can debug similar issues in the future. Thanks!

19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.