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
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.