Message says "Order Processing"

Hi, sorry, don't know much about certs, but have been waiting for new one(s) to be installed for 24 hours now. Thanks

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: and

I ran this command: certificate had expired, i deleted old cert info/data and clicked button to get new certificate, as instructed by Dreamhost Support

It produced this output: Certificate On Order

Your order for a Let's Encrypt Certificate is still being processed. Please check back in a few minutes.

My web server is (include version): cannot find

The operating system my web server runs on is (include version):sorry i don't know

My hosting provider, if applicable, is: Dreamhost

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Dreamhost's panel

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): i don't know what this is

Hello @gil49r, welcome to the Let's Encrypt community. :slightly_smiling_face:

Using the online tool Let's Debug yields these results

And here is some of the DNS Records

You have multiple IPv4 & IPv6 Addresses for (the only one I checked);
the all need to respond the same and all need to have access to Port 80 for the HTTP-01 challenge.

$ time curl -i ; echo
HTTP/1.1 301 Moved Permanently
Date: Mon, 27 May 2024 19:19:12 GMT
Content-Type: text/html
Content-Length: 167
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Mon, 27 May 2024 20:19:12 GMT
Report-To: {"endpoints":[{"url":"https:\/\/\/report\/v4?s=cjGkm9g%2FbLP3D2ycnoNpWAu4MYmjUvSa13D2e5ToteqaVtxIRU7NRsyqBp%2B7lQhHsVbhQy6XOf7UB%2Be85uAXNx7DrU9bjqofYVp%2BUjRz7Z550uENQFmdvTZyjB7GuIEDTPVu"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
X-Content-Type-Options: nosniff
Server: cloudflare
CF-RAY: 88a85aee78a6ef47-PDX
alt-svc: h3=":443"; ma=86400

<head><title>301 Moved Permanently</title></head>
<center><h1>301 Moved Permanently</h1></center>

real    0m0.040s
user    0m0.003s
sys     0m0.006s

Note how slow it is to access

real 0m38.972s
compared to the above.
of real 0m0.040s
that is 38.932 seconds longer!

$ time curl -i ; echo
HTTP/1.1 522
Date: Mon, 27 May 2024 19:19:58 GMT
Content-Type: text/plain; charset=UTF-8
Content-Length: 15
Connection: keep-alive
Report-To: {"endpoints":[{"url":"https:\/\/\/report\/v4?s=PFDO7lKs4SnfWtu4CCN5R%2FR9LkDSkD6ZDWUTYvM4c3Q%2BUgQ%2B0uPYaeD%2BSV%2FnOsHGRH8nqySYmyYYSt%2BWUIyG%2BhsDhTI6MPxe9ZdZV%2BPq5zxyVG0XTWAUBj1FtVOdEFnwmsHT"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: same-origin
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Server: cloudflare
CF-RAY: 88a85b1c2c9defac-PDX
alt-svc: h3=":443"; ma=86400

error code: 522
real    0m38.972s
user    0m0.009s
sys     0m0.003s

Edit: Also the server is findable. Server: cloudflare


Welcome @gil49r

Have those two domain names always been proxied at Cloudflare? Or is that new? Because getting a cert from "behind" a CDN takes special care.       291     IN      A       291     IN      A       300     IN      AAAA    2606:4700:3033::6815:2b46       300     IN      AAAA    2606:4700:3035::ac43:ddf0

A message saying "Order Processing" is not very helpful. Valid requests to Let's Encrypt would not take long (usually a few seconds or possibly a few minutes).

That is likely a problem in the panel program itself. Is Dreamhost able to look into their logs to see what the failure was?

Is this a cPanel system?

Sorry for all the questions but that really isn't much to go on. And, Dreamhost isn't being very helpful. It's their panel they should be able to provide a more detailed explanation.


Thanks very much, Bruce. This is all above my paygrade, unfortunately. If I'm reading correctly, anyone visiting my site could wait 38 seconds to the page load. I can say that when i've gone to my site in the past, it has been rather slow to load. I'll try to parse through your response this evening and again, thanks :slight_smile:


Notice though that test that took 38 seconds resulted in an HTTP error 522. That is probably an unusual situation and one that I did not see in my tests. That could easily happen if you were restarting your server or even just an unusual temporary comms problem. Of course if that persists the 522 is a serious issue


Thanks, Mike. The two domains have probably been proxied at cloudflare for a year and a half. I was at cloudflare today, looking for clues to solve this, but no luck.
I do understand Let's Encrypt is pretty quick off the dime, so after 24 hrs, seems something is in the way.
Dreamhost doesn't use cpanel, "DreamHost uses a custom-built panel to manage..."
Don't apologize for asking questions, nothing ever gets solved without asking.
So, now I'm going back to Dreamhost Support and will let you know what they say. Thanks!


So for anyone who might be following, "Error 522 is an HTTP status code that appears when the origin web server fails to respond. It typically occurs when a website uses a Content Delivery Network (CDN) service like Cloudflare. It occurs when Cloudflare tries to connect to your website and doesn't receive a response within a specific time."

So, my site has a fairly extensive catalogue of products/images, but if couldflare is an issue, maybe i should drop it?

If your "home" page takes over 30s to load each time then people won't be visiting your site very often :slight_smile:

If you have lots of static images a CDN is excellent for that. You just have to configure it to cache them properly.

I get almost instant responses from those same tests Bruce ran. I think chasing the 522 is a diversion.


Do you know which ACME Challenge that panel uses?

I have been assuming HTTP but I suppose TLS-ALPN or a DNS challenge is possible if they have a custom panel. The kind of challenge is setup by the ACME Client (the panel in this case) and the Let's Encrypt Server issues that challenge to prove you control that domain.

It is probably using an HTTP challenge which has a request like below (which failed 522 for Bruce). I have only ever seen it fail with 403 Forbidden. The 403 might mean that your Cloudflare security settings are not allowing the incoming requests from the Let's Encrypt Server. Have you changed them recently?

You might ask about Challenges · Cloudflare Web Application Firewall (WAF) docs
setting on the Cloudflare forum or perhaps @linkp will offer help (he's far more a CF expert than I am)

curl -I
HTTP/1.1 403 Forbidden
cf-mitigated: challenge
Server: cloudflare

I see that the site is currently paused at Cloudflare. That should remove one variable from the equation.

One Cloudflare feature that I have had interfere with my HTTP-01 challenges is Always Use HTTPS. I manually exempt the /.well-known/acme-challenge path from redirection in my Cloudflare accounts.

Here is a reply of mine in a previous topic here that lists some of the Cloudflare settings that I use to enhance HTTP-01 challenge reliability.


And, we no longer see a 403 for a test challenge. @gil49r I think reviewing the security settings just linked to by @linkp is a good idea.

I see that you have a lot of "moving parts". Not only did you have Cloudflare redirecting (and its CDN can cache) but your Wordpress is doing redirects and has a cache of its own. Not necessarily bad but more parts means more pieces to debug. And more things to tune properly :slight_smile:

Current test http challenge flow (with Cloudflare proxy disabled)

# Redirect to HTTPS by Apache
curl -I
HTTP/1.1 301 Moved Permanently
Server: Apache

# That in turn gets redirected to your WWW site
# Controlled by a WordPress setting
curl -I
HTTP/2 301
x-redirect-by: WordPress
server: Apache

# Following that gets the expected 404 for a Not Found
# wpo- headers probably from your Word Press setup
curl -I
HTTP/2 404
wpo-cache-status: not cached
wpo-cache-message: This page returned an HTTP unauthorised response code (404)
server: Apache

So Mike, Bruce and linkp,

Spent about 30 minutes with dreamhost support and to their credit they straightened me out on my stupidity and both sites now load. I didn't understand why the IPs changed, so:
"Looking at your account, I do noticed that there was an email sent about a recent server moved which would explain the changed of IP address, In the email notice, it was advised that domains using a custom nameserver need to update the A record of the website manually to current nameservers to continue your website and service feature running without any problem. By default, once a server move occurs, as part of our failsafe, the old server remains active before it gets decommissioned. The given time frame for the old server is allotted for end users to update the respective DNS entries to its external nameserver provider. However, since the website's A record has not been updated yet and the old server is already decommissioned, it caused an issue with the website."

"ok, that makes sense, so my bad for not paying closer attention"

So, to you guys here at the community, thanks for your help, appreciate the interest.
My home page takes about 5 seconds to load up.
I will check the reply re: HTTP-01 challenge.
I'm in just a little bit over my head on this, but def understand "moving parts", caches and proper tuning, so I'll dig into that. :slight_smile:


Hi @gil49r,

The presently being served certificate was not issued by Let's Debug,
that is OK if that is what you are expecting.


That is likely to be the Cloudflare edge certificate. The domain is currently proxied.


Cloudflare uses various certificate authorities to obtain certs on behalf of the domains they manage.


Thanks @linkp and @MikeMcQ :slight_smile: