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 2021/11/22 13:53:04 UTC

[GitHub] [trafficcontrol] mikeV02 opened a new issue #6374: Generating an SSL cert for DeliveryService using an external ACME (not Let'sEncrypt) provider always fails

mikeV02 opened a new issue #6374:
URL: https://github.com/apache/trafficcontrol/issues/6374


   <!--
   ************ STOP!! ************
   If this issue identifies a security vulnerability, DO NOT submit it! Instead, contact
   the Apache Traffic Control Security Team at security@trafficcontrol.apache.org and follow the
   guidelines at https://apache.org/security regarding vulnerability disclosure.
   
   - For *SUPPORT QUESTIONS*, use the #traffic-control channel on the ASF slack (https://s.apache.org/tc-slack-request)
   or the Traffic Control Users mailing list (send an email to users-subscribe@trafficcontrol.apache.org to subscribe).
   - Before submitting, please **SEARCH GITHUB** for a similar issue or PR
       * https://github.com/apache/trafficcontrol/issues
       * https://github.com/apache/trafficcontrol/pulls
   -->
   
   <!-- Do not submit security vulnerabilities or support requests here - see above -->
   ## This Bug Report affects these Traffic Control components:
   <!-- delete all those that don't apply -->
   - Traffic Ops
   
   ## Current behavior:
   <!-- Describe how the bug happens -->
   I was working on generating an SSL cert for one DeliveryService, and using an external ACME provider (zeroSSL) instead of Let'sEncrypt. I added the data to the cdn.conf, and then called the API [deliveryservices/sslkeys/generate/acme](https://traffic-control-cdn.readthedocs.io/en/latest/api/v4/deliveryservices_sslkeys_generate_acme.html#deliveryservices-sslkeys-generate-acme), but it always failed. Looking at the documentation, and the code, I could not find any place where to declare the ACME challenge (DNS01, TLSALPN01 or HTTP01) so that the internal ACME client uses either of those.
   
   ## Expected behavior:
   <!-- Describe what the behavior would be without the bug -->
   Calling the [deliveryservices/sslkeys/generate/acme](https://traffic-control-cdn.readthedocs.io/en/latest/api/v4/deliveryservices_sslkeys_generate_acme.html#deliveryservices-sslkeys-generate-acme) generates the SSL cert automatically using ACME with the selected provider already declared on cdn.conf in TrafficOps. And the possibility to declare which ACME challenge to use when calling the API to generate.
   
   ## Steps to reproduce:
   TrafficOps 6.0.1.
   1. Declare the ACME provider in the cdn.conf under the "acme_accounts" block (for example ZeroSSL).
   2. Add the email address for notification and the renewal days on the "acme_renewal" block.
   3. Issue en API call POSTing the information to generate the certificate according with documentation [deliveryservices/sslkeys/generate/acme](https://traffic-control-cdn.readthedocs.io/en/latest/api/v4/deliveryservices_sslkeys_generate_acme.html#deliveryservices-sslkeys-generate-acme).
   4. API Call returns the status URL to check the process generation (/api/4.0/async_status/1)
   5. Check the URL and see the generation fails.
   
   ## Checks I made
   I browsed the code for trafficOps and found the code block where the ACME challenges are declared for Let'sEncrypt, and noticed there is a check for the AcmeProvider, that only sets the DNS01 ACME challenge if the provider is Let'sEncrypt, but does not for other providers. My test was to remove that if-statement and set the DNS01 ACME challenge for all ACME Providers as equal. I recompiled trafficOps and re-installed it, and issued the API call to generate again. This time, it completed successfully.
   
   ![image](https://user-images.githubusercontent.com/8298055/142873194-8d8e6215-d603-48ad-bacf-e78a3a94bf30.png)
   


-- 
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.

To unsubscribe, e-mail: issues-unsubscribe@trafficcontrol.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org