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

[ambiente1]

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/
Merkle Town
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

[Osiris]

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

[ambiente1]

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

As i understand for now:

• get the year of the issue date by adding 3 month
  e.g.: 2020-11-08 + 3 month = 2021-02-08 = 2021

• selecting some servers from https://www.gstatic.com/ct/log_list/v2/log_list.json by adding the value of the calculation above
  e.g.: https://ct.googleapis.com/logs/argon2021/

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

[Osiris]

@ambiente1

get the year of the issue date by adding 3 month

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

@ambiente1

selecting some servers from https://www.gstatic.com/ct/log_list/v2/log_list.json by adding the value of the calculation above

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

@ambiente1

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

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

[ambiente1]

@Osiris

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.

Okay.

@Osiris

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

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.

[petercooperjr]

@ambiente1

Or do i need to submit to various log servers on my own?

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?

[ambiente1]

@petercooperjr

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?

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.

[Osiris]

@ambiente1

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.