Re: TC 9.0.21: ContextListener + Servlet app
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 6/16/19 14:58, André Warnier (tomcat) wrote: > On 16.06.2019 07:39, Christopher Schultz wrote: [...] >> >> Surprisingly, > > -1 Meh. >> browsers do not use the value for "id" as the "name" when a name >> is not specified for an tag. Without a "name" attribute, >> the form element is not sent to the server. :( >> > > Not really surprising, see : 1) > https://www.w3schools.com/html/html_id.asp "The id value can be > used by CSS and JavaScript.." 2) > https://www.w3.org/TR/html52/sec-forms.html#constructing-the-form-data - -set > > Only the "name" attribute is used to construct the data set that is > posted to the server. Sure, it's documented. That doesn't mean that everybody knows it. It's *documented* that HTTP's default character encoding is ISO-8859-1 when there is no Content-Type header, but apparently that's completely surprising to anyone responsible for writing a web browser. I could have sworn that "name" had been deprecated, but when I went back to look, it was "name" specifically on the element and not just in general. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0IA+0ACgkQHPApP6U8 pFjVAhAApIR7cvsGzJZ/gY+W6No567Oim1phSDXxo6YckTtSQS6lH3sC/BYsSea8 FQqD3QEfTu8xuS8eV18NctKjtMF7Sy/Birrq1eNRHYtK8agbpw8Q0O/9pFYqoW71 aOkSF0kp0C7u3L49T1ur51MkrSEVg2RWNnUtExqM9eNjqqNvjMbgHZyIQSCoKSOI iXWyJa1WuWVIRK3/fqud20LrFjjOybV6fBVFlXO1ZqaOefxZWX4V83KwxNmVxBtZ 0HPHfdKT6lIu3M0CrjhwTVIRXCk+z1bZw0+ODsEiWOBujG/QmufizuM8pTeQZhfN 7oI24aGX3X5iIim7GzmzNzoCm/YLyE5v53yxBgKU+qo8NHb6dYg5YZtcfyLdEuXs Ll0jSldLYYTUy+BuKO8slCha4QbrXOxeQpGB1d8MzmPnjXRPEByVV2cHckGv9D+o Ed6Vf41u0ACNWHAY2spuxDds0WlPU7PGvx+e2cu6/59gzjau9pm3RiofVwGe4j8F BBc0SfTuBnyX17Aft1eIcK0CEixSpwMG0oxIj6ZBndAyF5x0in7a7yI8wfHStTsE 68vX24DlYGmJN/PbhK2+QE3D/+Dh7cQz/6xOUvfsNHkvu52psIzlk4tOBnZaNQ+j qBp60dbI9LpjUyW2BArzFUHo/O+mn8UkK2+A7ehZsUI7TI3gvLk= =DfIN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 9.0.21: ContextListener + Servlet app
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tommy, > Tommy, > > On 6/15/19 21:51, Tommy Pham wrote: Hi Mark, After some research and thought about internal application flow, I think the 'cleanest' is have TC's default servlet handle the *.html requests and use the assigned filter to restrict the access as desired. Is there a better approach? On that plan, I have this mapping for TC's default servlet and init: Filter AppFilterAccessLog's servlet mapping: Servlet name: default , registered class: org.apache.catalina.servlets.DefaultServlet. Servlet default's mapping: /img/* /css/* /WEB-INF/* > > Uh... you sure you want that? What is stopping a client from > requesting /WEB-INF/web.xml? > /js/* Servlet default's init parameters: listings: false debug: 0 If I use *.html instead of /WEB-INF/*, it goes into infinite loop redirecting / forwarding until exception is thrown (I think that root cause is servlets' startup ordering). Below are what my access log filter see for HttpServletRequest: Attributes: javax.servlet.forward.request_uri=/erm-0.0.1-SNAPSHOT/ javax.servlet.forward.context_path=/erm-0.0.1-SNAPSHOT javax.servlet.forward.servlet_path= javax.servlet.forward.path_info=/ javax.servlet.forward.mapping=org.apache.catalina.core.ApplicationM app > ing$MappingImpl@7fc1f887 > org.apache.logging.log4j.web.Log4jServletFilter.FILTERED=true Class: org.apache.catalina.core.ApplicationHttpRequest DispatcherType: FORWARD [javax.servlet.DispatcherType] HttpServletMapping: Class: org.apache.catalina.core.ApplicationMapping$MappingImpl MappingMatch: PATH MatchValue: setup/step_0.html Pattern: /WEB-INF/* ServletName: default Below is from the actual filter assigned to TC's default servlet intended to restrict access: ContextPath: /erm-0.0.1-SNAPSHOT DispatcherType: FORWARD PathInfo: /setup/step_0.html PathTranslated: D:\apache-tomcat-9.0.21\webapps\erm-0.0.1-SNAPSHOT\setup\step_0.htm l > Method: GET RequestURI: /erm-0.0.1-SNAPSHOT/WEB-INF/setup/step_0.html RequestURL: http://localhost:8080/erm-0.0.1-SNAPSHOT/WEB-INF/setup/step_0.html ServletPath: /WEB-INF ServletContext.ServletContextName: erm response: org.apache.catalina.connector.ResponseFacade I think everything seems correct except the PathTranslated. It should be: D:\apache-tomcat-9.0.21\webapps\erm-0.0.1-SNAPSHOT\WEB-INF\setup\st ep_ > 0.html where the file is. I'm unable to find out why it's wrong after a couple hours of searching since the the browser shows an empty page... The string "/WEB-INF/setup/step_0.html" was passed to request.getRequestDispatcher(). According to the doc [1], " If the path begins with a "/" it is interpreted as relative to the current context root." everything is as it should be right, other than PathTranslated? Or did I misunderstood the usage of getRequestDispatcher().forward()? Currently, I have 4 filters in place and all are in passive monitoring mode. None of them have the code logic to perform their intended functions. 3 filters mapped to URL /* and one assigned to TC's default servlet. I'll work out their filtering order before the intended functions are implemented. > > Filters are applied in a predictable order. I highly recommend > reading the servlet specification to see how these things are > defined to work. It's quite readable. > > Why not allow Tomcat to serve everything in the web application > (other than /WEB-INF/* and /META-INF/*) as usual? What is it that > you need to put into there that you can't hide in some other way? > > It sounds like you are unnecessarily complicating your life. > > -chris > > >> I was using "/WEB-INF/*" as a test of the scaffolding for my >> application since previously "*.html" ended up infinite loop >> which, eventually, it threw an exception. Now that I've got >> "*.html" working, I'm still getting a blank page. The HTML files >> are only served as UI for the initial setup of the application. >> There won't be any static files other than JS, CSS, and images >> when the application is fully configured by administrator. Here >> are the servlets configuration: > >> Servlet name: default , registered class: >> org.apache.catalina.servlets.DefaultServlet. Servlet default's >> mapping: /img/* /css/* /js/* *.html Servlet default's init >> parameters: listings: false debug: 0 Servlet name: AppServlet , >> registered class: com.sointe.web.AppServlet. Servlet AppServlet's >> mapping: / Servlet AppServlet's init parameters: Servlet name: >> jsp , registered class: org.apache.jasper.servlet.JspServlet. >> Servlet jsp's mapping: *.jspx *.jsp Servlet jsp's init >> parameters: fork:
Re: OCSP with openSSL
Mark, > Am 17.06.2019 um 18:00 schrieb Mark Thomas : > > On 17/06/2019 15:51, logo wrote: >> Mark, >> >> >> Am 2019-06-17 16:29, schrieb Mark Thomas: >>> On 17/06/2019 15:15, logo wrote: Hi Mark, having been in contact with Усманов, I can confirm your summary. May I add my question from February with additional info to this thread: https://markmail.org/message/zvziqrhm32bctm7e >>> >>> Thanks. >>> >>> Progress can be tracked here: >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=56148 >>> >>> At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support >>> OCSP stapling with appropriate configuration. >>> >> >> Do you mean on trunk or really only configuration? >> >> I just tried it on 8.5.42 and it will not send the message on my >> letsencrypt cert. >> >> If it should work out of the box, do you mind to share the "appropriate" >> config here. > > I was testing Tomcat 9.0.x (latest source from Git) but with the > knowledge that we haven't made *any* changes to Tomcat to support OCSP > stapling and that 9.0.x and 8.5.x have very similar TLS code. > > I have just tested with 8.5.42. Both NIO+JSSE and NIO2+JSSE support OCSP > stapling. My Connector configuration is: > > port="8443" > proxyPort="443" > maxThreads="150" > useAsyncIO="true" > SSLEnabled="true"> > className="org.apache.coyote.http2.Http2Protocol" > useSendfile="false" > maxConcurrentStreamExecution="50" /> > > certificateFile="/.../cert.pem" > certificateChainFile="/.../chain.pem" > type="RSA" /> > > > > Mark > I’m lost. My conf is pretty much similar. JAVA_OPTS are set (startup logs show 17-Jun-2019 16:46:48.497 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.server.enableStatusRequestExtension=true ) I use a JSSE keystore - that contains the correct cert. Openssl syntax did not change anything. Running openssl to the letsencrypt ocsp responder from the machine gives a positive result. Tcpdump shows data. $ openssl ocsp -verify_other intermediate.pem -issuer intermediate.pem -cert xxx.crt -text -url http://ocsp.int-x3.letsencrypt.org -header "Host=ocsp.int-x3.letsencrypt.org" OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1 Serial Number: 041237E97D620E10AFA0442E9C1D7B588046 Request Extensions: OCSP Nonce: 0410E8ED9179F620FD43BBCC4C81EC432CFB OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Produced At: Jun 15 23:48:00 2019 GMT … Response verify OK But once I connect to tomcat from outside, I don’t see any tcpdump traffic. $ openssl s_client -connect xxx.dedyn.io:8443 -servername xxx.dedyn.io -tlsextdebug -status CONNECTED(0003) TLS server extension "renegotiation info" (id=65281), len=1 - 00. TLS server extension "server name" (id=0), len=0 TLS server extension "EC point formats" (id=11), len=4 - 03 00 01 02 TLS server extension "session ticket" (id=35), len=0 *OCSP response: no response sent* depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = xxx.dedyn.io verify return:1 --- Certificate chain 0 s:/CN=xxx.dedyn.io i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -BEGIN CERTIFICATE—— Any debug info I can create? Thanks Peter > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > smime.p7s Description: S/MIME cryptographic signature
Re: OCSP with openSSL
On 17/06/2019 15:51, logo wrote: > Mark, > > > Am 2019-06-17 16:29, schrieb Mark Thomas: >> On 17/06/2019 15:15, logo wrote: >>> Hi Mark, >>> >>> having been in contact with Усманов, I can confirm your summary. >>> >>> May I add my question from February with additional info to this thread: >>> https://markmail.org/message/zvziqrhm32bctm7e >> >> Thanks. >> >> Progress can be tracked here: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=56148 >> >> At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support >> OCSP stapling with appropriate configuration. >> > > Do you mean on trunk or really only configuration? > > I just tried it on 8.5.42 and it will not send the message on my > letsencrypt cert. > > If it should work out of the box, do you mind to share the "appropriate" > config here. I was testing Tomcat 9.0.x (latest source from Git) but with the knowledge that we haven't made *any* changes to Tomcat to support OCSP stapling and that 9.0.x and 8.5.x have very similar TLS code. I have just tested with 8.5.42. Both NIO+JSSE and NIO2+JSSE support OCSP stapling. My Connector configuration is: Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OCSP with openSSL
Mark,
Am 2019-06-17 16:29, schrieb Mark Thomas:
On 17/06/2019 15:15, logo wrote:
Hi Mark,
having been in contact with Усманов, I can confirm your summary.
May I add my question from February with additional info to this
thread:
https://markmail.org/message/zvziqrhm32bctm7e
Thanks.
Progress can be tracked here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56148
At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support
OCSP stapling with appropriate configuration.
Do you mean on trunk or really only configuration?
I just tried it on 8.5.42 and it will not send the message on my
letsencrypt cert.
If it should work out of the box, do you mind to share the "appropriate"
config here.
Thanks
Peter
The OpenSSL ones (APR/native, NIO+OpenSSL, NIO2+OpenSSL) do not.
It might be simply a configuration issue with OpenSSL. It might need
code changes in APR/Native. I'm currently looking in to that.
Mark
Thanks.
Peter
Am 2019-06-17 15:44, schrieb Mark Thomas:
Coming back to this as it has been on my TODO list for a while.
Having re-read the thread I think it would be helpful to first
clarify
exactly what behaviour you are expecting and not seeing.
The issue relates to OCSP checks when Tomcat is presenting it's
server
certificate to the client.
You are expecting Tomcat to use OCSP stapling to provide the OCSP
information to the client so that the client does not have to request
it
itself.
Tomcat is not providing the OCSP information. It appears that OCSP
stapling is not working.
Is the above a fair summary? If not, please provide corrections.
Thanks,
Mark
On 27/05/2019 12:36, Усманов Азат Анварович wrote:
Just a quick follow up , trying to get some answers, I added
include
to sslutils.c (which has alll the ocsp functions ) to
print some info.I added printf calls to every function defined in
this file. Interestingly enough when I issue the openssl
s_client
-connect debug.ieml.ru:8443 -tls1_2 -status -proxy 192.168.1.6:3131
both tls1_2 and tls 1_3 versions and when I access the server from
another machine via browser none of printf calls are displayed,
however, when I issue ssllabs server test (which is also supposedly
capable of detecting ocsp) some of them start to appear. sadly
none of them are ocsp related. I did put basic ifdef test for
HAVE_OCSP_STAPLING, surprisingly it shows that ocsp support is
indeed enabled . So here are both the modified sslutils.c file
and tomcat log snippet (not sure if attachments are allowed on the
list so posting it here )
Not sure where to go from here
/* Licensed to the Apache Software Foundation (ASF) under one or
more
* contributor license agreements. See the NOTICE file distributed
with
* this work for additional information regarding copyright
ownership.
* The ASF licenses this file to You under the Apache License,
Version 2.0
* (the "License"); you may not use this file except in compliance
with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions
and
* limitations under the License.
*/
/** SSL Utilities
*/
#include "tcn.h"
#include
#ifdef HAVE_OPENSSL
#include "apr_poll.h"
#include "ssl_private.h"
#ifdef WIN32
extern int WIN32_SSL_password_prompt(tcn_pass_cb_t *data);
#endif
#ifdef HAVE_OCSP_STAPLING
#include
#include
/* defines with the values as seen by the asn1parse -dump openssl
command */
#define ASN1_SEQUENCE 0x30
#define ASN1_OID 0x06
#define ASN1_STRING 0x86
static int ssl_verify_OCSP(X509_STORE_CTX *ctx);
static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX
*ctx);
#endif
/*
_
**
** Additional High-Level Functions for OpenSSL
**
_
*/
/* we initialize this index at startup time
* and never write to it at request time,
* so this static is thread safe.
* also note that OpenSSL increments at static variable when
* SSL_get_ex_new_index() is called, so we _must_ do this at
startup.
*/
static int SSL_app_data2_idx = -1;
static int SSL_app_data3_idx = -1;
static int SSL_app_data4_idx = -1;
void SSL_init_app_data_idx(void)
{ printf(" SSL_init_app_data_idx\n");
#ifdef HAVE_OCSP_STAPLING
printf("Hi OCSP \n");
#else
printf("Sorry no OCSP support\n");
#endif
int i;
if (SSL_app_data2_idx > -1) {
return;
}
/* we _do_ need to call this twice */
for (i = 0; i <= 1; i++) {
SSL_app_data2_idx =
SSL_get_ex_new_index(0,
"Second Application Data for SSL",
NULL,
Re: OCSP with openSSL
On 17/06/2019 15:15, logo wrote:
> Hi Mark,
>
> having been in contact with Усманов, I can confirm your summary.
>
> May I add my question from February with additional info to this thread:
> https://markmail.org/message/zvziqrhm32bctm7e
Thanks.
Progress can be tracked here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56148
At the moment, the pure JSSE solutions (NIO+JSSE, NIO2+JSSE) support
OCSP stapling with appropriate configuration.
The OpenSSL ones (APR/native, NIO+OpenSSL, NIO2+OpenSSL) do not.
It might be simply a configuration issue with OpenSSL. It might need
code changes in APR/Native. I'm currently looking in to that.
Mark
>
> Thanks.
>
> Peter
>
> Am 2019-06-17 15:44, schrieb Mark Thomas:
>> Coming back to this as it has been on my TODO list for a while.
>>
>> Having re-read the thread I think it would be helpful to first clarify
>> exactly what behaviour you are expecting and not seeing.
>>
>> The issue relates to OCSP checks when Tomcat is presenting it's server
>> certificate to the client.
>>
>> You are expecting Tomcat to use OCSP stapling to provide the OCSP
>> information to the client so that the client does not have to request it
>> itself.
>>
>> Tomcat is not providing the OCSP information. It appears that OCSP
>> stapling is not working.
>>
>> Is the above a fair summary? If not, please provide corrections.
>>
>> Thanks,
>>
>> Mark
>>
>>
>> On 27/05/2019 12:36, Усманов Азат Анварович wrote:
>>> Just a quick follow up , trying to get some answers, I added include
>>> to sslutils.c (which has alll the ocsp functions ) to
>>> print some info.I added printf calls to every function defined in
>>> this file. Interestingly enough when I issue the openssl s_client
>>> -connect debug.ieml.ru:8443 -tls1_2 -status -proxy 192.168.1.6:3131
>>> both tls1_2 and tls 1_3 versions and when I access the server from
>>> another machine via browser none of printf calls are displayed,
>>> however, when I issue ssllabs server test (which is also supposedly
>>> capable of detecting ocsp) some of them start to appear. sadly
>>> none of them are ocsp related. I did put basic ifdef test for
>>> HAVE_OCSP_STAPLING, surprisingly it shows that ocsp support is
>>> indeed enabled . So here are both the modified sslutils.c file
>>> and tomcat log snippet (not sure if attachments are allowed on the
>>> list so posting it here )
>>> Not sure where to go from here
>>> /* Licensed to the Apache Software Foundation (ASF) under one or more
>>> * contributor license agreements. See the NOTICE file distributed with
>>> * this work for additional information regarding copyright ownership.
>>> * The ASF licenses this file to You under the Apache License,
>>> Version 2.0
>>> * (the "License"); you may not use this file except in compliance with
>>> * the License. You may obtain a copy of the License at
>>> *
>>> * http://www.apache.org/licenses/LICENSE-2.0
>>> *
>>> * Unless required by applicable law or agreed to in writing, software
>>> * distributed under the License is distributed on an "AS IS" BASIS,
>>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>> implied.
>>> * See the License for the specific language governing permissions and
>>> * limitations under the License.
>>> */
>>>
>>> /** SSL Utilities
>>> */
>>>
>>> #include "tcn.h"
>>> #include
>>> #ifdef HAVE_OPENSSL
>>> #include "apr_poll.h"
>>> #include "ssl_private.h"
>>>
>>>
>>> #ifdef WIN32
>>> extern int WIN32_SSL_password_prompt(tcn_pass_cb_t *data);
>>> #endif
>>>
>>> #ifdef HAVE_OCSP_STAPLING
>>> #include
>>> #include
>>> /* defines with the values as seen by the asn1parse -dump openssl
>>> command */
>>> #define ASN1_SEQUENCE 0x30
>>> #define ASN1_OID 0x06
>>> #define ASN1_STRING 0x86
>>> static int ssl_verify_OCSP(X509_STORE_CTX *ctx);
>>> static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX
>>> *ctx);
>>> #endif
>>>
>>> /* _
>>> **
>>> ** Additional High-Level Functions for OpenSSL
>>> ** _
>>> */
>>>
>>> /* we initialize this index at startup time
>>> * and never write to it at request time,
>>> * so this static is thread safe.
>>> * also note that OpenSSL increments at static variable when
>>> * SSL_get_ex_new_index() is called, so we _must_ do this at startup.
>>> */
>>> static int SSL_app_data2_idx = -1;
>>> static int SSL_app_data3_idx = -1;
>>> static int SSL_app_data4_idx = -1;
>>>
>>> void SSL_init_app_data_idx(void)
>>> { printf(" SSL_init_app_data_idx\n");
>>> #ifdef HAVE_OCSP_STAPLING
>>> printf("Hi OCSP \n");
>>> #else
>>> printf("Sorry no OCSP support\n");
>>> #endif
>>>
>>> int i;
>>>
>>> if (SSL_app_data2_idx > -1) {
>>> return;
>>> }
>>>
>>> /* we _do_ need to call this twice */
>>> for (i = 0; i <= 1; i++) {
>>> SSL_app_data2_idx =
>>>
Re: OCSP with openSSL
Hi Mark,
having been in contact with Усманов, I can confirm your summary.
May I add my question from February with additional info to this thread:
https://markmail.org/message/zvziqrhm32bctm7e
Thanks.
Peter
Am 2019-06-17 15:44, schrieb Mark Thomas:
Coming back to this as it has been on my TODO list for a while.
Having re-read the thread I think it would be helpful to first clarify
exactly what behaviour you are expecting and not seeing.
The issue relates to OCSP checks when Tomcat is presenting it's server
certificate to the client.
You are expecting Tomcat to use OCSP stapling to provide the OCSP
information to the client so that the client does not have to request
it
itself.
Tomcat is not providing the OCSP information. It appears that OCSP
stapling is not working.
Is the above a fair summary? If not, please provide corrections.
Thanks,
Mark
On 27/05/2019 12:36, Усманов Азат Анварович wrote:
Just a quick follow up , trying to get some answers, I added include
to sslutils.c (which has alll the ocsp functions ) to
print some info.I added printf calls to every function defined in
this file. Interestingly enough when I issue the openssl s_client
-connect debug.ieml.ru:8443 -tls1_2 -status -proxy 192.168.1.6:3131
both tls1_2 and tls 1_3 versions and when I access the server from
another machine via browser none of printf calls are displayed,
however, when I issue ssllabs server test (which is also supposedly
capable of detecting ocsp) some of them start to appear. sadly none
of them are ocsp related. I did put basic ifdef test for
HAVE_OCSP_STAPLING, surprisingly it shows that ocsp support is
indeed enabled . So here are both the modified sslutils.c file and
tomcat log snippet (not sure if attachments are allowed on the list
so posting it here )
Not sure where to go from here
/* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version
2.0
* (the "License"); you may not use this file except in compliance
with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/** SSL Utilities
*/
#include "tcn.h"
#include
#ifdef HAVE_OPENSSL
#include "apr_poll.h"
#include "ssl_private.h"
#ifdef WIN32
extern int WIN32_SSL_password_prompt(tcn_pass_cb_t *data);
#endif
#ifdef HAVE_OCSP_STAPLING
#include
#include
/* defines with the values as seen by the asn1parse -dump openssl
command */
#define ASN1_SEQUENCE 0x30
#define ASN1_OID 0x06
#define ASN1_STRING 0x86
static int ssl_verify_OCSP(X509_STORE_CTX *ctx);
static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX
*ctx);
#endif
/* _
**
** Additional High-Level Functions for OpenSSL
** _
*/
/* we initialize this index at startup time
* and never write to it at request time,
* so this static is thread safe.
* also note that OpenSSL increments at static variable when
* SSL_get_ex_new_index() is called, so we _must_ do this at startup.
*/
static int SSL_app_data2_idx = -1;
static int SSL_app_data3_idx = -1;
static int SSL_app_data4_idx = -1;
void SSL_init_app_data_idx(void)
{ printf(" SSL_init_app_data_idx\n");
#ifdef HAVE_OCSP_STAPLING
printf("Hi OCSP \n");
#else
printf("Sorry no OCSP support\n");
#endif
int i;
if (SSL_app_data2_idx > -1) {
return;
}
/* we _do_ need to call this twice */
for (i = 0; i <= 1; i++) {
SSL_app_data2_idx =
SSL_get_ex_new_index(0,
"Second Application Data for SSL",
NULL, NULL, NULL);
}
if (SSL_app_data3_idx > -1) {
return;
}
SSL_app_data3_idx =
SSL_get_ex_new_index(0,
"Third Application Data for SSL",
NULL, NULL, NULL);
if (SSL_app_data4_idx > -1) {
return;
}
SSL_app_data4_idx =
SSL_get_ex_new_index(0,
"Fourth Application Data for SSL",
NULL, NULL, NULL);
}
void *SSL_get_app_data2(SSL *ssl)
{
printf("ssl_get_app_data2 \n");
return (void *)SSL_get_ex_data(ssl, SSL_app_data2_idx);
}
void SSL_set_app_data2(SSL *ssl, void *arg)
{
printf("ssl_set_app_data2 \n");
SSL_set_ex_data(ssl,
Re: OCSP with openSSL
Coming back to this as it has been on my TODO list for a while.
Having re-read the thread I think it would be helpful to first clarify
exactly what behaviour you are expecting and not seeing.
The issue relates to OCSP checks when Tomcat is presenting it's server
certificate to the client.
You are expecting Tomcat to use OCSP stapling to provide the OCSP
information to the client so that the client does not have to request it
itself.
Tomcat is not providing the OCSP information. It appears that OCSP
stapling is not working.
Is the above a fair summary? If not, please provide corrections.
Thanks,
Mark
On 27/05/2019 12:36, Усманов Азат Анварович wrote:
> Just a quick follow up , trying to get some answers, I added include
> to sslutils.c (which has alll the ocsp functions ) to print some
> info.I added printf calls to every function defined in this file.
> Interestingly enough when I issue the openssl s_client -connect
> debug.ieml.ru:8443 -tls1_2 -status -proxy 192.168.1.6:3131
> both tls1_2 and tls 1_3 versions and when I access the server from another
> machine via browser none of printf calls are displayed, however, when I
> issue ssllabs server test (which is also supposedly capable of detecting
> ocsp) some of them start to appear. sadly none of them are ocsp related. I
> did put basic ifdef test for HAVE_OCSP_STAPLING, surprisingly it shows
> that ocsp support is indeed enabled . So here are both the modified
> sslutils.c file and tomcat log snippet (not sure if attachments are allowed
> on the list so posting it here )
> Not sure where to go from here
> /* Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> /** SSL Utilities
> */
>
> #include "tcn.h"
> #include
> #ifdef HAVE_OPENSSL
> #include "apr_poll.h"
> #include "ssl_private.h"
>
>
> #ifdef WIN32
> extern int WIN32_SSL_password_prompt(tcn_pass_cb_t *data);
> #endif
>
> #ifdef HAVE_OCSP_STAPLING
> #include
> #include
> /* defines with the values as seen by the asn1parse -dump openssl command */
> #define ASN1_SEQUENCE 0x30
> #define ASN1_OID 0x06
> #define ASN1_STRING 0x86
> static int ssl_verify_OCSP(X509_STORE_CTX *ctx);
> static int ssl_ocsp_request(X509 *cert, X509 *issuer, X509_STORE_CTX *ctx);
> #endif
>
> /* _
> **
> ** Additional High-Level Functions for OpenSSL
> ** _
> */
>
> /* we initialize this index at startup time
> * and never write to it at request time,
> * so this static is thread safe.
> * also note that OpenSSL increments at static variable when
> * SSL_get_ex_new_index() is called, so we _must_ do this at startup.
> */
> static int SSL_app_data2_idx = -1;
> static int SSL_app_data3_idx = -1;
> static int SSL_app_data4_idx = -1;
>
> void SSL_init_app_data_idx(void)
> { printf(" SSL_init_app_data_idx\n");
>#ifdef HAVE_OCSP_STAPLING
> printf("Hi OCSP \n");
> #else
> printf("Sorry no OCSP support\n");
> #endif
>
> int i;
>
> if (SSL_app_data2_idx > -1) {
> return;
> }
>
> /* we _do_ need to call this twice */
> for (i = 0; i <= 1; i++) {
> SSL_app_data2_idx =
> SSL_get_ex_new_index(0,
> "Second Application Data for SSL",
> NULL, NULL, NULL);
> }
>
> if (SSL_app_data3_idx > -1) {
> return;
> }
>
> SSL_app_data3_idx =
> SSL_get_ex_new_index(0,
> "Third Application Data for SSL",
> NULL, NULL, NULL);
>
> if (SSL_app_data4_idx > -1) {
> return;
> }
>
> SSL_app_data4_idx =
> SSL_get_ex_new_index(0,
> "Fourth Application Data for SSL",
> NULL, NULL, NULL);
>
> }
>
> void *SSL_get_app_data2(SSL *ssl)
> {
> printf("ssl_get_app_data2 \n");
> return (void *)SSL_get_ex_data(ssl, SSL_app_data2_idx);
> }
>
> void SSL_set_app_data2(SSL *ssl, void *arg)
> {
> printf("ssl_set_app_data2 \n");
>
> SSL_set_ex_data(ssl, SSL_app_data2_idx, (char
Re: Tomcat embedded
On 17/06/2019 01:04, Tommy Pham wrote: > Hello everyone, > > 1) Is there an official documentation for embedding TC process? My search > shows various how-to on other sites. >a) If not, I guess I could request to be added to the wiki to > contribute one. Since I don't quite know all the details of TC, is there a > review process to ensure clarity and complete coverage of embedding process? The Javadoc is probably the best place to start: http://tomcat.apache.org/tomcat-9.0-doc/api/index.html There is a lot more information that could be presented there. Patches welcome. A Tomcat committer will review any patch before applying it. > 2) (probably better to ask the dev list?) I noticed there are some > differences in the official binary distribution vs development environment: >a) Official has annotations-api.jar while development has according to > gradle: > > default - Configuration for default artifacts. > +--- org.apache.tomcat.embed:tomcat-embed-core:9.0.+ -> 9.0.21 > |\--- org.apache.tomcat:tomcat-annotations-api:9.0.21 > > while the jar file names are different, the classes' name and the jar's > manifest within appear to the same. I think this is trivial. Whenever you wonder why a line of code is they way it is, running git blame on the file is usually informative.In this case it will lead you to: https://github.com/apache/tomcat/commit/1386eaac4d07b6bbae69b3981fe1f873a56b7cae >b) ecj version differences: the official binary uses ecj-4.10.jar > while the development, per gradle, uses ecj-3.16: It is the same version. The difference is due to where the JARs are obtained from. The Tomcat build script gets it from The Eclipse IDE 4.10 downloads - hence the version used. The pom.xml go directly to Maven Central which uses the internal version number 3.16. If you look in the manifests you'll see the internal version info is the same. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat 7 to 9 results in more open file descriptors
On 03/06/2019 22:46, Mark Thomas wrote: >> Florian, >> >>> On 5/23/19 06:59, Florian Trimmel wrote: We were able to figure out >>> what was causing the file descriptor leak. >> >>> The leak has occured in the JSF2 MyFaces Implementation we are >>> using. It is described here: >>> https://marc.info/?l=myfaces-dev=152536956716792=2 The problem >>> was found using this tool: http://file-leak-detector.kohsuke.org/ >> >> Yup, that'll do it. >> >> Thanks for coming back to report your results. > > +1. > > This got me thinking. We should add a debugging section to the Wiki and > include this tool. Done: https://cwiki.apache.org/confluence/display/TOMCAT/Debugging Additional content welcome. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
