So, given the discussion so far, I believe this is what should be done: Validate the added certificate. If it detects an unknown authority, allow the certs to be added but return an alert with level = warning with a message stating that the certs were added successfully but use an unknown authority and therefore might be invalid. In Traffic Portal this warning displays as a yellow box which should be a noticeable difference compared to the green box that is usually seen on success.
This means that no new query parameter needs to be added to this API endpoint for skipping validation altogether (as well as no TP checkbox). Real certs will be fully validated by the API, but self-signed certs will only be validated up to the point where they are detected as self-signed certs. Other issues with self-signed certs should be detected and prohibited by the API (e.g. they don't decode properly, mismatched keys, etc.), but they will not get the full validation provided by the golang standard library function for cert verification since that function exits early when it finds an unknown authority. So the end result is: - certificates signed by a known authority will be _fully_ validated and allowed in the API if all passes - certificates signed by an unknown authority will be _partially_ validated and allowed in the API if partial validation passes If you want your self-signed certs to be fully validated by the API, you will need to create an internal signing authority, sign your created certs using that internal signing authority, and install the internal signing authority certs on your TO servers. This is what I would recommend as it provides full verification of your "self-signed" certs because they will appear to be "real" certs and won't emit a warning from the API. That exercise is left up to the administrator. To everyone who has already +1'd the original proposal, would this approach also work for you? - Rawlin On Fri, Nov 30, 2018 at 12:09 PM Hank Beatty <hbea...@gmail.com> wrote: > > Hello Rawlin, > > +1 on validating certs. > > On #2: Would it be possible to have the API default to true and make the > query parameter (?validate=false). > > Regards, > Hank > > On 11/28/2018 06:45 PM, Rawlin Peters 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 > >
