On Sat, May 10, 2008 at 12:52:38PM -0700, scott learmonth wrote:
> I currently have numerous OpenBSD devices acting as FW/routers, [and]
> IPSec using ipv4 publickeys.
>
> I'm now ready to dive into the world of Road Warriors using OSX and
> Windows. (...) I'm pretty much forced to use an x509
> certificate structure, as copying around pubkeys is already getting
> annoying. In addition, OSX and Windows seem to have some choices and
> structure in place for signed certs and not much else that is easily
> configured.
>
> 1) Would you gurus suggest running my own CA, or using cacert.org? I'm
> not scared of rolling my own structure, but I also appreciate what
> cacert.org is trying to accomplish in the world of Verisign, etc.
>
> 2) If I roll my own, from a security standpoint, should my CA be a
> separate device, dedicated only to being a CA? What are the security
> ramifications of using an existing device (one of my OpenBSD
> firewalls) as the CA, or is it technically impossible (see 3) below)?
>
> 3) If I roll my own, from a technical standpoint, does my CA need to
> be a unique and separate device, ie is it required to be a third party
> in isakmpd negotiations?
[Note: this is pretty technical. If you don't understand something, feel
free to ask!]
I am somewhat confused by your third question. Signing certificates
("being a CA") requires that you have a CA certificate and the
associated key. Verifying certificates requires only the CA certificate.
isakmpd only verifies certificates.
Thus, your CA can be on a different machine or on the same machine. In
fact, it's possible, although not smart, to configure isakmpd to accept
all Verisign-signed certificates.
As to the rest of your questions...
The short answer:
I would recommend using a private self-signed CA on your gateway to
generate client certificates. Do include a revocation URL
(nsCaRevocationUrl in openssl.conf). Use cacert.org (or Thawte, or ...)
certificates for all external services (the VPN gateway, any HTTPS
servers, etc).
This is easy to set up, easy to maintain and pretty secure.
(Note that getting a cacert.org CA takes some work, and you can use
"normal" certificates here.)
The long answer:
If you issue only certificates that can only be used to connect to your
systems (no server certificates, no S/MIME, etc), you can use a
self-signed CA. Only you will ever trust those certificates anyway, and
it saves a bit of work.
Note that there is no requirement to use the same CA for VPN clients and
your own services. You could stick your "client CA" on the gateway
without major problems. (Assuming that client certificates only give
access to the gateway, and the CA can only be compromised by
compromising the gateway, this does not reduce security. On the other
hand, you do need to issue every VPN client a new key if your CA is
compromised, so keeping your CA secure does make a break-in less
painful.)
If you generate certificates that can be used with external systems
(server certificates are the obvious choice, but certificates that can
be used for S/MIME or to gain access to a third-party system also
qualify), you will need a proper infrastructure.
You could generate a root CA (where "root" is relative to your private
infrastructure - in this case, it is a good idea to have it signed by
cacert.org) and use that to sign one or more "signing" CA's. People can
then trust the root CA, which should be kept absolutely secure. (Print
out the private key and put it in a safe, or somesuch.)
Keep your signing CA as secure as is reasonable. Using a separate system
is best; booting a clean, non-networked system off a USB key or somesuch
is second-best; if neither is practical, stick it on a high-security
system like a firewall. If this CA is compromised, you can generate a
new signing CA.
This is possible, but it's likely to be more trouble than it is worth in
your case. Unless you like playing with crypto, of course.
Joachim
--
TFMotD: calendar (1) - reminder service
