Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autocreate self-signed SSL certificates #2429

Closed
jhg03a opened this issue Jun 19, 2018 · 4 comments
Closed

Autocreate self-signed SSL certificates #2429

jhg03a opened this issue Jun 19, 2018 · 4 comments
Labels
high impact impacts the basic function, deployment, or operation of a CDN new feature A new feature, capability or behavior Traffic Ops related to Traffic Ops

Comments

@jhg03a
Copy link
Contributor

jhg03a commented Jun 19, 2018

When creating a new Delivery service or modifying the type to support HTTPS, a default self-signed certificate should be created. This could be triggered by a miss when looking up the DS in riak. This specifically prevents situations where a CDN could be queued by a second user unaware of a DS change in flight. This is not prevented by DS Requests since you must fulfill the DS before you could create SSL certs. If this situation happens and ORT runs an update before SSL Keys are in place, a syncds will fail.

@mitchell852 mitchell852 added Traffic Ops API (golang) new feature A new feature, capability or behavior labels Jul 20, 2018
@jhg03a
Copy link
Contributor Author

jhg03a commented Aug 21, 2018

With the version of TR in the repo today, this can also cause TrafficRouter to also stop processing CRConfigs.

@dneuman64
Copy link
Contributor

TR not processing the CrConfig due to missing certificates has been in TR since 1.7 when we added HTTPS support.

@mitchell852 mitchell852 added Traffic Ops related to Traffic Ops high impact impacts the basic function, deployment, or operation of a CDN and removed Traffic Ops related to Traffic Ops Traffic Ops API (golang) labels Oct 17, 2018
@mitchell852
Copy link
Member

also, see #2159 to figure out if implementing Let's encrypt would nullify the need for this

@dneuman64
Copy link
Contributor

I don't think this is the way to solve this problem. We should be better with making changes more atomic. Therefore, I don't think this is something we will plan on fixing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high impact impacts the basic function, deployment, or operation of a CDN new feature A new feature, capability or behavior Traffic Ops related to Traffic Ops
Projects
No open projects
Development

No branches or pull requests

3 participants