Unexpected status 400 Bad Request from log server: chain failed to verify: NotAfter

I'm using a bash script to renew my certificates and push them via ct-submit-master to some log servers. But it seems to be not working properly.

How do you select the correct log server versions (year)?

My domain is: https://www.hscorp.de // https://crt.sh/?q=hscorp.de // https://crt.sh/?id=3617861766

I ran this command: certbot renew --quiet // ct-submit-master

It produced this output:

failed

nessie2020.ct.digicert.com/log/
yeti2020.ct.digicert.com/log/
ct.cloudflare.com/logs/nimbus2020/
mammoth.ct.comodo.com/
sabre.ct.comodo.com/

unexpected status 400 Bad Request from log server:
Bad Request
failed to verify add-chain contents: chain failed to verify: certificate NotAfter (2021-02-06 00:37:44 +0000 UTC) >= 2021-01-07 00:00:00 +0000 UTC

working

ct.googleapis.com/logs/argon2021/
ct.googleapis.com/logs/xenon2021/

My web server is (include version): nginx-1.18.0

The operating system my web server runs on is (include version): linux-gentoo-5.4.66

My hosting provider, if applicable, is: Hetzner

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): certbot-1.8.0 / certbot-1.9.0

1 Like

Your certificate has been logged by all kind of logs. The logs which are running yearly shards all list the 2021 shard.

I had asked something about this earlier and if I recall it correctly, the notAfter date determines the shard you'll have to choose. In this case 2021. (Source: How is it possible ? future logging)

Unfortunately, I don't know how the Comodo logs are temporally sharded.

In a Let's Encrypt blogpost there are 2 links in the Sharding section: https://letsencrypt.org/2019/11/20/how-le-runs-ct-logs.html

2 Likes

Okay, but i have a problem in understanding the term.

As i understand for now:

That's all?
Second question, do i need to forward sct to other log servers than lets-encrypt itself?

1 Like

It's better to just use the notAfter date in the certificate.

That is only applicable for those CT logs using temporal sharding. Not every log does that.

I'm afraid I don't understand this question. Forward the SCT? What does that mean?

2 Likes

Okay.

Sorry, i am not very familiar with this.
I mean, i submit the certificates to a log server using ct-submit-master.
The question is, do i need to submit these only to one log server like Let's encrypt ones and this log server shares itself to others?
Or do i need to submit to various log servers on my own?
Anf if, how many i should select?
Currently i'm using eight.

No, Let's Encrypt submits to the certificate transparency logs for you. (And that's really the point, that they have to make public everything they sign.) Why are you trying to submit certificates yourself? What's the problem that you're really trying to solve here?

1 Like

Perfect, than i misunderstand the usecase with ct-submit-master.
I thought i need to manually submit my certificates to any log server for being transparent.

No, Let's Encrypt submits a pre-certificate for which the CT logs return a SCT, which Let's Encrypt embeds in their definitive certificate, which in turn is send back to the ACME client.