You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael Salisbury <Mi...@skypoint.co.nz> on 2015/06/19 06:42:23 UTC
SSL configuration using PFX as keystore
Hi there,
I'm trying to get the above working using Tomcat 8.0, previously working with 7.0. This is part of a WebDAV connector in Confluence.
It seems I can connect from anything other than a Windows Mini Redirector client (Windows 7 or 8.1, x86 or x64). Using a web browser or 3rd party client (CyberDuck for instance) connects OK.
There are some registry keys in Windows one needs to enable to get this working first:
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Internet]
"BasicAuthLevel"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters]
"BasicAuthLevel"=dword:00000001
"UseBasicAuth"=dword:00000001
Server.xml
<Connector port="9443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
protocol="org.apache.coyote.http11.Http11NioProtocol"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocols="TLS" SSLEnabled="true"
URIEncoding="UTF-8"
keystoreType="PKCS12"
keystoreFile="${catalina.base}/conf/certname.pfx"
keystorePass="keypassword"/>
I'm fairly new to this, but have done a fair bit of reading to get it working previously in Tomcat7...so any help would be greatly appreciated.
Kind regards
Michael Salisbury
Senior Systems Architect | P 07 960 7011 | E michael@skypoint.co.nz<ma...@skypoint.co.nz> | W skypoint.co.nz
Waikato Innovation Park, Ruakura Rd, PO Box 9466, Hamilton 3240, NZ
[cid:image001.png@01CF0265.772EC520]
Please send any support enquiries to E support@skypoint.co.nz<ma...@skypoint.co.nz>
[MCSA_2013(rgb)_14802] [HP Accredited Technical Professional]
Re: SSL configuration using PFX as keystore
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 6/19/15 9:14 AM, André Warnier wrote:
> Daniel Mikusa wrote:
>> On Fri, Jun 19, 2015 at 12:42 AM, Michael Salisbury
>> <Mi...@skypoint.co.nz> wrote:
>>
>>> Hi there,
>>>
>>> I’m trying to get the above working using Tomcat 8.0,
>>> previously working with 7.0. This is part of a WebDAV
>>> connector in Confluence.
>>>
>>> It seems I can connect from anything other than a Windows Mini
>>> Redirector client (Windows 7 or 8.1, x86 or x64). Using a web
>>> browser or 3rd party client (CyberDuck for instance) connects
>>> OK.
>>>
>
> You should do a search in Google for "Windows and DAV". The various
> implementations over the years of DAV in MS Windows are a real
> horror story.
Since Windows Vista, we've had to resort to using various hacks, then
finally gave up and bought a 3rd-party WebDAV filesystem driver which
works beautifully (I'll give a shout-out to South River Technologies'
WebDrive product -- also does (S)FTP, S3, Google Drive, dropbox, etc.)
At some point, an unmodified version of Windows started refusing to
connect to a remote WebDAV share unless the type of authentication
being used was DIGEST -- no support for BASIC. The restriction was
supposed to have been dropped when using BASIC + HTTPS, but it still
doesn't seem to work.
My conclusion was finally that Microsoft felt no need to support the
WebDAV standard while simultaneously advertising such support, so I
went elsewhere for my WebDAV needs. (Plus, my Mac works flawlessly, as
do the various Linux implementations I've tried.)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJViBf7AAoJEBzwKT+lPKRYFbwQALoL9ASTz36WQfMHdqdwkm4R
ADqlSe8fvl276HjBaL0tmpfj++V/GwDqLM62deDOnSAoQZs+AUzTqUiFaueCuWA4
4eE1AGl4rzT9SRtkUxtoKLC+6Qjzx+TnrQertkdtiDVRgrflKVREX0JfV6YlaDkn
ra1JCEYL+nSkTLtuZwfsB/LcUN5qPR6shyw+01nsqoCFP4tL7Eda/O+VrLI5A1Zl
a7+BAiUbl0Y5GNoJAIzEhbX/C1a18AoVUbQzlQXxjcOwyylLS/KGo46HSr9P0Gii
sBzNE6ePg+UA8R6rTnQ5+fw+Y39FVKZtdzrnVLhwtABhwHG8xAd8FxTeR+ySva4v
Rfuh2Nh4Jj8fhncjD9GZWpwpMokYy3ka3qI7hILJDpshboH3pto1cVPZE6PWXDmN
2uSolRulhhtXvx24Jizv1QaMaaUmtjnqQrum70WIhO0mfM8i76wuTNu67yP+N9lv
NO0YtDPy1KmPuRd3hpXs6oCnMvFfztrCXy9Ll0XNjal6qXnO9avQwTUmLwDIqJaz
vRzniKZmw0USJU+tpCZ8PbpKMVq9fn2MFDKo4MTg0HPrq9T/VUz4D7jn2A52pq1T
VK70Vaa7Zn0OvcjWOnrt/bC77nInzyYAUlU0attnAFHL6RjEFpAr1k7qYvOes+bm
NW7jYQwhwtt02scp3Fok
=wSuW
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 22/06/2015 00:25, Michael Salisbury wrote:
>> Thanks, I've done much searching - hence why I'm finally posting here.
>>
>> Windows WebDAV is actually quite reasonable
>
> Many people would disagree with that statement. It hasn't been updated
> since the early days of Windows 7 but this site gives you an idea of
> just what a disaster the Windows WebDAV client has been:
> http://greenbytes.de/tech/webdav/webdav-redirector-list.html
>
> It is possible that things have improved in the last few years but the
> fact that Tomcat's WebDAV implementation works with a bunch of standards
> compliant clients and only fails with the Windows client suggests that
> the Windows client still has some issues.
>
>> - a lot of what one reads on the internet is because people don't know how to configure it. It won't pass basic authentication across a connection by default, you have to turn it on and there are two different settings for allowing it over SSL only or a non-encrypted connection.
>>
>> 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.
>>
A good example of the idiosyncracies of the Windows webDAV client : re-enter the same URL,
but specifiy the ":port" after the server name (even if it is 80).
On some Windows configurations, when not specifying the port, it tries to map this to a
"Windows share URL", à la "\\servername\sharename", leading to the error above.
My earlier comments were meant in a practical sense. We provide document-management
applications, where one of the ways in which a user can file a document into the system is
via DAV drag-and-drop directories.
We have spent a lot of time trying to debug these issues, to finally come to the
conclusion that the only way to insure consistent behaviour among customers who may have
different versions of Windows and different software installed on their PCs (sometimes on
a PC-by-PC base), was to recommend that they use one of these external WebDav clients.
Your situation may be different, and you might be able to enforce some specific Windows
version, and/or some specific Registry settings. We could not do that, hence our solution.
I was just trying to potentially save you a lot of hassle and loss of time.
I don't know if in your case it is practical and/or business-effective to use an
additional webDav client, but if it is possible, that would still be my recommendation.
Since we do that, we have 0 problems in that area. Before we did that, we had several
related support calls per week. Your call.
>> 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.
>
Not to make this a rant or a flame, but the same issues as described on the greenbytes
page mentioned above, also happen with other server-side DAV implementations, such as
Apache httpd. So it is not really a Tomcat-only issue.
> 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Michael,
On 6/22/15 6:39 PM, Michael Salisbury wrote:
> 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.
Well... what is "the client"?
Can you try using another client, just to see if the problem seems to
be more on the server-side configuration or with the client?
I think you can get a time-limited version of WebDrive for instance.
Use that on a Windows VM that you can roll-back and re-try indefinitely.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJViXg6AAoJEBzwKT+lPKRYKsQQAMDrrbDTERoz8+E0quagzTj+
bE6FqKUJ405D9F+l046rd451poCbgMKcU14dXvtWI5CEfGQixk6psMAVeVeXbYWx
rTU+TC5vZ6BJg3aC/VzaTN1SQi2ClO4dXs98O9sGXiEKsA1u/NAfAYEr/F8iMzah
ez2c5YdzyhVVjBPXxS7IiFCvp05c4czTC1zbgbhuj27z1hWjq29R4xQ3XNwaxqvp
DrKdbUj9qmjVBG3DXK/RcmF1jTMSjrXCZrb/HSO/M2VRyDWFMvCnGhBQ1lUXdQl6
0murUgGjLFKG5t4DhYWFl+JjD2YG++NEZRtJVlr23i6h4d22UppLDESSpXmhtTE5
6EkJ9H9RS8bADRG0XO6Orbsp9cBXf1tRpLxBDVs+Ud2SLgCEvI3ipPDkEqv21Ar2
CJ7HR6mjhYcj0astbh8PWjXSLsXAbPLvnKBRc8FjfnGhFVmoQauyPe7QlCWpUnML
FgSC0TD77XeQ1mkYDM+Cl5TEPgjjrfHeQAza6jgfMWJbTgmbGx/Hy9JmiyLt6O8s
4+myFTO92WjwkbVQ5PJ3s5O3LhdAtdcyckUpPyIr9aTWwe3JPqSwkBISfh90yp5L
dkKr2xAmoXzwsMXgnCHnw29JODH3BgiIqUBgP3ZtVq5ZPrmnBEXPdXixKboJZstX
TET4moL6g9Wv2bpXY6nn
=oMwD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL configuration using PFX as keystore
Posted by Michael Salisbury <Mi...@skypoint.co.nz>.
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 michael@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 support@skypoint.co.nz
-----Original Message-----
From: André Warnier [mailto:aw@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 7/22/15 1:18 PM, Mark Thomas wrote:
> On 08/07/2015 16:22, André Warnier wrote:
>
> <snip />
>
>> With respect, you both don't get it. MS support is deliberately
>> pitiful, to emphasize the fact that MS software is by definition
>> bug-free and does not really need support.
>
> I've had several extremely frustrating telephone calls this
> afternoon where various levels of Microsoft staff repeating their
> position that the WebDAV client is "working as designed" and that
> prompting for authentication is a perfectly reasonable response
> when trying to connect to a server that does not require
> authentication but does have a cert issued by a CA the client
> doesn't trust.
Yep: "working as designed" means "we designed it to work with our own
products under the conditions we ave specified, and nuts to you if you
want something different." Otherwise known as the "standards be
damned" design principle. I don't know why anyone is surprised, here.
> So far the minor security vulnerability (details to follow once
> Microsoft provide their final response in writing) is "working as
> designed" as well. Hmm. "Microsoft Windows - insecure by design".
> There is a nice strap line. I wonder if their marketing folks would
> like to use it. I'd be happy to offer them a royalty free license.
>
> I've asked MS to provide the justification for this position in
> writing - mainly because I intend writing up a blog post to make
> clear to those who haven't already figured it out that the
> Microsoft WebDAV client is, despite the improvements in recent
> Windows versions, still buggy and - more importantly - Microsoft
> are point blank refusing to fix obvious bugs and (minor) security
> vulnerabilities.
>
> I recall that someone on this list said that they had switched to a
> 3rd party WebDAV client and hadn't looked back since. Could that
> person remind me what that client was. I'd be happy to give it a
> plug in the blog post.
South River Technologies' WebDrive. It's a remote filesystem driver
that creates a drive letter which maps to some remote share and
supports (proper) WebDAV(S) including proper file-locking (as well as
local caching of files with lots of configuration options),
(S)FTP/FTP(S), Amazon S3, Google Drive, DropBox, SharePoint, and
something called "OneDrive", which I've never heard of.
I've never used WebDrive for anything other than WebDAV; I'm not sure
how great it is for those other protocols, but I suspect it will
perform well. Their tech support folks were even kind enough to walk
one of my users through the installation and configuration of the
software when she called to ask how to download the installer.
http://www.southrivertech.com/products/webdrive/
(Note: I have no financial interest in SRT. I'm just a happy user of
their product.)
> I'll also be updating the Tomcat docs to make it clear that the
> Microsoft WebDAV client is unsupported and I'll be removing the
> WebDAV fix valve from Tomcat 9 onwards since it fixes bugs in old,
> unsupported MS WebDAV clients and there is no way to fix issues
> like the current one on the server side. I'll be asking httpd to
> add a similar note regarding the supportability of the MS WebDAV
> client.
+1
I just sent an email to the folks running http://webdav.org/ about
Tomcat itself as well as WebDrive.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVr+PrAAoJEBzwKT+lPKRYkwUP/RRE/FZ6WYLlsox2TJ5BHKrP
Ns/Ke7SiQ7cDfY7Da7lUjRxOYjlVI6LeLDMENsDSkPGWRU76lUDqVFiLGc3VqHpL
KQJlERQ7Qu8Byc8UIz3r6gnnZtNpZTmEk4mHhLr8f9LZ9+MABakgmT3nHWt9utdK
X9lyBz3FY9y8stnwhDyXau5tUBUhiM4bA0gy38cqynSQEl2UL92NTAz/cwj13NEZ
6lODrV1wR7bONi2FOeCwfEghq13RaGStdRPTtCI/C7UtG+1eCbicCv9Zjx/+0u13
yNJkUJAUNeSyE5ahFLbiz/WtUTUMulWTSU0uLXs3K0B2fpK3FQU26UYFZPVBMhG1
qNXOcHkdjzoYbfxSTwxsrnrk55daf7bdwjPJ5S/Ljz2nythXGzcZJpq9idNS+9VE
5hYsGd5kxyX1FPUn3/nBNcXBsaf2CgEMM1CEJgLIZqXFcRpV5QNZy0OafUUC1FZX
qSHJUJDhvYfuUZ6xK89yidSEiKmHgYPG7hNGgQWe4EbQ1SLLdYpQwRQODrJ3selp
Rvq2Qy7pZW1qP454gu1xHIuyGNgoCLzrY60knIr68OzQ96vSSGRC29hWPAEOpeh6
qbYG/s86jxq4FRPnxhSVvf8WJme7O4nmafn4c0D1WVGRH16V1bc4PWMTuwf8bV/j
2d85aDMdyUVpUiyMtrgA
=hV9K
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 08/07/2015 16:22, André Warnier wrote:
>
> <snip />
>
>> With respect, you both don't get it. MS support is deliberately
>> pitiful, to emphasize the fact that MS software is by definition
>> bug-free and does not really need support.
>
> I've had several extremely frustrating telephone calls this afternoon
> where various levels of Microsoft staff repeating their position that
> the WebDAV client is "working as designed" and that prompting for
> authentication is a perfectly reasonable response when trying to connect
> to a server that does not require authentication but does have a cert
> issued by a CA the client doesn't trust.
>
> So far the minor security vulnerability (details to follow once
> Microsoft provide their final response in writing) is "working as
> designed" as well. Hmm. "Microsoft Windows - insecure by design". There
> is a nice strap line. I wonder if their marketing folks would like to
> use it. I'd be happy to offer them a royalty free license.
>
> I've asked MS to provide the justification for this position in writing
> - mainly because I intend writing up a blog post to make clear to those
> who haven't already figured it out that the Microsoft WebDAV client is,
> despite the improvements in recent Windows versions, still buggy and -
> more importantly - Microsoft are point blank refusing to fix obvious
> bugs and (minor) security vulnerabilities.
>
> I recall that someone on this list said that they had switched to a 3rd
> party WebDAV client and hadn't looked back since. Could that person
> remind me what that client was. I'd be happy to give it a plug in the
> blog post.
If that person was me, I was mentioning WebDrive
(http://www.southrivertech.com/products/webdrive/)
>
> I'll also be updating the Tomcat docs to make it clear that the
> Microsoft WebDAV client is unsupported and I'll be removing the WebDAV
> fix valve from Tomcat 9 onwards since it fixes bugs in old, unsupported
> MS WebDAV clients and there is no way to fix issues like the current one
> on the server side. I'll be asking httpd to add a similar note regarding
> the supportability of the MS WebDAV client.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Posted by Mark Thomas <ma...@apache.org>.
On 08/07/2015 16:22, André Warnier wrote:
<snip />
> With respect, you both don't get it. MS support is deliberately
> pitiful, to emphasize the fact that MS software is by definition
> bug-free and does not really need support.
I've had several extremely frustrating telephone calls this afternoon
where various levels of Microsoft staff repeating their position that
the WebDAV client is "working as designed" and that prompting for
authentication is a perfectly reasonable response when trying to connect
to a server that does not require authentication but does have a cert
issued by a CA the client doesn't trust.
So far the minor security vulnerability (details to follow once
Microsoft provide their final response in writing) is "working as
designed" as well. Hmm. "Microsoft Windows - insecure by design". There
is a nice strap line. I wonder if their marketing folks would like to
use it. I'd be happy to offer them a royalty free license.
I've asked MS to provide the justification for this position in writing
- mainly because I intend writing up a blog post to make clear to those
who haven't already figured it out that the Microsoft WebDAV client is,
despite the improvements in recent Windows versions, still buggy and -
more importantly - Microsoft are point blank refusing to fix obvious
bugs and (minor) security vulnerabilities.
I recall that someone on this list said that they had switched to a 3rd
party WebDAV client and hadn't looked back since. Could that person
remind me what that client was. I'd be happy to give it a plug in the
blog post.
I'll also be updating the Tomcat docs to make it clear that the
Microsoft WebDAV client is unsupported and I'll be removing the WebDAV
fix valve from Tomcat 9 onwards since it fixes bugs in old, unsupported
MS WebDAV clients and there is no way to fix issues like the current one
on the server side. I'll be asking httpd to add a similar note regarding
the supportability of the MS WebDAV client.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 7/7/15 9:39 AM, Mark Thomas wrote:
>> On 30/06/2015 21:16, Mark Thomas wrote:
>>> This is probably off-topic now so marking as such.
>>>
>>> On 29/06/2015 14:29, André Warnier wrote:
>>>> Mark Thomas wrote:
>>>>> On 26/06/2015 19:37, Mark Thomas wrote:
>>>>>> On 22/06/2015 11:56, Mark Thomas wrote:
>>>>>>> On 22/06/2015 09:39, Mark Thomas wrote:
>>>>>> <snip/>
>>>>>>
>>>>>>> Prompting for authentication in response to an untrusted
>>>>>>> certificate is bizarre to say the least.
>> <snip/>
>>
>>> Progress, if you can call it that, has not been good. They have
>>> now asked for additional network traces since:
>>>
>>> <quote> ... to be able to understand what packets are sent by
>>> client and what response did Server generate for the specific
>>> packet, I would like to check a simultaneous trace on both
>>> communication endpoints </quote>
>>>
>>> I have just sent a very long, fairly stropy reply pointing out
>>> the complete pointlessness of this request - not least because
>>> the information they claim they don't have is right in front of
>>> them in the form of the sequence and acknowledgement numbers in
>>> the network trace.
>> This continues to drag on. The stropy e-mail got the issue
>> re-assigned to someone with marginally more clue. They put together
>> a test environment (with IIS instead of Tomcat) and then attempted
>> to demonstrate that the issue did not occur and hence it must be a
>> Tomcat problem.
>
> "Our non-standard client works perfectly well with our non-standard
> server. The fact that our non-standard client doesn't work with your
> standards-compliant server obviously points to your software as the
> problem."
>
> Nice tautology you got there. It would be a shame if something were to
> happen to it.
>
> *sigh*
>
> Well, if you're willing to continue to tilt at this particular
> windmill, it would be a great service to the world. I'm not hopeful,
> though, as WebDAV support in Microsoft Windows has degraded
> consistently over the past 10 years and never improved. I don't know
> why they even bother to /claim/ support for it anymore. Evidently,
> nobody in the Microsoft world gives a rats posterior about WebDAV...
> they all use SMB anyway.
>
>> However, once they had configured their environment to match my
>> original bug report (server using cert issued by CA client doesn't
>> trust, server configured not to require authentication) imagine my
>> lack of surprise when the problem was repeated with IIS. Needless
>> to say the other end of the conference call went very, very quiet
>> at that point.
>>
>> The issue has now been passed to yet another support employee (I
>> refuse to call these people engineers) who apparently wants to
>> discuss the issue further. What they can possibly need to discuss
>> at this point I have no idea but having told them (again) how to
>> contact me I am waiting to hear from them.
>>
>> I also discovered that - despite the conference call - the latest
>> support ticket update from Microsoft claimed the issue could not
>> be repeated with IIS.
>>
>> It appears that the issue has been passed to the IIS team which
>> makes no sense at all since all the evidence points to this being a
>> WebDAV client bug and I have been making that point since this
>> whole sorry episode started.
>
> The good news is that the IIS team is likely to refuse to accept
> responsibility for the bug (because, by definition, IIS contains zero
> bugs) and likely to pass the buck back to the WebDAV client team. If
> you catch them at just the right time, you may be able to show MS how
> to do their own jobs.
>
>> While I continue to appreciate the free MSDN license Microsoft
>> kindly provide to Apache committers, I must confess to being
>> completely unimpressed by Microsoft's support structures and count
>> myself fortunate that I don't have to run an IT infrastructure that
>> relies on them.
>
> +1
>
With respect, you both don't get it. MS support is deliberately pitiful, to emphasize the
fact that MS software is by definition bug-free and does not really need support.
And to really bring the point home, MS seems to have plans to not name the next version
"Windows" anymore, but invent some other name. Now /that/ should allow them to definitely
start with a clean slate in their support database.
There might be an idea for Tomcat there.. "Bulldog" ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 7/7/15 9:39 AM, Mark Thomas wrote:
> On 30/06/2015 21:16, Mark Thomas wrote:
>> This is probably off-topic now so marking as such.
>>
>> On 29/06/2015 14:29, André Warnier wrote:
>>> Mark Thomas wrote:
>>>> On 26/06/2015 19:37, Mark Thomas wrote:
>>>>> On 22/06/2015 11:56, Mark Thomas wrote:
>>>>>> On 22/06/2015 09:39, Mark Thomas wrote:
>>>>> <snip/>
>>>>>
>>>>>> Prompting for authentication in response to an untrusted
>>>>>> certificate is bizarre to say the least.
>
> <snip/>
>
>> Progress, if you can call it that, has not been good. They have
>> now asked for additional network traces since:
>>
>> <quote> ... to be able to understand what packets are sent by
>> client and what response did Server generate for the specific
>> packet, I would like to check a simultaneous trace on both
>> communication endpoints </quote>
>>
>> I have just sent a very long, fairly stropy reply pointing out
>> the complete pointlessness of this request - not least because
>> the information they claim they don't have is right in front of
>> them in the form of the sequence and acknowledgement numbers in
>> the network trace.
>
> This continues to drag on. The stropy e-mail got the issue
> re-assigned to someone with marginally more clue. They put together
> a test environment (with IIS instead of Tomcat) and then attempted
> to demonstrate that the issue did not occur and hence it must be a
> Tomcat problem.
"Our non-standard client works perfectly well with our non-standard
server. The fact that our non-standard client doesn't work with your
standards-compliant server obviously points to your software as the
problem."
Nice tautology you got there. It would be a shame if something were to
happen to it.
*sigh*
Well, if you're willing to continue to tilt at this particular
windmill, it would be a great service to the world. I'm not hopeful,
though, as WebDAV support in Microsoft Windows has degraded
consistently over the past 10 years and never improved. I don't know
why they even bother to /claim/ support for it anymore. Evidently,
nobody in the Microsoft world gives a rats posterior about WebDAV...
they all use SMB anyway.
> However, once they had configured their environment to match my
> original bug report (server using cert issued by CA client doesn't
> trust, server configured not to require authentication) imagine my
> lack of surprise when the problem was repeated with IIS. Needless
> to say the other end of the conference call went very, very quiet
> at that point.
>
> The issue has now been passed to yet another support employee (I
> refuse to call these people engineers) who apparently wants to
> discuss the issue further. What they can possibly need to discuss
> at this point I have no idea but having told them (again) how to
> contact me I am waiting to hear from them.
>
> I also discovered that - despite the conference call - the latest
> support ticket update from Microsoft claimed the issue could not
> be repeated with IIS.
>
> It appears that the issue has been passed to the IIS team which
> makes no sense at all since all the evidence points to this being a
> WebDAV client bug and I have been making that point since this
> whole sorry episode started.
The good news is that the IIS team is likely to refuse to accept
responsibility for the bug (because, by definition, IIS contains zero
bugs) and likely to pass the buck back to the WebDAV client team. If
you catch them at just the right time, you may be able to show MS how
to do their own jobs.
> While I continue to appreciate the free MSDN license Microsoft
> kindly provide to Apache committers, I must confess to being
> completely unimpressed by Microsoft's support structures and count
> myself fortunate that I don't have to run an IT infrastructure that
> relies on them.
+1
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVnSpYAAoJEBzwKT+lPKRYCDkP/2KJK6mjA0rCQ8m/cT+3iPTe
bDyXDNTs4g2aycCdKReW9MtcGwy0Qf2M5YEv6+f5EzKjDeMuR5KZU2kieqFf0nh2
DOft4iCLFdbynqyXHPq0fEpbg0dGJjAr9sB+ifA/0t+2v7iXB2bxvfu/2MZrhHYl
I9L2zGrrq3JcuXrEMINm5PZJDkHwHf1lWrXTk/P/2hCw7mHFVj9qraPE3bfQULVZ
XviuW4l7TfbIfqu5B8w42/VYayOC3l9rh4eW59Eea44bikj44c9q2OuB94JNXYy8
mvSS2oyOX0pe2JtjrAt0XFHL7fuz4C4bbZeEremdYrLclbVlC20PuKvxeuvuEfXn
jE71qIuP+4vPD5+VlUuyIkW04r73CqeaEYGQPatrBCA+J702B05IsND3JF7ZHrdq
/Ms7PugZurLJD99/UJMCvFCDnPiuL4jWMDo1NLDq5BOCXHtdN2KeDYG0zTJhh2Dk
nH1y/sdJ8B3Uaya8heK7b+oxR2LS77vfmTyYRD9KMIgFDeMay1hPOvy9nAot2PEw
CJkfd1YVVl+0Ym9mqKq4wybTguSXfA4DrC98H3BskuWhtB3Ev79bUCPsHxa8je1k
FcN3+KaslxAk3UcxvgsXTagRIGo3S7Wnk8X2LOqrAmB0m9A8kMZuT3lHiCyhyPxG
GhatQDMYanSiOd3NJNTc
=+Gqo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: SSL configuration using PFX as keystore
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2015 21:16, Mark Thomas wrote:
> This is probably off-topic now so marking as such.
>
> On 29/06/2015 14:29, André Warnier wrote:
>> Mark Thomas wrote:
>>> On 26/06/2015 19:37, Mark Thomas wrote:
>>>> On 22/06/2015 11:56, Mark Thomas wrote:
>>>>> On 22/06/2015 09:39, Mark Thomas wrote:
>>>> <snip/>
>>>>
>>>>> Prompting for authentication in response to an untrusted certificate is
>>>>> bizarre to say the least.
<snip/>
> Progress, if you can call it that, has not been good. They have now
> asked for additional network traces since:
>
> <quote>
> ... to be able to understand what packets are sent by client and what
> response did Server generate for the specific packet, I would like to
> check a simultaneous trace on both communication endpoints
> </quote>
>
> I have just sent a very long, fairly stropy reply pointing out the
> complete pointlessness of this request - not least because the
> information they claim they don't have is right in front of them in the
> form of the sequence and acknowledgement numbers in the network trace.
This continues to drag on. The stropy e-mail got the issue re-assigned
to someone with marginally more clue. They put together a test
environment (with IIS instead of Tomcat) and then attempted to
demonstrate that the issue did not occur and hence it must be a Tomcat
problem.
However, once they had configured their environment to match my original
bug report (server using cert issued by CA client doesn't trust, server
configured not to require authentication) imagine my lack of surprise
when the problem was repeated with IIS. Needless to say the other end of
the conference call went very, very quiet at that point.
The issue has now been passed to yet another support employee (I refuse
to call these people engineers) who apparently wants to discuss the
issue further. What they can possibly need to discuss at this point I
have no idea but having told them (again) how to contact me I am waiting
to hear from them.
I also discovered that - despite the conference call - the latest
support ticket update from Microsoft claimed the issue could not be
repeated with IIS.
It appears that the issue has been passed to the IIS team which makes no
sense at all since all the evidence points to this being a WebDAV client
bug and I have been making that point since this whole sorry episode
started.
While I continue to appreciate the free MSDN license Microsoft kindly
provide to Apache committers, I must confess to being completely
unimpressed by Microsoft's support structures and count myself fortunate
that I don't have to run an IT infrastructure that relies on them.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
[OT] Re: SSL configuration using PFX as keystore
Posted by Mark Thomas <ma...@apache.org>.
This is probably off-topic now so marking as such.
On 29/06/2015 14:29, André Warnier wrote:
> Mark Thomas wrote:
>> On 26/06/2015 19:37, Mark Thomas wrote:
>>> On 22/06/2015 11:56, Mark Thomas wrote:
>>>> On 22/06/2015 09:39, Mark Thomas wrote:
>>> <snip/>
>>>
>>>> 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).
>>> Support incident raised. I await the response with interest...
>>
>> Oh dear. Not a good first response from Microsoft.
>>
>> First they tried to say that the WebDAV server must be triggering the
>> prompt for credentials which would be difficult to say the least given
>> that the TLS connection is never established AND that the WebDAV
>> endpoint was configured for anonymous access.
>>
>> Then they tried to suggest that I contact Apache for support. Lets just
>> say that suggestion got shut down rather quickly.
>
> Like, "I /am/ Apache support" ? :-)
Pretty much. Once I'd stopped laughing.
>> Finally they went back to trying to suggest that the server was asking
>> for credentials. A rather circular discussion followed that demonstrated
>> that the support person had little to no understanding of the OSI
>> network model (they continued to try to claim that establishing a TCP
>> connection meant that the WebDAV server could have sent the request for
>> authentication credentials despite the fact that the TLS connection
>> failed).
>>
>> The only small ray of hope is that they asked for a network trace of the
>> connection process. That should enable someone more clueful at Microsoft
>> to confirm it is the client error handling at fault.
>>
>> I'll keep the list informed of progress.
Progress, if you can call it that, has not been good. They have now
asked for additional network traces since:
<quote>
... to be able to understand what packets are sent by client and what
response did Server generate for the specific packet, I would like to
check a simultaneous trace on both communication endpoints
</quote>
I have just sent a very long, fairly stropy reply pointing out the
complete pointlessness of this request - not least because the
information they claim they don't have is right in front of them in the
form of the sequence and acknowledgement numbers in the network trace.
I've also formally complained to the support engineer's manager and
requested - no, make that demanded - that the issue is passed to the
relevant product team.
I'd share the full e-mails but during my investigations I have stumbled
across a very, very minor security issue in the Microsoft WebDAV client.
It barely qualifies as a problem but it is only fair to give Microsoft a
chance to fix it before I go public with the details. I'll save the
e-mails and make then public once the security issue has gone away. It
might make an amusing lightning talk presentation at ApacheCon one year.
I will say that if you are using the WebDAV client then it is extremely
unlikely that you will be affected by the security issue. My view is
that the security issue is not sufficient reason on its own to look for
a different client.
That said, based on my experience of this WebDAV client in the past
(very buggy) and my current experience trying to get what should be a
simple bug fixed in the current client I would always recommend that you
use a 3rd party WebDAV client (and check out the quality of the support
provided before you make your final selection).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 26/06/2015 19:37, Mark Thomas wrote:
>> On 22/06/2015 11:56, Mark Thomas wrote:
>>> On 22/06/2015 09:39, Mark Thomas wrote:
>> <snip/>
>>
>>> 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).
>> Support incident raised. I await the response with interest...
>
> Oh dear. Not a good first response from Microsoft.
>
> First they tried to say that the WebDAV server must be triggering the
> prompt for credentials which would be difficult to say the least given
> that the TLS connection is never established AND that the WebDAV
> endpoint was configured for anonymous access.
>
> Then they tried to suggest that I contact Apache for support. Lets just
> say that suggestion got shut down rather quickly.
Like, "I /am/ Apache support" ? :-)
>
> Finally they went back to trying to suggest that the server was asking
> for credentials. A rather circular discussion followed that demonstrated
> that the support person had little to no understanding of the OSI
> network model (they continued to try to claim that establishing a TCP
> connection meant that the WebDAV server could have sent the request for
> authentication credentials despite the fact that the TLS connection failed).
>
> The only small ray of hope is that they asked for a network trace of the
> connection process. That should enable someone more clueful at Microsoft
> to confirm it is the client error handling at fault.
>
> I'll keep the list informed of progress.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by Mark Thomas <ma...@apache.org>.
On 26/06/2015 19:37, Mark Thomas wrote:
> On 22/06/2015 11:56, Mark Thomas wrote:
>> On 22/06/2015 09:39, Mark Thomas wrote:
>
> <snip/>
>
>> 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).
>
> Support incident raised. I await the response with interest...
Oh dear. Not a good first response from Microsoft.
First they tried to say that the WebDAV server must be triggering the
prompt for credentials which would be difficult to say the least given
that the TLS connection is never established AND that the WebDAV
endpoint was configured for anonymous access.
Then they tried to suggest that I contact Apache for support. Lets just
say that suggestion got shut down rather quickly.
Finally they went back to trying to suggest that the server was asking
for credentials. A rather circular discussion followed that demonstrated
that the support person had little to no understanding of the OSI
network model (they continued to try to claim that establishing a TCP
connection meant that the WebDAV server could have sent the request for
authentication credentials despite the fact that the TLS connection failed).
The only small ray of hope is that they asked for a network trace of the
connection process. That should enable someone more clueful at Microsoft
to confirm it is the client error handling at fault.
I'll keep the list informed of progress.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by Mark Thomas <ma...@apache.org>.
On 22/06/2015 11:56, Mark Thomas wrote:
> On 22/06/2015 09:39, Mark Thomas wrote:
<snip/>
> 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).
Support incident raised. I await the response with interest...
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by Mark Thomas <ma...@apache.org>.
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 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by Mark Thomas <ma...@apache.org>.
On 22/06/2015 00:25, Michael Salisbury wrote:
> Thanks, I've done much searching - hence why I'm finally posting here.
>
> Windows WebDAV is actually quite reasonable
Many people would disagree with that statement. It hasn't been updated
since the early days of Windows 7 but this site gives you an idea of
just what a disaster the Windows WebDAV client has been:
http://greenbytes.de/tech/webdav/webdav-redirector-list.html
It is possible that things have improved in the last few years but the
fact that Tomcat's WebDAV implementation works with a bunch of standards
compliant clients and only fails with the Windows client suggests that
the Windows client still has some issues.
> - a lot of what one reads on the internet is because people don't know how to configure it. It won't pass basic authentication across a connection by default, you have to turn it on and there are two different settings for allowing it over SSL only or a non-encrypted connection.
>
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL configuration using PFX as keystore
Posted by Michael Salisbury <Mi...@skypoint.co.nz>.
Thanks, I've done much searching - hence why I'm finally posting here.
Windows WebDAV is actually quite reasonable - a lot of what one reads on the internet is because people don't know how to configure it. It won't pass basic authentication across a connection by default, you have to turn it on and there are two different settings for allowing it over SSL only or a non-encrypted connection.
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.
I'll run a Wireshark trace and see what comes up, nothing in the Tomcat logs that I can see...
Thanks
Michael Salisbury
Senior Systems Architect | P 07 960 7011 | E michael@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 support@skypoint.co.nz
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: Saturday, 20 June 2015 1:15 a.m.
To: Tomcat Users List
Subject: Re: SSL configuration using PFX as keystore
Daniel Mikusa wrote:
> On Fri, Jun 19, 2015 at 12:42 AM, Michael Salisbury
> <Mi...@skypoint.co.nz>
> wrote:
>
>> Hi there,
>>
>> I’m trying to get the above working using Tomcat 8.0, previously
>> working with 7.0. This is part of a WebDAV connector in Confluence.
>>
>> It seems I can connect from anything other than a Windows Mini
>> Redirector client (Windows 7 or 8.1, x86 or x64). Using a web
>> browser or 3rd party client (CyberDuck for instance) connects OK.
>>
You should do a search in Google for "Windows and DAV".
The various implementations over the years of DAV in MS Windows are a real horror story.
As far as I know (but it varies according to Windows versions and patches, and even according to whatever other software is installed on the workstation) :
- recent version of Windows will only accept to connect to DAV folders via HTTPS
- recent and less recent versions of Windows will only accept to connect to a DAV folder, if that DAV folder is at the "document root" of the webserver
In other words, for all practical purposes, you /have to/ use a third-party client.
(WebDrive is another one which I know works)
And if you don't, be prepared for a lot of support calls..
>
> What happens when you try to connect with the Windows Mini Redirector?
> Do you get a client error? If so, what? Do you get any errors or
> messages in the Tomcat logs? If not, you might try running wireshark
> to investigate further. Capture packets from a working client and
> packets from the MS client then look to see what's different.
>
> That said, the fact that it's working for a large selection of clients
> except one, seems to point to a problem with the client and not your
> Tomcat setup. What makes you think this is a Tomcat issue? Was there
> something specific you had to do in Tomcat 7 to make the MS client work?
>
> Dan
>
>
>> There are some registry keys in Windows one needs to enable to get
>> this working first:
>>
>>
>>
>> [HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Internet]
>>
>> "BasicAuthLevel"=dword:00000001
>>
>>
>>
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Param
>> eters]
>>
>> "BasicAuthLevel"=dword:00000001
>>
>> "UseBasicAuth"=dword:00000001
>>
>>
>>
>> Server.xml
>>
>> <Connector port="9443" maxHttpHeaderSize="8192"
>>
>> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
>>
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>
>> enableLookups="false" disableUploadTimeout="true"
>>
>> acceptCount="100" scheme="https" secure="true"
>>
>> clientAuth="false" sslProtocols="TLS" SSLEnabled="true"
>>
>> URIEncoding="UTF-8"
>>
>> keystoreType="PKCS12"
>>
>> keystoreFile="${catalina.base}/conf/certname.pfx"
>>
>> keystorePass="keypassword"/>
>>
>>
>>
>> I’m fairly new to this, but have done a fair bit of reading to get it
>> working previously in Tomcat7…so any help would be greatly appreciated.
>>
>>
>>
>> Kind regards
>>
>>
>>
>> *Michael Salisbury*
>>
>>
>>
>> *Senior Systems Architect* | *P* 07 960 7011 | *E*
>> michael@skypoint.co.nz | *W* skypoint.co.nz
>>
>>
>>
>> Waikato Innovation Park, Ruakura Rd, PO Box 9466, Hamilton 3240, NZ
>>
>>
>>
>>
>>
>> [image: cid:image001.png@01CF0265.772EC520]
>>
>>
>>
>> Please send any support enquiries to *E* support@skypoint.co.nz
>>
>>
>>
>> [image: MCSA_2013(rgb)_14802] [image: HP Accredited Technical
>> Professional]
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by André Warnier <aw...@ice-sa.com>.
Daniel Mikusa wrote:
> On Fri, Jun 19, 2015 at 12:42 AM, Michael Salisbury <Mi...@skypoint.co.nz>
> wrote:
>
>> Hi there,
>>
>> I’m trying to get the above working using Tomcat 8.0, previously working
>> with 7.0. This is part of a WebDAV connector in Confluence.
>>
>> It seems I can connect from anything other than a Windows Mini Redirector
>> client (Windows 7 or 8.1, x86 or x64). Using a web browser or 3rd party
>> client (CyberDuck for instance) connects OK.
>>
You should do a search in Google for "Windows and DAV".
The various implementations over the years of DAV in MS Windows are a real horror story.
As far as I know (but it varies according to Windows versions and patches, and even
according to whatever other software is installed on the workstation) :
- recent version of Windows will only accept to connect to DAV folders via HTTPS
- recent and less recent versions of Windows will only accept to connect to a DAV folder,
if that DAV folder is at the "document root" of the webserver
In other words, for all practical purposes, you /have to/ use a third-party client.
(WebDrive is another one which I know works)
And if you don't, be prepared for a lot of support calls..
>
> What happens when you try to connect with the Windows Mini Redirector? Do
> you get a client error? If so, what? Do you get any errors or messages in
> the Tomcat logs? If not, you might try running wireshark to investigate
> further. Capture packets from a working client and packets from the MS
> client then look to see what's different.
>
> That said, the fact that it's working for a large selection of clients
> except one, seems to point to a problem with the client and not your Tomcat
> setup. What makes you think this is a Tomcat issue? Was there something
> specific you had to do in Tomcat 7 to make the MS client work?
>
> Dan
>
>
>> There are some registry keys in Windows one needs to enable to get this
>> working first:
>>
>>
>>
>> [HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Internet]
>>
>> "BasicAuthLevel"=dword:00000001
>>
>>
>>
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters]
>>
>> "BasicAuthLevel"=dword:00000001
>>
>> "UseBasicAuth"=dword:00000001
>>
>>
>>
>> Server.xml
>>
>> <Connector port="9443" maxHttpHeaderSize="8192"
>>
>> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
>>
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>
>> enableLookups="false" disableUploadTimeout="true"
>>
>> acceptCount="100" scheme="https" secure="true"
>>
>> clientAuth="false" sslProtocols="TLS" SSLEnabled="true"
>>
>> URIEncoding="UTF-8"
>>
>> keystoreType="PKCS12"
>>
>> keystoreFile="${catalina.base}/conf/certname.pfx"
>>
>> keystorePass="keypassword"/>
>>
>>
>>
>> I’m fairly new to this, but have done a fair bit of reading to get it
>> working previously in Tomcat7…so any help would be greatly appreciated.
>>
>>
>>
>> Kind regards
>>
>>
>>
>> *Michael Salisbury*
>>
>>
>>
>> *Senior Systems Architect* | *P* 07 960 7011 | *E*
>> michael@skypoint.co.nz | *W* skypoint.co.nz
>>
>>
>>
>> Waikato Innovation Park, Ruakura Rd, PO Box 9466, Hamilton 3240, NZ
>>
>>
>>
>>
>>
>> [image: cid:image001.png@01CF0265.772EC520]
>>
>>
>>
>> Please send any support enquiries to *E* support@skypoint.co.nz
>>
>>
>>
>> [image: MCSA_2013(rgb)_14802] [image: HP Accredited Technical
>> Professional]
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL configuration using PFX as keystore
Posted by Daniel Mikusa <dm...@pivotal.io>.
On Fri, Jun 19, 2015 at 12:42 AM, Michael Salisbury <Mi...@skypoint.co.nz>
wrote:
> Hi there,
>
> I’m trying to get the above working using Tomcat 8.0, previously working
> with 7.0. This is part of a WebDAV connector in Confluence.
>
> It seems I can connect from anything other than a Windows Mini Redirector
> client (Windows 7 or 8.1, x86 or x64). Using a web browser or 3rd party
> client (CyberDuck for instance) connects OK.
>
What happens when you try to connect with the Windows Mini Redirector? Do
you get a client error? If so, what? Do you get any errors or messages in
the Tomcat logs? If not, you might try running wireshark to investigate
further. Capture packets from a working client and packets from the MS
client then look to see what's different.
That said, the fact that it's working for a large selection of clients
except one, seems to point to a problem with the client and not your Tomcat
setup. What makes you think this is a Tomcat issue? Was there something
specific you had to do in Tomcat 7 to make the MS client work?
Dan
>
> There are some registry keys in Windows one needs to enable to get this
> working first:
>
>
>
> [HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Internet]
>
> "BasicAuthLevel"=dword:00000001
>
>
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters]
>
> "BasicAuthLevel"=dword:00000001
>
> "UseBasicAuth"=dword:00000001
>
>
>
> Server.xml
>
> <Connector port="9443" maxHttpHeaderSize="8192"
>
> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> enableLookups="false" disableUploadTimeout="true"
>
> acceptCount="100" scheme="https" secure="true"
>
> clientAuth="false" sslProtocols="TLS" SSLEnabled="true"
>
> URIEncoding="UTF-8"
>
> keystoreType="PKCS12"
>
> keystoreFile="${catalina.base}/conf/certname.pfx"
>
> keystorePass="keypassword"/>
>
>
>
> I’m fairly new to this, but have done a fair bit of reading to get it
> working previously in Tomcat7…so any help would be greatly appreciated.
>
>
>
> Kind regards
>
>
>
> *Michael Salisbury*
>
>
>
> *Senior Systems Architect* | *P* 07 960 7011 | *E*
> michael@skypoint.co.nz | *W* skypoint.co.nz
>
>
>
> Waikato Innovation Park, Ruakura Rd, PO Box 9466, Hamilton 3240, NZ
>
>
>
>
>
> [image: cid:image001.png@01CF0265.772EC520]
>
>
>
> Please send any support enquiries to *E* support@skypoint.co.nz
>
>
>
> [image: MCSA_2013(rgb)_14802] [image: HP Accredited Technical
> Professional]
>
>
>