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