FYI - TP can handle 4 alert levels: success, info, warning or error. Basically it just pops up a different colored message depending on the level value. success=green, info=blue, warning=yellow, error=red.
This isn't really documented anywhere i guess except for in here: https://cwiki.apache.org/confluence/display/TC/API+Guidelines On Thu, Nov 29, 2018 at 3:51 PM Gray, Jonathan <[email protected]> wrote: > I'm not sure we can ever flag an untrusted authority as an error as a rule > because a tenant could be creating a DS explicitly with internal trust > which could be fine if their application stack could consume it. It's > basically just informational to know if the cert is in a global trust or > not. We could return a 200 with a warning maybe. A lot of our endpoints > use following response idiom: > > "alerts": [ > { > "level": "success", > "text": "Profile was deleted." > } > ] > > Seems like today we basically just map 200 == level success and basically > everything else == level error. What would the TP UI do with that > information is a different question. > > I'd be ok with just dropping trust authority as a success criteria > entirely though too. The other stated error conditions are still valid > though. > > Jonathan G > > > On 11/29/18, 2:41 PM, "Rawlin Peters" <[email protected]> wrote: > > 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 > > > > > > > > > > > > >
