Unable to renew certificate after setting A record

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

My domain is:rocki.co.jp

I ran this command:sudo certbot certonly --manual -d rocki.co.jp
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate for rocki.co.jp

It produced this output:- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Create a file containing just this data:


And make it available on your web server at this URL:


Press Enter to Continue

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: rocki.co.jp
Type: unauthorized
Detail: Invalid response from https://rocki.co.jp/.well-known/acme-challenge/IWAqmVE22BG_1AnaJrhu4LZfXbY6xUERqr6Ihp2rolE: 404

Hint: The Certificate Authority failed to verify the manually created challenge files. Ensure that you created these in the correct location.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

However, since the beginning of this year, we have outsourced the management of our web pages to a third party and have set up an A-record.

Since the beginning of this year, we have outsourced the web page management to a third party and set the A record. After setting the A record, the SSL update of the WWW is done by the outsourced company and the SSL update of the hosting is done by us.

Before setting the A record, the file was created in /.well-known/acme-challenge in WWW, but after setting the A record, the file was created directly in rocki.co.jp and succeeded.

Also, this is the third update since the A record was set, but it did not succeed once, and when I perform the update after the expiration of the update deadline, the update is successful, although I do not know why.

Translated with DeepL Translate: The world's most accurate translator (free version)

My web server is (include version):Apache/2.4.56 (Unix)

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

My hosting provider, if applicable, is:NTT COMMUNICATIONS

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot1.21.0

Create the file under /.well-known/acme-challenge - only putting the file under the root won't work and probably only passed due to the previous validation being cached by Let's Encrypt.

If you can you should use the certbot Apache integration which is generally something like certbot --apache

1 Like

Thanks for the advice.

I tried creating a /.well-known/acme-challenge directory, but it didn't work.

Does this mean I need the certbot Apache integration plugin?

1 Like

Maybe this is due to the automatic translator, but I don't understand this part:

  • "the SSL update of the WWW is done by the outsourced company"
  • "the SSL update of the hosting is done by us"

What exactly is the difference between "the WWW" and "the hosting"?


Thank you for your comment.

I apologize for the lack of clarity in my wording.
I meant that the web page part is renewed by the subcontractor, and the whole hosting server except the web page part is renewed by us for SSL.

1 Like

But how is that technically separated? Often a website is hosted on the same server as the rest, e.g. have the same IP address.


The web page portion is linked using A records, the consignee's server is configured with SSL settings by the consignee, and the hosting server is updated by us.

I renewed the certificate using the exact same procedure, and the certificate was issued and renewed without any errors.

I don't know why I was able to renew.
The last time I renewed after the expiration date, I was able to do so.

Is there some setting on how long it takes for the certificate to expire, etc.?

Was the renewal done with the previous validation as the person who posted said?

Your first post used --manual so you control when to renew. All Let's Encrypt certs expire after 90 days and recommend to renew with 1/3 of its life remaining (so after 60 days from issuance).

Automated methods do this for you and often allow options to change the renewal time.

No. A previous renewal is cached for only 30 days for the same ACME account. I see two certs issued recently (Aug1 and Aug2) but I assume these are both yours. If so, the second one would not have needed a new auth. But, the one before these was on May8 so was older than 30 day cache.


Thank you for your comment.

I understood the time to expiration and the renewal recommendation.

--A previous renewal is cached for only 30 days for the same ACME account.
→If so, I wonder why it was able to be renewed this time.
When asked if I wanted to update or not, I chose yes, and the location of the secret key came up instantly.

Until a few days ago, when I created an acme-challenge in the specified location, it was in the same state as my first post.

Is the fact that the secret key was issued immediately this time still due to the expiration date approaching?

1 Like

The difference related to the expiration date is not in the certificate authority's behavior, just in clients' behavior in deciding whether to attempt a renewal automatically. The certificate authority is not more willing to give you a renewal certificate closer to the expiration date than it was further from the expiration date.


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