I am looking to disable TLS 1.0 and 1.1 for my custom domain. I followed the recommendation in How can I disable TLS 1.0, TLS 1.1 and weak ciphers with custom domains? by setting tls_policy to recommended.
It did disable TLS 1.1; however, TLS 1.0 is still enabled. How do I completely downgrade support for both these older TLS versions?
Thanks for reporting that. I’ll look into that and will get back to you shortly!
Hey there!
I was asked to have your tenant name to perform some checks. Can you send it to me via private message? Thank you!
Hey there!
Have you had a chance to check out my last message? Thank you!
Solution
"tls_policy":"recommended" instead of "tls_policy":"compatible"
Hello,
I have some additional detail around this. Depending on how you’re checking for TLS 1.0 and 1.1 support it can appear to still be enabled after changing the policy via the management API, particularly if you are using the SSL Labs tool (it’s a great tool but it’s not always 100% clear what it is doing).
SSL Labs is checking for TLS protocol support with and without SNI (Server Name Indication). Our configuration flag disables TLS 1.0/1.1 only for requests to your domain, as indicated by SNI in the TLS handshake. The “default” domain that you would reach without SNI will still allow you to negotiate a TLS 1.0 connection (the default domain does not have a valid certificate so that’s not very useful).
You can see this with OpenSSL when you try to force a TLSv1/1.1 connection for your domain with SNI (-servername does SNI for the indicated domain and -tls1 and -tls1_1 forces TLSv1 and v1.1, respectively):
openssl s_client -connect my.custom.domain:443 -servername my.custom.domain -tls1
and
openssl s_client -connect my.custom.domain:443 -servername my.custom.domain -tls1_1
(I won’t include the output here as it’s messy, but the result is a handshake failure for both TLS versions)
And then try:
openssl s_client -connect my.custom.domain:443 -tls1
That does TLSv1 without SNI–the handshake succeeds but from the TLS perspective there is no hostname context, so you get the server’s default certificate (it’s self-signed and expired since it’s not actually used). A connection without SNI can’t be used to interact with your tenant.
I hope that helps clear this up.
Thanks for clarifying that Matt!
Thanks Matt and Konrad. We will look into this.
Let us know if you have any further questions!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
FYI, we have removed support for TLS 1.0/1.1 as of May 12, 2021. The above commands forcing TLS 1.0 and 1.1 will now return a handshake error regardless of tenant settings or SNI.
The request is rejected at the network edge so you won’t see any indication of the failure in tenant logs.
Thanks for following up on that Matt!