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 > >
