[unisog] Certificate Authority set-up for your schools?
Christopher A Bongaarts
cab at tc.umn.edu
Tue Oct 8 22:03:36 GMT 2002
As Jerry A. Copus once put it so eloquently:
> We're on the verge of purchasing a certificate for our domain from Thawte
> so we can start implementing some SSL with a pre-established trusted root.
> We're going to start with a "wildcard" 56-bit certificate for our domain,
> but we're naturally planning on expanding that as soon as possible to a
> larger key size etc.
> We're a state University with a number of sister schools. We also have an
> umbrella organization (UW-System) that oversees all of our operations. We
> recently been pushing some cooperative ventures wherein UW-System licenses
> or implements a technology or system that we all share. This seems like a
> natural opportunity to do that with a CA.
> My question is whether other similarly structured state schools have set up
> a central Certificate Authority for all of their schools and what advice
> they can give about licensing the certificates, procedures for issuing
> derivative certificates, and anything else relative to how they use
> certificates (what kind/size etc.).
We don't really have an umbrella organzation (more like we have
several "branch locations" of a single large organization, with
somewhat autonomous subunits), but I think the structure here is
For certs that will be visible on a large scale, such as web server
certs, IMAPS/POPS certs, etc., we use Thawte's SPKI program, where we
actually do the approval for certs issued for our domain(s). This has
worked well for us, although recently they redesigned the program so
it is not as convenient in some ways. This is nice because the certs
are recognized by pretty much every browser out-of-the-box, with no
user education or root CA importation involved. The discount is
substantial (you effectively buy in bulk in advance and "spend" to
issue or renew certs), and we can bill using our internal campus
We do use a wildcard cert for one application (IMAPS/POPS where the
hostname is (username).email.umn.edu, which uses our X.500 directory
to dynamically resolve to one of a set of 6 email servers) where it
would be impossible to use a normal cert. In general, wildcard certs
are a bad idea (they don't work on all server platforms, you have to
share private keys across the systems, etc.) And the companies
issuing them are starting to price them so it doesn't actually save
much money (for 6 servers our wildcard cert cost $10 more than 6
separate certs would have cost).
For other projects, including using certificates for authentication,
we do have some CA's running here, mostly still pilot projects.
We are doing what some are calling "PKI-lite", which is just a fancy
way of saying that we're not making the same kind of legal claims to
validity that are often associated with PKI. We're using OpenSSL for
our CA software, with locally written software to integrate it with
We're not looking to issue web server certs through these CA's, mostly
because web services tend to have global scope, and it is not
reasonable to expect the coffee house down the street to update their
browsers every time your root CA rolls over. On the other hand, this
could be useful for truly local activities (i.e. web-based workflow
applications and such could use a local cert, as you presumably must
train users how to use it and they mostly use it from an office PC
that the department supplies).
Plan to have multiple CA's. You may have most of them subordinate to
a single "root CA", perhaps signed by Thawte/Verisign for oodles of
money, or by CREN for cheaper or free if your institution is a member.
So far it seems best to separate out functional CA's below your
institutional root, then have CA's subordinate to them that actually
sign "end-user" certs.
Don't build a bunch of CA's just to have CA's. Make sure you have an
idea of what you're trying to accomplish before doing so. If all
you're doing is trying to avoid paying for web server certs, that's a
much different problem than trying to issue certs to all of your
students for authentication.
To get an idea of the kinds of things we and other universities are up
to, take a look at these sites:
both of which also have links to lots of other sites on these topics.
%% Christopher A. Bongaarts %% cab at tc.umn.edu %%
%% Internet Services %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
More information about the unisog