When renew dry-run-- works, verification working?

az, I think that is what is happening for me now. I will have to wait 30+ days to check it.

Is there a way to force renew one subdomain only with certbot-auto? What is the command? BTW, I do not have certbot installed, only certbot-auto. Thank you.

Well, you could do something like:

certbot-auto renew --cert-name pqr.neroth.org --force-renewal

but be very careful, as if you create too many duplicate certificates, you may get locked out from doing it again for 7 days.

_az, Thank you. Since my certificate is currently valid, the command you gave creates a duplicate? Does the new one replace my old one, and practically I would not see any side effects going forward, other than the new one will have an expiry of a few days later? My next auto renewal of all the subdomains would work just as before (if I had not made this dup}. Thanks

Yes, that’s correct.

Hmmm… I ran it with a dry-run-- . To my surprise, it went thru, Congratulations and all. But I do not have port 80 open, at least so I think.

Could you check if my port 80 is open on that subdomain? Thanks.

It’s not open, no - https://letsdebug.net/pqr.neroth.org/18104

The success is likely due to --dry-run using the cached authorization as described earlier.

That you for test link to check open port 80.

Now the plot thickens. I ran it without the -dru-run–. And it actually succeeded. I checked the status, and in fact that subdomain as a renewal as of now.

So what gives? What is the debug link to check if for some reason I have a dns record I had forgotten about?

Your latest /var/log/letsencrypt/letsencrypt.log should detail exactly what port was used, and what happened.

If you can extract a URL from that file that looks like this:

https://acme-v02.api.letsencrypt.org/acme/order/{some numbers}/{some numbers}

it will explain how the renewal was executed.

Please not:
--dry-run uses the staging servers which are forcing only HTTP renewals TODAY.
Without it you use regular production servers which are NOT yet forcing HTTP renewals.

Disclaimer: Mileage may vary. Does not cover all conditions and all situations (like: cached domain authentications). See LOGS for full details.
LOL

_az, I see 3 of that form in the log of the single subdomain renewal yesterday. But I do not know how to figure out how the verification was done.

There are posts to the above website with ports :443 and one default (no colon).
Are the ports 80, 443 used simply to post from my server processor to the outside or for reaching my created standalone server from outside. If the former, there are no restriction on outgoing ports. But incoming on those ports are not open in the router…

Please help me with more details.

I wanted you to post the URLs that you found, since they will contain the validation mechanisms used to authenticate your domains.

But your subdomain still does not have port 80 open, which you MUST open or you won’t be able to renew in future.

The command used was the one you provided:
certbot-auto renew --cert-name pqr.neroth.org --force-renewal

There are two of these url at two places.
Location: https://acme-v02.api.letsencrypt.org/acme/order/{number1}/{number2}

And another, this one with the same {numbers}
2019-01-21 17:02:20,674:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/order/{}/{}:

And 4th, this
2019-01-21 17:02:20,851:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 “POST /acme/order/{}/{} HTTP/1 .1” 200 465

Remember this renewal actually completed yesterday, after the renewal about a few days ago. The certificate has a newer date than other subdomains.

Hi @Cqc

we need the correct numbers to check that.

PS: Now, your site is completely invisible, no http, no https, no /.well-known/acme-challenge.

And your ns2.neroth.org doesn’t support TCP-connections.

Fatal error: Nameserver doesn't support TCP connection: ns2.neroth.org
Nameserver Timeout checking Echo Capitalization: ns2.neroth.org
Nameserver Timeout checking EDNS512: ns2.neroth.org

(via https://check-your-website.server-daten.de/?q=pqr.neroth.org ).

https://acme-v02.api.letsencrypt.org/acme/order/19175837/282065609

I see now that it is a self standing url…

My question/puzzle is NOT why I cannot renew with 443, 80 closed, but why I was able to renew. Thank you for your help

1 Like

Following the authorizations-link:

https://acme-v02.api.letsencrypt.org/acme/authz/idbahvW7VTOS3S2aN7VMaHyDi1Z9kr9MXbhv8RF8Ajw

http-01 was used:

http://pqr.neroth.org/.well-known/acme-challenge/H71FUP11JeU1TJlX74WJQB7hQUnGPzm5in29kQrp43A

worked.


Renewals were being allowed over 443; but that is coming to an end now:

Thank you for all the replies.

However, my puzzlement remains. As others here have checked and stated both my ports 80 and 443 are closed. So was the renewal effected?

Closed to some or closed to all?
For instance: Geo-Location blocking can simulate closed but in reality be somewhat still open.

Anyhow, you can check the certificate transparency logs to see if indeed there was a new cert issued.
Try: https://crt.sh/
[if you used the staging environment then only your logs can show what transpired]

This was against production.
And https://crt.sh/?q=pqr.neroth.org shows a valid cert was created on 2019.01.22
Yet this doesn’t say much about how the cert was obtained (via http, https, dns, using smoke signals, …)
So it doesn’t really help much to answer your topic question…
Unless you can see exactly how it was authenticated in the logs.

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