Add enhanced X509 Certificate/Private RSA Key validation to Traffic Ops (AddSSLKeys Endpoint)#3382
Conversation
|
Refer to this link for build results (access rights to CI server needed): |
|
If this PR only partially fixes that issue, you should change "Fixes" to e.g. "Addressed" - As-is, GitHub's going to auto-close the issue when this gets merged. |
ocket8888
left a comment
There was a problem hiding this comment.
It'd be nice if you could add something to the deliveryservices/sslkeys/add API endpoint docs about supported algorithms/chains/whatever else you think is appropriate.
There was a problem hiding this comment.
Looks good, only things are making sure EC certs are still allowed, and language idioms.
Tested in a CiaB, works as expected, except that EC certs aren't allowed.
We do support EC and DSA certs in TC, this needs to check and allow those as well. Other than that, mostly just language idiom and format things, if you don't mind fixing those.
That said, most of our code in TC allows any cert the libraries we're using support (Go, Java, Perl, etc). It does seem like we might be making things harder for ourselves in the future, by whitelisting instead of blacklisting. If we just check for invalid things we know about, we'll support new cert types that our libraries add for free. If you could make this allow types that we don't know about, and just return errors for known bad things, I think that would be even better.
Once the idioms and EC support are added, I'll test EC certs in the CIAB again, and it should be good to merge.
EDIT: Hm, looks like I might be mistaken about EC support. It works on Edges, but it looks like TR might have trouble with them. Still, we should support them, they're smaller and more secure. How would you feel about adding a warning, but allowing them? So when TR is fixed, we don't have to also fix TO?
|
Thanks for reviewing this PR @ocket8888 @rob05c. I'm working on getting these requested changes in today. |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
I'm adding some extra logic at the end of the certificate unit tests that check for correct number of certs that should be in the cert chain. Unit tests for non-SKIAKI certificates do not have the correct number of items in the returned certificate bundle. |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
Sometimes, the Certificate.Verify method will remove elements from a valid certificate chain. Instead of using the output of that method, always use the user input certificate and return a warning if the input certificate does not match the output of the Certificate.Verify method. Fixes #3398 (cherry picked from commit dde742e)
|
I have forced pushed a branch that combines PR #3382 with PR #3417 and adds ECDSA support for DNS delivery services.
|
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
Add unit test for encrypted ECDSA private key
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
Add ECDSA mismatched cert/key unit test Update error messages to be more meaningful
|
Refer to this link for build results (access rights to CI server needed): |
Missing RSA keyEncipherment unit test Missing ECDSA digitalSignature unit test Missing serverAuth extendedKeyUsage (x509v3 only) unit test
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Latest branch provides the following changes:
|
rawlinp
left a comment
There was a problem hiding this comment.
Nice work on this PR!
For comments I've prefixed with nit: feel free to tell me you'd like to leave it how it is if you feel strongly about it. The other few comments I believe should be addressed before this is merged.
Minor changes to error message formatting and string comparison Re-sort go import statements
|
@rawlinp I pushed four commits that resolve all comments you raised from yesterday's review. |
|
Refer to this link for build results (access rights to CI server needed): |
Which issue is fixed by this PR? If not related to an existing issue, what does this PR do?
Partially addresses #3267
All imported x509 certificates / private key pairs will be validated with the following criteria:
Which TC components are affected by this PR?
What is the best way to verify this PR? Please include manual steps or automated tests.
(If no tests are part of this PR, please provide explanation as to why no tests are included.)
Tests to perform for validation:
Expected Result: x509 certificate and key are rejected and not saved in traffic vault.
Expected Result: x509 certificate and key are rejected and not saved in traffic vault.
Expected Result: x509 certificate and key are rejected and . not saved in traffic vault.
Import self-signed certificate for a delivery service with matching Private RSA key.
Optional: Startup CiaB with this commit cherry-picked in.
Run the unit tests in
deliveryservice/keys_test.goCheck all that apply