Announcing DogTag test instance availability

[Ali Khalidi]

On Fri, Apr 24, 2015 at 7:09 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>
> On Thu, 23 Apr 2015 22:01:06 +0300
> Ali Khalidi <ali.elkhalidi at gmail.com> wrote:
>
> > Hi everyone,
> >
> > An instance of DogTag 10.1.2 is currently available at
> > 209.132.184.223.
>
> Cool. Thanks for setting this up!
>
> > The instance is running a CA for fedoraproject.org
> >
> > a miniHowTO is here:
> > https://doteast.fedorapeople.org/projects/dogtag/dogtag-miniHOWTO.txt
>
> Looks pretty simple to install actually. Much better than I was
> fearing.
>
> > We're in the process of fleshing-out a list of testing
> > scenarios/requirements on how to integrate this within
> > fedora-infrastructure (fedora-cert, etc.) and explore if its going to
> > benefit us.
> >
> > So, if you think this will touch your work/system, benefit it, we
> > would very much like to hear your thoughts.
>
> So, here's our current use cases for ssl certs:
>
> Primary: Koji build system
>
>   fedora-cert is the command line tool to validate and get a new cert.
>
>   Anytime a cert is issued to a user, all previous certs for that user
>   are revoked.
>
>   certs are good for 6 months.
>
>   Additionally we have to issue certs to all the koji builders (as
>   thats how they also authenticate to the hub).
>
>   I'm hazy on if the koji hub needs just to validate certs are signed
>   by the right ca, or if it needs anything more. Perhaps Dennis can
>   chime in here.
>
> So, the questions here:
I'll answer these questions from the perspective of having two
distinct system, then go into measures of integrating the two systems.

> 1. can we interface dogtag to fedora-cert?

Looking at FAS code (both client and server), it looks that
fedora-cert primary depends on FAS server to manage the cycle of
issuing, validating, and revoking user certificates. This brings the
advantage of isolating and abstracting account management
(authentication and authorization) and services (cert issue) from the
client, and consolidating it to where the user database resides.

First, the account database:

FAS uses postgresql, while dogtag "depends" on 389-ds. dogtag uses the
directory to store accounts and uses it for authorizations.


Now, given that we're using FAS as the interface system to the users,
the task of certificate management now becomes FAS/dogtag interaction.
Additionally, since we're using FAS for authentication and
authorization, then this minimizes authentication and authorization
requirement to that of a single account that represents FAS, enabling
it to perform its operations of cert management.

dogtag has three levels of privileges when it comes to our
requirements (there are others, but I'm simplifying matters) : Admin,
Agent, and user. the one or interest, and I choose in my testing was
an Agent. with this privilege, FAS can authenticate to dogtag, and
submit cert enrollment, revoke, renew, and validate (does not need
authorization actually) requests on behalf of users and they get
auto-approved.

So, to summarize, I suppose that interfacing involves modifying FAS
rather than fedora-cert. and looking at FAS code, it seems very doable
using the interfaces provided by dogtag to do so: cli tools, REST API,
and python stubs. even for cert validation using OCSP, which voids the
use of CRLs altogether.

> 2. Can we set certs to expire after 6 months?

in short, yes, this comes out of the box for user certificates.
Moreover, one can tailor the certificate as he pleases (validity
period for this aspect, as well as others) using certificate profiles
and their constrains.

> 3. Can we make dogtag only allow one valid cert at a time for a user?

Yup. FAS uses openssl index file to track certificates. dogtag will be
used as a service to search for the user certificate and revoke/renew
accordingly.

> 4. Can we issue certs to arbitrary names like buildvm-1.phx2.fedoraproject.org?

if you mean by arbitrary, SANs (SubjectAltName extentions) then yes;
also available by default for user certificates, and I don't see why
it can not be added to a server issued certificate.

>
> Secondary use cases:
>
> Currently we have 2 things that use their own CA/Cert setup, fedmsg and
> openvpn.
>
> Does dogtag let you do multiple CAs? I'm not sure we would want these
> to be under the main fedora one, but perhaps thats ok. I'm not sure if
> there's really that much advantage to moving these from the current
> system, but still pondering on the idea.

Well, the way I understand CAs is that they are hierarchical in
nature. they establish a "linage" if so to speak. So, if your question
is about running multiple CAs in the same instance, then I guess no.
But you can have a root CA and a sub-ordinate CA in two seperate
instances (jvms) and they will be linked in a chain.


dotEast2015 ;)

>
> kevin
>
>
> _______________________________________________
> infrastructure mailing list
> infrastructure at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure