[jira] [Commented] (TS-3235) PluginVC crashed with unrecognized event
[
https://issues.apache.org/jira/browse/TS-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287412#comment-14287412
]
portl4t commented on TS-3235:
-
Actually, I am not familiar with your business, before you call the Intercept
api, a continuation will be created with a mutex, may be this mutex is the key
point, meanwhile, I never use customer's thread before, why do you have to use
customer's thread?
PluginVC crashed with unrecognized event
Key: TS-3235
URL: https://issues.apache.org/jira/browse/TS-3235
Project: Traffic Server
Issue Type: Bug
Components: CPP API, HTTP, Plugins
Reporter: kang li
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: pluginvc-crash.diff
We are using atscppapi to create Intercept plugin.
From the coredump , that seems Continuation of the InterceptPlugin was
already been destroyed.
{code}
#0 0x00375ac32925 in raise () from /lib64/libc.so.6
#1 0x00375ac34105 in abort () from /lib64/libc.so.6
#2 0x2b21eeae3458 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b21eeae3525 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`,
ap=0x2b21f4913ad0) at ink_error.cc:65
#4 0x2b21eeae35ee in ink_fatal (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b21eeae2160 in _ink_assert (expression=0x76ddb8 call_event ==
core_lock_retry_event, file=0x76dd04 PluginVC.cc, line=203)
at ink_assert.cc:37
#6 0x00530217 in PluginVC::main_handler (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at PluginVC.cc:203
#7 0x004f5854 in Continuation::handleEvent (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x00755d26 in EThread::process_event (this=0x309b250,
e=0xe0f5b80, calling_code=1) at UnixEThread.cc:145
#9 0x0075610a in EThread::execute (this=0x309b250) at
UnixEThread.cc:239
#10 0x00755284 in spawn_thread_internal (a=0x2849330) at Thread.cc:88
#11 0x2b21ef05f9d1 in start_thread () from /lib64/libpthread.so.0
#12 0x00375ace8b7d in clone () from /lib64/libc.so.6
(gdb) p sm_lock_retry_event
$13 = (Event *) 0x2b2496146e90
(gdb) p core_lock_retry_event
$14 = (Event *) 0x0
(gdb) p active_event
$15 = (Event *) 0x0
(gdb) p inactive_event
$16 = (Event *) 0x0
(gdb) p *(INKContInternal*)this-core_obj-connect_to
Cannot access memory at address 0x2b269cd46c10
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2941) ATS not closing TLS connection properly
[
https://issues.apache.org/jira/browse/TS-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287515#comment-14287515
]
Susan Hinrichs commented on TS-2941:
Potentially TS-3283 relates. Although that bug relates only to error cases,
and only refers to pre-5.0. Not sure what version we are looking at here.
ATS not closing TLS connection properly
---
Key: TS-2941
URL: https://issues.apache.org/jira/browse/TS-2941
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Alexey Ivanov
Assignee: Susan Hinrichs
Fix For: sometime
We are seeing lots of RSTs on our edge boxes from HTTPS-enabled clients:
{code}
20:31:42.861752 IP client-ip.56898 www.linkedin.com.https: Flags [S], seq
2989744105, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val
1060727394 ecr 0,sackOK,eol], length 0
20:31:42.861760 IP www.linkedin.com.https client-ip.56898: Flags [S.], seq
441157858, ack 2989744106, win 14480, options [mss 1460,sackOK,TS val
579955489 ecr 1060727394,nop,wscale 7], length 0
20:31:43.005735 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
1, win 8235, options [nop,nop,TS val 1060727553 ecr 579955489], length 0
20:31:43.012094 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
1:216, ack 1, win 8235, options [nop,nop,TS val 1060727555 ecr 579955489],
length 215
20:31:43.012115 IP www.linkedin.com.https client-ip.56898: Flags [.], ack
216, win 122, options [nop,nop,TS val 579955639 ecr 1060727555], length 0
20:31:43.012400 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
1:186, ack 216, win 122, options [nop,nop,TS val 579955640 ecr 1060727555],
length 185
20:31:43.157903 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
186, win 8223, options [nop,nop,TS val 1060727703 ecr 579955640], length 0
20:31:43.157919 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
216:222, ack 186, win 8223, options [nop,nop,TS val 1060727704 ecr
579955640], length 6
20:31:43.163988 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
222:307, ack 186, win 8223, options [nop,nop,TS val 1060727704 ecr
579955640], length 85
20:31:43.164096 IP www.linkedin.com.https client-ip.56898: Flags [.], ack
307, win 122, options [nop,nop,TS val 579955791 ecr 1060727704], length 0
20:31:43.164650 IP client-ip.56898 www.linkedin.com.https: Flags [.], seq
307:1755, ack 186, win 8223, options [nop,nop,TS val 1060727705 ecr
579955640], length 1448
20:31:43.164668 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
1755:2472, ack 186, win 8223, options [nop,nop,TS val 1060727705 ecr
579955640], length 717
20:31:43.164677 IP www.linkedin.com.https client-ip.56898: Flags [.], ack
2472, win 167, options [nop,nop,TS val 579955792 ecr 1060727705], length 0
20:31:43.504019 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
186:1167, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 981
20:31:43.504043 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
1167:1764, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 597
20:31:43.504101 IP www.linkedin.com.https client-ip.56898: Flags [.], seq
1764:3212, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 1448
20:31:43.504118 IP www.linkedin.com.https client-ip.56898: Flags [.], seq
3212:4660, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 1448
20:31:43.504150 IP www.linkedin.com.https client-ip.56898: Flags [.], seq
4660:6108, ack 2472, win 167, options [nop,nop,TS val 579956132 ecr
1060727705], length 1448
20:31:43.743945 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
1167, win 8162, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
20:31:43.743966 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
6108:6126, ack 2472, win 167, options [nop,nop,TS val 579956371 ecr
1060728286], length 18
20:31:43.743987 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
4660, win 7944, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
20:31:43.743994 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
6108, win 8192, options [nop,nop,TS val 1060728286 ecr 579956132], length 0
20:31:43.895889 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
6126, win 8190, options [nop,nop,TS val 1060728437 ecr 579956371], length 0
20:31:54.189610 IP www.linkedin.com.https client-ip.56898: Flags [F.], seq
6126, ack 2472, win 167, options [nop,nop,TS val 579966817 ecr 1060728437],
length 0
20:31:54.305500 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
6127, win 8192, options [nop,nop,TS val 1060738819 ecr 579966817], length 0
[jira] [Commented] (TS-3100) Extend the tr-pass window to allow malformed HTTP commands to be blind tunneled
[ https://issues.apache.org/jira/browse/TS-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287508#comment-14287508 ] ASF subversion and git services commented on TS-3100: - Commit 497e4755d7773590204b89b6c262f6605a9c8e21 in trafficserver's branch refs/heads/master from shinrich [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=497e475 ] TS-3100: Extend tr-pass to allow malformed HTTP GET requests to be blind tunneled. Extend the tr-pass window to allow malformed HTTP commands to be blind tunneled --- Key: TS-3100 URL: https://issues.apache.org/jira/browse/TS-3100 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.3.0 Attachments: ts-3100.diff Some servers abuse the HTTP protocol to implement services. ATS certainly should not cache responses from malformed GET, POST, etc, it should get out of the way if possible and pass the traffic along if the customer has marked the port with tr-pass. As the code is currently written, it will make the tr-pass blind tunnel decision if the initial request does not parse. But if the initial request does parse but the specification violation occurs later, the tr-pass decision is not revisited. One ISP using ATS has reported the following scenarios. The client sends a well formed GET request. Then after the double carriage return line feeds, it sends some additional text. The server interprets this as additional requests for information. Since the GET request was well formed, the connection is put on the HTTP path and the extra data after the carriage return line feeds is stripped before it is passed along to the server. At a minimum, I want to revisit tr-pass decision after the header has been parsed and the carriage return line feeds have been read in the GET case. If the connection is not set to pipeline requests and there is more data in the buffer, pass the connection on to be blind tunneled. I plan to review the POST and PUT paths for other early options for tr-pass evaluations too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3235) PluginVC crashed with unrecognized event
[
https://issues.apache.org/jira/browse/TS-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287417#comment-14287417
]
zouyu commented on TS-3235:
---
@portl4t,
I think it is a common case that customer may use their own threads.
The continuation's mutex can be got, because the caller should create the mutex
and then create the continuation. My concern is that most objects are
transparent to user, the inner structure is hidden to user, so like 'vc', it is
operated in ATS core and caller cannot get its mutex directly. Seems ATS is
lack of API to get it.
PluginVC crashed with unrecognized event
Key: TS-3235
URL: https://issues.apache.org/jira/browse/TS-3235
Project: Traffic Server
Issue Type: Bug
Components: CPP API, HTTP, Plugins
Reporter: kang li
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: pluginvc-crash.diff
We are using atscppapi to create Intercept plugin.
From the coredump , that seems Continuation of the InterceptPlugin was
already been destroyed.
{code}
#0 0x00375ac32925 in raise () from /lib64/libc.so.6
#1 0x00375ac34105 in abort () from /lib64/libc.so.6
#2 0x2b21eeae3458 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b21eeae3525 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`,
ap=0x2b21f4913ad0) at ink_error.cc:65
#4 0x2b21eeae35ee in ink_fatal (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b21eeae2160 in _ink_assert (expression=0x76ddb8 call_event ==
core_lock_retry_event, file=0x76dd04 PluginVC.cc, line=203)
at ink_assert.cc:37
#6 0x00530217 in PluginVC::main_handler (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at PluginVC.cc:203
#7 0x004f5854 in Continuation::handleEvent (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x00755d26 in EThread::process_event (this=0x309b250,
e=0xe0f5b80, calling_code=1) at UnixEThread.cc:145
#9 0x0075610a in EThread::execute (this=0x309b250) at
UnixEThread.cc:239
#10 0x00755284 in spawn_thread_internal (a=0x2849330) at Thread.cc:88
#11 0x2b21ef05f9d1 in start_thread () from /lib64/libpthread.so.0
#12 0x00375ace8b7d in clone () from /lib64/libc.so.6
(gdb) p sm_lock_retry_event
$13 = (Event *) 0x2b2496146e90
(gdb) p core_lock_retry_event
$14 = (Event *) 0x0
(gdb) p active_event
$15 = (Event *) 0x0
(gdb) p inactive_event
$16 = (Event *) 0x0
(gdb) p *(INKContInternal*)this-core_obj-connect_to
Cannot access memory at address 0x2b269cd46c10
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3140) Traffic server crashes when there is a redirect response in cache
[ https://issues.apache.org/jira/browse/TS-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287479#comment-14287479 ] ASF subversion and git services commented on TS-3140: - Commit 9e2689b78a3ab6b768ec60506057b065206f4e0d in trafficserver's branch refs/heads/master from shinrich [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9e2689b ] TS-3140: Traffic Server asserts during response redirect. Traffic server crashes when there is a redirect response in cache - Key: TS-3140 URL: https://issues.apache.org/jira/browse/TS-3140 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 5.0.1 Reporter: zouyu Assignee: Susan Hinrichs Labels: crash, review Fix For: 5.3.0 Attachments: TS-3140-2.diff, TS-3140.diff Traffic server will crash in below steps: 1. Enable redirect and http cache, make sure that traffic server can cache redirect request redirect response such as 302/307 response. 2. make a remap url in traffic server which will remap to a redirect url 'redirect_url_1' which points to 'www.google.com' ( note that 'www.google.com' is also a redirect url which may point to 'www.google.com.sg') 3. make number_of_redirections=1 in records.config. 4. access the 'redirect_url_1'. At first time, after access it, traffic server will cache the redirect response such as 307. 5. try to access the 'redirect_url_1' again, this time traffic server will crash. The root cause is that in above case, traffic sever will check the cache in a loop definitely which will exhausted the stack space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Build failed in Jenkins: tsqa-master #37
See https://ci.trafficserver.apache.org/job/tsqa-master/37/ -- Started by timer Building remotely on QA1 (qa) in workspace https://ci.trafficserver.apache.org/job/tsqa-master/ws/ /usr/bin/git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository /usr/bin/git config remote.origin.url git://git.apache.org/trafficserver.git # timeout=10 Cleaning workspace /usr/bin/git rev-parse --verify HEAD # timeout=10 Resetting working tree /usr/bin/git reset --hard # timeout=10 ERROR: Error fetching remote repo 'origin' ERROR: Error fetching remote repo 'origin'
[jira] [Commented] (TS-3235) PluginVC crashed with unrecognized event
[
https://issues.apache.org/jira/browse/TS-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287179#comment-14287179
]
zouyu commented on TS-3235:
---
@portl4t,
One more question about holding the lock of continuation before performing task
in customer threads,
if so, should we move the lock into 'TS' API? such as TSVIOReenable,
TSVConnClose?
For continuation, customer can get the lock because when he wants to create a
continuation, he must create the related mutex, but for 'VC', how the customer
can get the related mutex from it directly? since ATS already hide the inner
objects from customers.
For example, if we want to call TSVConnClose, we need to get the lock of the
'VC', but how to get it directly? Seems no API to do it.
And also for TSVIOReenable, if the customer doesn't check the code that vio's
mutex = cont's mutex,
how he can get the vio's mutex?
PluginVC crashed with unrecognized event
Key: TS-3235
URL: https://issues.apache.org/jira/browse/TS-3235
Project: Traffic Server
Issue Type: Bug
Components: CPP API, HTTP, Plugins
Reporter: kang li
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: pluginvc-crash.diff
We are using atscppapi to create Intercept plugin.
From the coredump , that seems Continuation of the InterceptPlugin was
already been destroyed.
{code}
#0 0x00375ac32925 in raise () from /lib64/libc.so.6
#1 0x00375ac34105 in abort () from /lib64/libc.so.6
#2 0x2b21eeae3458 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b21eeae3525 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`,
ap=0x2b21f4913ad0) at ink_error.cc:65
#4 0x2b21eeae35ee in ink_fatal (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b21eeae2160 in _ink_assert (expression=0x76ddb8 call_event ==
core_lock_retry_event, file=0x76dd04 PluginVC.cc, line=203)
at ink_assert.cc:37
#6 0x00530217 in PluginVC::main_handler (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at PluginVC.cc:203
#7 0x004f5854 in Continuation::handleEvent (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x00755d26 in EThread::process_event (this=0x309b250,
e=0xe0f5b80, calling_code=1) at UnixEThread.cc:145
#9 0x0075610a in EThread::execute (this=0x309b250) at
UnixEThread.cc:239
#10 0x00755284 in spawn_thread_internal (a=0x2849330) at Thread.cc:88
#11 0x2b21ef05f9d1 in start_thread () from /lib64/libpthread.so.0
#12 0x00375ace8b7d in clone () from /lib64/libc.so.6
(gdb) p sm_lock_retry_event
$13 = (Event *) 0x2b2496146e90
(gdb) p core_lock_retry_event
$14 = (Event *) 0x0
(gdb) p active_event
$15 = (Event *) 0x0
(gdb) p inactive_event
$16 = (Event *) 0x0
(gdb) p *(INKContInternal*)this-core_obj-connect_to
Cannot access memory at address 0x2b269cd46c10
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287914#comment-14287914
]
Andre edited comment on TS-3314 at 1/22/15 6:29 PM:
setting it to CONFIG proxy.config.ssl.server.dhparams_file STRING
/opt/trafficserver/certs/dh2048.pem does not work either
my certs is in /home/www/certs, but I have a symbolic link in
/opt/trafficserver to certs.
proxy.config.config_dir is not set in my records.conf, so it should default to
/opt/trafficserver
was (Author: votan):
setting it to CONFIG proxy.config.ssl.server.dhparams_file STRING
/opt/trafficserver/etc/trafficserver/certs/dh2048.pem does not work either
my certs is in /home/www/certs, but I have a symbolic link in
/opt/trafficserver to certs.
proxy.config.config_dir is not set in my records.conf, so it should default to
/opt/trafficserver
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287914#comment-14287914
]
Andre edited comment on TS-3314 at 1/22/15 6:30 PM:
*edit*
setting it to CONFIG proxy.config.ssl.server.dhparams_file STRING
/opt/trafficserver/certs/dh2048.pem works!
my certs is in /home/www/certs, but I have a symbolic link in
/opt/trafficserver to certs.
proxy.config.config_dir is not set in my records.conf, so it should default to
/opt/trafficserver
was (Author: votan):
setting it to CONFIG proxy.config.ssl.server.dhparams_file STRING
/opt/trafficserver/certs/dh2048.pem does not work either
my certs is in /home/www/certs, but I have a symbolic link in
/opt/trafficserver to certs.
proxy.config.config_dir is not set in my records.conf, so it should default to
/opt/trafficserver
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2490: -- Attachment: (was: TS-2490.diff) traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Assignee: Alan M. Carroll Labels: review, yahoo Fix For: 6.0.0 Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2490: -- Attachment: TS-2490_new.diff Updating the patch to also use the configured init cop timer, when traffic_server crashes and traffic_cop/traffic_manager brings it up. traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Assignee: Alan M. Carroll Labels: review, yahoo Fix For: 6.0.0 Attachments: TS-2490_new.diff Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287969#comment-14287969 ] Sudheer Vinukonda edited comment on TS-2490 at 1/22/15 6:56 PM: Updating the patch to also use the configured init cop timer, when traffic_server crashes and traffic_cop/traffic_manager brings it up. Note: I know [~zwoop] suggested not to include this patch to the master, but, along with us, some other users (e.g. [~reveller]) are internally using this patch as an interim solution. So, wanted to update it, since, we had an outage bcoz of it (with the cop not being able to bring up server after a crash). was (Author: sudheerv): Updating the patch to also use the configured init cop timer, when traffic_server crashes and traffic_cop/traffic_manager brings it up. traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Assignee: Alan M. Carroll Labels: review, yahoo Fix For: 6.0.0 Attachments: TS-2490_new.diff Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-3314:
--
Assignee: Susan Hinrichs
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2941) ATS not closing TLS connection properly
[
https://issues.apache.org/jira/browse/TS-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287534#comment-14287534
]
Susan Hinrichs commented on TS-2941:
I'm seeing the same thing. And indeed we are still setting
SSL_CTX_set_quiet_shutdown. [~Kang Li] did you end up making a patch to
explicitly do the send notify?
Is sending the explicit send notify something that we always want to do? Is
the current situation an accident of implementation, or was this a conscious
decision to avoid it?
Unless there is a compelling reason not to do it, we should follow the spec.
ATS not closing TLS connection properly
---
Key: TS-2941
URL: https://issues.apache.org/jira/browse/TS-2941
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Alexey Ivanov
Assignee: Susan Hinrichs
Fix For: sometime
We are seeing lots of RSTs on our edge boxes from HTTPS-enabled clients:
{code}
20:31:42.861752 IP client-ip.56898 www.linkedin.com.https: Flags [S], seq
2989744105, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val
1060727394 ecr 0,sackOK,eol], length 0
20:31:42.861760 IP www.linkedin.com.https client-ip.56898: Flags [S.], seq
441157858, ack 2989744106, win 14480, options [mss 1460,sackOK,TS val
579955489 ecr 1060727394,nop,wscale 7], length 0
20:31:43.005735 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
1, win 8235, options [nop,nop,TS val 1060727553 ecr 579955489], length 0
20:31:43.012094 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
1:216, ack 1, win 8235, options [nop,nop,TS val 1060727555 ecr 579955489],
length 215
20:31:43.012115 IP www.linkedin.com.https client-ip.56898: Flags [.], ack
216, win 122, options [nop,nop,TS val 579955639 ecr 1060727555], length 0
20:31:43.012400 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
1:186, ack 216, win 122, options [nop,nop,TS val 579955640 ecr 1060727555],
length 185
20:31:43.157903 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
186, win 8223, options [nop,nop,TS val 1060727703 ecr 579955640], length 0
20:31:43.157919 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
216:222, ack 186, win 8223, options [nop,nop,TS val 1060727704 ecr
579955640], length 6
20:31:43.163988 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
222:307, ack 186, win 8223, options [nop,nop,TS val 1060727704 ecr
579955640], length 85
20:31:43.164096 IP www.linkedin.com.https client-ip.56898: Flags [.], ack
307, win 122, options [nop,nop,TS val 579955791 ecr 1060727704], length 0
20:31:43.164650 IP client-ip.56898 www.linkedin.com.https: Flags [.], seq
307:1755, ack 186, win 8223, options [nop,nop,TS val 1060727705 ecr
579955640], length 1448
20:31:43.164668 IP client-ip.56898 www.linkedin.com.https: Flags [P.], seq
1755:2472, ack 186, win 8223, options [nop,nop,TS val 1060727705 ecr
579955640], length 717
20:31:43.164677 IP www.linkedin.com.https client-ip.56898: Flags [.], ack
2472, win 167, options [nop,nop,TS val 579955792 ecr 1060727705], length 0
20:31:43.504019 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
186:1167, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 981
20:31:43.504043 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
1167:1764, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 597
20:31:43.504101 IP www.linkedin.com.https client-ip.56898: Flags [.], seq
1764:3212, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 1448
20:31:43.504118 IP www.linkedin.com.https client-ip.56898: Flags [.], seq
3212:4660, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
1060727705], length 1448
20:31:43.504150 IP www.linkedin.com.https client-ip.56898: Flags [.], seq
4660:6108, ack 2472, win 167, options [nop,nop,TS val 579956132 ecr
1060727705], length 1448
20:31:43.743945 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
1167, win 8162, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
20:31:43.743966 IP www.linkedin.com.https client-ip.56898: Flags [P.], seq
6108:6126, ack 2472, win 167, options [nop,nop,TS val 579956371 ecr
1060728286], length 18
20:31:43.743987 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
4660, win 7944, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
20:31:43.743994 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
6108, win 8192, options [nop,nop,TS val 1060728286 ecr 579956132], length 0
20:31:43.895889 IP client-ip.56898 www.linkedin.com.https: Flags [.], ack
6126, win 8190, options [nop,nop,TS val 1060728437 ecr 579956371], length 0
20:31:54.189610 IP www.linkedin.com.https
[jira] [Created] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
Andre created TS-3314:
-
Summary: SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the ca
is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3316) fix the build for 32 bit architectures
James Peach created TS-3316: --- Summary: fix the build for 32 bit architectures Key: TS-3316 URL: https://issues.apache.org/jira/browse/TS-3316 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach The build is broken on 32bit. Make some minor fixes to keep it going. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3316) fix the build for 32 bit architectures
[ https://issues.apache.org/jira/browse/TS-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-3316. - Resolution: Fixed Fix Version/s: 5.3.0 Assignee: James Peach fix the build for 32 bit architectures -- Key: TS-3316 URL: https://issues.apache.org/jira/browse/TS-3316 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: James Peach Fix For: 5.3.0 The build is broken on 32bit. Make some minor fixes to keep it going. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Build failed in Jenkins: tsqa-master #38
See https://ci.trafficserver.apache.org/job/tsqa-master/38/changes Changes: [James Peach] TS-3309: document TLS session ticket rotation [Bryan Call] TS-153: Dynamic keep-alive timeouts [James Peach] TS-3287: fix URL rewrite allocation size [Bryan Call] TS-153: Updates to traffic_top to report dynamic KA times [Bryan Call] TS-153: Dynamic keep-alive timeouts [Phil Sorber] Fix clang analyzer issue [shinrich] Fix clang analyzer warning. [shinrich] TS-3140: Traffic Server asserts during response redirect. [shinrich] TS-3100: Extend tr-pass to allow malformed HTTP GET requests to be blind [Phil Sorber] Remove superfluous assert. 'this' is always a valid pointer. [Sudheer Vinukonda] update docs to clarify that using per thread server session [James Peach] TS-3316: various trivial build fixes for 32bit systems. [mlibbey] fix link to Partitioning the Cache section [mlibbey] fix link to release process [mlibbey] fix link to Congestion Control [mlibbey] Fix link to host log splitting [mlibbey] Fix link to null transformation [mlibbey] fix links to sections; Monitoring Traffic [mlibbey] Uncomment ICP doc section [mlibbey] fix broken links to log formats, ICP [mlibbey] Update squid log format header name [mlibbey] fix broken link [mlibbey] Remove broken link [mlibbey] Add vconnection section reference [mlibbey] Fix broken link, format [mlibbey] Fix broken link [mlibbey] Fix broken link [mlibbey] Fix broken links [mlibbey] fix broken link [mlibbey] Fix broken link [mlibbey] fix broken link [mlibbey] fix broken link [Bryan Call] TS-153: Dynamic keep-alive timeouts [Bryan Call] TS-153: Dynamic keep-alive timeouts [Bryan Call] TS-153: Forgot to add the abort after removing the assert when a stat -- [...truncated 541 lines...] config.status: creating iocore/cluster/Makefile config.status: creating iocore/dns/Makefile config.status: creating iocore/eventsystem/Makefile config.status: creating iocore/hostdb/Makefile config.status: creating iocore/net/Makefile config.status: creating iocore/utils/Makefile config.status: creating lib/Makefile config.status: creating lib/perl/Makefile config.status: creating lib/perl/lib/Apache/TS.pm config.status: creating lib/records/Makefile config.status: creating lib/ts/Makefile config.status: creating lib/ts/apidefs.h config.status: creating lib/ts/ink_config.h config.status: creating lib/tsconfig/Makefile config.status: creating lib/wccp/Makefile config.status: creating mgmt/Makefile config.status: creating mgmt/api/Makefile config.status: creating mgmt/api/include/Makefile config.status: creating mgmt/cluster/Makefile config.status: creating mgmt/utils/Makefile config.status: creating mgmt/web2/Makefile config.status: creating plugins/Makefile config.status: creating plugins/cacheurl/Makefile config.status: creating plugins/conf_remap/Makefile config.status: creating plugins/gzip/Makefile config.status: creating plugins/header_rewrite/Makefile config.status: creating plugins/libloader/Makefile config.status: creating plugins/regex_remap/Makefile config.status: creating plugins/stats_over_http/Makefile config.status: creating plugins/tcpinfo/Makefile config.status: creating proxy/Makefile config.status: creating proxy/api/ts/Makefile config.status: creating proxy/config/Makefile config.status: creating proxy/config/body_factory/Makefile config.status: creating proxy/config/body_factory/default/Makefile config.status: creating proxy/config/records.config.default config.status: creating proxy/config/storage.config.default config.status: creating proxy/congest/Makefile config.status: creating proxy/hdrs/Makefile config.status: creating proxy/http/Makefile config.status: creating proxy/http/remap/Makefile config.status: creating proxy/http2/Makefile config.status: creating proxy/logging/Makefile config.status: creating proxy/shared/Makefile config.status: creating proxy/spdy/Makefile config.status: creating rc/Makefile config.status: creating rc/trafficserver config.status: creating rc/trafficserver.conf config.status: creating rc/trafficserver.service config.status: creating rc/trafficserver.xml config.status: creating tools/Makefile config.status: creating tools/tsxs config.status: creating plugins/experimental/Makefile config.status: creating plugins/experimental/authproxy/Makefile config.status: creating plugins/experimental/background_fetch/Makefile config.status: creating plugins/experimental/balancer/Makefile config.status: creating plugins/experimental/buffer_upload/Makefile config.status: creating plugins/experimental/channel_stats/Makefile config.status: creating plugins/experimental/collapsed_connection/Makefile config.status: creating plugins/experimental/custom_redirect/Makefile config.status: creating plugins/experimental/epic/Makefile config.status: creating plugins/experimental/escalate/Makefile config.status: creating plugins/experimental/esi/Makefile config.status: creating
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288645#comment-14288645 ] ASF subversion and git services commented on TS-153: Commit abe6035641ef4b00e14c3e9b87fc616eba345a03 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=abe6035 ] TS-153: Fixed warning of unused argument Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.3.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3315) Assert after try lock
[
https://issues.apache.org/jira/browse/TS-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288662#comment-14288662
]
weijin commented on TS-3315:
the try lock of cont-mutex should never fail. If fail, which means the caller
may have flaws or bugs.
Assert after try lock
-
Key: TS-3315
URL: https://issues.apache.org/jira/browse/TS-3315
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Phil Sorber
In iocore/cache/Cache.cc there is the following:
{code}
CACHE_TRY_LOCK(lock, cont-mutex, this_ethread());
ink_assert(lock.is_locked());
{code}
Does it really make sense to try and assert when a try can fail?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3316) fix the build for 32 bit architectures
[ https://issues.apache.org/jira/browse/TS-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288398#comment-14288398 ] ASF subversion and git services commented on TS-3316: - Commit cc6b44fad9ba735d2591dd2e0aa991ce5bc91f9a in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cc6b44f ] TS-3316: various trivial build fixes for 32bit systems. fix the build for 32 bit architectures -- Key: TS-3316 URL: https://issues.apache.org/jira/browse/TS-3316 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach The build is broken on 32bit. Make some minor fixes to keep it going. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3317) Should we consider eliminating the mgmt_port aka backdoor_port ?
[ https://issues.apache.org/jira/browse/TS-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3317: -- Labels: incompatible (was: ) Should we consider eliminating the mgmt_port aka backdoor_port ? Key: TS-3317 URL: https://issues.apache.org/jira/browse/TS-3317 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Labels: incompatible Fix For: 6.0.0 Do we really need this? If the only thing in use today is for traffic_cop to always be allowed a connection, maybe we can have some other mechanism ? In either case, there's a bunch of additional stuff in there for the backdoor_port, including proxy.config.url_remap.handle_backdoor_urls (off by default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3317) Should we consider eliminating the mgmt_port aka backdoor_port ?
Leif Hedstrom created TS-3317: - Summary: Should we consider eliminating the mgmt_port aka backdoor_port ? Key: TS-3317 URL: https://issues.apache.org/jira/browse/TS-3317 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Do we really need this? If the only thing in use today is for traffic_cop to always be allowed a connection, maybe we can have some other mechanism ? In either case, there's a bunch of additional stuff in there for the backdoor_port, including proxy.config.url_remap.handle_backdoor_urls (off by default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3317) Should we consider eliminating the mgmt_port aka backdoor_port ?
[ https://issues.apache.org/jira/browse/TS-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3317: -- Fix Version/s: 6.0.0 Should we consider eliminating the mgmt_port aka backdoor_port ? Key: TS-3317 URL: https://issues.apache.org/jira/browse/TS-3317 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Labels: incompatible Fix For: 6.0.0 Do we really need this? If the only thing in use today is for traffic_cop to always be allowed a connection, maybe we can have some other mechanism ? In either case, there's a bunch of additional stuff in there for the backdoor_port, including proxy.config.url_remap.handle_backdoor_urls (off by default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288541#comment-14288541 ] ASF subversion and git services commented on TS-153: Commit ab3fec0a88aba5bf8da5078ea0ab326e4fd61988 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ab3fec0 ] TS-153: Dynamic keep-alive timeouts Updates after a code review with AMC and more testing Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.3.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288565#comment-14288565 ] ASF subversion and git services commented on TS-153: Commit 9763a7f87a1cf7e3a6df20edc7bf19bf99965663 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9763a7f ] TS-153: Dynamic keep-alive timeouts Removed an unneed removal from the LRU. Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.3.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288581#comment-14288581 ] ASF subversion and git services commented on TS-153: Commit b48c343e6bbc58527b875fef31cbc1c8349fc650 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b48c343 ] TS-153: Forgot to add the abort after removing the assert when a stat can't be fetched in traffic_top Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.3.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to normal : tsqa-master #39
See https://ci.trafficserver.apache.org/job/tsqa-master/39/changes
[jira] [Commented] (TS-3315) Assert after try lock
[
https://issues.apache.org/jira/browse/TS-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288822#comment-14288822
]
Phil Sorber commented on TS-3315:
-
And we try so we can assert there? Perhaps we need a comment then to indicate
why we do this strange behavior.
Assert after try lock
-
Key: TS-3315
URL: https://issues.apache.org/jira/browse/TS-3315
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Phil Sorber
In iocore/cache/Cache.cc there is the following:
{code}
CACHE_TRY_LOCK(lock, cont-mutex, this_ethread());
ink_assert(lock.is_locked());
{code}
Does it really make sense to try and assert when a try can fail?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287799#comment-14287799
]
Andre commented on TS-3314:
---
Exactly. I have the 3 mentioned dhparams in the same folder as the certificates
and it worked with 5.1.2.
I could set proxy.config.ssl.server.dhparams_file to the certificates directory
if that helps?
here's the ciphers I accept which, in my humble opinion, represent a modern,
sane default:
proxy.config.ssl.server.cipher_suite STRING
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:!aNULL:!eNULL
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287702#comment-14287702
]
Susan Hinrichs commented on TS-3314:
This was broken by TS-2417, adding support for DHE. This patch added a new
entry for the dhparams file, proxy.config.ssl.server.dhparams_file.
If the parameter is not set, it loads a built-in 2048 param. If it fails to
load the built in or the one specified by the dhparams_file, it issues the
error you are seeing.
This still is a bit confusing, because I would assume that the built-in one
would get successfully loaded in your case. That still isn't what you want,
since you want choices on which dhparam to load I assume based on the cipher
negotiated.
I'm still figuring out how the old scheme worked. You just placed the dh files
in the same directory as the certificates and the write DH param would get
loaded depending on the version of cipher selected by the negotiation?
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287799#comment-14287799
]
Andre edited comment on TS-3314 at 1/22/15 5:24 PM:
Exactly. I have the 3 mentioned dhparams in the same folder as the certificates
and it worked with 5.1.2.
here's the config part:
CONFIG proxy.config.ssl.server.cert.path STRING certs/
CONFIG proxy.config.ssl.server.private_key.path STRING certs/
CONFIG proxy.config.ssl.server.dhparams_file STRING certs/dh2048.pem
here's the ciphers I accept which, in my humble opinion, represent a modern,
sane default:
proxy.config.ssl.server.cipher_suite STRING
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:!aNULL:!eNULL
was (Author: votan):
Exactly. I have the 3 mentioned dhparams in the same folder as the certificates
and it worked with 5.1.2.
I could set proxy.config.ssl.server.dhparams_file to the certificates directory
if that helps?
here's the ciphers I accept which, in my humble opinion, represent a modern,
sane default:
proxy.config.ssl.server.cipher_suite STRING
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:!aNULL:!eNULL
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3315) Assert after try lock
Phil Sorber created TS-3315:
---
Summary: Assert after try lock
Key: TS-3315
URL: https://issues.apache.org/jira/browse/TS-3315
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Phil Sorber
In iocore/cache/Cache.cc there is the following:
{code}
CACHE_TRY_LOCK(lock, cont-mutex, this_ethread());
ink_assert(lock.is_locked());
{code}
Does it really make sense to try and assert when a try can fail?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287917#comment-14287917
]
Andre edited comment on TS-3314 at 1/22/15 6:26 PM:
That could be true, I just took the same ciphers that I used on my origin
before putting ATS in front of it :)
was (Author: votan):
That could be true :)
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287917#comment-14287917
]
Andre commented on TS-3314:
---
That could be true :)
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287884#comment-14287884
]
Susan Hinrichs commented on TS-3314:
The dhparams_file path is calculated relative to the path in
proxy.config.config_dir
So where is your certs directory? When I got the relative path wrong in my
build, I see the same behavior that you describe.
Try putting an absolute path to your .pem file. Or try adjusting the relative
path so it will be correct when combined with the value of your config_dir
parameter.
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287899#comment-14287899
]
Bryan Call commented on TS-3314:
[~andnej]
DHE support wasn't added until 5.2.0 (TS-2417). I would assume that those
ciphers were silently ignored when you were running earlier versions.
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287899#comment-14287899
]
Bryan Call edited comment on TS-3314 at 1/22/15 6:23 PM:
-
[~andnej]
DHE support wasn't added until 5.2.0, released on 1/14/15 (TS-2417). I would
assume that those ciphers were silently ignored when you were running earlier
versions.
was (Author: bcall):
[~andnej]
DHE support wasn't added until 5.2.0 (TS-2417). I would assume that those
ciphers were silently ignored when you were running earlier versions.
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287914#comment-14287914
]
Andre commented on TS-3314:
---
setting it to CONFIG proxy.config.ssl.server.dhparams_file STRING
/opt/trafficserver/etc/trafficserver/certs/dh2048.pem does not work either
my certs is in /home/www/certs, but I have a symbolic link in
/opt/trafficserver to certs.
proxy.config.config_dir is not set in my records.conf, so it should default to
/opt/trafficserver
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287839#comment-14287839
]
Susan Hinrichs commented on TS-3314:
Are you certain your dh2048.pem file was being used? The dhparams_file does
not appear until 5.2. Just doubled checked that in the 5.1.2 source.
If you add an unrecognized config entry, ATS does not complain. And ATS is
setting the SSL_OP_SINGLE_DH_USE and SSL_OP_SINGLE_ECDH_USE which I think means
that you do not need to specify the DH parameters.
In any case, thanks for your records.config entries. I'll get the 5.2 behavior
tracked down.
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287860#comment-14287860
]
Andre commented on TS-3314:
---
I have these entries since I've first setup ATS back in October and didn't
touch it since basically.
So this line does date back to October and I think that was 5.1.0 or 5.1.1 ?
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288213#comment-14288213
]
Susan Hinrichs commented on TS-3314:
Great! I'll go ahead and close out the issue then.
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-3314) SSL errors after upgrade from 5.1.2 - 5.2.0
[
https://issues.apache.org/jira/browse/TS-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-3314.
--
Resolution: Not a Problem
SSL errors after upgrade from 5.1.2 - 5.2.0
Key: TS-3314
URL: https://issues.apache.org/jira/browse/TS-3314
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Andre
Assignee: Susan Hinrichs
I upgraded my ATS from 5.1.2 to 5.2.0 by keeping all my config files.
When I start the trafficserver, I do get errors in the diags.log and https
sites do not work. Here is an extract of the diags.log:
{code}
[Jan 22 15:19:58.381] Server {0x2b42c3b03bc0} NOTE: loading SSL certificate
configuration from /opt/trafficserver/etc/trafficserver/ssl_multicert.config
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.386] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 57
[Jan 22 15:19:58.391] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.392] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 58
[Jan 22 15:19:58.396] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.397] Server {0x2b42c3b03bc0} ERROR: failed to load SSL
certificate specification from
/opt/trafficserver/etc/trafficserver/ssl_multicert.config line 59
[Jan 22 15:19:58.401] Server {0x2b42c3b03bc0} ERROR: SSL dhparams source
returned invalid parameters
[Jan 22 15:19:58.413] Server {0x2b42c3b03bc0} NOTE: traffic server running
[Jan 22 15:19:58.494] Server {0x2b42c9547700} NOTE: cache enabled
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR:
SSL::47566040430336:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:20:01.176] Server {0x2b42d4f17700} ERROR: failed to create SSL
server session
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR:
SSL::47566041483008:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 66.249.64.77
[Jan 22 15:22:19.813] Server {0x2b42d5018700} ERROR: failed to create SSL
server session
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR:
SSL::47566042535680:error:140BA0C3:SSL routines:SSL_new:null ssl
ctx:ssl_lib.c:281: peer address is 2a01:4f8:160:24ca::3
[Jan 22 15:25:01.191] Server {0x2b42d5119700} ERROR: failed to create SSL
server session
{code}
Here is what I have in my ssl_multicert.config:
{code}
ssl_cert_name=domain1.crt ssl_key_name=domain1.key
ssl_cert_name=domain2.crt ssl_key_name=domain2.key
dest_ip=* ssl_cert_name=domain3.crt ssl_key_name=domain3.key
{code}
the .crt files contain my certificate and the intermediate certificate, the
ca is in the truststore.
There are 3 possible dh params available in the configured certificate
directory: dh512.pem, dh1024.pem and dh2048.pem
why did it work in 5.1.2 and is no longer working in 5.2.0?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
