Questions about SHA-1 CSRs and validation using TLS 1.0 / 1.1 URLs

If you have any questions about the upcoming deprecation of SHA-1 CSRs and TLS 1.0 / 1.1 during validation, please post them on this thread.


I presume the primary motivation behind this is because Golang is moving towards rejecting SHA-1 signatures (crypto/x509: reject SHA-1 signatures in Verify · Issue #41682 · golang/go · GitHub) and is also dropping support for TLS 1.0/1.1 (crypto/tls: disable client-side TLS 1.0 and TLS 1.1 · Issue #45428 · golang/go · GitHub)? So you effectively get these things when you upgrade Go.

Anyway, I think this will be helpful in the long run. Only issue may be old software that is fixed on handing out SHA-1 CSRs. You can fix an ACME client, but not clients where you have no control over CSR generation (you know, devices where you would manually upload certs). So yeah, unfortunate but hopefully for the better.


Isn't this default behaviour for renewal after having Certbot install a cert using --nginx or --apache? As I don't think the default Certbot redirect makes a distinction between http-01 challenge requests and non-http-01 requests with the default redirect.

So that makes me wonder: how can that number of 0.00023 % be so low? That few Certbot users out there?


I think that number refers to setups that both redirect to https and do not support TLSv1.2+.


That's correct. To be more specific: in Go 1.18, SHA-1 signatures on CSRs started to be rejected. There's an override that with an environment variable, up until Go 1.19. As it turns out, the upcoming Go 1.18 release is going to relax that restriction a bit, but we still want to get ahead of it.

That's correct.

Also if I recall correctly, Certbot sets up an if statement on Nginx to answer the challenge directly on HTTP without waiting for a redirect. So that's part of why the number of validations that follow redirects isn't higher.


Hm, true, if the apache or nginx plugin is used as installer as wel as authenticator, this is I believe the case. However, if the webroot plugin is used in combination with the nginx or apache installer plugin, then this is not the case I believe. That said, this is probably not that common. We sometimes advice this combination for certain troublesome configurations to "just get it to work" instead of spending much time on debugging the not-so-standard webserver configuration. But it won't be common indeed I recon :slight_smile:


IIRC, Tomcat is frequently an example of webroot authentication and an apache-oriented deployment hook.


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