The new replacement certificate doesn’t exist at all until you request it with your client software and also prove your control over the domain name. It’s not that there’s some URL where the replacement certificate is already waiting to be downloaded, for example.
Could you please fill out the “Help” question template below to give some more context for your situation?
Please fill out the fields below so we can help you better.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or 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):
Collaborating Centre on Sustainable Consumption and Production (CSCP) gGmbH; Sitz der Gesellschaft/Registered Office: Wuppertal, Germany; Registergericht/Registered at Amtsgericht Wuppertal, Germany; Eintragungs-Nr./Registration no.: HRB 20060; USt.-ID Nr./VAT ID No.: DE 250 910 282; Geschaeftsfuehrer/Managing Director: Michael Kuhndt
@cpu, do you have more information in server logs to show what the nature of the connection failure was? I don’t immediately see a problem with this setup that would account for this failure.
There is something strange in your redirection, you are adding a question mark ? at the end of every redirection, maybe it is worth to re-check your redirection rules.
curl -IkL server.cscp.net/.well-known/acme-challenge/test
HTTP/1.1 301 Moved Permanently
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 04 Jul 2017 17:53:39 GMT
Content-Type: text/html
Content-Length: 193
Connection: keep-alive
Location: https://server.cscp.net/.well-known/acme-challenge/test? <-- that ? should not be there.
HTTP/1.1 404 Not Found
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 04 Jul 2017 17:53:39 GMT
Content-Type: text/html
Content-Length: 177
Connection: keep-alive
I see a few failures for some cscp.net subdomains (e.g. zurmo, files, etc) around 04/07/2017 07:09 with the following underlying error:
dial tcp 87.139.107.23:80: getsockopt: no route to host
It seems like it may have been transient, I see successful requests to issue for these same names later on. I would guess something went bump-in-the-web between the VA and this IP.