there are lot's of possible causes. you may start with:
aos seems not to respect the x-forwarded-by header but webdav relies on the url send in the body which may be the containers host name. When using a reverse proxy like nginx you need to set aos.baseUrlOverwrite in your alfresco-global. e.g.
Firstly, the aos.baseUrlOverwrite option is set correctly to https://<alfresco server dns>/alfresco/aos in the alfresco-global.properties file
With respect to your other questions...
1. The version of nginx we are running is "openresty/18.104.22.168" and it is compiled with the "--with-http_dav_module" flag and is verified by running nginx -V
2. Commercial certs for our domains are installed and configured within the nginx config on each of our domains "prod", "uat" and "dev"and all are trusted by all Windows machines on our network.
All http traffic is automatically redirected to https at the nginx reverse proxy and is then proxied on to the correct service endpoints i.e. http://alfresco:8080
3. All components of the Alfresco installation, alfresco, share, solr6, nginx etc are all running inside independent docker containers started with a docker-compose.yml file running on ubuntu 16.04 VM's. So the alfresco web client is not running on a windows box and alfresco itself has been deployed along with the aos amp file.
All SSO auth is done via Kerberos and users are automatically logged into their Share UI when selecting an "Internet Explorer shortcut" from their desktop once logged in.
4. I have tried setting up a mapped drive with both the https:// and a UNC options, like you stated. All options return the same Windows errors I stated in my original post.
For the UNC options I have tried
\\<alfresco server dns>@SSL\alfresco\aos - The DNS of the server running the Alfresco docker images ad defined in the SSL certs
\\<hostname>@SSL\alfresco\aos - The hostname of the Ubunto 16.04 VM running the Alfresco docker image
\\<IP>@SSL\alfresco\aos - The IP address of the Ubunto 16,04 VM running the Alfresco docker images
1. Set in tomcat's server.xml your proxyPort="443" and either RemoteIpValve (remapping the requests host name using e.g. x-forwarded-for, x-forwarded-proto set in your nginx location definition) or proxyName (Apache Tomcat 8 (8.0.53) - Proxy Support HOW-TO ) in the Connector definition nginx is connecting to.
3. was related to your windows client. Windows still uses IE redirector running as windows service "Web Client" to connect to a WebDAV/SP server. So please check if the service is running.
To make debugging easier you may allow windows to connect to non ssl servers, disable the redirect in nginx and try to connect from windows explorer without @SSL
1. The Tomcat server.xml has already been set and configured with the proxyPort and the nginx config already sets the x-forwarded-for and x-forwarded-proto headers for requests.
Secondly, I realized after I sent the last reply that the WebClient Service you mentioned refers to a Windows specific service for WebDAV.
This is currently being setup by the network team as the users Windows machines are actually served over Citrix and these are currently locked down without that service running meaning that drives cannot currently be mapped to WebDAV sources.
Once the network team has made the required changes I'll test this out and let you know the outcome.
Thanks for your input on this it was most helpful in first confirming I had set the Alfresco server side components up correctly and secondly pointing out that the WebClient service needs to be running on the Windows machines.
I had somehow interpreted WebClient to mean the Alfresco/Share UI that users mostly interact with. I'm not a Windows person