Unable to register an account with ACME server. Error returned by the ACME server: Unable to validate JWS :: Invalid Content-Type header on POST. Content-Type must be "application/jose+json"

Help
1

My domain is: sonar.endurosatlab.com

I ran this command (part of a Python script):

certbot_cmd = [
"certbot", "certonly", "--non-interactive", "--agree-tos", "-v",
"--dns-route53",
"-d", URL
]

(Where URL variable = sonar.endurosatlab.com)

It produced this output:

Failed to renew certificate for sonar.endurosatlab.com.
Certbot output: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found credentials in environment variables.
Plugins selected: Authenticator dns-route53, Installer None
Unable to register an account with ACME server. Error returned by the ACME server: Unable to validate JWS :: Invalid Content-Type header on POST. Content-Type must be "application/jose+json"

My web server is (include version): N/A

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

My hosting provider, if applicable, is: N/A

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): No

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

More context:
I am running a Python script to renew certificates. The job is scheduled to run every morning in our Gitlab environment and check for expiring certificates. If the certificate of a given domain expires, the certbot kicks in and issues a new LE certificate and stores it in AWS S3.
The domain endurosatlab.com is hosted in AWS Route53, hence I use certbot-dns-route53.
That used to work like a charm few days ago but today I'm seeing the error mentioned above. I haven't changed anything on the Gitlab workflow.

2

Are you totally sure that you're running cerbot 4.0? Are you communicating through some kind of proxy that could alter traffic?

3 Likes
3

In addition to questions from @webprofusion your workflow looks erratic.

First, your error says the failure was registering an ACME Account. But, a renewal normally uses the prior ACME acount info. You shouldn't need a new account.

Second, you have been getting certs on irregular schedule. You got one for this domain about 6 days ago so there should be no need to even try getting another one now. There is a similar erratic pattern for other subdomains of this apex domain.

If you are testing please use the Let's Encrypt staging system.

image
image1821×354 107 KB

4 Likes
4

The command shown is not a renewal command.

3 Likes
6

Since I'm saving the certificates in an S3 bucket I do need to re-issue them (overwrite the old files in the bucket).

7

Yes, I double checked that by running below command in the Gitlab pipeline:

$ certbot --version
certbot 4.0.0

8

I agree I should be using the staging system, definitely taking this into consideration.

However, I still don't understand why using the prior ACME account info (which successfully issued certificates) would throw such error.

9

Certbot does not write to S3. So you must be doing this as a --deploy-hook or some other way. In any case, the point being made was that certbot renew is the normal way to renew certificates. Not by repeating certbot certonly ...

The Certbot renew updates the certs in the /etc/letsencrypt/live the same way

It didn't. The message says it is trying to create a new ACME Account. Looks like somehow the old account info was lost. Or perhaps you are running with non-root permissions and changed how you are running now compared to prior.

4 Likes
10

Thanks Mike, I would go through our Gitlab runners (running in EKS btw) and see if any changes were made in the last couple of days. Thanks for your detailed explanations :slight_smile:

3 Likes