Thanks guys, I was wondering when I'd get a point where it's no longer practical to run the client through Windows, perhaps I'm getting close. I can connect fine over HTTP, but when I put in the SSL/certificate configuration no go - implementing the suggestions made by all.
Michael Salisbury Senior Systems Architect | P 07 960 7011 | E mich...@skypoint.co.nz | W skypoint.co.nz Waikato Innovation Park, Ruakura Rd, PO Box 9466, Hamilton 3240, NZ Please send any support enquiries to E supp...@skypoint.co.nz -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, 22 June 2015 11:24 p.m. To: Tomcat Users List Subject: Re: SSL configuration using PFX as keystore Mark Thomas wrote: > On 22/06/2015 09:39, Mark Thomas wrote: >> On 22/06/2015 00:25, Michael Salisbury wrote: > > <snip/> > >>> When connecting from a Windows client (any Windows client) I get a 'network >>> path not found' error 0x80070035. I know the path is valid as I can reach >>> it via other means, and other WebDAV clients. >>> >>> The main reason I think this is a Tomcat issue is that it was working just >>> fine with v7.0 and no other Windows client changes (updates, software etc.) >>> have been made. There wasn't anything specific in the Tomcat7 config that >>> I needed to get the MS client to work, only on the client itself those >>> registry changes as previously mentioned. >> What about the WebdavFixFilter? Is it configured in Tomcat 7 but not 8? >> >>> I'll run a Wireshark trace and see what comes up, nothing in the Tomcat >>> logs that I can see... >> I'll do a quick test now and see what I can come up with. > > I needed to enable directory listings otherwise I got a 'network name > not found' error 0x80070043. > > With that one change I was able to map a Windows network drive to: > > http://<ip-address>/ > http://<ip-address>/test > http://<ip-address>:8080/ > http://<ip-address>:8080/test > > With https the behaviour is very strange. Windows is prompting me for > credentials even though none are required. I suspect that the > untrusted test certificate may be causing some of these problems. > > I fixed the certificate problem so that IE viewed the site as trusted > and then I could map a network drive to: > > https://<ip-address>/ > https://<ip-address>/test > https://<ip-address>:8443/ > https://<ip-address>:8443/test > > No registry changes were required to get this to work. > > Prompting for authentication in response to an untrusted certificate > is bizarre to say the least. > > Microsoft generously provide MSDN subscriptions for Apache committers > which is why I have the various OS's to hand to test this. The > subscription also comes with tech support. I'll open an incident. It > will be interesting to see if things have improved since I last tried > raising bugs with Microsoft (I filed so many bugs with MS Office and > it took so long for MS to fix them that I hit the limit of issues MS > would let me have open in parallel). > > I was testing with Windows 7, SP1, 64-bit, fully patched > > None of my WebDAV endpoints are configured to require authentication. > > I did not have to use the WebdavFixFilter. > > Note that I do not have MS Office installed on this machine. > > It does look like things have improved with more recent versions of > the Windows clients. I'm not sure what is causing the error you are seeing. > Maybe MS Office ships with a different WebDAV client. From what I remember, yes it does. That is what I was referring to when talking about "depending on what other software is installed on the workstation." As I recall, when installing MS-office, it replaces the "mini-redirector" by its own DLL, and that changes the behaviour in a number of instances. From past > experience, I'd suggest trying some of the following: > - get it working over http before trying https > - get it working at the server root before trying just a context > - get it working without authentication before trying with > authentication > - ensure you have directory listings enabled > - ensure that IE trusts any certificates and no certificate errors are > reported when connecting over https > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
