We are using DNN Release 09.06.02 hosted on Microsoft Azure. Until recently we have had no issues with using the DNN Azure Storage Connector to access documents stored in Azure blob spaces.
We have configurated the storage space interface to use TLS 1.2. However, we are unable to access any of the couments via the DNN Azure Connector or directly using the Azure document URL.
We have also incorporated Web Service interfaces to our DNN instance using the WSDL interface.
So, my question is in regards to the DNN incorporation of TLS 1.2 into the DNN base software. Which release was the first to incorporate the TLS 1.2 protocols for both email (SMTP) and HTTP interface protocols.
This becomes a critical issue after October 30, 2024 when Microsoft will no longer support use of any TLS version less than TLS 1.2.
Thanks for any further information..
If I remember correctly, tls 1.2 was DNN 9.3 ( a looooooong time ago :-) )
So, we need to dig further on this one. First is to verify that the server is also set to support 1.2 As you mention that the Azure url is not accessible directly, that sounds like an Azure permission. Or do I misinterpretate this?
Tycho,
Thanks for your response. Upon checking on the interface, I think that the issue may be with the DNN Storage Connector. I just invoked a new connector and noticed that the Asure Connector has been re-labeled as Connector 2-4. When I use this Connector with a Site Asset, there appears to be no problem; but it does not work, I receive the following error message:
AuthenticationFailed
Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:a44f3694-001e-004e-4c36-22402e000000 Time:2024-10-19T14:49:41.8874863Z
se is mandatory. Cannot be empty
Now, it becomes interesting. When all stopped working well the URL for this file was shown as:
https://thevwc.org/websit...mUfwErKECTARBqBUg%3D
Note that the interface used the DNNFileManagerPolicy. If I remove this restriction to use the following URL:
https://vwcmembers.blob.c...itevideos/Router.mp4
I can access the file, both from the website and directly from a browser.
SO, I think that the issue is two fold:
a. The DNNFileManagerPolicy has an issue
b. This file policy has been removed from Azure recently, when I added a new Connector.
this is additional information and I am not sure why the DNN Azure Connector has been renamed, why it has been removed from Azure and why it does not appear to be working.
Oh .. I forgot to add that the current URL that is transmitted to Azure for a file using the current DNN Azure Connector is:
vwcmembers.blob.core.windows.net/we...9340709065
Note that it does NOT contain the invocation for the Azure File Manager as previously. This also point to an issue with the current version of the DNN Azure File Connector.
It's worth noting that upgrading DNN would be a very good idea. There have been many underlying updates since DNN 9.6.2, including many to the connector. (Not to mention some important security updates.)
I'd also suggest putting the site behind a WAF if you haven't already, and also enforce TLS 1.2 at that level (in addition to doing this in Azure itself).
I apparently solved the issue with an upgrade to DNN Release 9.9.1 which is the latest that I have fully tested with all of our custom modified modules.
Thanks for listening....
Posted By Hans Zassenhaus on 10/21/2024 2:10 PM I apparently solved the issue with an upgrade to DNN Release 9.9.1 which is the latest that I have fully tested with all of our custom modified modules. Thanks for listening....
Great news! Thanks for letting us know. 💪🏽
It can save a ton of time when it comes to things like this, if you're able to keep up with updates. There are always bugs being fixed that can be a real time-saver! 😎
OOPS ...I was too quick to pull the OK trigger, Iguess. I went back to the website this morning and the problem had returned, even with the installation and re-installation of DNN Release 9.9.1.
Apparently there was a setting change in Azure, which removed the DNNFileManagerPolicy parameter from the Azure invocation submitted by DNN to Azure. Not sure what happened here; but the net result is that the request for access to the Blob container is not authorized. The error messages are non-existent in the logs.
Posted By Hans Zassenhaus on 10/22/2024 12:03 PM OOPS ...I was too quick to pull the OK trigger, Iguess. I went back to the website this morning and the problem had returned, even with the installation and re-installation of DNN Release 9.9.1. Apparently there was a setting change in Azure, which removed the DNNFileManagerPolicy parameter from the Azure invocation submitted by DNN to Azure. Not sure what happened here; but the net result is that the request for access to the Blob container is not authorized. The error messages are non-existent in the logs.
I just did a quick search and I don't see the Azure Connector logging listed as a reported issue yet. You may want to report the logging issue as a bug in GitHub so it works better for you and everyone else in the future. 😎
These Forums are dedicated to the discussion of DNN Platform.
For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:
Awesome! Simply post in the forums using the link below and we'll get you started.