You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2019/06/10 20:36:10 UTC

[GitHub] [trafficcontrol] JBevillC opened a new issue #3676: TO CDN APIs: Initial GET request of CDN SSL keys API required to setup DS linkage

JBevillC opened a new issue #3676: TO CDN APIs: Initial GET request of CDN SSL keys API required to setup DS linkage
URL: https://github.com/apache/trafficcontrol/issues/3676
 
 
   **Component:** Traffic Ops, Traffic Vault
   **Endpoint1**: /api/$ver/cdns/name/{{name}}/sslkeys
   **Endpoint2**: /api/$ver/deliveryservices/xmlId/{{ds_name}}/sslkeys
   **Description**:   
   
   For new Traffic Control deployments that have a dry (empty) Traffic Vault, an initial GET request to the Traffic Ops CDN SSLKeys endpoint (Endpoint1) must be requested before any keys are imported via the Delivery Service sslkeys APIs (Endpoint2).  Any keys that are imported via the DS keys APIs (Endpoint2) prior to this initial GET will get stored in Traffic Vault and a 200 HTTP status will be returned, but the linkage to the CDN will not be performed and subsequent GET request of the CDN sslkeys API will return an empty result (despite the keys actually being in Traffic Vault, but not linked up properly.)
   
   **Analysis**: 
   
   A brief investigation shows that the cdn sslkeys APIs use methods from the `riaksvc` package (traffic ops golang) to retrieve the keys. Methods `riaksvc.GetCDNSSLKeys()` and `riaksvc.GetCDNSSLKeysDSNames()` use the `riaksvc.SearchDocsToCDNSSLKeys()` method to locate the keys.  If the keys in Riak aren't present (the linkage between the CDN and the DS), it will be created by this search method.  There is even a comment in the source that indicates the developer who wrote this code was aware of it:
   
   ```
   # FROM 
   // SearchDocsToCDNSSLKeys converts the SearchDoc array returned by Riak into a CDNSSLKey slice.
   If a SearchDoc doesn't contain expected fields, it ---> **creates** <--- the key with those fields defaulted to empty strings.
   ```
   Essentially, the search function will create the keys and default them to empty if the SearchDoc results are empty, hence why the initial request is necessary. Without the keys in place, the linkage between CDN <--> DS keys just doesn't seem to exist. Note: the initial GET request against the CDN sslkeys API only needs to happen once.  I suspect this could be related to how Apache Solr works internal with Riak/Traffic Vault.  This bug may be related to issue #1847 
   
   **Steps to Reproduce**:
   
   The easiest way to reproduce this bug is via CDN-in-a-Box and by removing the initial GET request(s) to the CDN sslkeys endpoints prior to the keys being imported via the DS addkeys API at the end of the `trafficops` container.  Omitting the initial GET request as mentioned, the certificates will successfully get imported to Traffic Vault, but the CDN sslkeys API will always return an empty result. Note, that this bug only occurs on dry installs of Traffic Vault with no key data. Below is the snippet of code from CiaB trafficops container that needs to be commented out to reproduce this bug:
   
   ```
   # From $src/trafficcontrol/infrastructure/cdn-in-a-box/traffic_ops/run-go.sh (lines 125-130)
   125       sleep 2
   126       cdn_sslkeys_response=$(to-get "api/1.3/cdns/name/$CDN_NAME/sslkeys.json" | jq '.response[] | length')
   127       echo "cdn_sslkeys_response=$cdn_sslkeys_response"
   128 
   129       if [ -n "$cdn_sslkeys_response" ] ; then
   130          if ((cdn_sslkeys_response==0)); then
   ```
   
   Once those lines are commented out and CiaB is re-built/re-started, the Traffic Router will run in a loop waiting for the SSL certificates to be imported, even though they have already been imported and can be retrieved individually by the DS sslkeys API (GET request), however the CDN sslkeys API endpoint used by Traffic Router (property $certificate.api.url) request will return an empty result.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services