Why does the Rfc6265CookieProcessor handle the version 1 cookie?

[Kyohei Nakamura]

Hi all,

The documentation of the Cookie Processor says that the
Rfc6265CookieProcessor is based on the RFC6265.
The RFC6265 specification does not allow the Version attribute in the
Cookie header.
However the Rfc6265CookieProcessor handles the version 1 cookie ($Version=1).
I think the Rfc6265CookieProcessor should complies with the RFC6265
specification that does not allow the Version attribute.

Why does the Rfc6265CookieProcessor handle the version 1 cookie?


Best regards,
Kyohei Nakamura

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Facing issue while configuring SSL

[Devendra Sengar]

File is there and permission is also fine and having proper openssl.cnf.

Any other view?

Thanks,
Devendra

On Tue, Jul 12, 2016 at 9:10 PM, André Warnier (tomcat) 
wrote:

> On 12.07.2016 16:33, Harrie Robins wrote:
>
>> java.lang.Exception: Unable to load certificate key
>> conf/localhost-key.pem (error:02001003:system library:fopen:No such process
>>
>> If I'm correct you are either missing correct rights to this file or it
>> is not in the given location.
>> A second possibility is missing password for key file.
>>
>
> Alternatively, searching Google for error:02001003, there are a number of
> hits there which point to the same kind of message, most of which seem to
> be for Windows and OpenSSL, and most of which mention the need for a proper
> "openssl.cnf" in the proper location.
> This may or may not be relevant to your problem.
>
>
>
>> SSLPassword="pass"
>>
>> Regards,
>>
>> Harrie
>>
>> -Original Message-
>> From: Devendra Sengar [mailto:dssen...@gmail.com]
>> Sent: dinsdag 12 juli 2016 10:50
>> To: users@tomcat.apache.org
>> Subject: Facing issue while configuring SSL
>>
>> Hi,
>>
>> This is regarding the configuration of Tomcat SSL using the APR library
>> on Java 6.
>>
>> While starting the server I am getting the below error:
>>
>> SEVERE: Failed to initialize end point associated with ProtocolHandler
>> ["http-apr-443"]
>> java.lang.Exception: Unable to load certificate key
>> conf/localhost-key.pem (error:02001003:system library:fopen:No such process)
>>
>> I am trying to implement SSL using independent libraries for OpenSSL,
>> Tomcat Native and Apache Portable Runtime.
>>
>> I have downloaded precompiled versions of OpenSSL and Tomcat Native (see
>> them attached). I have tried compiling the Apache Portable Runtime using
>> Visual Studio (find it also attached).
>>
>> I am running those libraries on either Tomcat 7.0.6 or 7.0.70 64-bit for
>> Windows (using the 64-bit distro, not the installer one).
>>
>> We are restricted by our applicatioin to use Oracle Java 6 Updated 115
>> 64-bit.
>>
>> The versions of the libraries I am using are the latest available online,
>> again see the binaries attached.
>>
>> The parameters used in the server.xml file are:
>>
>> For Tomcat 7.0.6:
>> >protocol="org.apache.coyote.http11.Http11AprProtocol"
>>port="443" maxThreads="200"
>>scheme="https" secure="true" SSLEnabled="true"
>>SSLCertificateFile="conf/localhost-cert.pem"
>>SSLCertificateKeyFile="conf/localhost-key.pem"
>>SSLCertificateChainFile="conf/ca.crt"
>>SSLVerifyClient="optional" SSLProtocol="TLSv1"
>>SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>
>>
>> For Tomcat 7.0.70
>>
>> >protocol="org.apache.coyote.http11.Http11AprProtocol"
>>port="443" maxThreads="200"
>>scheme="https" secure="true" SSLEnabled="true"
>>SSLCertificateFile="conf/localhost-cert.pem"
>>SSLCertificateKeyFile="conf/localhost-key.pem"
>>SSLCertificateChainFile="conf/ca.crt"
>>SSLVerifyClient="optional" SSLProtocol="TLSv1_2"
>>SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>
>>
>> The library files are in the tomcat bin folder as openssl.exe,
>> tcnative-1.dll and libapr-1.dll.
>>
>> tcnative-1.dll:
>>
>> https://drive.google.com/file/d/0ByilOlQCXOkWQ1ZCckhodHBvQk0/view?usp=sharing
>> openssl.exe:
>>
>> https://drive.google.com/file/d/0ByilOlQCXOkWQk9KUUJSb3ZqeW8/view?usp=sharing
>> libapr-1.dll:
>>
>> https://drive.google.com/file/d/0ByilOlQCXOkWV09NTi0tNWxhZnM/view?usp=sharing
>>
>>
>> The same certificates files mentioned in the server.xml file were used
>> and work in a brand new Apache web server.
>>
>> Please let us know your opinion of what can cause those errors?
>>
>> Can it be because of a APR dll not compiled properly?
>>
>> Any other idea?
>>
>> Thanks,
>> Devendra
>>
>>
>> -
>> 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
>
>

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-07-12 14:34 GMT-04:00 Sean Son :

> Are there any logs on the tomcat server that I should check in order to fix
> this SSL issue? or is this strictly a certificate related issue?
>

At my opinion, it is a DNS issue. Your certificate specify the
SubjectAlternativeName field with two DNS entries. If none of these can be
resolved for your server, the certificate is considered invalid.

-
Daniel Savard

Re: Encoding issues with Tomcat 7.0.69+ and 8.0.33+

[Mark Thomas]

On 12/07/2016 11:11, Vincent Massol wrote:
> Hi Mark,
> 
> I’ve seen your mail on the devs list. IMO you have only 2 choices:

You are welcome to comment on the dev list thread.

> * Option 1: decode the path passed to RD
> * Option 2: revert the changes brought by 
> http://svn.apache.org/viewvc?view=revision=1741019 and 
> http://svn.apache.org/viewvc?view=revision=1741024 (or at least part 
> of it) so that the path passed to RD is not encoded (i.e. same as before).
> 
> Any other choice will result in Tomcat having an important regression 
> compared to before and XWiki won’t be able to use those new Tomcat versions 
> (and I suspect a lot of others webapps will be in the same situations).
> 
> Now I understand the problem with option 1. Users who were passing undecoded 
> paths to RD will get broken too. However if they were doing since Tomcat was 
> not encoding the path, I believe that they would have resulted in invalid 
> URLs generated by the forward(), no? So maybe it’s not an issue after all.

Option 2 isn't going to happen. That would be a clear breach of the
Servlet spec.

My guess is that we'll implement option 1 but make the behaviour
configurable. Defaults TBD, possibly varying by version.

It is worth keeping in mind that decoding the path is not the same as
requiring it to be encoded. If you decode "/foo bar" and "/foo%20bar"
you end up with the same result. This should reduce the risk of
application breakage if the default becomes to decode the path.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: mod-jk + ssl: requests are not forward to tomcat correctly

[Mark Eggers]

Late to the party as always:

See reply inline.

On 7/11/2016 10:38 AM, Wayne Li wrote:
> Thank you for quick reply.
> Thank you for suggest LiveHTTPHeaders for firefox. I just tried. Good. It
> says that the file was loaded. So I think the problems are in the lines of:
> 
>   http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.css"/>
>   http://code.jquery.com/jquery-1.11.3.min.js";>
>   http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.js";>
> 
> These lines could not be forwarded under ssl? What should I do?
> Thanks.

I don't know if code.jquery.com supports both HTTP and HTTPS. You could
use a different CDN for the jQuery code if you want.

Something like the following will support both if code.jquery.com does:

>> my application.
>>>
>>> Then, I also trying to use ssl and generated self-signed certificate. It
>>> works, because
>>> the browser warns me about unknown certificate. If I type "
>>> https://www.mytest.com/index.jsp";
>>> on the browser's bar, it shows the page. But not correctly: the page
>>> contains:
>>>  
>>>