FortiOS 7.2 - Error (No order for ID X)

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

Yesterday one of our client's Fortigate firewalls could not renew the certificate with the comment "Error (No order for ID %idnumber%)" and Fortinet support says the issue is on the Let's Encrypt side. My question is if anybody can help me determine if this will happen again and/or how to prevent it. Any information is helpful and thank you.

It looks like there is nowhere near enough info to diagnosticate this.

This is almost never the case.

6 Likes

I saw your domain name before your removed it from your post

A test HTTP Challenge is redirected to a port number which is not allowed by ACME protocol.

Are you using the HTTP Challenge?

curl -I [redacted]/.well-known/acme-challenge/Test123

HTTP/1.1 307 Temporary Redirect
Date: Tue, 19 Sep 2023 21:31:53 GMT
Server: xxxxxxxx-xxxxx
Location: https://[redacted]:4443/.well-known/acme-challenge/Test123

Note the many 'x's for the Server header are exactly as returned by your domain. I did not modify that line at all.

Without knowing the real domain this kind of problem is very difficult to debug.

See redirection rules here

3 Likes

Sorry I am willing to try whatever I just didn't want to put our client's domain information here. I am a jr. engineer and trying to understand where this issue lies. It seems to me its the way Fortinet handles the chain of authority w/ Let's Encrypt. I doubt Ill be able to get Fortigate to fix this from must my support ticket.

1 Like

There was a cert for that domain issued Sep18 and it is being used for HTTPS on port 4443

HTTPS on port 443, on the other hand, returns a self-signed Fortinet cert. Maybe that's intentional I don't know

The place to start is knowing what kind of ACME challenge is used - HTTP, DNS or TLS-ALPN. We can't tell that from what you've given. I'm not sure what you mean by Fortinet mis-handling the chain of authority.

3 Likes

From @MikeMcQ post I understand that you currently redirect port 80 to port 4443. That doesn't work if you want to use http validation. You can only redirect to to 80 or 443.

The advice is to perform validation on 80, usually.

4 Likes

If an order is missing, it is possible they're hitting "the 404 bug": Reduce inaccurate 404s by adding structure to ACME object URLs · Issue #6549 · letsencrypt/boulder · GitHub

Simply retrying will usually help.

5 Likes

What are the full version numbers?

2 Likes

FortiGate 7.2.5,build1517 (GA) (Feature)

1 Like

Okay the way I understand this is that since we are redirecting our vpn.domain.com forward to a non-80 or 443 port the cert doesn't get proper communication w/ Let's Encrypt and can cause an error w/ renewal? Sorry if I sound dumb both the problem and my understanding of how certificates work is all new to me right now.

Yes. If these domains are on the same machine or in the same data center, you can do a proxypass instead of a redirect to get around that issue.

Edit: You can use this technique if the domains are anywhere, but having them on the same machine or network is substantially easier.

2 Likes

How exactly?
If you are to get a cert for the firewall, HTTP must reach the firewall on the IP of the FQDN requested.

4 Likes

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