As of freeVSD-1.4.8 it is possible for freeVSD to be installed into a
virtual server, this allows a virtual server owner to run vsd-genca and
create her own certificate authority just a hosting server owner can. She
may then generate signed certificates to allow authenticated access to
adminsister domains using a windows client. It should be possible to use the
same VSD CA to generate certificate/key pairs for use with HTTPS but this
isn't something I have tried yet. Using the existing vsd-ca command set it
is possible to generate valid certificates with any specified CommonName
based on the /etc/vsd/openssl.cnf file. In freeVSD-1.4.8 the example
openssl.cnf had, for simplicty, been considerably stripped down and tweaked
from the default file supplied with OpenSSL. This meant that many of the
extension features, which are used by browsers but not utilised by freeVSD,
were not present and this may well cause problems if you attempt to use the
resulting certifates for HTTPS.
With the freeVSD-1.4.9 code (availabler via CVS) VSD CA has been
considerably enhanced (see the freeVSD-1.4.9 INSTALL document) and all SSL
support in freeVSD now properly references a single openssl.cnf file. This
file can now include all valid extensions, in fact the default openssl.cnf
file supplied with OpenSSL can be used successfully with freeVSD, though the
version incldued in the distribution is preferable. This VSD CA should
produce all the files necessary for use with Apache mod_ssl, but it is not
something I have tried yet. Having had a quick look at the http/conf/ file
structure I would say:
ssl.key/snakeoil-ca.key is equivalent to /etc/vsd/ca/private/cakey.pem
ssl.key/snakeoil.key is equivalent to /etc/vsd/certs/<server>.key
ssl.crt/snakeoil-ca.crt is equivalent to /etc/vsd/ca/cacert.pem
ssl.crt/snakeoil.crt is equivalent to /etc/vsd/certs/<server>.crt
It should be just a matter of taking the files from your self-signed VSD CA
and placing them (or linking them?) into the httpd.conf structure, or
modifying httpd.conf itself to reference the files themselves...
I did notice that the snakeoil.key file is in a different format to that
produced by VSD CA - this may be something that needs resolving.
The only problem with using certificates from a VSD CA for HTTPS is that the
browser will deem the certificates are coming from an untrusted source, and
various warnings and messages will result. The only solution to this is get
your certificates signed by a Trusted Authority, for a fee. At present I do
not believe there is any way round this...
Anyway, all this assumes you want to use the VSD CA interface which is
intended to simplify the whole certificate handling operation, but the
initial task has been providing authenticated access for VSD clients. I do
intend to make the whole thing more amenable to managing certificates/keys
for more general purposes, including Apache sites, and properly handling
certificate requests. I intend to base some of my work on the information
provided here: http://cognac.epfl.ch/SIC/SL/CA/ which should give you the
knowledge you seek.
If you can't wait for me to get round to it, (and it will be at least a
month as I am taking a fortnight off soon), feel free to get stuck in
yourself - just give me some feedback on how best it could be incoproated
into the VSD CA.
Tim
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Reid
> Sent: 09 June 2001 15:26
> To: [EMAIL PROTECTED]
> Subject: SSL cert generation in VS
>
>
> Hi
>
> Should it be possible for a VS admin to create a cert/key for a
> virt domain
> in his VS (IP based not name based)? Or even gen info for a VS
> cert for the
> main site on the VS. There is the 'snake-oil' key/cert etc. This is on an
> rpm/pre-built-skel VSD host and I do mean a cert for https connections to
> 8443 not for the windows client to 1726.
>
> We would usually use
>
> openssl req -new > new.cert.csr
> openssl rsa -in privkey.pem -out new.cert.key
> openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey
> new.cert.key -days 365
>
> we get:
>
> bash: new.cert.csr: Permission denied
>
> Thanks
>
> gary
