Ok, I will make sure the TP checkbox says "Validate Certificates” with it checked by default.
However, Jonathan does bring up a good point about emitting a warning for authority trust validation rather than an error. My worry is that things in TP are typically binary: either the operation failed or it was a success. If we return a warning with the 200 rather than prohibiting it, the warning could go unnoticed leading to unintentional deployment of self-signed certs. With the checkbox, it requires that extra step of disabling validation when you are certain the self-signed certs are okay before adding them. Are you alright with that, Jonathan, as opposed to just allowing the self-signed certs to go through with a warning? - Rawlin On Thu, Nov 29, 2018 at 10:39 AM Gray, Jonathan <[email protected]> wrote: > > There are some kinds of validation that should be errors such as mismatched > keys, broken chains, or cert ordering problems. Authority trust validation > (against the TO system trusts) should be a warning. > > Jonathan G > > On 11/29/18, 7:45 AM, "Jeremy Mitchell" <[email protected]> wrote: > > +1 on not doing no double negatives...you know what i mean :) > > On Thu, Nov 29, 2018 at 6:35 AM Eric Friedrich -X (efriedri - TRITON UK > BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > <[email protected]> wrote: > > > +1 > > Sounds like a useful change, I know getting the right keys with the > right > > certs can be difficult. > > > > Is it possible to have the TP checkbox match the “polarity” of the API > > query parameter? Rather than “Skip Validation”, can the checkbox say > > “Validate Certs” and be checked by default? > > > > Its easier to conceptualize a positive rather than a double negative > > (unchecked so dont skip validation => Do validation). > > > > —ERic > > > > > > > On Nov 28, 2018, at 6:45 PM, Rawlin Peters <[email protected]> > > wrote: > > > > > > Hey Traffic Controllers, > > > > > > If you're running a recent release of master you may find that you > > > currently cannot _add_ self-signed certificates using the API (and by > > > extension TP). However, the API still allows generating self-signed > > > certificates. So, if your self-signed certs are generated by the API, > > > you probably won't have any issues with those right now. However, if > > > you're generating your self-signed certs through some other means than > > > the API (e.g. in order to add SANs to the cert), you may find that you > > > cannot currently _add_ those self-signed certs via the API. This is > > > because self-signed certs do not pass the new validation in the _add_ > > > API endpoint. Since this new validation is a bit of a breaking API > > > change, I'm proposing the following: > > > > > > 1. By default, the deliveryservices/sslkeys/add endpoint will NOT do > > > any extra validation of the SSL cert being added. This is the old Perl > > > behavior and has led to a lot of headaches due to it being very easy > > > to add bad certs to a delivery service. > > > 2. Add a new query parameter to this API (?validate=true) which when > > > set to 'true' will actually perform the full validation of the > > > certificate being added. > > > 3. In Traffic Portal, add a checkbox next to the "Update Keys" button > > > (which makes a request to the _add_ endpoint) that says "Skip > > > certificate validation" or something. By default that checkbox will be > > > unchecked which will add the '?validate=true' query parameter, meaning > > > the certs will be validated. This would allow you to validate your > > > certs in the API/Traffic Portal up to the point where you believe the > > > only remaining issue is that they're self-signed. At that point you > > > would check the box to "skip validation" to allow the addition of your > > > self-signed certs. > > > > > > We really need to add validation of SSL certificates to this API > > > endpoint, but at the same time I don't want this to be a breaking API > > > change or require too much mental overhead in the UI. This would allow > > > us to get some cert validation by default in Traffic Portal but still > > > be able to bypass the validation for self-signed certs when needed. If > > > using the API directly, you wouldn't need to fix anything for > > > self-signed certs since the validation will not be done unless the new > > > query param is used. > > > > > > Please +1 if you agree with the proposal as-is, -1 if you disagree or > > > think the proposal needs fixing/adjusted (and please be clear on how I > > > can change that to a +1), or just reply with a +/-0 if you don't care > > > too strongly either way but have a different idea or some feedback to > > > give. > > > > > > - Rawlin > > > > > >
