Hi,
all my tasks have the same error:
“ERROR”,“Thread-1601”,“07/13/2015”,“00:30:00”,“”,"schedule task:DHCR
AE_Code_Update;peer not
authenticated;javax.net.ssl.SSLPeerUnverifiedException: peer not
authenticated
at
sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:421)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Lucee 4.5.1.022 final
Windows Server 2012 (6.2) 64bit
MichaOn Mon, Jul 13, 2015 at 5:18 PM, Michael Vornkahl < @Michael_Vornkahl> wrote:
Hi,
all my tasks have the same error:
“ERROR”,“Thread-1601”,“07/13/2015”,“00:30:00”,“”,"schedule task:DHCR
AE_Code_Update;peer not
authenticated;javax.net.ssl.SSLPeerUnverifiedException: peer not
authenticated
at
sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:421)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Lucee 4.5.1.022 final
Windows Server 2012 (6.2) 64bit
I’ve been asking the Lucee guys to prominently publicize any manual steps
that go along with an update, but I don’t think that idea got any traction
(since v5.x will do away with some of this manual stuff, supposedly).
Maybe it applies; maybe not. (Or maybe you just need to add the new? cert
to the keystore.)
Thanks,
JamieOn Mon, Jul 13, 2015 at 12:38 PM, Michael Vornkahl < @Michael_Vornkahl> wrote:
Hi,
is it possible, that my provider has changed the SSL-settings and this
caused the error?
M.
Am Montag, 13. Juli 2015 17:42:07 UTC+2 schrieb Michael Vornkahl:
Via the admin page → update …
Am Montag, 13. Juli 2015 17:24:18 UTC+2 schrieb Micha:
Hi,
all my tasks have the same error:
“ERROR”,“Thread-1601”,“07/13/2015”,“00:30:00”,“”,"schedule task:DHCR
AE_Code_Update;peer not
authenticated;javax.net.ssl.SSLPeerUnverifiedException: peer not
authenticated
at
sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:421)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at
lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Lucee 4.5.1.022 final
Windows Server 2012 (6.2) 64bit
Hi,
all my tasks have the same error:
“ERROR”,“Thread-1601”,“07/13/2015”,“00:30:00”,“”,"schedule task:DHCR
AE_Code_Update;peer not
authenticated;javax.net.ssl.SSLPeerUnverifiedException: peer not
authenticated
at
sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:421)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at
lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Lucee 4.5.1.022 final
Windows Server 2012 (6.2) 64bit
Hi Jamie,
I’ve update the jars as you described it above, but this doesn’t solve my
problems.
No I get the following error:
“ERROR”,“Thread-58”,“07/14/2015”,“16:27:53”,“”,"schedule task:Anzahl neu
Erfassungen;Connection reset;java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Thank you for your help
MichaelAm Dienstag, 14. Juli 2015 15:09:24 UTC+2 schrieb Jamie Jackson:
Yes, the Jar changes I mentioned are the second half of the fix for (most)
NSI problems. You already did the first half of that fix with the
auto-updater.
In other words, try what’s in that comment I linked, but you won’t be able
to run that script directly in windows (since it’s a Linux shell script).
Instead, just follow the spirit of the script (the wgets are simply
download commands).
The bottom line is that you are to replace three Jar files with new ones.
On Jul 14, 2015 1:01 AM, “Michael Vornkahl” <michael.v...@gmail.com <javascript:>> wrote:
Hi,
@ Jamie: Is this working on windows server 2012?
@ all: My provider told me, that it could be, that Lucee has a problem
with SNI.
My tasks are running without problems under http, but not under https. I
found dome older hinta to SNI problems, but couldn’t find a solution.
@ all: My provider told me, that it could be, that Lucee has a problem with SNI.
My tasks are running without problems under http, but not under https. I found dome older hinta to SNI problems, but couldn’t find a solution.
Did you remove the old jars and restart Lucee, by the way?
Thanks,
JamieOn Tue, Jul 14, 2015 at 10:30 AM, Michael Vornkahl < @Michael_Vornkahl> wrote:
Hi Jamie,
I’ve update the jars as you described it above, but this doesn’t solve my
problems.
No I get the following error:
“ERROR”,“Thread-58”,“07/14/2015”,“16:27:53”,“”,"schedule task:Anzahl neu
Erfassungen;Connection reset;java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Thank you for your help
Michael
Am Dienstag, 14. Juli 2015 15:09:24 UTC+2 schrieb Jamie Jackson:
Yes, the Jar changes I mentioned are the second half of the fix for
(most) NSI problems. You already did the first half of that fix with the
auto-updater.
In other words, try what’s in that comment I linked, but you won’t be
able to run that script directly in windows (since it’s a Linux shell
script). Instead, just follow the spirit of the script (the wgets are
simply download commands).
The bottom line is that you are to replace three Jar files with new ones.
On Jul 14, 2015 1:01 AM, “Michael Vornkahl” michael.v...@gmail.com wrote:
Hi,
@ Jamie: Is this working on windows server 2012?
@ all: My provider told me, that it could be, that Lucee has a problem
with SNI.
My tasks are running without problems under http, but not under https. I
found dome older hinta to SNI problems, but couldn’t find a solution.
Yes, the Jar changes I mentioned are the second half of the fix for (most)
NSI problems. You already did the first half of that fix with the
auto-updater.
In other words, try what’s in that comment I linked, but you won’t be able
to run that script directly in windows (since it’s a Linux shell script).
Instead, just follow the spirit of the script (the wgets are simply
download commands).
The bottom line is that you are to replace three Jar files with new ones.On Jul 14, 2015 1:01 AM, “Michael Vornkahl” <@Michael_Vornkahl> wrote:
Hi,
@ Jamie: Is this working on windows server 2012?
@ all: My provider told me, that it could be, that Lucee has a problem
with SNI.
My tasks are running without problems under http, but not under https. I
found dome older hinta to SNI problems, but couldn’t find a solution.
Yes, I rebooted the server.
After disabling SNI everything worked fine.
So I’m sure that it wasn’t caused by the lucee update. I think, lucee has a
problem with SNI and https and scheduled tasks.
Maybe someone could confirm this.
M.Am Dienstag, 14. Juli 2015 18:22:39 UTC+2 schrieb Jamie Jackson:
Hi Michael,
Did you remove the old jars and restart Lucee, by the way?
Thanks,
Jamie
On Tue, Jul 14, 2015 at 10:30 AM, Michael Vornkahl <michael.v...@gmail.com <javascript:>> wrote:
Hi Jamie,
I’ve update the jars as you described it above, but this doesn’t solve my
problems.
No I get the following error:
“ERROR”,“Thread-58”,“07/14/2015”,“16:27:53”,“”,"schedule task:Anzahl neu
Erfassungen;Connection reset;java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at
lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Thank you for your help
Michael
Am Dienstag, 14. Juli 2015 15:09:24 UTC+2 schrieb Jamie Jackson:
Yes, the Jar changes I mentioned are the second half of the fix for
(most) NSI problems. You already did the first half of that fix with the
auto-updater.
In other words, try what’s in that comment I linked, but you won’t be
able to run that script directly in windows (since it’s a Linux shell
script). Instead, just follow the spirit of the script (the wgets are
simply download commands).
The bottom line is that you are to replace three Jar files with new ones.
On Jul 14, 2015 1:01 AM, “Michael Vornkahl” michael.v...@gmail.com wrote:
Hi,
@ Jamie: Is this working on windows server 2012?
@ all: My provider told me, that it could be, that Lucee has a problem
with SNI.
My tasks are running without problems under http, but not under https.
I found dome older hinta to SNI problems, but couldn’t find a solution.
kliakos had lingering problems with a cert, even after patching, but his
error was different. [LDEV-292] - Lucee
Does the SNI cert work with a straight cfhttp call? If not, then we’ll know
it’s unrelated to cfschedule.On Jul 15, 2015 4:44 AM, “Michael Vornkahl” <@Michael_Vornkahl> wrote:
Yes, I rebooted the server.
After disabling SNI everything worked fine.
So I’m sure that it wasn’t caused by the lucee update. I think, lucee has
a problem with SNI and https and scheduled tasks.
Maybe someone could confirm this.
M.
Am Dienstag, 14. Juli 2015 18:22:39 UTC+2 schrieb Jamie Jackson:
Hi Michael,
Did you remove the old jars and restart Lucee, by the way?
Hi Jamie,
I’ve update the jars as you described it above, but this doesn’t solve
my problems.
No I get the following error:
“ERROR”,“Thread-58”,“07/14/2015”,“16:27:53”,“”,"schedule task:Anzahl neu
Erfassungen;Connection reset;java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at
lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Thank you for your help
Michael
Am Dienstag, 14. Juli 2015 15:09:24 UTC+2 schrieb Jamie Jackson:
Yes, the Jar changes I mentioned are the second half of the fix for
(most) NSI problems. You already did the first half of that fix with the
auto-updater.
In other words, try what’s in that comment I linked, but you won’t be
able to run that script directly in windows (since it’s a Linux shell
script). Instead, just follow the spirit of the script (the wgets are
simply download commands).
The bottom line is that you are to replace three Jar files with new
ones.
On Jul 14, 2015 1:01 AM, “Michael Vornkahl” michael.v...@gmail.com wrote:
Hi,
@ Jamie: Is this working on windows server 2012?
@ all: My provider told me, that it could be, that Lucee has a problem
with SNI.
My tasks are running without problems under http, but not under https.
I found dome older hinta to SNI problems, but couldn’t find a solution.
Sorry,
I couldn’t verify if cfhttp is working.
We changed the SNI-settings and I couldn’t switch back, because it’s a
productive server, hosted by provider.
M.Am Mittwoch, 15. Juli 2015 14:06:43 UTC+2 schrieb Jamie Jackson:
kliakos had lingering problems with a cert, even after patching, but his
error was different. [LDEV-292] - Lucee
Does the SNI cert work with a straight cfhttp call? If not, then we’ll
know it’s unrelated to cfschedule.
On Jul 15, 2015 4:44 AM, “Michael Vornkahl” <michael.v...@gmail.com <javascript:>> wrote:
Yes, I rebooted the server.
After disabling SNI everything worked fine.
So I’m sure that it wasn’t caused by the lucee update. I think, lucee has
a problem with SNI and https and scheduled tasks.
Maybe someone could confirm this.
M.
Am Dienstag, 14. Juli 2015 18:22:39 UTC+2 schrieb Jamie Jackson:
Hi Michael,
Did you remove the old jars and restart Lucee, by the way?
Hi Jamie,
I’ve update the jars as you described it above, but this doesn’t solve
my problems.
No I get the following error:
“ERROR”,“Thread-58”,“07/14/2015”,“16:27:53”,“”,"schedule task:Anzahl
neu Erfassungen;Connection reset;java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at
lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Thank you for your help
Michael
Am Dienstag, 14. Juli 2015 15:09:24 UTC+2 schrieb Jamie Jackson:
Yes, the Jar changes I mentioned are the second half of the fix for
(most) NSI problems. You already did the first half of that fix with the
auto-updater.
In other words, try what’s in that comment I linked, but you won’t be
able to run that script directly in windows (since it’s a Linux shell
script). Instead, just follow the spirit of the script (the wgets are
simply download commands).
The bottom line is that you are to replace three Jar files with new
ones.
On Jul 14, 2015 1:01 AM, “Michael Vornkahl” michael.v...@gmail.com wrote:
Hi,
@ Jamie: Is this working on windows server 2012?
@ all: My provider told me, that it could be, that Lucee has a
problem with SNI.
My tasks are running without problems under http, but not under
https. I found dome older hinta to SNI problems, but couldn’t find a
solution.
I’m experiencing the exact same issue now as Michael Vornkahl.
This is driving me crazy, second day now with issues with SNI.
I have patched Lucee to .23
Updated the jar files to version 4.5 of the httpclient.
Restarted everything
Still getting
“ERROR”,“Thread-11365”,“08/18/2015”,“22:06:00”,“”,"schedule
task:[TASKNAME];Connection reset;java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)On Thursday, July 16, 2015 at 11:12:53 AM UTC+2, Michael Vornkahl wrote:
Sorry,
I couldn’t verify if cfhttp is working.
We changed the SNI-settings and I couldn’t switch back, because it’s a
productive server, hosted by provider.
M.
Am Mittwoch, 15. Juli 2015 14:06:43 UTC+2 schrieb Jamie Jackson:
kliakos had lingering problems with a cert, even after patching, but his
error was different. [LDEV-292] - Lucee
Does the SNI cert work with a straight cfhttp call? If not, then we’ll
know it’s unrelated to cfschedule.
On Jul 15, 2015 4:44 AM, “Michael Vornkahl” michael.v...@gmail.com wrote:
Yes, I rebooted the server.
After disabling SNI everything worked fine.
So I’m sure that it wasn’t caused by the lucee update. I think, lucee
has a problem with SNI and https and scheduled tasks.
Maybe someone could confirm this.
M.
Am Dienstag, 14. Juli 2015 18:22:39 UTC+2 schrieb Jamie Jackson:
Hi Michael,
Did you remove the old jars and restart Lucee, by the way?
Hi Jamie,
I’ve update the jars as you described it above, but this doesn’t solve
my problems.
No I get the following error:
“ERROR”,“Thread-58”,“07/14/2015”,“16:27:53”,“”,"schedule task:Anzahl
neu Erfassungen;Connection reset;java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.execute(HTTPEngine4Impl.java:416)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl._invoke(HTTPEngine4Impl.java:252)
at
lucee.commons.net.http.httpclient4.HTTPEngine4Impl.get(HTTPEngine4Impl.java:112)
at lucee.commons.net.http.HTTPEngine.get(HTTPEngine.java:86)
at
lucee.runtime.schedule.ExecutionThread.execute(ExecutionThread.java:108)
at lucee.runtime.schedule.ExecutionThread.run(ExecutionThread.java:58)
"
Thank you for your help
Michael
Am Dienstag, 14. Juli 2015 15:09:24 UTC+2 schrieb Jamie Jackson:
Yes, the Jar changes I mentioned are the second half of the fix for
(most) NSI problems. You already did the first half of that fix with the
auto-updater.
In other words, try what’s in that comment I linked, but you won’t be
able to run that script directly in windows (since it’s a Linux shell
script). Instead, just follow the spirit of the script (the wgets are
simply download commands).
The bottom line is that you are to replace three Jar files with new
ones.
On Jul 14, 2015 1:01 AM, “Michael Vornkahl” michael.v...@gmail.com wrote:
Hi,
@ Jamie: Is this working on windows server 2012?
@ all: My provider told me, that it could be, that Lucee has a
problem with SNI.
My tasks are running without problems under http, but not under
https. I found dome older hinta to SNI problems, but couldn’t find a
solution.
I updated the jar files (to fix the wildcard issue) and everything worked
fine. However last week I enabled SNI on server2012 r2 w 4.5.1.023
installed and now my cfhttp call to https fails with a
This isn’t a huge deal for me as it’s a single cfhttp call which is part of
a manual process anyways so I’ll just give people a link. I’ll hope to see
the issue resolved in v5.>>>>
How does that work if there are several sites on the same server and all
of them are using http://localhost?
Can you provide some sort of proof of concept on how to do that?
Thanks!
–DavidOn 2015-09-23 12:12, Nando Breiter wrote:
I’ve worked around any and all issues with scheduled tasks running
over https in a particular app by reworking them to point to localhost
urls. Given that we can expect web servers to adapt to evolving ssl
standards more quickly than Lucee, that’s my current strategy - avoid
exposing the app engine to ssl.
Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland
On Wed, Sep 23, 2015 at 10:45 AM, David Eurenius <@David_Eurenius mailto:David_Eurenius> wrote:
Thanks Jay for chiming in.
This is a huge deal for us, but there are no activity in resolving
this. Which is worrying.
Using cfhttp with an SNI configuration must be more and more used
out there.
Scheduled tasks are something that must also be common.
I'm happy to answering any question to get this lifted and to get
this resolved.
Updated apache http jar-files, latest Lucee 4.5.1.023, windows
2012, IIS 8.5.
On Tuesday, September 22, 2015 at 7:22:26 PM UTC+2, Jay B wrote:
Just going to add a me too fwiw.
I updated the jar files (to fix the wildcard issue) and
everything worked fine. However last week I enabled SNI on
server2012 r2 w 4.5.1.023 installed and now my cfhttp call to
https fails with a
Connection reset;java.net <http://java.net>.SocketException:
Connection reset
This isn't a huge deal for me as it's a single cfhttp call
which is part of a manual process anyways so I'll just give
people a link. I'll hope to see the issue resolved in v5.
--
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany -
Get your ticket NOW - http://www.cfcamp.org/
---
You received this message because you are subscribed to the Google
Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to lucee@googlegroups.com
<mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/9df2121f-58b6-4ec5-8d72-248649e42c02%40googlegroups.com
<https://groups.google.com/d/msgid/lucee/9df2121f-58b6-4ec5-8d72-248649e42c02%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
–
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get
your ticket NOW - http://www.cfcamp.org/
I agree with David that this is a fairly big deal. We’ve just moved to SSL
only and I think a lot of people are heading that way. With the uptake of
IIS8, SNI is going to be more of an issue because why use multiple IPs when
SNI can do it for you.
That being said, the localhost solution seems to be the best option for
now.On Wednesday, September 23, 2015 at 4:39:01 AM UTC-6, Nando Breiter wrote:
What I’ve done is add unique parameters to scheduled task url to set the
datasources and paths necessary for it to work properly across multiple
domains, and consumed those parameters in a way that does not compromise
security - they don’t work from “the outside”. It took a bit of thought,
but I’m pleased with the outcome, because I’m no longer concerned that
critical scheduled tasks might fail in the future because of an ssl glitch.
Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland
How does that work if there are several sites on the same server and all
of them are using http://localhost?
Can you provide some sort of proof of concept on how to do that?
Thanks!
–David
On 2015-09-23 12:12, Nando Breiter wrote:
I’ve worked around any and all issues with scheduled tasks running over
https in a particular app by reworking them to point to localhost urls.
Given that we can expect web servers to adapt to evolving ssl standards
more quickly than Lucee, that’s my current strategy - avoid exposing the
app engine to ssl.
Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland
On Tuesday, September 22, 2015 at 7:22:26 PM UTC+2, Jay B wrote:
Just going to add a me too fwiw.
I updated the jar files (to fix the wildcard issue) and everything
worked fine. However last week I enabled SNI on server2012 r2 w 4.5.1.023
installed and now my cfhttp call to https fails with a
This isn’t a huge deal for me as it’s a single cfhttp call which is
part of a manual process anyways so I’ll just give people a link. I’ll hope
to see the issue resolved in v5.
–
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get
your ticket NOW - http://www.cfcamp.org/
What I’ve done is add unique parameters to scheduled task url to set the
datasources and paths necessary for it to work properly across multiple
domains, and consumed those parameters in a way that does not compromise
security - they don’t work from “the outside”. It took a bit of thought,
but I’m pleased with the outcome, because I’m no longer concerned that
critical scheduled tasks might fail in the future because of an ssl glitch.
Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland
How does that work if there are several sites on the same server and all
of them are using http://localhost?
Can you provide some sort of proof of concept on how to do that?
Thanks!
–David
On 2015-09-23 12:12, Nando Breiter wrote:
I’ve worked around any and all issues with scheduled tasks running over
https in a particular app by reworking them to point to localhost urls.
Given that we can expect web servers to adapt to evolving ssl standards
more quickly than Lucee, that’s my current strategy - avoid exposing the
app engine to ssl.
Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland
On Tuesday, September 22, 2015 at 7:22:26 PM UTC+2, Jay B wrote:
Just going to add a me too fwiw.
I updated the jar files (to fix the wildcard issue) and everything
worked fine. However last week I enabled SNI on server2012 r2 w 4.5.1.023
installed and now my cfhttp call to https fails with a
This isn’t a huge deal for me as it’s a single cfhttp call which is part
of a manual process anyways so I’ll just give people a link. I’ll hope to
see the issue resolved in v5.
–
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your
ticket NOW - http://www.cfcamp.org/
I’ve worked around any and all issues with scheduled tasks running over
https in a particular app by reworking them to point to localhost urls.
Given that we can expect web servers to adapt to evolving ssl standards
more quickly than Lucee, that’s my current strategy - avoid exposing the
app engine to ssl.
Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland
On Tuesday, September 22, 2015 at 7:22:26 PM UTC+2, Jay B wrote:
Just going to add a me too fwiw.
I updated the jar files (to fix the wildcard issue) and everything worked
fine. However last week I enabled SNI on server2012 r2 w 4.5.1.023
installed and now my cfhttp call to https fails with a
This isn’t a huge deal for me as it’s a single cfhttp call which is part
of a manual process anyways so I’ll just give people a link. I’ll hope to
see the issue resolved in v5.
–
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your
ticket NOW - http://www.cfcamp.org/
Thanks Jay for chiming in.
This is a huge deal for us, but there are no activity in resolving this.
Which is worrying.
Using cfhttp with an SNI configuration must be more and more used out there.
Scheduled tasks are something that must also be common.
I’m happy to answering any question to get this lifted and to get this
resolved.
Updated apache http jar-files, latest Lucee 4.5.1.023, windows 2012, IIS
8.5.On Tuesday, September 22, 2015 at 7:22:26 PM UTC+2, Jay B wrote:
Just going to add a me too fwiw.
I updated the jar files (to fix the wildcard issue) and everything worked
fine. However last week I enabled SNI on server2012 r2 w 4.5.1.023
installed and now my cfhttp call to https fails with a
This isn’t a huge deal for me as it’s a single cfhttp call which is part
of a manual process anyways so I’ll just give people a link. I’ll hope to
see the issue resolved in v5.
An ideal solution might often be the possibility to call a function from
cfschedule, rather than it being exclusively tied to an http request. I
would think that tasks are usually an internal affair - no need to call out
to another server, and no need to return a response either.
I still think that Lucee and/or Tomcat 8 is broken in this regard that
it’s not possible to execute scheduled tasks on 2 SSL sites sharing 1 IP
(SNI).
Is there a bug report filed for this? My impression is that the Lucee devs
rely on bug reports, and the more documentation you can provide in them,
the better the chance it will be acted on. A “broken” comment here may be
glanced at, but doesn’t really help get the issue resolved.
Again, one of the reasons I worked around issues with ssl by running my
scheduled tasks via localhost:8888 is that I anticipate that web servers
and browsers will adapt to evolving ssl standards much more quickly than
Lucee, simply because the Lucee devs are vastly outnumbered, not only by
developers upgrading and improving ssl, but by hackers trying to break each
improved version. The current SNI issue (if there is one) may be fixed,
only for another issue to crop up next year, breaking Lucee’s ssl
implementation again in a certain case.
I don’t want my scheduled task implementation exposed to this risk, so I
don’t run scheduled tasks over https.