Hostnames in sent list of SHA-1 CSR deprecation

In May we updated our ACME client to use SHA256 in CSRs, with your help in the following post I submitted to your forum:

We host hundreds of hostnames that use LE certificates. All of them were issued using our self-developed ACME client.

Today we received a message from you about the deprecation of the SHA1 CSR, with a partial list of the hostnames we host. I believe some of these certificates already used SHA256 in their CSRs.

For instance, the first hostname in the list is 360cycling.com.br. Its cert was renewed on 7/15/22 using SHA256 in the CSR.

Also, the list doesn't contain many other hostnames we host that were renewed using the same updated ACME client prior to the above date.

For example, the lingerie.com.br certificate was renewed on 7/6/22 with the same client and is not on the list.

Could you please double check that the list you sent is accurate?

4 Likes

The search we ran to identify potentially affected certificates looked backwards for 90 days. For your example of 360cycling.com.br, it was previously issued on 2022-05-15, which was requested with SHA-1. Your later issuance on 2022-07-15 used SHA256 in the CSR.

We didn't filter out certificates which were issued later with a different hash, which seems like it is confusing in your case where you've already upgraded during the period of logs we examined. I'm sorry we overlooked that case and that it caused confusion here. Thank you for upgrading your software, though!

9 Likes

Thank you, Matthew. That explains everything.

To avoid confusion, I suggest you only include the most recent issue of each certificate in the warning list, if it still uses SHA1 in the CSR of course.

3 Likes

Sometimes people use two different clients with the same domain name (eg, If they’re running a web and a mail server or something), so we can’t guarantee that just because another cert was issued that the sha-1 client was unused. So we took the more cautious approach.

We could have perhaps flagged this though or otherwise noted it in the email, but I think it’s a bit of an edge-case and hard to handle.

4 Likes

Is it an edge case? It seems this is the more common situation. If I understand correctly, you email someone saying to upgrade. They do and get new cert. They are done. No further warning needed.

It seems the edge case is someone using two different acme clients and only upgrading one of them.

2 Likes

The "catch window" is anyone with X clients NOT having upgraded (all) X clients PRIOR to the 90 day window.

So, even when X is one, they can still fit; As most clients renew on a 60 day window.
[leaving room for two renewals within the 90 day window and each being of different types]

When X is greater than one, then it seems even more likely to occur - or, at least, in having a greater chance of occurring. It comes down to WHEN did their client get updated and what percentage of their clients have been updated.

Maybe we could use a smaller (than 90) window and "slide along with it" and achieve the same level of awareness - while reducing the number of "false positive" alerts.

How would a "59 day window" work?

1 Like

The common case is you're not using SHA-1 CSRs at all. So as soon as we're looking at these clients, we should presume something unusual is going on. In the case of this thread, it's an in-house client that happened to be updated during the last 90 days to fix this problem already.

The downside to not notifying somebody they used SHA-1 is that their renewals might break unexpectedly in the future, which is very bad. The downside to sending an un-needed email is that somebody may do a bit of investigation and learn there's no action to be taken, which isn't so bad at all.

And the more processing we do, the more likely it is we're going to introduce an error or mistake, so simplicity is valuable here too.

3 Likes

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