You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Gray, Jonathan" <Jo...@comcast.com> on 2018/12/13 00:27:01 UTC
Re: [EXTERNAL] Intermediate SSL Certificate Handling
Something to think about, intermediate cert chains are ordered and of indeterminate length if present at all. Also, for a given root CA, there may be multiple variants of intermediate cert chains.
Jonathan G
On 12/12/18, 9:50 AM, "Howell, Jeff (Contractor)" <Je...@comcast.com> wrote:
Greetings Traffic Controllers.
I have an idea for a change in how SSL certs are managed in TO/TP. Currently we have to concatenate the intermediate certs onto the server cert and paste that into the SSL key interface. As the intermediate is likely the same for the majority of certs in the cdn, it makes more sense to decouple that from the server cert.
I’m proposing that a new interface is created in TP to load intermediate certs chains into ATC, creating a library of intermediate certs. In the SSL key interface, intermediate cert chains are selected via dropdown rather than concatenated onto the server cert. This mitigates human error in formatting and certificate ordering.
Best Regards,
Jeff
Re: [EXTERNAL] Intermediate SSL Certificate Handling
Posted by Rawlin Peters <ra...@gmail.com>.
I believe the latest version of the deliveryservices/sslkeys/add
endpoint does some reordering of certs when given a cert chain that
may be out of order and verifies the certs using the root CA bundles
installed on the system (specifically it uses this method:
https://golang.org/pkg/crypto/x509/#Certificate.Verify). So if the TO
server has the root CA bundles installed that you need, I think it
might just work as long as the intermediate certs you need are also
installed in the system's root CA bundle. It would be worth a shot to
test that new functionality out and see if it provides what you're
looking for.
- Rawlin
On Wed, Dec 12, 2018 at 5:40 PM Phil Sorber <so...@apache.org> wrote:
>
> FWIW, I made a tool that handled this all. You could pass it a bundle and
> it would create a minimal chain to install. Would be great if someone could
> find that code and open source it. It was written in Go and could likely be
> integrated into the UI.
>
> Thanks.
>
> On Wed, Dec 12, 2018 at 4:27 PM Gray, Jonathan <Jo...@comcast.com>
> wrote:
>
> > Something to think about, intermediate cert chains are ordered and of
> > indeterminate length if present at all. Also, for a given root CA, there
> > may be multiple variants of intermediate cert chains.
> >
> > Jonathan G
> >
> > On 12/12/18, 9:50 AM, "Howell, Jeff (Contractor)" <
> > Jeff_Howell@comcast.com> wrote:
> >
> > Greetings Traffic Controllers.
> >
> > I have an idea for a change in how SSL certs are managed in TO/TP.
> > Currently we have to concatenate the intermediate certs onto the server
> > cert and paste that into the SSL key interface. As the intermediate is
> > likely the same for the majority of certs in the cdn, it makes more sense
> > to decouple that from the server cert.
> >
> > I’m proposing that a new interface is created in TP to load
> > intermediate certs chains into ATC, creating a library of intermediate
> > certs. In the SSL key interface, intermediate cert chains are selected via
> > dropdown rather than concatenated onto the server cert. This mitigates
> > human error in formatting and certificate ordering.
> >
> > Best Regards,
> > Jeff
> >
> >
> >
Re: [EXTERNAL] Intermediate SSL Certificate Handling
Posted by "Gelinas, Derek" <De...@comcast.com>.
Any idea where we should look? I can go huntin'.
On 12/12/18, 5:40 PM, "Phil Sorber" <so...@apache.org> wrote:
FWIW, I made a tool that handled this all. You could pass it a bundle and
it would create a minimal chain to install. Would be great if someone could
find that code and open source it. It was written in Go and could likely be
integrated into the UI.
Thanks.
On Wed, Dec 12, 2018 at 4:27 PM Gray, Jonathan <Jo...@comcast.com>
wrote:
> Something to think about, intermediate cert chains are ordered and of
> indeterminate length if present at all. Also, for a given root CA, there
> may be multiple variants of intermediate cert chains.
>
> Jonathan G
>
> On 12/12/18, 9:50 AM, "Howell, Jeff (Contractor)" <
> Jeff_Howell@comcast.com> wrote:
>
> Greetings Traffic Controllers.
>
> I have an idea for a change in how SSL certs are managed in TO/TP.
> Currently we have to concatenate the intermediate certs onto the server
> cert and paste that into the SSL key interface. As the intermediate is
> likely the same for the majority of certs in the cdn, it makes more sense
> to decouple that from the server cert.
>
> I’m proposing that a new interface is created in TP to load
> intermediate certs chains into ATC, creating a library of intermediate
> certs. In the SSL key interface, intermediate cert chains are selected via
> dropdown rather than concatenated onto the server cert. This mitigates
> human error in formatting and certificate ordering.
>
> Best Regards,
> Jeff
>
>
>
Re: [EXTERNAL] Intermediate SSL Certificate Handling
Posted by Phil Sorber <so...@apache.org>.
FWIW, I made a tool that handled this all. You could pass it a bundle and
it would create a minimal chain to install. Would be great if someone could
find that code and open source it. It was written in Go and could likely be
integrated into the UI.
Thanks.
On Wed, Dec 12, 2018 at 4:27 PM Gray, Jonathan <Jo...@comcast.com>
wrote:
> Something to think about, intermediate cert chains are ordered and of
> indeterminate length if present at all. Also, for a given root CA, there
> may be multiple variants of intermediate cert chains.
>
> Jonathan G
>
> On 12/12/18, 9:50 AM, "Howell, Jeff (Contractor)" <
> Jeff_Howell@comcast.com> wrote:
>
> Greetings Traffic Controllers.
>
> I have an idea for a change in how SSL certs are managed in TO/TP.
> Currently we have to concatenate the intermediate certs onto the server
> cert and paste that into the SSL key interface. As the intermediate is
> likely the same for the majority of certs in the cdn, it makes more sense
> to decouple that from the server cert.
>
> I’m proposing that a new interface is created in TP to load
> intermediate certs chains into ATC, creating a library of intermediate
> certs. In the SSL key interface, intermediate cert chains are selected via
> dropdown rather than concatenated onto the server cert. This mitigates
> human error in formatting and certificate ordering.
>
> Best Regards,
> Jeff
>
>
>