During secondary validation: The key authorization file from the server did not match this challenge

Help
1

Hello,

I'm having an issue with the following certificate request. Requesting the SSL is indicating secondary validation is failing.

“Let’s Encrypt™” HTTP DCV error (mail.todotaller.cl): 403 urn:ietf:params:acme:error:unauthorized (The client lacks sufficient authorization) (During secondary validation: The key authorization file from the server did not match this challenge. Expected "V65k9b0osAUTARzjVdVJqHOBgTx4skjmgphKesAvzM4.Nd5uGAOHhwL7bKiVbhNMWOwK1KOz62_lNIXypInNRzc" (got ""))

Is this the result of not reaching the server?

The debug page indicates it should be okay.

Best Regards,

2

Welcome @cPanel-L3-Techs

There is an interesting combination of symptoms here. One is the part of the error message that says (got "") along with saying "secondary validation".

Let's Encrypt checks from (currently) 5 global points. A secondary failure means the primary (first) worked but some of the others failed. For some reason your server gave an empty reply after it correctly returned the challenge token with the first request.

Looking at your server's response headers I noticed this

X-Cache: MISS from todotaller.cl

Now, that was a request to your home page but it tells me some sort of caching is setup on your system. This caching is probably not working right for the ACME Challenge

Does that make sense?

Note the Let's Debug won't reproduce this problem. One is it only does one check from its own server. And, once the Let's Encrypt Staging system fails with 404 (like it should) the secondary centers are not active.

You might just be blocking some of the secondary validation centers too. Although we usually see those as timeouts and not "got nothing" replies.

4 Likes
4

Hello,

I thought it should be a timeout rather than a reply of "nothing." I'm not familiar with the secondary validation method. When I couldn't find a request that replied this way, I thought maybe it was related to the firewall. This alone didn't fully make much sense, though.

Thanks for the clarification about the debug page.

I'll examine the X-Cache header a bit closer to determine if this has any effect on the response.

2 Likes
5

Thanks for the help. The issue was indeed the cache I suspect.

CacheQuickHandler off CacheEnable socache / CacheHeader on CacheDefaultExpire 3600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5

Possibly, the cache header breaks secondary validations? Disabled the cache on this path and it resolved the issue.

<Location "/.well-known/acme-challenge">
CacheDisable on

2 Likes
6

The Let's Encrypt Server (primary and secondary) do not look at HTTP response headers. They are just looking for the correct challenge data response.

You didn't say exactly how you requested the cert. And, I don't know the details of your caching system. But I will still guess :slight_smile:

I think the first incoming HTTP challenge request to your server passed "through" the cache and your Apache sent the correct reply. Your cache hadn't seen it before so couldn't do anything with it. After that LE tries four more identical HTTP requests from different parts of the world (these are the secondary centers).

Your cache didn't retain the data from the first request yet it was enabled to reply for such URI formats. So, the cacher gave an empty reply.

6 Likes
7

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