RE: tomcat 7 connection pool validation interval
-Original Message-
From: Phil Steitz [mailto:phil.ste...@gmail.com]
Sent: Friday, July 01, 2016 9:16 PM
To: users@tomcat.apache.org
Subject: Re: tomcat 7 connection pool validation interval
On 7/1/16 7:14 AM, Nir Dweck wrote:
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Thursday, June 30, 2016 6:57 PM
> To: Tomcat Users List
> Subject: Re: tomcat 7 connection pool validation interval
>
>
>
On Jun 30, 2016, at 9:32 AM, Nir Dweck wrote:
I am using tomcat connection pool (tomcat 7) in my application (java
application) to connect to a remote Oracle DB on an Azure machine. My
connection pool configuration is as follow:
PoolProperties p = new PoolProperties();
p.setUrl(connString);
p.setUsername(user);
p.setPassword(password);
p.setDriverClassName("oracle.jdbc.OracleDriver");
p.setValidationQuery("SELECT 1 from dual");
p.setValidationInterval(1 * 6/2);
p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
p.setTestOnBorrow(true);
p.setTestWhileIdle(true);
p.setMinIdle(10);
p.setInitialSize(10);
However looking at the capture file, I see that the connections are not
checked every 30 seconds as I expected. One connection is checked
correctly, the others are checked after 3 times the configuration (180
second). then again only some of the connections are checked and after a
while it seems to stable on twice the configuration period (every 60
seconds).
I tested it with different configured time and different pool size, all
had a instability period in which each time only part of the connections
were checked and eventually it stabled on checks of all the connections
every twice the configured time.
What am I missing?
Thanks,
>>> Most likely the connections not being tested are checked out to clients
>>> when the pool maintenance runs. Assuming you are using the default DBCP
>>> pool, >>only idle connections (meaning waiting in the pool) are tested by
>>> the maintenance thread.
>>> Phil
>> No, all connection are idle, but still looking at wireShark the validation
>> query is sent every twice the TimeBetweenEvictionRunsMillis.
>
>I am sorry I should have been more clear. The term, "idle" is a little
>confusing here. I should have said connections are only checked when they are
>not >checked out to client threads. A connection can be "idle" from the DB
>standpoint but still checked out to a client. A connection that is checked
>out to a >client will not be tested by the pool maintenance thread. Are there
>clients using the pool while you are running this test?
>I notice now a parameter not supported by DBCP, so I guess you must be using
>the tomcat-jdbc pool. It looks to me like it defines "idle" the same way DBCP
>does - in other words above statements are true for that pool too.
>It is also possible that setting validationInterval to a value <=
>timeBetweenEvictionRuns may cause some validations to be suppressed, since the
>former is a >max frequency.
>Phil
Hi Phil,
I understood you correctly, none of the connections are held by any client. All
are idle in the pool. I tried also setting timeBetweenEvictionRuns to half
validationInterval, but still, the best I get is that the connections are
validated in half the frequency I requested (every 2 * validationInterval). And
yes I am using tomcat-jdbc pool.
Nir
>>
>
> Nir
>
>> Nir
> -
> 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
>
>
-
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: Tomcat 7 and SHA-1
2016-07-01 16:21 GMT-04:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Greg, > > On 7/1/16 3:03 AM, Greg Beresnev wrote: > > Thanks Daniel - any idea which cipher in particular needs to be > > absent in order for the SHA-1-based connection/authentication was > > rejected/failed? > > I'm afraid Daniel may have confused the issue, because the > certificate-signing algorithm is completely independent of any cipher > suites that you may use for the encrypted TLS connection. > > FWIW, at $work, we typically filter-out anything that looks like this: > > NULL|_anon_|_DHE_|EXPORT|RC4|MD5|SHA$ > > But there's no way I know of to reject the local server certificate if > it doesn't meet some kind of criteria. > > I checked, and Nagios's check_http utility does NOT have a check for > anything about a certificate other than it's expiration date. This > seems like a good thing to add to that tool (along with complaining > about support for certain protocols like SSLv3). > > There are other tools you could use, such as Mark's suggestion of > using Qualys's ssltest site. > > In fact, to enforce SHA-2 (which is the same as SHA-256) you just have to switch to TLSv1.2 and nothing less. As per the RFC 5246 https://tools.ietf.org/html/rfc5246 SHA-2 is mandatory, paragraph 1.2. Chris, you are right, the cipher suite is something different from the HMAC for the certificate itself. However, if the user wants to ban the SHA-1 from the negociated symmetric encryption algorithm, he will have to set a proper cipher suite to exclude anything without SHA-256 and more from the accepted ciphers. You have to experiment with the openssl cipher command to find out a proper combination. - Daniel Savard
Re: Need help setting up SSL on Tomcat 8
2016-07-01 16:08 GMT-04:00 Christopher Schultz : > > > > > Thank you for the reply. How would I go about specifying the alias > > of the certificate? > > You may have to re-import it, but I've had bad experiences with Java > keystores so ALWAYS keep a backup in case you host something. > > The first item in your keystore certainly looks like a certificate to > me. It's the *second* item that is a private key. > > What if you add these attributes to your connector: > > keyAlias="root" > > ? > > If that doesn't work, try using a tool like Portecle to try to adjust > some things (like the "aliases"). It's much better and safer than > using keytool IMO. Remember ALWAYS KEEP A BACKUP! > > Chris, in a keystore, the entry with the certificate created using the private key from that keystore is a single entry identified as PrivateKey. If you have a single certificate created from a private key in that keystore you will have only one entry, not two and it will be labeled as private key. In fact, it can be checked using the -v option to print details about each entry. This should be enough to identify without ambiguity which entry is what. This is what I recommend to do in order to understand what really is in the keystore. I doubt the alias root with the first entry in the keystore is actually the certificate needed here. Sean, print the details and you will have the alias and Common Name clearly identified on the output in a verbose format. Use the -v option to the keytool command for this. No need to post everything here if you are unsure. - Daniel Savard
Re: How to configure SPNEGO authentication with fallback to FORM auth?
On 6/30/2016 7:52 AM, ken edward wrote: I did get it to work. Simply merged existing spnego and form auth valves together, I will try to post later.. On Fri, Jun 24, 2016 at 6:21 PM, Terence M. Bandoian wrote: On 6/24/2016 10:45 AM, ken edward wrote: On Fri, Jun 24, 2016 at 11:26 AM, Mark Thomas wrote: On 24/06/2016 16:17, ken edward wrote: On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas wrote: On 24 June 2016 14:22:32 BST, ken edward wrote: Hello, I have tomcat 8 on linux, configured with kerberos/SPNEGO authentication. All works well, but if the client cannot use kerberos to authenticate, it will not fallback to FORM authentication. I see some references that tomcat 8 does not do fallback negotiation for FORM auth. True? Yes Any workarounds? Nothing simple. Both SPNEGO and FORM have their complications. You'll need to code some form of custom solution. Have a look in the archives. This has come up before and I think there is some sample code that might get you most of the way there. I had already searched the mail archives, and did not see any sample code. If anyone has any insight, please do post some code fragments. I was thinking of this: http://wiki.apache.org/tomcat/SSLWithFORMFallback Not quite what you are looking for but it might help. I guess I need to extend the SPNEGO valve code in tomcat 8 to handle fallback to FORM auth, similar to SSLWIthFORMFallback. aaarg. Such a simple and essential use case. Perplexing that it is not implemented. If you get it working, you might consider submitting a patch. Doing so might save someone else from cursing under their breath. -Terence Bandoian http://www.tmbsw.com/ Sounds great! -Terence - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 and SHA-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Greg, On 7/1/16 3:03 AM, Greg Beresnev wrote: > Thanks Daniel - any idea which cipher in particular needs to be > absent in order for the SHA-1-based connection/authentication was > rejected/failed? I'm afraid Daniel may have confused the issue, because the certificate-signing algorithm is completely independent of any cipher suites that you may use for the encrypted TLS connection. FWIW, at $work, we typically filter-out anything that looks like this: NULL|_anon_|_DHE_|EXPORT|RC4|MD5|SHA$ But there's no way I know of to reject the local server certificate if it doesn't meet some kind of criteria. I checked, and Nagios's check_http utility does NOT have a check for anything about a certificate other than it's expiration date. This seems like a good thing to add to that tool (along with complaining about support for certain protocols like SSLv3). There are other tools you could use, such as Mark's suggestion of using Qualys's ssltest site. - -chris > On Fri, Jul 1, 2016 at 4:53 PM, Daniel Savard > wrote: > >> 2016-06-30 23:05 GMT-04:00 Greg Beresnev >> : >> >>> Hi, >>> >>> We're in the process of updating our web application to stop >>> using SHA-1 certificates and I was wondering if there was some >>> way to configure >> Tomcat >>> (we're on version 7.0.39 - yes, I know, we are pretty >>> old-school and >> should >>> get with the times) to either throw errors or at least log >>> warnings for >> the >>> cases where connection/authentication attempt is being made >>> using SHA-1 certificate? >>> >> >> No. >> >> However, you can select the accepted ciphers to reject anything >> that doesn't meet your standards. >> >> - Daniel Savard >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXdtDnAAoJEBzwKT+lPKRY/f0QAKK7mUZJxvCqfDm98BlbbbUj DR5a/CRPvg7O41+tXSEMqnUiDaJIkLpOGeE/wjwECc7Iv8v8TDdcj8yzIlueqHJu mwIlX370v4FiOH6vut7qgN51kieMTaRHhS3CL5Q37ogJCaRC8V8T9WFJvsJU49gC M7NiHe4ZV47nlZ3dvUFZ8VunX1BU5DcxQRI0nF6k9R4dvrrUX5AR5A0WN4tv1qAp Cg/WpuLizcet4GSZmQpk1mVe3J7fCXRQsYMUiJdj2p2mhviI1pZjwe+F4WyOq9gL EDI2Gel7Mq26aWKiZFrW+JNsAfDFYgJmFFIWj7LY/L1P9vJMy6xK02iE4t3pTg+2 frl4UCXOaInvXdM+ZfZuJLwYeUtyoYWnxIVcbaEtr2VlBVXBBzezpZfjMnVcUPtO Vyu2VAPKWipoNk0deSX7eHwMX5AiKMfvLvrkYGQnumVxDTf2z6ttxleJJUnNOONW Q+dD65hamBzSMq8pvcz1cH8mRpuxYxZIguaFYwEN6uJdIoafztc0cXf8kbrDaNBe Jo3sEKbUuWZJoMA2ZaU0hx1evT648g5VWzyJfwox6RUKesw2JqWSBC/Mn2X0CHit g71pkQ4iij5WrrbsPgL5aT9zUjLqdn6UGoRu69CsWFSRcHYOUygikajP21ZsNrBy N3OmO7YGgli4zOq8bkxK =qqDk -END PGP SIGNATURE- - 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sean,
On 7/1/16 11:11 AM, Sean Son wrote:
> On Fri, Jul 1, 2016 at 2:57 AM, Daniel Savard
> wrote:
>
>> 2016-06-29 9:08 GMT-04:00 Sean Son
>> :
>>
>>> Hello Daniel
>>>
>>> Thank you for the information. Here is the output of the
>>> keytool command:
>>>
>>> Keystore type: JKS Keystore provider: SUN
>>>
>>> Your keystore contains 2 entries
>>>
>>> root, Jun 16, 2016, trustedCertEntry, Certificate fingerprint
>>> (SHA1):
>>> 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
>>> {b81d8607-57e9-4c35-a058-cd46099e7797}, Jun 16, 2016,
>>> PrivateKeyEntry, Certificate fingerprint (SHA1):
>>> 6C:67:52:63:6B:EF:A2:3D:CD:A7:CB:64:99:99:4F:9C:3E:85:B9:AA
>>>
>>>
>>> Is it possible that the error that I am seeing, is related to
>>> the fact that I am using a wildcard certificate?
>>>
>>
>> So, the first entry in the keystore isn't your certificate. As I
>> told you before, if you do not specify explicitely the alias of
>> the certificate so send, the first entry in the keystore is sent.
>> In this case, root.
>>
>> The attribute to tell the connector which certificate to send, is
>> keyAlias, however it seems your certificate has no alias in the
>> keystore.
>>
>> - Daniel Savard
>>
>
>
> Thank you for the reply. How would I go about specifying the alias
> of the certificate?
You may have to re-import it, but I've had bad experiences with Java
keystores so ALWAYS keep a backup in case you host something.
The first item in your keystore certainly looks like a certificate to
me. It's the *second* item that is a private key.
What if you add these attributes to your connector:
keyAlias="root"
?
If that doesn't work, try using a tool like Portecle to try to adjust
some things (like the "aliases"). It's much better and safer than
using keytool IMO. Remember ALWAYS KEEP A BACKUP!
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXds3aAAoJEBzwKT+lPKRYioQQAIJXjzniDRnW2U9+W0d/x7M5
/6nBHRw42COjvmHMUC5fY0lQR0rESHYC3yDhkmuutpeYNJyLO/TWLYZUGnEHf7US
7S+2IcYM19AEbDnp8qvE4pMOshJwf7eRic7lBr1OfJ50CKjdzvv2EiSFwO8tdY+6
eYODI+ZBvC7/lUFZ/H9cGlxx2kQHcuzWoE2+9I5DRxzIPP04nN8sfKXHoEiPH97j
d4dQMBpbNC87P6HlcGxpoxcoCfYPpHLMae5PXdSLHnyvU6YKGCUkm5bRE4ieC9F1
ZjFIH+rJZW61wJw64PXOvMm9k6zFL2R5CIsEg3OdZa6Injh951nH3H5GEF7xvJHy
Z1heq6NmuwzHkYT0/vI4S141tscEziNqsTw2kMyV9+QFEHp1u3zin62gIoDXFaHf
jG33c1cWfl4zkWhzWeZcmEN/n6Z+N0x/RZpRugoRy0heero8VF5lgKnjn/7kHuLm
BCZgA5KrsNSYcnQCeDPqTVeKoUXmF0e92xsCAKRjYjBsSUo8Uc0rlu2GaJhYYQma
rIMKli4f5KVAd3vzj4DE8EdmLxNDfgHvftGVMbTViCMlhwwZqI8NA6wGhA+JCVeH
H29sXNh5D5txBfwz10UvEC9iGFRBWZ1jZfrSdEbb4Ra8acrrC+Er6bwgjB8MMAnX
QpMck2thv/QiUCIr7gIb
=LOtb
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7 connection pool validation interval
On 7/1/16 7:14 AM, Nir Dweck wrote:
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Thursday, June 30, 2016 6:57 PM
> To: Tomcat Users List
> Subject: Re: tomcat 7 connection pool validation interval
>
>
>
>>> On Jun 30, 2016, at 9:32 AM, Nir Dweck wrote:
>>>
>>> I am using tomcat connection pool (tomcat 7) in my application (java
>>> application) to connect to a remote Oracle DB on an Azure machine. My
>>> connection pool configuration is as follow:
>>>
>>>PoolProperties p = new PoolProperties();
>>>p.setUrl(connString);
>>>p.setUsername(user);
>>>p.setPassword(password);
>>>p.setDriverClassName("oracle.jdbc.OracleDriver");
>>>p.setValidationQuery("SELECT 1 from dual");
>>>p.setValidationInterval(1 * 6/2);
>>>p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
>>>p.setTestOnBorrow(true);
>>>p.setTestWhileIdle(true);
>>>p.setMinIdle(10);
>>>p.setInitialSize(10);
>>> However looking at the capture file, I see that the connections are not
>>> checked every 30 seconds as I expected. One connection is checked
>>> correctly, the others are checked after 3 times the configuration (180
>>> second). then again only some of the connections are checked and after a
>>> while it seems to stable on twice the configuration period (every 60
>>> seconds).
>>>
>>> I tested it with different configured time and different pool size, all had
>>> a instability period in which each time only part of the connections were
>>> checked and eventually it stabled on checks of all the connections every
>>> twice the configured time.
>>> What am I missing?
>>> Thanks,
>> Most likely the connections not being tested are checked out to clients when
>> the pool maintenance runs. Assuming you are using the default DBCP pool,
>> >only idle connections (meaning waiting in the pool) are tested by the
>> maintenance thread.
>> Phil
> No, all connection are idle, but still looking at wireShark the validation
> query is sent every twice the TimeBetweenEvictionRunsMillis.
I am sorry I should have been more clear. The term, "idle" is a
little confusing here. I should have said connections are only
checked when they are not checked out to client threads. A
connection can be "idle" from the DB standpoint but still checked
out to a client. A connection that is checked out to a client will
not be tested by the pool maintenance thread. Are there clients
using the pool while you are running this test?
I notice now a parameter not supported by DBCP, so I guess you must
be using the tomcat-jdbc pool. It looks to me like it defines
"idle" the same way DBCP does - in other words above statements are
true for that pool too.
It is also possible that setting validationInterval to a value <=
timeBetweenEvictionRuns may cause some validations to be suppressed,
since the former is a max frequency.
Phil
>
>
> Nir
>
>> Nir
> -
> 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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
poor upload performance with isapi_redirect.dll and IIS
We're seeing some really poor performance with isapi_redirect.dll and uploading files with IIS. In a particular example, using a 200MB file, the file upload (POST) takes ~50 seconds on localhost. The same upload using Apache and mod_jk takes about ~6 seconds. The interesting thing is, on a remote client, the behavior is almost the same. Upload to IIS takes ~50 seconds, upload to apache/mod_jk takes ~7 seconds. I've done some wireshark captures have found some of the differences. Apache streams to mod_jk as the upload is occurring. IIS appears to be buffering the entire upload before finally streaming to tomcat via ajp. The TCP recieve window is regularly being starved (ZeroWindow) and the client has to wait for a window update before being able to send more. I'm not familiar with ISAPI at all, so I don't know if the responsibility on the buffering of the POST is an IIS issue, or is the isapi_redirect filter the problem? Or is there some overall limitation with isapi? Thoughts? Andy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues
Hi all, Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 8.5.3x64 using the connector protocol of: protocol="org.apache.coyote.http11.Http11Nio2Protocol" fails with url encoding errors? Once it was changed back to protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped. This completely broke the application and made it unusable as the xml being returned was not decoded and resulted in sax parse exceptions with our AJAX connections. I haven't found anything related to the protocol changing, only the parameters for the SSL/TLS attributes which are in place and work. It's almost like it's blocking the requests when it should be unblocking the requests? Thanks!! Database Type: Oracle 12c Linux x64 Driver used: ojdbc7.jar Connector attribute: An example of the error looks like the below: 23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] (ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, StorageStream) sax parse error: Content is not allowed in prolog. From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66) at com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477) at com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432) at com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818) at com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481) at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554) at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388) at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277) at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015) at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848) at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331) at com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817) at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:327) at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:270) at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:247) at com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:278) at com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:223) at com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:574) at com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:374) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:338) at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:379) at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:216) at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppServerBridgeToPega.java:265) at com.pega.pegarules.internal.web.servlet.WebStandardBoot.doPost(WebStandardBoot.java:118) at javax.servlet.http.HttpServlet.service(HttpServlet.java:648) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
Re: Need help setting up SSL on Tomcat 8
On Fri, Jul 1, 2016 at 2:57 AM, Daniel Savard
wrote:
> 2016-06-29 9:08 GMT-04:00 Sean Son :
>
> > Hello Daniel
> >
> > Thank you for the information. Here is the output of the keytool command:
> >
> > Keystore type: JKS
> > Keystore provider: SUN
> >
> > Your keystore contains 2 entries
> >
> > root, Jun 16, 2016, trustedCertEntry,
> > Certificate fingerprint (SHA1):
> > 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
> > {b81d8607-57e9-4c35-a058-cd46099e7797}, Jun 16, 2016, PrivateKeyEntry,
> > Certificate fingerprint (SHA1):
> > 6C:67:52:63:6B:EF:A2:3D:CD:A7:CB:64:99:99:4F:9C:3E:85:B9:AA
> >
> >
> > Is it possible that the error that I am seeing, is related to the fact
> > that I am using a wildcard certificate?
> >
>
> So, the first entry in the keystore isn't your certificate. As I told you
> before, if you do not specify explicitely the alias of the certificate so
> send, the first entry in the keystore is sent. In this case, root.
>
> The attribute to tell the connector which certificate to send, is keyAlias,
> however it seems your certificate has no alias in the keystore.
>
> -
> Daniel Savard
>
Thank you for the reply. How would I go about specifying the alias of the
certificate?
RE: tomcat 7 connection pool validation interval
-Original Message-
From: Phil Steitz [mailto:phil.ste...@gmail.com]
Sent: Thursday, June 30, 2016 6:57 PM
To: Tomcat Users List
Subject: Re: tomcat 7 connection pool validation interval
>> On Jun 30, 2016, at 9:32 AM, Nir Dweck wrote:
>>
>> I am using tomcat connection pool (tomcat 7) in my application (java
>> application) to connect to a remote Oracle DB on an Azure machine. My
>> connection pool configuration is as follow:
>>
>>PoolProperties p = new PoolProperties();
>>p.setUrl(connString);
>>p.setUsername(user);
>>p.setPassword(password);
>>p.setDriverClassName("oracle.jdbc.OracleDriver");
>>p.setValidationQuery("SELECT 1 from dual");
>>p.setValidationInterval(1 * 6/2);
>>p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
>>p.setTestOnBorrow(true);
>>p.setTestWhileIdle(true);
>>p.setMinIdle(10);
>>p.setInitialSize(10);
>> However looking at the capture file, I see that the connections are not
>> checked every 30 seconds as I expected. One connection is checked correctly,
>> the others are checked after 3 times the configuration (180 second). then
>> again only some of the connections are checked and after a while it seems to
>> stable on twice the configuration period (every 60 seconds).
>>
>> I tested it with different configured time and different pool size, all had
>> a instability period in which each time only part of the connections were
>> checked and eventually it stabled on checks of all the connections every
>> twice the configured time.
> >What am I missing?
> >Thanks,
>Most likely the connections not being tested are checked out to clients when
>the pool maintenance runs. Assuming you are using the default DBCP pool,
>>only idle connections (meaning waiting in the pool) are tested by the
>maintenance thread.
>Phil
No, all connection are idle, but still looking at wireShark the validation
query is sent every twice the TimeBetweenEvictionRunsMillis.
Nir
>
> Nir
-
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: ***UNCHECKED*** Re: Tomcat 7 and SHA-1
On 01/07/2016 08:03, Greg Beresnev wrote: > Thanks Daniel - any idea which cipher in particular needs to be absent in > order for the SHA-1-based connection/authentication was rejected/failed? I recommend using SSLLabs to test your site. Also, the version of Java you use is important. See this page for details: https://wiki.apache.org/tomcat/Security/Ciphers Finally, if you want to limit client certificates, you could add a custom X509UsernameRetrieverClassName to your Realm and use that to drop and user certificates using SHA1. It isn't what that class was intended for but it should work. Mark > > regards, > Greg > > > On Fri, Jul 1, 2016 at 4:53 PM, Daniel Savard > wrote: > >> 2016-06-30 23:05 GMT-04:00 Greg Beresnev : >> >>> Hi, >>> >>> We're in the process of updating our web application to stop using SHA-1 >>> certificates and I was wondering if there was some way to configure >> Tomcat >>> (we're on version 7.0.39 - yes, I know, we are pretty old-school and >> should >>> get with the times) to either throw errors or at least log warnings for >> the >>> cases where connection/authentication attempt is being made using SHA-1 >>> certificate? >>> >> >> No. >> >> However, you can select the accepted ciphers to reject anything that >> doesn't meet your standards. >> >> - >> Daniel Savard >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 and SHA-1
Thanks Daniel - any idea which cipher in particular needs to be absent in order for the SHA-1-based connection/authentication was rejected/failed? regards, Greg On Fri, Jul 1, 2016 at 4:53 PM, Daniel Savard wrote: > 2016-06-30 23:05 GMT-04:00 Greg Beresnev : > > > Hi, > > > > We're in the process of updating our web application to stop using SHA-1 > > certificates and I was wondering if there was some way to configure > Tomcat > > (we're on version 7.0.39 - yes, I know, we are pretty old-school and > should > > get with the times) to either throw errors or at least log warnings for > the > > cases where connection/authentication attempt is being made using SHA-1 > > certificate? > > > > No. > > However, you can select the accepted ciphers to reject anything that > doesn't meet your standards. > > - > Daniel Savard >
