Disabling deprecated TLS cipher suites during validation

We will be disabling support for certain rare and obsolete algorithms in TLS handshakes conducted by the HTTP-01 and TLS-ALPN-01 validation methods. Specifically, we are disabling the following cipher suites:

  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

We currently observe nearly zero usage of these cipher suites: only 0.004% of successful HTTP-01 and TLS-ALPN-01 validations end up using one of them.

If your web server is up-to-date and you haven't manually configured a cipher suite preference, you should not be affected.

If your web server only negotiates these cipher suites, and you use TLS-ALPN-01 validation or HTTP-01 validation with a redirect to an HTTPS URL, validation will fail.

This change will go into effect in Staging today and in Production on Wednesday, July 24.


Note: This does not have any effect on the key types or signature algorithms used in certificates that we issue. This affects only the validation process.

During a TLS handshake, the client (our validation agents) and the server (your webserver) negotiate a cipher suite to use to encrypt the connection. While all modern cipher suites use the TLS certificate's key to sign an ephemeral key exchange, there are a collection of older cipher suites (listed above) which use the RSA TLS certificate's key to directly encrypt the session key. This has multiple issues -- such as not providing forward secrecy -- and has led to these cipher suites being removed from TLS 1.3 entirely and strongly discouraged in TLS 1.2. The cipher suites are deprecated in Go's standard library, and this change corresponds to removing the tlsrsakex=1 GODEBUG variable in our environment.

Generally both the client and the server have a list of cipher suites they’re willing to negotiate, and select one that both prefer. When we reach out to perform HTTP-01 or TLS-ALPN-01 validation, we put these suites at the very bottom of the list so that most servers don’t select them, even if they technically still support them. The only servers that should be affected by this change are those that are configured to only support these cipher suites; all others will continue to successfully negotiate a more modern key exchange method.

If you experience validation failures due to this, possible fixes include:

  • using DNS-01 validation;
  • updating your web server to support TLS 1.3;
  • enabling ECDHE cipher suites in your server configuration; or
  • not redirecting your HTTP validation traffic to HTTPS URLs.

To verify that you are unaffected, you can test against our Staging environment. If you have any questions, please create a new thread in the Help section of this forum with details about your web server and ACME client configuration.

14 Likes

This change has been deployed to staging.

7 Likes