(Edited: have now confirmed that the thing that stopped this working was NOT a windows update, but an update to our service app)
We have a .Net 7 Web API service, running using Kestrel.
This service used to work, but it seems that upgrading it from .Net Core 3.1 to .Net 7 has stopped TLS1.0 from working in some situations.
This serves requests from a number of other devices/machines on a local network, using HTTPS.
A number of these devices are legacy/embedded (typically Windows XP embedded), which exclusively support TLS1.0.
I will upfront state that upgrading these clients in any way is simply not an option, nor do we have access to those machines to change their configuration in any way.
I know and understand why TLS1.0/1.1 are now considered obsolete and absolutely not recommended, but in this situation we simply don't have a choice, and we are trying to get these ancient client machines out of the picture, but this is unlikely to happen in the near future.
On some other similar setups, we have successfully worked around this problem by re-enabling TLS1.0 and re-enabling certain cipher suites, but for this machine that doesn't appear to have helped. We have done this both via direct registry changes and using the IISCrypto tool.
I have a simple Test Client application which happens to be written in .Net Framework 4.8, and by changing that to exclusively use TLS1.0 I don't have the same issue, so it's not TLS1.0 specifically, but seems to be something else like Cipher suites.
Using Wireshark I can see the "Client Hello" message, and the list of supported cipher suites:
This is invariably responded to with an "Alert (Level: Fatal, Description: Protocol Version)" message:
I can add info about the relevant registry settings, but IISCrypto gathers all this fairly well, and it now reports that not only the server does support TLS1.0:
but also that I have enabled and moved to the top a number of the specific ciphers requested in the "Client Hello" message:
(Previously we have worked around this sort of issue by only having to enable TLS_RSA_WITH_3DES_EDE_CBC_SHA and not change any ordering, but we've not found that helped here at all - you can see that this specific cipher suite is listed as the 2nd available in the cipher suite list on the machine, and is the third in the list in the original client request)
In case anyone asks if using IISCrypto is the problem, windows itself happily reports TLS1.0 is enabled:
and powershell's Get-TlsCipherSuite does list the ones I've added, in the order I added them:
- Other clients which are more modern are fine.
- Other installations with similar sorts of clients and older Server OS are also fine
- A couple of installations with similar sorts of clients and the service running on Win11 are also fine, after we re-enabled TLS1.0 and re-enabled one specific cipher suite.
Any more suggestions of things I might look at?
