Certificate with loadbalancer on OVH

Help
1

We are trying to configure Let’s Encrypt in 2 Nginx servers behind a OVH loadbalancer, but I always get the error --> The key authorization file from the server did not match this challenge.

We stopped one node and I only running one Nginx server to debug the problem, but we got the same error.

When we configure the DNS to the Nginx server IP, the procedure works fine, so the problem is located with the load balancer.

The configuration of my Nginx is:

server {
    listen       80 default_server;
    server_name  _;

location /.well-known/acme-challenge {
	default_type "text/plain";
	root /usr/share/nginx/html/.well-known;
}

    return 301 https://$host$request_uri;

}

My domain is: testssl.nubaltec.net

I ran this command: certbot certonly --test-cert --webroot -w /usr/share/nginx/html -d testssl.nubaltec.net --agree-tos --http-01-address 188.165.59.55

It produced this output:
The following errors were reported by the server:

Domain: testssl.nubaltec.net
Type: unauthorized
Detail: The key authorization file from the server did not match
this challenge
[SUQHnck2Ca06XJTetkHP8lEgDmGykFqKByWdfRYBM0I.uxTA_TlNKmSGqIT8qGlRw8bm5XlDd4uBcphGCHT84Vw]
!=
[SUQHnck2Ca06XJTetkHP8lEgDmGykFqKByWdfRYBM0I.4E3VCTFsySjUrqnCg0ooULx-3kbdPBygi0aWkvg5Gd8]

My web server is (include version): Nginx 1.14

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

My hosting provider, if applicable, is: OVH

I can login to a root shell on my machine (yes or no, or I don’t know): yes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): Certbot 0.29.1

2

This account thumbprint appears to belong to [one of] OVH's ACME accounts.

In the past they were intercepting these requests to generate their own certificates for their load balancer service:

And from what I can tell, they are still doing that. The tell-tale sign is that your Server: nginx/1.14.2 header does not appear in the server response for responses under /.well-known/acme-challenge/, which means the request does not arrive to your server.

The only suggestion I can make is the same one pfg did in the above post, and that's to use a DNS-01 ACME client. (Or just use the SSL feature included with the OVH load balancer).

1 Like
3

These will NOT match:

1 Like
4

I solved de problems with the Nginx configuration, but appears the same error.

I’m going to open an incidence in OVH

server {
listen 80 default_server;
server_name _;
root /usr/share/nginx/html;

location /.well-known {
	default_type "text/plain";
	root /usr/share/nginx/html;
}

location / {
	return 301 https://$server_name$request_uri;
}

}

5

? ? ?

So you still get:

I believe you are still not correctly aligning the --webroot used with the challenge path used...

This
location /.well-known
root /usr/share/nginx/html
will become this
/usr/share/nginx/html/acme-challenge/{AUTH-TOKEN-FILE}

While this
–webroot -w /usr/share/nginx/html
will become this
/usr/share/nginx/html/.well-known/acme-challenge/{AUTH-TOKEN-FILE}

6

It doesn’t matter, the OVH load balancer does not pass-through the request … it’s an indiscriminate HTTP 200 that echoes the request URL back with OVH’s account thumbprint:

$ curl 188.165.59.55/.well-known/acme-challenge/rg305
rg305.4E3VCTFsySjUrqnCg0ooULx-3kbdPBygi0aWkvg5Gd8

So-called “stateless” HTTP-01 response like https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode

1 Like
7

Finally we solved the problem, it was in the OVH loadbalancer, we changed the configuration for the port 80 from trafic HTTP to trafic TCP, and that’s all.

Thanks a lot !

1 Like
8

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