Any successful SSL Implementation on Tomcat 9.0.69, Java 11, and Oracle ORDS 22.2?

2023-02-22 Thread James Boggs
Has anyone been able to complete a successful SSL Implementation on Tomcat 
9.0.69, Java 11, and Oracle ORDS 22.2?
We had SSL working with Tomcat 9.0.65, Java 8, and ORDS 21, on an Oracle 19c 
database with Oracle APEX 21 (on Windows Server 2012).
Now ORDS requires Java 11 which does not have a JRE like Java 8 had.
After upgrading the software and installing Java 11, we used Java 11 to create 
a new Keystore which is type PKCS#12, then created a SSL certificate request 
file with type RSA, sent that off, and received back a download text file we 
saved as a ".cer" certificate file type, it contains a BEGIN and END with a 
single block of text in between.
Importing that into the keystore does not seem to work and it seems there is 
new syntax required for the Tomcat server.xml file.
The company also had a PKCS#7 (.p7b) file and a chain file that is a .p7c file 
type.
Research makes it seem like both Tomcat and ORDS require PKCS#12 but the 
company only provides me a PKCS7, and any attempts to convert it to PKCS#12 
don't work as a keyfile is not provided to us.

Thanks for any help, James.



James Boggs | Senior DBA/SA | Mobile: 571-337-0535
"Trust, Integrity, Loyalty to Our Customers, Employees and Partner"
VA Verified (SDVOSB) | SBA Certified 8(a) | SB | SDB | MBE/DBE (MD) | SWaM (VA)
ISO 9001:2015|ISO/IEC 2-1:2018|ISO/IEC 27001:2013|
CMMI-DEV Level 3 Appraised |
GSA Schedule Holder: IT-70#:GS35F237AA
GSA 8(a) STARS III#: 47QTCB21D0030
CIO-SP3 Contract#: HHSN316201800033W(SDVOSB)
CIO-SP3 Contract#: HHSN316201800054W(HUBZone)
Seaport-NXG Contract#: N00178-19-D-8420
eFAST Contract#: DTFAWA-13-A-00074
[cid:image001.png@01D946CC.29AC9830]
[cid:image002.png@01D946CC.29AC9830]
Fax: 410-814-7539 
|jbo...@rightdirectiontech.com
RightDirection Technology Solutions, LLC | 300 E. Lombard St Suite 840 | 
Baltimore, MD 21202 |
www.rightdirectiontech.com

Please Go Green! Please do not print this e-mail unless necessary.

Notice of Confidentiality: This e-mail and any attachments thereto, are 
intended only for use by the addressee(s) named herein and may contain legally 
privileged and/or confidential information. If you are not the intended 
recipient of this e-mail (or the person responsible for delivering this 
document to the intended recipient), you are hereby notified that any 
dissemination, distribution, printing or copying of this e-mail, and any 
attachment thereto, is strictly prohibited. If you have received this e-mail in 
error, please respond to the individual sending the message, and permanently 
delete the original and any copy of any e-mail and printout thereof.



Re: Got a customer who's paranoid about Manager

2023-02-22 Thread Alex O'Ree
is removing the manager war an option for you? i don't think it's required
for operation. you could also rename it so that it's in a different url
path than the default

On Wed, Feb 22, 2023 at 12:58 PM Mark Thomas  wrote:

> On 22/02/2023 17:49, James H. H. Lampert wrote:
> > On 2/22/23 9:23 AM, Mark Thomas wrote:
> >> Fire them and hire a security consultant with a proper understanding
> >> of risk?
> >
> > Pardon my Yiddish, but "Fun dayn moyl in Gots oyern." (From your mouth
> > to God's ears. Such a colorful language.)
> >
> > But just because you're paranoid doesn't mean they're not out to get you.
> >
> > So just add
> >
> >denyStatus="404"
> > to the RemoteAddrValve?
>
> Exactly.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Got a customer who's paranoid about Manager

2023-02-22 Thread Mark Thomas

On 22/02/2023 17:49, James H. H. Lampert wrote:

On 2/22/23 9:23 AM, Mark Thomas wrote:
Fire them and hire a security consultant with a proper understanding 
of risk?


Pardon my Yiddish, but "Fun dayn moyl in Gots oyern." (From your mouth 
to God's ears. Such a colorful language.)


But just because you're paranoid doesn't mean they're not out to get you.

So just add

   denyStatus="404"
to the RemoteAddrValve?


Exactly.

Mark

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



Re: Got a customer who's paranoid about Manager

2023-02-22 Thread James H. H. Lampert

On 2/22/23 9:23 AM, Mark Thomas wrote:
Fire them and hire a security consultant with a proper understanding of 
risk?


Pardon my Yiddish, but "Fun dayn moyl in Gots oyern." (From your mouth 
to God's ears. Such a colorful language.)


But just because you're paranoid doesn't mean they're not out to get you.

So just add

  denyStatus="404"
to the RemoteAddrValve?

--
JHHL

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



Re: Database related performance degradation after upgrading from Tomcat 9.0.33 to Tomcat 9.0.69

2023-02-22 Thread Mark Thomas

On 22/02/2023 04:58, Konstantin Kolinko wrote:

ср, 22 февр. 2023 г. в 01:31, Artur Tomusiak - Hannon Hill
:


After upgrading from Tomcat 9.0.33 to Tomcat 9.0.69,


Note that using a binary search (bisection) one could limit the version range.


Relevant version information is:

9.0.71 - DBCP f131286  2.10.0-SNAPSHOT  2022-12-30
9.0.53 - DBCP 2abdb49  2.9.02021-08-03
9.0.42 - DBCP e24196a  2.9.0-SNAPSHOT   2021-01-15
9.0.38 - DBCP 6d232e5  2.8.0-SNAPSHOT   2020-08-11
9.0.30 - DBCP a363906  2.8.0-SNAPSHOT   2019-12-06



Alternatively, it is possible to reconfigure the pool to use Apache
Commons DBCP 2 and Apache Commons Pool 2 directly (instead of
package-renamed version used by Tomcat), and bisect their version
ranges.


Given Tomcat's tendency to update to specific commits rather than 
releases, bisecting Tomcat versions is probably easier.


Does your database provide any form of debug logging? The additional 
commands should be easy to spot in such a log.


Changes to autoCommit and readOnly handling in 9.0.38 could result in 
additional database calls. See 
https://issues.apache.org/jira/browse/DBCP-558


I don't see anything else obvious in the change history but a debug log 
for the connection is likely to be the quickest way to see what is going on.


Mark

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



Re: Got a customer who's paranoid about Manager

2023-02-22 Thread Mark Thomas

On 22/02/2023 17:10, James H. H. Lampert wrote:
We've got a customer -- the same one that was our first test of a 
working RemoteAddrValve -- whose security consultant is complaining that 
a potential intruder can confirm the *existence* of the manager context 
(because it returns a 403, as opposed to, say, a 404).


Any ideas?


Fire them and hire a security consultant with a proper understanding of 
risk?


Alternatively, you can use denyStatus="404" on the RemoteAddrValve. That 
attribute should be available in all versions of all currently supported 
Tomcat releases (it was added back in 2011). You can set it to any value 
valid for use with HttpServletResponse.sendError(int).


Mark

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



Got a customer who's paranoid about Manager

2023-02-22 Thread James H. H. Lampert
We've got a customer -- the same one that was our first test of a 
working RemoteAddrValve -- whose security consultant is complaining that 
a potential intruder can confirm the *existence* of the manager context 
(because it returns a 403, as opposed to, say, a 404).


Any ideas?

--
JHHL

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