RE: OT: hsts in Tomcat 9.0.73
Thanks Peter,
I still do not see the hsts header. I'm wondering if this is causing it.
SSL certificate verify result: self signed certificate in certificate chain
(19), continuing anyway.
I don't know why it's complaining as the certificate for Tomcat is not a
self-signed certificate.
Thanks,
Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His
Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are
not the addressee or authorized to receive this for the addressee, you must not
use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
> -Original Message-
> From: l...@kreuser.name
> Sent: Friday, April 21, 2023 5:32 PM
> To: Tomcat Users List
> Subject: Re: OT: hsts in Tomcat 9.0.73
>
> Jon,
>
>
> Oh, I see there is a redirect. I do see a similar behavior on redirects (302)
> or
> auth (401 eg. on the manager app). But HSTS on 200, 404 or 403.
>
> What happens if you call "/c/portal/license" ?
>
> Peter
>
> > Am 21.04.2023 um 23:05 schrieb jonmcalexan...@wellsfargo.com.invalid
> :
> >
> > Here is the output from a powershell command:
> >
> > Invoke-WebRequest -Uri https://ldvwa00a0010.wellsfargo.com:8443
> > -MaximumRedirection 0 | Select-Object -ExpandProperty Headers
> >
> > KeyValue
> > ----
> > X-Content-Type-Options nosniff
> > X-Frame-OptionsSAMEORIGIN
> > X-XSS-Protection 1
> > Set-Cookie JSESSIONID=E60F2DA9B666966565C8076FE5C47226.wfig1;
> Path=/; Secure; HttpOnly,COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069
> 23:39:55 GMT; Path=/; Secure; HttpOnly,GU...
> > Location
> https://ldvwa00a0010.wellsfargo.com:8443/c/portal/license
> > Content-Length 0
> > Date Fri, 21 Apr 2023 20:57:47 GMT
> > Keep-Alive timeout=60
> > Connection keep-alive
> >
> >
> > Here is curl
> >
> > curl -ikl --verbose
> >
> https://urldefense.com/v3/__https://HOST:8443__;!!F9svGWnIaVPGSwU!u
> DCA
> > GHZL-GxWlS7CM9oz5r-
> Ix6vcjidfq9Xc7ATcRPT98_ehOMc8VHsjrk4wxDJ158oYIdARw8
> > VKJ_UMK-M5PSM$ > op.txt
> >
> > % Total% Received % Xferd Average Speed TimeTime Time
> > Current
> > Dload Upload Total SpentLeft Speed
> > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> > 0* Trying IP:8443...
> > * TCP_NODELAY set
> > * Connected to HOST (IP) port 8443 (#0)
> > * ALPN, offering h2
> > * ALPN, offering http/1.1
> > } [5 bytes data]
> > * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> > } [512 bytes data]
> > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> > 0* TLSv1.3 (IN), TLS
> handshake, Server hello (2):
> > { [85 bytes data]
> > * TLSv1.2 (IN), TLS handshake, Certificate (11):
> > { [3806 bytes data]
> > * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
> > { [300 bytes data]
> > * TLSv1.2 (IN), TLS handshake, Server finished (14):
> > { [4 bytes data]
> > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> > } [37 bytes data]
> > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
> > } [1 bytes data]
> > * TLSv1.2 (OUT), TLS handshake, Finished (20):
> > } [16 bytes data]
> > * TLSv1.2 (IN), TLS handshake, Finished (20):
> > { [16 bytes data]
> > * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> > * ALPN, server did not agree to a protocol
> > * Server certificate:
> > * subject: C=US; O=; OU=; CN=
> > * start date: Aug 10 16:35:12 2022 GMT
> > * expire date: Aug 9 16:35:12 2024 GMT
> > * issuer: C=US; O=; OU=; CN=
> > * SSL certificate verify result: self signed certificate in certificate
> > chain (19),
> continuing anyway.
> > 0 00 00 0 0 0 --:--:-- 0:00:02 --:--:--
> > 0} [5 bytes data]
> >> GET / HTTP/1.1
> >> Host: HOST:8443
> >> User-Agent: curl/7.65.3
> >> Accept: */*
> >>
> > { [5 bytes data]
> > * Mark bundle as not supporting multiuse < HTTP/1.1 302 <
> > X-Content-Type-Options: nosniff < X-Frame-Options: SAMEORIGIN <
> > X-XSS-Protection: 1 < Set-Cookie:
> > JSESSIONID=CB5FFB977D92D0CB953AE651014CD048.wfig1; Path=/; Secure;
> > HttpOnly < Set-Cookie: COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069
> > 23:42:52 GMT; Path=/; Secure; HttpOnly < Set-Cookie:
> > GUEST_LANGUAGE_ID=en_US; Expires=Tue, 03 Dec 2069 23:42:52 GMT;
> > Path=/; Secure; HttpOnly < Location:
> > https://urldefense.com/v3/__https://HOST:8443/c/portal/license__;!!F9s
> > vGWnIaVPGSwU!uDCAGHZL-GxWlS7CM9oz5r-
>
Re: OT: hsts in Tomcat 9.0.73
Jon,
Oh, I see there is a redirect. I do see a similar behavior on redirects (302)
or auth (401 eg. on the manager app). But HSTS on 200, 404 or 403.
What happens if you call "/c/portal/license" ?
Peter
> Am 21.04.2023 um 23:05 schrieb jonmcalexan...@wellsfargo.com.invalid
> :
>
> Here is the output from a powershell command:
>
> Invoke-WebRequest -Uri https://ldvwa00a0010.wellsfargo.com:8443
> -MaximumRedirection 0 | Select-Object -ExpandProperty Headers
>
> KeyValue
> ----
> X-Content-Type-Options nosniff
> X-Frame-OptionsSAMEORIGIN
> X-XSS-Protection 1
> Set-Cookie JSESSIONID=E60F2DA9B666966565C8076FE5C47226.wfig1;
> Path=/; Secure; HttpOnly,COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069
> 23:39:55 GMT; Path=/; Secure; HttpOnly,GU...
> Location
> https://ldvwa00a0010.wellsfargo.com:8443/c/portal/license
> Content-Length 0
> Date Fri, 21 Apr 2023 20:57:47 GMT
> Keep-Alive timeout=60
> Connection keep-alive
>
>
> Here is curl
>
> curl -ikl --verbose https://HOST:8443 > op.txt
>
> % Total% Received % Xferd Average Speed TimeTime Time Current
> Dload Upload Total SpentLeft Speed
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0* Trying IP:8443...
> * TCP_NODELAY set
> * Connected to HOST (IP) port 8443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> } [5 bytes data]
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> } [512 bytes data]
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0* TLSv1.3 (IN), TLS handshake, Server hello (2):
> { [85 bytes data]
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> { [3806 bytes data]
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
> { [300 bytes data]
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
> { [4 bytes data]
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> } [37 bytes data]
> * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
> } [1 bytes data]
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
> } [16 bytes data]
> * TLSv1.2 (IN), TLS handshake, Finished (20):
> { [16 bytes data]
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> * ALPN, server did not agree to a protocol
> * Server certificate:
> * subject: C=US; O=; OU=; CN=
> * start date: Aug 10 16:35:12 2022 GMT
> * expire date: Aug 9 16:35:12 2024 GMT
> * issuer: C=US; O=; OU=; CN=
> * SSL certificate verify result: self signed certificate in certificate
> chain (19), continuing anyway.
> 0 00 00 0 0 0 --:--:-- 0:00:02 --:--:--
> 0} [5 bytes data]
>> GET / HTTP/1.1
>> Host: HOST:8443
>> User-Agent: curl/7.65.3
>> Accept: */*
>>
> { [5 bytes data]
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 302
> < X-Content-Type-Options: nosniff
> < X-Frame-Options: SAMEORIGIN
> < X-XSS-Protection: 1
> < Set-Cookie: JSESSIONID=CB5FFB977D92D0CB953AE651014CD048.wfig1; Path=/;
> Secure; HttpOnly
> < Set-Cookie: COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069 23:42:52 GMT;
> Path=/; Secure; HttpOnly
> < Set-Cookie: GUEST_LANGUAGE_ID=en_US; Expires=Tue, 03 Dec 2069 23:42:52 GMT;
> Path=/; Secure; HttpOnly
> < Location: https://HOST:8443/c/portal/license
> < Content-Length: 0
> < Date: Fri, 21 Apr 2023 21:00:44 GMT
> <
> 0 00 00 0 0 0 --:--:-- 0:00:03 --:--:-- 0
> * Connection #0 to host left intact
>
> Thanks,
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Senior Infrastructure Engineer
> Asst. Vice President
> He/His
>
> Middleware Product Engineering
> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
> This message may contain confidential and/or privileged information. If you
> are not the addressee or authorized to receive this for the addressee, you
> must not use, copy, disclose, or take any action based on this message or any
> information herein. If you have received this message in error, please advise
> the sender immediately by reply e-mail and delete this message. Thank you for
> your cooperation.
>
>
>> -Original Message-
>> From: Christopher Schultz
>> Sent: Friday, April 21, 2023 1:17 PM
>> To: users@tomcat.apache.org
>> Subject: Re: OT: hsts in Tomcat 9.0.73
>>
>> Jon,
>>
>> On 4/21/23 11:47, jonmcalexan...@wellsfargo.com.INVALID wrote:
>>> Thank you Olaf, however, the connection was made over https directly
>>> to Tomcat on port 8443.
>> Sample curl with secrets removed?
>>
>> -chris
>>
-Original Message-
From: Olaf Kock
Sent: Friday, April 21, 2023 1:48 AM
To: users@tomcat.apache.org
Subject: Re: OT: hsts in Tomcat 9.0.73
Am 21.04.23 um 07:03
RE: OT: hsts in Tomcat 9.0.73
Here is the output from a powershell command:
Invoke-WebRequest -Uri https://ldvwa00a0010.wellsfargo.com:8443
-MaximumRedirection 0 | Select-Object -ExpandProperty Headers
KeyValue
----
X-Content-Type-Options nosniff
X-Frame-OptionsSAMEORIGIN
X-XSS-Protection 1
Set-Cookie JSESSIONID=E60F2DA9B666966565C8076FE5C47226.wfig1;
Path=/; Secure; HttpOnly,COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069 23:39:55
GMT; Path=/; Secure; HttpOnly,GU...
Location https://ldvwa00a0010.wellsfargo.com:8443/c/portal/license
Content-Length 0
Date Fri, 21 Apr 2023 20:57:47 GMT
Keep-Alive timeout=60
Connection keep-alive
Here is curl
curl -ikl --verbose https://HOST:8443 > op.txt
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Trying IP:8443...
* TCP_NODELAY set
* Connected to HOST (IP) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [85 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3806 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; O=; OU=; CN=
* start date: Aug 10 16:35:12 2022 GMT
* expire date: Aug 9 16:35:12 2024 GMT
* issuer: C=US; O=; OU=; CN=
* SSL certificate verify result: self signed certificate in certificate chain
(19), continuing anyway.
0 00 00 0 0 0 --:--:-- 0:00:02 --:--:-- 0}
[5 bytes data]
> GET / HTTP/1.1
> Host: HOST:8443
> User-Agent: curl/7.65.3
> Accept: */*
>
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 302
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1
< Set-Cookie: JSESSIONID=CB5FFB977D92D0CB953AE651014CD048.wfig1; Path=/;
Secure; HttpOnly
< Set-Cookie: COOKIE_SUPPORT=true; Expires=Tue, 03 Dec 2069 23:42:52 GMT;
Path=/; Secure; HttpOnly
< Set-Cookie: GUEST_LANGUAGE_ID=en_US; Expires=Tue, 03 Dec 2069 23:42:52 GMT;
Path=/; Secure; HttpOnly
< Location: https://HOST:8443/c/portal/license
< Content-Length: 0
< Date: Fri, 21 Apr 2023 21:00:44 GMT
<
0 00 00 0 0 0 --:--:-- 0:00:03 --:--:-- 0
* Connection #0 to host left intact
Thanks,
Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His
Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are
not the addressee or authorized to receive this for the addressee, you must not
use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
> -Original Message-
> From: Christopher Schultz
> Sent: Friday, April 21, 2023 1:17 PM
> To: users@tomcat.apache.org
> Subject: Re: OT: hsts in Tomcat 9.0.73
>
> Jon,
>
> On 4/21/23 11:47, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Thank you Olaf, however, the connection was made over https directly
> > to Tomcat on port 8443.
> Sample curl with secrets removed?
>
> -chris
>
> >> -Original Message-
> >> From: Olaf Kock
> >> Sent: Friday, April 21, 2023 1:48 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: OT: hsts in Tomcat 9.0.73
> >>
> >>
> >> Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID:
> >>> No, there is no error and no stack trace. Everything works, just the
> >>> hsts
> >> header isn't in the list of headers.
> >>>
> >> The lowest hanging fruit: HSTS is only defined on https - on http it
> >> doesn't have any meaning and Tomcat would be correct in not sending
> >> it (I haven't looked at the source if it does, but it should be easy
> >> to test)
> >>
> >> If you have a reverse proxy handling https & proxying through http,
> >> Tomcat might not know
RE: OT: hsts in Tomcat 9.0.73
Hey Peter, Yes, the context is ROOT as this app does have a ROOT component. Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: l...@kreuser.name > Sent: Friday, April 21, 2023 1:58 PM > To: Tomcat Users List > Subject: Re: OT: hsts in Tomcat 9.0.73 > > Jon, > > again, the Qualys Scanner usually does not know any other webcontexts > than root, manager and examples. So if you don't have a root context, it may > well end up in the woods and the result will not have a HSTS-Header. Can you > verify the requested resource? > > Best regards > > Peter > > > Am 21.04.2023 um 17:47 schrieb jonmcalexan...@wellsfargo.com.invalid > : > > > > Thank you Olaf, however, the connection was made over https directly to > Tomcat on port 8443. > > > > Thanks, > > > > Dream * Excel * Explore * Inspire > > Jon McAlexander > > Senior Infrastructure Engineer > > Asst. Vice President > > He/His > > > > Middleware Product Engineering > > Enterprise CIO | EAS | Middleware | Infrastructure Solutions > > > > 8080 Cobblestone Rd | Urbandale, IA 50322 > > MAC: F4469-010 > > Tel 515-988-2508 | Cell 515-988-2508 > > > > jonmcalexan...@wellsfargo.com > > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or any > information herein. If you have received this message in error, please advise > the sender immediately by reply e-mail and delete this message. Thank you > for your cooperation. > > > > > >> -Original Message- > >> From: Olaf Kock > >> Sent: Friday, April 21, 2023 1:48 AM > >> To: users@tomcat.apache.org > >> Subject: Re: OT: hsts in Tomcat 9.0.73 > >> > >> > >> Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID: > >>> No, there is no error and no stack trace. Everything works, just the > >>> hsts > >> header isn't in the list of headers. > >>> > >> The lowest hanging fruit: HSTS is only defined on https - on http it > >> doesn't have any meaning and Tomcat would be correct in not sending > >> it (I haven't looked at the source if it does, but it should be easy > >> to test) > >> > >> If you have a reverse proxy handling https & proxying through http, > >> Tomcat might not know that it'd be fine to send the header. (If that > >> is your case, there is the brute force "secure" attribute on the > >> connector > >> - use it only when there's no way to connect through http from > >> anywhere but your reverse proxy) > >> > >> This has bitten me a few times > >> > >> Olaf > >> > >> > >> - > >> 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: java.lang.InternalError: Unexpected CryptoAPI failure generating seed
That document is mostly about a corrupted install in Weblogic, but after that, it suggests making sure you are using the urandom (non-blocking) random number generator. If you're using the blocking RNG, it would explain why the issue is not easily repeatable. -Djava.security.egd=file:/dev/./urandom I can't recall if the format of that string is the same in Windows, but it should be similar. Tom On Fri, Apr 21, 2023 at 2:15 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Harri, > > On 4/21/23 04:39, Harri Pesonen wrote: > > No, I think that I have seen this only once now, but of course it might > have happened more than once. > > Googling says that other people have seen this as well, but very > randomly. > > Apparently the problem happens in Windows function, but JNI call does > not tell the reason for failure. > > This happened in AWS cloud, perhaps the server was busy or something. > > Or there is some kind of bug in JDK. > > Probably this would need JDK developer to look at. > > There might be solution here: > > https://support.oracle.com/knowledge/Middleware/1492450_1.html#FIX > > But I can't see it.  > > I can't see it, either; I'm not an Oracle customer. > > > If this is rare, and Tomcat can't really do anything about it, I would > say "monitor your servers and restart them if necessary." > > Sorry... it doesn't look like we really have any other choices, here. > > -chris > > > -Original Message- > > From: Christopher Schultz > > Sent: torstai 20. huhtikuuta 2023 19.35 > > To: users@tomcat.apache.org > > Subject: Re: java.lang.InternalError: Unexpected CryptoAPI failure > generating seed > > > > Harri, > > > > On 4/18/23 07:43, Harri Pesonen wrote: > >> Hello, we have: > >> > >> Tomcat/8.5.83 > >> Windows Server 2016 > >> java.version=11.0.12 > >> java.vendor=Azul Systems, Inc. > >> sun.arch.data.model=64 > >> > >> Sometimes Tomcat fails to start our application because of this error: > >> > >> 06:45:58.230 ERR> (Catalina-startStop-1) > (org.apache.catalina.startup.HostConfig#deployDescriptors) Error waiting > for multi-thread deployment of deployment descriptors to complete > >> java.util.concurrent.ExecutionException: java.lang.InternalError: > Unexpected CryptoAPI failure generating seed > >>at > java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) > >>at > java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) > >>at > org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:594) > >>at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) > >>at > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1610) > >>at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:318) > >>at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > >>at > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) > >>at > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) > >>at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:962) > >>at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:833) > >>at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > >>at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1427) > >>at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1417) > >>at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > >>at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>at > java.base/java.lang.Thread.run(Thread.java:829) > >> Caused by: java.lang.InternalError: Unexpected CryptoAPI failure > generating seed > >>at > java.base/sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62) > >>at > java.base/sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144) > >>at > java.base/sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:204) > >>at > java.base/sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:222) > >>at >
Re: OT: hsts in Tomcat 9.0.73
Jon, again, the Qualys Scanner usually does not know any other webcontexts than root, manager and examples. So if you don't have a root context, it may well end up in the woods and the result will not have a HSTS-Header. Can you verify the requested resource? Best regards Peter > Am 21.04.2023 um 17:47 schrieb jonmcalexan...@wellsfargo.com.invalid > : > > Thank you Olaf, however, the connection was made over https directly to > Tomcat on port 8443. > > Thanks, > > Dream * Excel * Explore * Inspire > Jon McAlexander > Senior Infrastructure Engineer > Asst. Vice President > He/His > > Middleware Product Engineering > Enterprise CIO | EAS | Middleware | Infrastructure Solutions > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or any > information herein. If you have received this message in error, please advise > the sender immediately by reply e-mail and delete this message. Thank you for > your cooperation. > > >> -Original Message- >> From: Olaf Kock >> Sent: Friday, April 21, 2023 1:48 AM >> To: users@tomcat.apache.org >> Subject: Re: OT: hsts in Tomcat 9.0.73 >> >> >> Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID: >>> No, there is no error and no stack trace. Everything works, just the hsts >> header isn't in the list of headers. >>> >> The lowest hanging fruit: HSTS is only defined on https - on http it doesn't >> have any meaning and Tomcat would be correct in not sending it (I haven't >> looked at the source if it does, but it should be easy to test) >> >> If you have a reverse proxy handling https & proxying through http, Tomcat >> might not know that it'd be fine to send the header. (If that is your case, >> there is the brute force "secure" attribute on the connector >> - use it only when there's no way to connect through http from anywhere >> but your reverse proxy) >> >> This has bitten me a few times >> >> Olaf >> >> >> - >> 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: [OT] MySQL Connection settings
in general. something all purpose to get started with On Fri, Apr 21, 2023, 14:17 Christopher Schultz < ch...@christopherschultz.net> wrote: > Kevin, > > On 4/21/23 09:35, Kevin Huntly wrote: > > I'm not a DBA nor do I pretend to be, so I'm asking what everyone's > > thoughts are on MySQL connection string settings? What are the best > options > > to use, what options are absolutely required, etc? > > Just ... in general? Or do you have a specific use-case? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: OT: hsts in Tomcat 9.0.73
Jon, On 4/21/23 11:47, jonmcalexan...@wellsfargo.com.INVALID wrote: Thank you Olaf, however, the connection was made over https directly to Tomcat on port 8443. Sample curl with secrets removed? -chris -Original Message- From: Olaf Kock Sent: Friday, April 21, 2023 1:48 AM To: users@tomcat.apache.org Subject: Re: OT: hsts in Tomcat 9.0.73 Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID: No, there is no error and no stack trace. Everything works, just the hsts header isn't in the list of headers. The lowest hanging fruit: HSTS is only defined on https - on http it doesn't have any meaning and Tomcat would be correct in not sending it (I haven't looked at the source if it does, but it should be easy to test) If you have a reverse proxy handling https & proxying through http, Tomcat might not know that it'd be fine to send the header. (If that is your case, there is the brute force "secure" attribute on the connector - use it only when there's no way to connect through http from anywhere but your reverse proxy) This has bitten me a few times Olaf - 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: [OT] MySQL Connection settings
Kevin, On 4/21/23 09:35, Kevin Huntly wrote: I'm not a DBA nor do I pretend to be, so I'm asking what everyone's thoughts are on MySQL connection string settings? What are the best options to use, what options are absolutely required, etc? Just ... in general? Or do you have a specific use-case? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.InternalError: Unexpected CryptoAPI failure generating seed
Harri, On 4/21/23 04:39, Harri Pesonen wrote: No, I think that I have seen this only once now, but of course it might have happened more than once. Googling says that other people have seen this as well, but very randomly. Apparently the problem happens in Windows function, but JNI call does not tell the reason for failure. This happened in AWS cloud, perhaps the server was busy or something. Or there is some kind of bug in JDK. Probably this would need JDK developer to look at. There might be solution here: https://support.oracle.com/knowledge/Middleware/1492450_1.html#FIX But I can't see it.  I can't see it, either; I'm not an Oracle customer. If this is rare, and Tomcat can't really do anything about it, I would say "monitor your servers and restart them if necessary." Sorry... it doesn't look like we really have any other choices, here. -chris -Original Message- From: Christopher Schultz Sent: torstai 20. huhtikuuta 2023 19.35 To: users@tomcat.apache.org Subject: Re: java.lang.InternalError: Unexpected CryptoAPI failure generating seed Harri, On 4/18/23 07:43, Harri Pesonen wrote: Hello, we have: Tomcat/8.5.83 Windows Server 2016 java.version=11.0.12 java.vendor=Azul Systems, Inc. sun.arch.data.model=64 Sometimes Tomcat fails to start our application because of this error: 06:45:58.230 ERR> (Catalina-startStop-1) (org.apache.catalina.startup.HostConfig#deployDescriptors) Error waiting for multi-thread deployment of deployment descriptors to complete java.util.concurrent.ExecutionException: java.lang.InternalError: Unexpected CryptoAPI failure generating seed at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:594) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1610) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:318) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:962) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:833) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1427) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1417) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating seed at java.base/sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62) at java.base/sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144) at java.base/sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:204) at java.base/sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:222) at java.base/java.security.SecureRandom.nextBytes(SecureRandom.java:751) at java.base/java.security.SecureRandom.next(SecureRandom.java:808) at java.base/java.util.Random.nextInt(Random.java:329) at org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom(SessionIdGeneratorBase.java:290) at org.apache.catalina.util.SessionIdGeneratorBase.getRandomBytes(SessionIdGeneratorBase.java:222) at org.apache.catalina.util.StandardSessionIdGenerator.generateSessionId(StandardSessionIdGenerator.java:34) at org.apache.catalina.util.SessionIdGeneratorBase.generateSessionId(SessionIdGeneratorBase.java:214)
RE: OT: hsts in Tomcat 9.0.73
Thank you Olaf, however, the connection was made over https directly to Tomcat on port 8443. Thanks, Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Olaf Kock > Sent: Friday, April 21, 2023 1:48 AM > To: users@tomcat.apache.org > Subject: Re: OT: hsts in Tomcat 9.0.73 > > > Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID: > > No, there is no error and no stack trace. Everything works, just the hsts > header isn't in the list of headers. > > > The lowest hanging fruit: HSTS is only defined on https - on http it doesn't > have any meaning and Tomcat would be correct in not sending it (I haven't > looked at the source if it does, but it should be easy to test) > > If you have a reverse proxy handling https & proxying through http, Tomcat > might not know that it'd be fine to send the header. (If that is your case, > there is the brute force "secure" attribute on the connector > - use it only when there's no way to connect through http from anywhere > but your reverse proxy) > > This has bitten me a few times > > Olaf > > > - > 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
MySQL Connection settings
Hi Everyone, I'm not a DBA nor do I pretend to be, so I'm asking what everyone's thoughts are on MySQL connection string settings? What are the best options to use, what options are absolutely required, etc? Kevin Huntly Email: kmhun...@gmail.com Cell: 716/424-3311 -BEGIN GEEK CODE BLOCK- Version: 1.0 GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E--- W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+) PGP++(+++) t+ 5-- X-- R+ tv+ b++ DI++ D++ G++ e(+) h--- r+++ y+++* --END GEEK CODE BLOCK--
RE: java.lang.InternalError: Unexpected CryptoAPI failure generating seed
No, I think that I have seen this only once now, but of course it might have happened more than once. Googling says that other people have seen this as well, but very randomly. Apparently the problem happens in Windows function, but JNI call does not tell the reason for failure. This happened in AWS cloud, perhaps the server was busy or something. Or there is some kind of bug in JDK. Probably this would need JDK developer to look at. There might be solution here: https://support.oracle.com/knowledge/Middleware/1492450_1.html#FIX But I can't see it.  -Harri -Original Message- From: Christopher Schultz Sent: torstai 20. huhtikuuta 2023 19.35 To: users@tomcat.apache.org Subject: Re: java.lang.InternalError: Unexpected CryptoAPI failure generating seed Harri, On 4/18/23 07:43, Harri Pesonen wrote: > Hello, we have: > > Tomcat/8.5.83 > Windows Server 2016 > java.version=11.0.12 > java.vendor=Azul Systems, Inc. > sun.arch.data.model=64 > > Sometimes Tomcat fails to start our application because of this error: > > 06:45:58.230 ERR> (Catalina-startStop-1) > (org.apache.catalina.startup.HostConfig#deployDescriptors) Error waiting for > multi-thread deployment of deployment descriptors to complete > java.util.concurrent.ExecutionException: java.lang.InternalError: Unexpected > CryptoAPI failure generating seed > at > java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) > at > java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) > at > org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:594) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) > at > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1610) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:318) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > at > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) > at > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:962) > at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:833) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1427) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1417) > at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > java.base/java.lang.Thread.run(Thread.java:829) > Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating > seed > at > java.base/sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62) > at > java.base/sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144) > at > java.base/sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:204) > at > java.base/sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:222) > at > java.base/java.security.SecureRandom.nextBytes(SecureRandom.java:751) > at > java.base/java.security.SecureRandom.next(SecureRandom.java:808) > at > java.base/java.util.Random.nextInt(Random.java:329) > at > org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom(SessionIdGeneratorBase.java:290) > at > org.apache.catalina.util.SessionIdGeneratorBase.getRandomBytes(SessionIdGeneratorBase.java:222) > at > org.apache.catalina.util.StandardSessionIdGenerator.generateSessionId(StandardSessionIdGenerator.java:34) > at > org.apache.catalina.util.SessionIdGeneratorBase.generateSessionId(SessionIdGeneratorBase.java:214) > at > org.apache.catalina.util.SessionIdGeneratorBase.startInternal(SessionIdGeneratorBase.java:310) > at >
Re: OT: hsts in Tomcat 9.0.73
Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID: No, there is no error and no stack trace. Everything works, just the hsts header isn't in the list of headers. The lowest hanging fruit: HSTS is only defined on https - on http it doesn't have any meaning and Tomcat would be correct in not sending it (I haven't looked at the source if it does, but it should be easy to test) If you have a reverse proxy handling https & proxying through http, Tomcat might not know that it'd be fine to send the header. (If that is your case, there is the brute force "secure" attribute on the connector - use it only when there's no way to connect through http from anywhere but your reverse proxy) This has bitten me a few times Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
