Stefan Holmstr�m Q (KI/EAB) wrote:
Hello,
What I am looking at is creating and installing certificates for IPSec devices in a production enviroment.
yeah, depends ;o) - if they can speak scep (a special cisco protocol)
than you will be able with the 0.9.2line of openca and maybe with some
non-scep-enabled devices which are linux/bsd based with support of sscep
to nearly automate the whole process - with centralised management and
distributed requesting for each device
BUT - like always - and this is a big ONE
you have to plan this very carefully and setup the especially the ca
very safe - cause you would like to enable the batch feature of it
to get this all automagically working
this statement meas: it would be possible to get those structures
working, but there is some work behind and at least some extensive
testing, to make sure this system would do what is supposed to do - and
not accidentially issuing certs for entities you won't like to have one...
Generating a uniqe certificate for every device and installing it in a prodcution line will be rather time consuming so I'm trying to figure out what the options are.
depends - if you have a kind of centralised database/ldap system with
all those devices
you can automat the process of certificate generation - even the
key-pairs... the question would than be how to get the keys and the
certs to the devices...
Must the certificate request generated by RA be signed by the CA before it can be installed into the device?
yes, this is the basic ideas behind a certificate
you have bob, alice and the ca
bob and alice trust this ca to be trustworthy to do some things
- check if the request is ok
means:
- check if the device is the device it tells it would be
- check if this device is allowed to request this certificate
- check if this device is allowed to get those rights/attributes in
the certificate
- keep its key-pair safe
means:
- only authorized personal can access the keys and do signing
- or at least no-one can get access to it, if we talk about
automatized pki-structures
- so only the suspected entities can get valid certificates
now bob requests a certificate - the ca issues it - means signing the
request, eventually changing attributes and lifetimes...
now alice is a gatekeeper somewhere who also trusts this ca, like
mentioned, those alice just have to look if the cert is timly valid, the
signing is ok and this cert isn't on any crl (means invalidated before
its time runs out) - so the gatekeeper can just control without any
internet connection in the wortst case... and makes is decission
you have to make up in which timeframes it would be safe to make an
decission without beeing able to ask for a new crl for example and so
on... because, in case there happend something and device-bob isn't
allowed anymore to bypass this gatekeeper - it takes time to get this
processed at the ca - issue new crl (or update ocsp-data and devices)
distribute it...
and bob as the device can check if this is the real gatekeeper alice
and it is safe to send data to it...
a certificate is actually some data structure which has:
- attributes
- public key of bob
- singed by ca
so - you can only have a certificate after signing through the ca ;o)
before that point, there is no certificate (just you sign it yourself,
but this doesn't makes sense - maybe for testing something *g* - in this
realtion at least... sometimes its usefull)
The ideal would be if the device can request a certificate from a production site RA/CA and then download it to the device and the CA database is transported to the "real" CA but this requires that the production setup is an exact match to the real CA considering address, CA public key, certificate serials, right?
yes, like stated in the beginning, there are options to get this
working, but even those options still require manual interaction at
least at this device itself...
the way to go would be something like scep (simple certificate
enrollment procotol), it allows you handle the request and reciving of
certificate completly at client side, and the ra/ca things can be
automated if you do some preparation in front of the process
(means: the ra/ca musst know either the diveces somehow and a secret for
each, to decide if an request should be processed or not..., this can be
done, like stated, when you have some kind of database where the ca can
get those informations from)
cisco devices usally can speak scep, if they are ipsec enabled,
linux/bsd based stuff can use sscep to achive this functionality
other devices could get more difficult to manage, since openca does not
support other certificate enrollment procolls at the moment
an alternative could be (if possible) to implement at the client some
functionality which is able to communicate though the webinterface of
openca... but i think it would be easier to integrate sscep in this case
Using the real CA (e.g. request is sent when customer plugs it in) presents a problem since the only thing uniqe is the serial number and then anybody can get a valid certificate as long as they provide a correct serial number.
usaly - if you generate keys at ca level - you protect the keys with
passphrases, so an serial would only be enough to get the certificate
but a certificate itself is a thing that is supposed to be public and
accessible by anyone, since it just assigns the public key of an key
pair to an identity - so anything signed by the corresponding private
key can be trustworthy traced back to this identity (supposed, the
private key is safed, so it can only be used through this identity, but
this a key idea of pki and certificates)
on the other side, you just generate keys at the device - maybe the
devices are able to handle smartcards or usb-based-tokens than you can
safe those keys even more simple for accessing through entities which
shouldn't get access to it...
One idea I have is to install one batch certificate e.g. same pulic key and then the CA would be able to match the certificate with the serial number and complete the certificate, or issue a new one?
this isn't a good idea ;o)
greetings
dalini
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
_______________________________________________
Openca-Users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-users
