Can't get a certificate for domain on www or naked version, getting error 'order authorization error'

Help
1

I can't get a certificate for domain on www or naked version, getting error 'order authorization error'.

Wondering whether this rate limiting as had an issue with spurious subdomains requesting certificates, but can't find the error in any of the forums or docs.

Thanks for your help.

My domain is: ama-uk.com

I ran this command: using a proxy called lets-proxy

It produced this output: error: order authorization error

My web server is (include version): Apache/2.4.29 (Ubuntu) Ubuntu 18.04.5

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

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

2

You may need to post this error on the github for lets-proxy

It looks like there is some configuration error in that setup. I say that because HTTP ACME Challenge requests are rejected with an HTTP error 503 Service Unavailable. Yet, other requests to that domain work normally.

# This request gets an expected 404
curl -I http://ama-uk.com/.well-known/acme-cha
HTTP/1.0 404 Not Found
Date: Thu, 07 Mar 2024 12:15:02 GMT
Server: Apache/2.4.29 (Ubuntu)
Set-Cookie: CONCRETE5=6eqsfgmfi724cicj3ivbon89v2; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT

# This example ACME Challenge request gets 503
curl -I http://ama-uk.com/.well-known/acme-challenge/TestToken404
HTTP/1.1 503 Service Unavailable
Date: Thu, 07 Mar 2024 12:15:15 GMT
Server: Apache/2.4.29 (Ubuntu)
2 Likes
3

Hey Mike, thanks for the response.

I've also asked on the github issues of that service but not heard back as of yet.

Would you say the misconfiguration leans more towards server config as oppose to let's encrypt related?

The domain in question was requesting lots of certificates from spurious subdomains which meant I had to delete all certificates for said domain from server.

Once I had created the necessary blacklist/whitelist for the proxy, I'm now unable to get a certificate for the www or blank versions.

Cheers

1 Like
4

I have never seen that lets-proxy system before and it has a lot of "moving parts". I didn't study it. I am not sure which component should be handling the acme challenge.

We saw similar kinds of failures with people who used a Palo Alto brand firewall. Your 503 is not exactly like what we saw with those. But, are you using that brand of firewall? If not then you will likely have to wait for response to your github issue.

2 Likes
5

As far as I know we don't have that type of firewall.

This lets-proxy has been working on 8 different servers for best part of 5 years, in the main without any issues.

The odd thing is that it does seem to be able to add certificates for other subdomains, just not the 2 we need.

Thanks for your help, I will just have to hope and pray I hear back on github.

2 Likes
6

What's interesting is that curl gives the same 503 for a domain that is working:

curl -I http://www.holywoodmortgagecentre.co.uk/.well-known/acme-challenge/TestToken404

So this may be a red herring in terms of debugging it.

1 Like
7

Maybe. That holywood domain is using a cert created on Jan22. Yet, it was last renewed on Feb27. Not sure I'd call that "working" :slight_smile:

Still, it is possible there are dynamically started components to handle an acme challenge. And, if that is not actively running some other component sees the challenge and rejects it with 503. So, sure, maybe a red herring.

2 Likes
8

I take your point. This is the problem with using third-party solutions - it can be a can of worms once you encounter an issue and start trying to debug it.

I may end up installing certbot and taking a more manual approach.

The current approach has been for convenience as it automatically handles this without us having to manually set up a new certificate once a customer makes their domain 'live'.

Not sure there are any other solutions like this other than caddy server, which I would need to look in to whether this works with apache on Linux.

Thanks again.

1 Like
9

caddy is one option. It would just reverse proxy to Apache.

For Apache there is also mod_md. It is an ACME Client built-in to Apache since 2.4.30. Looks like you are on 2.4.29 so an upgrade or possible manual install of mod_md would be required. 2.4.29 is a bit old so upgrade not bad idea anyway.

See the Apache docs about mod_md (here). Or, the docs on the github from where it began shown below. Lots of nice how-to's on github although now that it is built in to Apache you don't have to install it anymore. Just load the module and config the rest (pretty easy).

2 Likes
10

Thanks that's great. I'm just reading up on mod_md now and it looks interesting.

Things have moved on a lot in the past few years; always great to try and keep up to date with technology when we can.

Also looking in to Caddy so I can pick what's best for my scenario.

It's feeling more and more like I may have to move away from lets-proxy as I can not reliably debug these issues.

Thanks again.

2 Likes
11

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