Hi TC developers and users, I would appreciate any help making a Traffic Router (=TR) respond to HTTPS requests. I am setting up one of our TC setups (Version 1.7) with an HTTPS DS for the first time, and the TR misbehaves. I have configured the DS for HTTPS, and setup Riak like I normally do (This is not the first time I have installed TC 1.7 with Riak), and loaded a certificate into the DS in Traffic Ops (=TO), and generated CrConfig.
However, when attempting to connect to the TR using HTTPS, it responds to the "Client Hello" message with an "Alert (21): Handshake Failure (40)" message (Wireshark is cool). This is shown by curl as one of the following messages (Depending on the curl version used): $curl https://tr.file-sharing.<cdn-domain>/some-file curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s). Or: curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure (Throughout this message, I have replaced actual CDN/domain names with the strings <cdn-name>, <tc-domain> and <cdn-domain>, as these are potentially customer sensitive data). When using HTTP and not HTTPS, I get the expected 302 response from TR. If you have any experience in dealing with such a situation, I would appreciate any advice, the sooner the better. Here is what I could dig so far: TR responds with an "Alert: Handshake Failure" when the "Client Hello" message contains a host name which does not match any of the certificates it has. (I have another TR that responds well to proper HTTPS requests. I opened an HTTPS connection to it, with a "Client Hello" host name which does not match any DS, and it responded exactly like the misbehaving TR responds, with an "Alert: Handshake Failure" message.) Which leads me to believe that the problem is that the TR does not have the certificate for this DS"file-sharing". However: According to the TR log files, it attempts to GET the sslkeys.json from TO every hour. The TO access log shows that it responds to these GET requests with 200, so I believe that TR has the certificates. After every such hourly GET operation, there is an error message in the TR log. To the best of my understanding, this error message is not real, there is a bug in the code, causing it to emit an error message for every domain being looked at, even when there is no error. Here is such a set of hourly TR log messages : INFO 2017-04-25T17:09:14.411 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: https://ops.<tc-domain>/api/1.1/user/login; timeout is 15000 INFO 2017-04-25T17:09:14.439 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: https://ops.<tc-domain>/api/1.2/cdns/name/<cdn-name>/sslkeys.json; timeout is 15000 ERROR 2017-04-25T17:09:14.811 [Thread-5] com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker - No certificate data for https file-sharing domain <cdn-domain> And here is the respective TO access log message: <some-ip-address> - - [25/Apr/2017:17:09:33 +0000] "GET /api/1.2/cdns/name/<cdn-name>/sslkeys.json HTTP/1.1" 200 5002 353167 "Java/1.8.0_92" The TR log error message is due to a bug in core/src/main/java/com/comcast/cdn/traffic_control/traffic_router/core/config/CertificateChecker.java. The function deliveryServiceHasValidCertificates() emits this error for every DS domain name being checked, regardless of the presence (Or not) of a certificate for the DS being checked. When I manually get the sslkeys.json file from traffic ops, I see that it contains a certificate for the DS called "file-sharing", with a hostname that is exactly what is should be: "hostname":"*.file-sharing.<cdn-domain>". So I have no idea why tomcat behaves as if it does not have a proper certificate. This is as far as I got. If you have any idea how to debug this further, I would appreciate any advice. For example: 1. Is there a way to query the tomcat server, at run time, what certificates it knows about ? 2. Are there any relevant log messages that can be enabled ? If so, how do I enable them ? 3. Any idea as to any other thing worth checking ? Thanks a lot in advance, Oren. -- *Oren Shemesh* Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | [email protected] <[email protected]>
