-
Notifications
You must be signed in to change notification settings - Fork 351
Generate a self signed cert on ds creation/update #6024
Conversation
traffic_ops/traffic_ops_golang/deliveryservice/deliveryservices.go
Outdated
Show resolved
Hide resolved
traffic_ops/traffic_ops_golang/deliveryservice/deliveryservices.go
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does using inf.Tx.Tx not work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it will after the switch to using createV40 and updateV40 so ill get rid of this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think this went back and forth, but are we not able to use inf.Tx.Tx here? It seems like maybe there was a missing nil pointer check that ended up fixing the tests?
rawlinp
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, and manual testing confirms the certs are created as expected. Should we add TO API tests to check for the cert creation? It would probably need to be wrapped in if includeSystemTests.
Also, I can't tell if the TO API tests and TP tests are failing due to this PR. I've rerun them a few times, but they seem to be consistent.
63823b6 to
2615ec7
Compare
|
Would there be a way to configure these so the CSR is valid to use after being auto-generated? That would mean new configuration. |
|
I like that idea. Just make the new config optional and use |
720f4e4 to
ee0e574
Compare
ee0e574 to
83fd30a
Compare
83fd30a to
7b3ee0c
Compare
|
Closes #2429 |
870983a to
6c98eaf
Compare
d2dda5c to
b61dfe8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think this went back and forth, but are we not able to use inf.Tx.Tx here? It seems like maybe there was a missing nil pointer check that ended up fixing the tests?
5268396 to
e5cf40b
Compare
rawlinp
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, and TO generated a cert on DS create (with https enabled) and update (from http to https) as expected.
* Generate a self signed cert on ds creation/update * Added nil check for example urls, fixed test that was failing * updated per comments * fixed tests * more test fixing * added default cert verification test * added default cert config to cdn.conf * updated gofmt * added nil check * added default cert config validation and updated db tx use (cherry picked from commit 7d0472d)
What does this PR (Pull Request) do?
This PR updates TO so that when a new HTTPS delivery service is created or an HTTP delivery service is updated to HTTPS, a self signed certificate is created as a placeholder.
Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
Create a new HTTPS DS and verify that a self signed certificate is generated and stored
Create an HTTP DS and verify that no cert is generated
Update that HTTP DS to use HTTPS and verify that a self signed cert is generated and stored
Update an existing HTTPS DS that already has a cert and verify that the previous cert remains unchanged
Verify that all other DS creation / update functionality is unchanged
If this is a bug fix, what versions of Traffic Control are affected?
The following criteria are ALL met by this PR
This test does not include docs or tests since it is a minor change that will not impact these
Additional Information