The error called Authentication Failed Because the Remote Party has Closed the Transport Stream may occur when you are trying to call an external API. For your information, this kind of error has something to do with the Security Protocol Type. By getting this error, your application’s default security protocol type is set to low.
If you are facing the intermittent errors when sending SMTP emails with Office 365, there might be something wrong with the SSRS or PBIRS. However, there is a chance for the error to be caused by a different app.
There is a thing known as TLS. This one has become the reason why a lot of people are frowning their forehead. Actually, TLS is a great thing and there are some changes with the intention to safeguard your security. However, a lot of people believe that these changes have picked up radically since around mid October last year. The possible reason why this issue is intermittent is that Microsoft is rolling out the changes gradually on a server basis and whether your email sends successfully depends on whether you connected to an endpoint that has had this change yet.
A couple years ago, Microsoft stated that they would stop the TLS 1.0 and TLs 1.1. Due to the current pandemic, this one was paused and then continued starting from October 15, 2020.
In order to fix the Authentication Failed Because the Remote Party has Closed the Transport Stream error message, all that you have to do is to simply stop using TLS 1.0 or TLS 1.1 to send mail. However, for those who are using a really old application, it can be harder than it seems. It is also harder if the SMTP library used by the application is old and has not been updated. Here are two solutions that can solve the issue:
Solution 1:
The first method to fix the Authentication Failed Because the Remote Party has Closed the Transport Stream error message is to set up an email relay. This one is able to be done by IIS or a different application. Feel free to try anything that you want. By following the step, you will have your application forward the outbound email to the email relay, the one that will accept the email with TLs 1.0 or TLS 1.1. Then, the email relay will relay the email to Office 365 with the TLs 1.2 or higher. It will act like a middle man or a bridge that connects your application and Office 365. For those who are having a hard time and need help to set up a relay, you are suggested to ask your SMTP administrators if they can lend their hand. In case you do not have one, the best thing that you can do is to look it up on Youtube or use your favorite search engine to find one. By following the steps, it should be easy for you to find one since there are a lot of them.
Before trying this solution, you will need to know that there are some processes and cons. The pros include you will not affect any other applications with this workaround. As for the cons, you will be sending the mail to the relay with TLS 1.0 or TLS 1.1 or unencrypted, meaning it is possible that a middle man attacker would be able to potentially read the data that you are sending. There is no way for you to be fully protected by TLs 1.2.
Solution 2:
Compared to the first solution, this one is harder. However, it could be an issue if the application that is having issues is hosted on a machine with a lot of other applications. In order to fix the issue, you can try to apply the following registry entries to the machine that is affected. Remember that it is important for you to disable the TLS 1.0 and TLS 1.1 for all outgoing client connections. Not only that, you also need to tell the system to use the TLs 1.2 or TLs 1.3 instead of the previous two.
Apparently, what your applications want to use will be overrode and they will be forced to use a secure TLS. While your Office 365 issue will be fixed, it could break the other things. For instance, there is a possibility of you having an ELT job running on the same machine that uses an old OLEDB driver to extract data from a database and store it to another. In fact, the TLS 1.2 is not supported by the older OLEDB. The reason is because your change is telling it that it is a must for it to use TLs 1.2 or higher and if not the OLEDB driver will fail. Besides, a full account of what other processes are running on the machine as all client connections will be affected.
There is a benefit of choosing the second method, which is being able to upgrade all client connections to TLS 1.2 or higher. However, it also has some weaknesses, such as you will get in trouble if you are connecting to a different system that does not support TLs 1.2 or if TLs 1.2 is not supported by your client drivers.
Make sure to add the following registry to target 32-bit applications that are running on 32-bit Oss and for 64-bit applications that are running on 64-bit Oss:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
“SystemDefaultTlsVersions” = dword:00000001
“SchUseStrongCrypto” = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions” = dword:00000001
“SchUseStrongCrypto” = dword:00000001
For 32-bit applications that are running on 64-bit OSs, update (or create) the following subkey values:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
“SystemDefaultTlsVersions” = dword:00000001
“SchUseStrongCrypto” = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions” = dword:00000001
“SchUseStrongCrypto” = dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
“Enabled” = dword:00000000
“DisabledByDefault” = dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
“Enabled” = dword:00000000
“DisabledByDefault” = dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
“Enabled” = dword:00000001
“DisabledByDefault” = dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
“Enabled” = dword:00000001
“DisabledByDefault” = dword:00000000
After the changes are applied, do not forget to reboot the machine.
AUTHOR BIO
On my daily job, I am a software engineer, programmer & computer technician. My passion is assembling PC hardware, studying Operating System and all things related to computers technology. I also love to make short films for YouTube as a producer. More at about me…
Leave a Reply