How can I act as a Certificate Authority (CA) with openssl ??

I (name David) want to put a secure web server up for a friend (Paul)
to he can access some documents securely for himself, no matter where
in the world he is. Whilst signing the certificate myself (saying I'm
Micky Mouse if I want) is okay for our purposes, I'd like (just out of
interest) to know how to be a Certificating Authority (CA). Somehow I
don't think I will put Verisign out of bussiess, but I'm interested in
the prccess.

http://www.openssl.org/docs/HOWTO/keys.txt

show you how to generate an RSA server key:

openssl genrsa -out privkey.pem 2048

and

http://www.openssl.org/docs/HOWTO/certificates.txt

shown you how to sign it yourself

openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

The latter web site also shows you how to create a certificate
request, to be signed by a CA.

openssl req -new -key privkey.pem -out cert.csr

but there is no mention of what processes the CA will use to sign it -
there is mention of the file ca.txt, but that does not seem to exist.
I assume the CA will need to generate public and private keys for
themselves, then sign your certificate (cert.scr in the above
example), but what is the exact process? Can anyone give me some
openssl commands that will do it?

I want to create certificates for Apache 2.x.


David Kirkby

On 2004-09-27, Dr. David Kirkby <see_my_signature_for_my_real_address@hotmail.co m> wrote:
> I (name David) want to put a secure web server up for a friend (Paul)
> to he can access some documents securely for himself, no matter where
> in the world he is. Whilst signing the certificate myself (saying I'm
> Micky Mouse if I want) is okay for our purposes, I'd like (just out of
> interest) to know how to be a Certificating Authority (CA).

To become a CA you need to 'register' yourself as a CA by submitting
the request to whoever is managing the first-level domain registration
in your country. Every country have different way, but basically they
require that you are a corporation or business body with certain cash
available (aka: you don't disappear in a puff of smoke after 2 years
or so) and you need to follow other guidelines.

And BTW, don't sign your certificate with MM: you'll get sued by
Disney.

Davide

--
A computer without Windows is like a fish without a bicycle

Davide Bianchi <davideyeahsure@onlyforfun.net> wrote in message news:<slrnclhunp.1ij.davideyeahsure@fogg.onlyforfu n.net>...
> On 2004-09-27, Dr. David Kirkby <see_my_signature_for_my_real_address@hotmail.co m> wrote:
> > I (name David) want to put a secure web server up for a friend (Paul)
> > to he can access some documents securely for himself, no matter where
> > in the world he is. Whilst signing the certificate myself (saying I'm
> > Micky Mouse if I want) is okay for our purposes, I'd like (just out of
> > interest) to know how to be a Certificating Authority (CA).
>
> To become a CA you need to 'register' yourself as a CA by submitting
> the request to whoever is managing the first-level domain registration
> in your country. Every country have different way, but basically they
> require that you are a corporation or business body with certain cash
> available (aka: you don't disappear in a puff of smoke after 2 years
> or so) and you need to follow other guidelines.

But as far as I am aware, there is nothing legally (in the UK at
least) stopping me signing a digital certificate, verifying the
identity of someone else, then putting that on a web site. Of course,
whether a third party chooses to trust me is entirely up to them.
Being a 'nobody', I don't suppose others would attach too much weight
to it.

As long as you have a fixed IP (IP address = A.B.C.D), there is
nothing stopping me having a secure server at https://A.B.C.D, without
any domain name, so the point about the top level domain can't really
be valid.

I can see that the cost of certificates might make some companies
think about doing their own. If the securtiy office, or HP department
of a company wishes to sign digital signatures for staff, I can't see
why they should not do so. I'm sure if Microsoft signed their own
certificates, in a way verifyable from the homepage of
www.microsoft.com, that would satisfy most poeple.

I was more interested in this for the technical reasons, rather than
for any other purpose, since the certificate is going to go onto a
site that is password protected, and will only be accessable to 2 or 3
people. So the fact the rest of the world does not trust me, makes no
difference at all.

> And BTW, don't sign your certificate with MM: you'll get sued by
> Disney.

Point taken!

> Davide

David Kirkby

In article <c99d2c79.0409280255.cbb9e6d@posting.google.com> , Dr. David Kirkby wrote:
> But as far as I am aware, there is nothing legally (in the UK at
> least) stopping me signing a digital certificate, verifying the
> identity of someone else, then putting that on a web site. Of course,
> whether a third party chooses to trust me is entirely up to them.
> Being a 'nobody', I don't suppose others would attach too much weight
> to it.

There isn't. From what you said the only reason for you to consider
paying for a certificate is that it might be simpler for you.

The "Mickey Mouse" comment was wrong as well. You might run into a trademark
problem if you were selling certificates using "Mickey Mouse" as the
organization name, but for your own private certs this isn't a problem.

> I can see that the cost of certificates might make some companies
> think about doing their own. If the securtiy office, or HP department
> of a company wishes to sign digital signatures for staff, I can't see
> why they should not do so. I'm sure if Microsoft signed their own
> certificates, in a way verifyable from the homepage of
> www.microsoft.com, that would satisfy most poeple.

The main problem with doing your own and not controlling the browsers
used to access the web site is that people will get scary warnings
from their browser. The browser maker and cert orgs like this since
companies with pay money to the cert companies to avoid scaring away
customers and the cert companies pay the browser companies to include
their certs as trusted by default. The whole thing is a big scam as
it doesn't protect people from going a different site than they meant
that also has a valid cert and it doesn't protect information stored
at the remote site. Most credit card theft from web transactions is
going to come from data that is stored at the remote site, not by
sniffing it in transit.

Bruno Wolff III <bruno@cerberus.csd.uwm.edu> wrote in message news:<slrncljgop.avp.bruno@cerberus.csd.uwm.edu>.. .
> In article <c99d2c79.0409280255.cbb9e6d@posting.google.com> , Dr. David Kirkby wrote:
> > But as far as I am aware, there is nothing legally (in the UK at
> > least) stopping me signing a digital certificate, verifying the
> > identity of someone else, then putting that on a web site. Of course,
> > whether a third party chooses to trust me is entirely up to them.
> > Being a 'nobody', I don't suppose others would attach too much weight
> > to it.
>
> There isn't. From what you said the only reason for you to consider
> paying for a certificate is that it might be simpler for you.

I'm interested in how it is done technically, so finding a simple
solution does not bother me too much. I enjoy technically challenging
things. Throwing money at a problem is not my idea of fun.

Amateur radio (ham radio) has been spoilt by this. Whereas years ago,
everyone built their own equipment and understood it, now that is very
rare indeed. 99.9% of radio hams just go to a shop, spend a fortune
(usually on interest free credit), then plug it all in. Many are
incapable of soldering a plug on the end of a bit of cable. That has
spoit it a lot for me.

> The "Mickey Mouse" comment was wrong as well. You might run into a trademark
> problem if you were selling certificates using "Mickey Mouse" as the
> organization name, but for your own private certs this isn't a problem.

Well, whatever the situation with requard to Micky Mouse, I will not
be doing that. I was only meant as a joke - the term seems to be used
in this way in the UK. We might well say a company is 'a mickey mouse
outfit' indicating they are not very professional.

I once gave a talk about computer security at work (I might not be an
expert, but I know more than most). To get over the point about how
easy it is to spoof emails, I sent everyone an email, that appeared to
come from Micky Mouse.

> > I can see that the cost of certificates might make some companies
> > think about doing their own.

> The main problem with doing your own and not controlling the browsers
> used to access the web site is that people will get scary warnings
> from their browser. The browser maker and cert orgs like this since
> companies with pay money to the cert companies to avoid scaring away
> customers and the cert companies pay the browser companies to include
> their certs as trusted by default.

In my particular instance, the people given access to the site are
friends of a friend, and he only invisages half a dozen or so having
the password. Hence those people will just be told the problem with
the certificate. There is no payment for access to the data - just
free to those who he needs to share it with. As such, in this case,
there is no point at all in him paying for a certificate.

I realise if you are doing credit card transactions there is not much
alternative but to buy a certificate.

But for other uses, there are no doubt occasions where it is viable to
avoid the cost, if the users are warned.


> The whole thing is a big scam as
> it doesn't protect people from going a different site than they meant
> that also has a valid cert and it doesn't protect information stored
> at the remote site.

True. The certificate only verifies who you are - not what your
background is.

> Most credit card theft from web transactions is
> going to come from data that is stored at the remote site, not by
> sniffing it in transit.

True.

What I find a bit odd is the web pages where they ask you to put say
the 2nd and the 4th chaacter of a password. That means the password is
stored in plain text. Whereas if you ask for the whole password, it is
possible (and sensible) to store it in an encrypted format. I can't
see how you can encrypt a password in any half-secure way, if you ask
for part of it.

Dr. David Kirkby.

> but there is no mention of what processes the CA will use to sign it -
> there is mention of the file ca.txt, but that does not seem to exist.
> I assume the CA will need to generate public and private keys for
> themselves, then sign your certificate (cert.scr in the above
> example), but what is the exact process? Can anyone give me some
> openssl commands that will do it?
>
> I want to create certificates for Apache 2.x.

try http://www.modssl.org/docs/2.8/ssl_faq.html#ToC29
the process is the same for apache2 or in fact anything that uses x509
certificates in PEM format.

if you want to delve into the depths of it you might want to have a
closer look at the docs for openssl ca module under

http://www.openssl.org/docs/apps/ca.html#

the general process to set up a ca is to generate key pair, generate
self-signed ca certificate, store private key in a very safe place,
distribute ca certificate to anybody to trust your ca (ideally by
convincing browser manufacturers to put it into their products by
default), sign certificate requests and keep good track of all certs
issued.
if a cert needs to be revoked, a new revocation list should be
published on the locations which _should_ be mentioned under CRL
distribution points in the ca cert asap.

joachim

-----BEGIN PGP SIGNED MESSAGE-----

In article <c99d2c79.0409271558.62e91a5c@posting.google.com >,
Dr. David Kirkby <see_my_signature_for_my_real_address@hotmail.co m> wrote:
>I (name David) want to put a secure web server up for a friend (Paul)
>to he can access some documents securely for himself, no matter where
>in the world he is. Whilst signing the certificate myself (saying I'm
>Micky Mouse if I want) is okay for our purposes, I'd like (just out of
>interest) to know how to be a Certificating Authority (CA). Somehow I
>don't think I will put Verisign out of bussiess, but I'm interested in
>the prccess.
>
>http://www.openssl.org/docs/HOWTO/keys.txt
>
>show you how to generate an RSA server key:
>
>openssl genrsa -out privkey.pem 2048
>
>and
>
>http://www.openssl.org/docs/HOWTO/certificates.txt
>
>shown you how to sign it yourself
>
>openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
>
>The latter web site also shows you how to create a certificate
>request, to be signed by a CA.
>
>openssl req -new -key privkey.pem -out cert.csr
>
>but there is no mention of what processes the CA will use to sign it -
>there is mention of the file ca.txt, but that does not seem to exist.
>I assume the CA will need to generate public and private keys for
>themselves, then sign your certificate (cert.scr in the above
>example), but what is the exact process? Can anyone give me some
>openssl commands that will do it?
>
>I want to create certificates for Apache 2.x.
>

_ You should check out the globus toolkit stuff, it includes
a very simple-minded interface to all this stuff so you can
easily setup your own CA for testing.

http://www.globus.org/


_ Booker C. Bense


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBQWRXSGTWTAjn5N/lAQHgiwQAtak9vmxJtc++k3ltK9RTu2Iwj+NIu0Yd
yYAfpxU+owslxk8cyN3+XkVxwxR7SDsQYp8eSCxUYHxnKchMEU eZ8Xl4U0rsrIoL
AUJl54VbdLJEIEdfz+hV76Y8UNtwKGIb43ThfxXyHxMDq9tI7J GRxSut09Dk87wo
xsb3c3STGNU=
=4Rzd
-----END PGP SIGNATURE-----

see_my_signature_for_my_real_address@hotmail.com (Dr. David Kirkby) writes:
> I (name David) want to put a secure web server up for a friend
> (Paul) to he can access some documents securely for himself, no
> matter where in the world he is. Whilst signing the certificate
> myself (saying I'm Micky Mouse if I want) is okay for our purposes,
> I'd like (just out of interest) to know how to be a Certificating
> Authority (CA). Somehow I don't think I will put Verisign out of
> bussiess, but I'm interested in the prccess.

the whole point of a digital certificate is so that a relying party
that otherwise doesn't have any knowledge about the originating party
.... can equate the originating party's public key with something about
the originating party.

normally in public key infrastructures where there is some
relationship and knowledge that exists between the relying party and
the originating party .... the relying party has a table of public
keys with information about their respective owners. This is
effectively the PGP model. It has also been the standard industry
business model for userid/password authentication system for scores of
years ... and can be applied to public key infrastructures by
replacing the "password" in the authentication tables with public keys
(aka radius, kerberos, password tables, etc).

in a certification environment ... the relying party's public key
tables, instead of containing the public keys and information directly
about originating parties .... contains public keys and information
about certification authorities (and the relying party has absolutely
no way of obtaining information directly about the originating party).

the relying party is totally dependent upon and trusts the
certification authority for providing information about the
originating party in the form of digital certificates.

to be a certification authority there then are at least requirements for

1) manufactoring the digital certificates
2) establishing trust with the relying parties that they are dependent
on the certification authority for supplying the information about the
originating party
3) loading the certificate authority's public key in the relying
parties authentication table

i.e. the relying parties have to trust the certification authority to
provide the information about the originating party (in lieu of the
relying party having the information directly about the originating
party) and the relying parties have to have the certification
authorities public key loaded into their authentication table (in lieu
of directly loading the public key of the originating parties in their
authentication table).

in the past, there has been mention of PKIs ... where the certification
authority both manufacture certificates for arbritrary distribution
and provide a mechanism for managing those certificates.

many of the infrastructure are purely certificate manufactoring
operations as opposed to real PKIs ... and, in fact, I coined the term
certificate manufactoring in the mid-90s to differentiate from true
PKIs.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/