Mac OS X server apache runs under _www

I am running a Joomla website, At this moment it has a letsencrypt certificate until Aug20. Getting this certificate was not a problem.
Running renew for a new certificate is a problem. The script does not use _www, so the mystery file(s) are just not visible over the internet.
What is the best way to solve this?

Hi @cobrp,

Could you explain more about what you mean here? What script are you using? What Let’s Encrypt client are you using? How do you mean that it “does not use _www”?

The cert is use ( has only these FQDNs in the SAN:
X509v3 Subject Alternative Name:

So, it’s safe to assume that a problem will occur when accessing the site(s) via domain names without the leading www; as shown here:

In regards to a solution…
It seems that the renewal script is using plain domain names while the initial cert process used only the www names.
@schoen Can this cert be expanded to included the base domain names?
Or should a completely new cert request be made to include all the required names?

I’ve never used “–expand” option but I think either method should work.

Thanks for your fast reply :
I did use and letsencypt-auto renew. Both were complaining about fetching the two files with long names like VbxAIhlpATGqBAtnCq… I called ‘mystery’ files.
My scripts have other rights than _www. So writing the ‘mystery’ files leads to files with the wrong rights.

@rg305, thank you for your tip!
I wil try to expand.


On server:

varvik:acme-challenge cobraspenning$ pwd

-rw-r–r-- 1 root staff 0 17 aug 14:42 EazEB90HdD7IeWqrZ0CfrFsB3TX3GdU_lKnZXgpDU8I.rmRqc95coC6My-ZRDLLkP7yP_Nhx10IPTOmv3c_IpY0
-rw-r–r-- 1 _www staff 15 17 aug 14:10 test.txt

The consequence of root:staff is that the file will not be displayed in a url.

Hi @cobrp,

I’m afraid I don’t agree with your interpretation of this error. “Timeout” means that the certificate authority could not connect to the web server at all, not that the web server refused to serve a file or didn’t recognize the contents of the file.

In the permissions -rw-r–r-- for this file, the third r means world-readable, which means that the web server can read the file even though it is owned by a different user. Having world-readable files created by a different user is not unusual or a problem for a web server in general.

However, in order to issue a certificate, including a renewal certificate, the certificate authority needs to use one of the supported validation methods to check your control over the domain name. Currently, your server at does not accept any incoming connections at all on port 80 (HTTP), only on port 443 (HTTPS). The webroot method that you’re using here requires that there is an existing web server that listens on port 80, and that’s the port that the certificate authority will connect to. Right now, when the certificate authority tries to connect to port 80, it finds nothing listening at all—and that’s the reason for the Timeout error. I see this myself when I try to connect from other locations on the Internet.

You can also confirm it by trying to look at

in a browser. Depending on the server headers that you use, it might need to be a fresh browser profile that has not connected to the HTTPS version of the site before. You should see that this doesn’t connect at all because nothing is listening on port 80.

If you can’t receive inbound connections on port 80, you can use a different challenge method. They are described at


Hi @schoen,

Thank you!

After the first certification I closed down the sites over port 80. The ports are open again and renewing was an easy job!

varvik:my_script cobraspenning$ ./
1 identity imported.
2 certificates imported.

Thanks again!!!:grinning:

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