[lopsa-tech] Certificate Authority Software / Single Sourcing Machine Identities

[Daniel Clark]

Does anyone has anything good (or bad) to say about any of the
certificate authority management applications such as OpenCA and
EJBCA, or pointers to best practices type documents regarding running
certificate authorities in general or with a certain piece of
software?

In a recent lopsa-discuss thread [1], Lamont Granquist wrote "[...]
What I wind up with is having to maintain puppet/cfengine SSL certs,
/etc/krb5.keytab files and the ssh_known_hosts file with a pile of
glue code around them that I write as a one off.  Why all the
duplication? Why is this so hard?"; however after that the discussion
mostly went in other directions.

I am also running into this problem now that I am looking into setting
up IPsec; my current state of confusion is documented here [2].

So far the choices looks like (a) run a Kerberos Realm (which I
already do) and set up a SSL certificate authority, or (b) try to use
KCA (Kerberos CA) as a SSL CA for longer-term SSL certs [3].

The later option looks like it could be great, but also looks like it
might require someone with more low-level protocol and C knowledge
than I possess. Is anyone using KCA in this manner, or know of any
technical barriers to its use?

The only doc I could find was at Fermilab [4], which implies that
there is a 7 day limit to certificates created in this manner; but
that may only be due to Fermilab policy.

[1] [lopsa-discuss] Trying to kick-start O'Reilly's sysadmin space
http://lopsa.org/pipermail/discuss/2007-February/001977.html

[2] Towards a single PKI for Configuration Management
http://opensysadmin.com/trac/wiki/PkiSecurity

[3] KX.509 for IPsec / as a SSL CA
On 4/5/07, Kevin Coffman <kwc at citi dot umich dot edu> wrote:
> > Is there anything inherent in kx.509 that make the x.509 certificates
> > produced by Kerberos suitable only for short-term use (e.g. could I
> > tweak a few settings and get a SSL cert good for a year or two)? I
> > understand the short-term model in the intended use (web
> > certificates), but there are many other places that SSL is used where
> > it would be useful to have Kerberos be a single source of machine and
> > user identity information.
>
> You could do this.  By using short-term certs we were avoiding
> issues with revocation.  If you want to ignore those issues
> there is nothing that I am aware of that limits the certificates
> issued by the kca to be short-term.
>
> If you want to do revocation checking, you'll have to add the
> appropriate extensions to the issued certs.  Being able to do
> that with a config file rather than requiring modification of
> the source code is something I'd like to see, but finding the
> time has been a problem...
>
> > Specifically I ask because I'm looking into deploying IPsec; while
> > there are some IPsec implementations/platforms that support Kerberos
> > directly, many do not. It would be great to leverage our existing
> > Kerberos infrastructure as a SSL CA rather than set up one of the CAs
> > like EJBCA, which requires a whole stack of Java crud to work.
> >
> > BTW is there a mailing list or anything like that for KX.509 around?
>
> The source code is now up on sourceforge, which also has a mailing list.
> However, it hasn't been advertised very well.
>
> http://sourceforge.net/projects/kx509
> http://sourceforge.net/projects/kpkcs11

[4] Fermilab Kerberos Certificate Authority (KCA)
http://security.fnal.gov/pki/what_is_cert.html#kcacert

--
Daniel Clark # http://dclark.us # http://opensysadmin.com