Certificates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Certificates

Mark-62
Hi,

I am trying to add SSL to a propriatory tcp/ip application.  I am
reasonably confident in the programming side but I am utterly confused
with regards to certificates.  The more I read about this the more
confused I get :-(

I hope someone can help me understand how to set things up.

We have a client server application which we wish to secure.  As there
are only
a few clients I think we can act as the CA.  I have followed the
examples in
the Book "Network Security with OpenSSL" but do not understand what all
the files
I have created are for.

I would be grateful for some assistance and hopefully I will soon
understand things enough to ask some more specific questions.

TIA, Mark.

ca.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Perry L. Jones
Certificates are a lot like pgp keys with one difference the public key
has be wrapped with the Public Key infrastructure (PKI). So a public
cert will not only contain the public key but it will also contain
information about what the key can be used for (signing, encrypting,
server, client, CA signing, etc..... ) who it was issued to and what CA
signed it (issue DN) it.

If you are going to build a client server application you I am guessing
you will want at lest 3 certificates.

CA - ( self sigen cert )
Client - ( certificate request signed by CA )
Server - ( certificate request signed by CA )

The certificate request is the public key and other information about
the uses (subject DN, etc ...) that gets signed by the CA. After it is
signed by the CA it is a PKI public cert.

Hope this helps a little.

Perry

Mark wrote:

>Hi,
>
>I am trying to add SSL to a propriatory tcp/ip application.  I am
>reasonably confident in the programming side but I am utterly confused
>with regards to certificates.  The more I read about this the more
>confused I get :-(
>
>I hope someone can help me understand how to set things up.
>
>We have a client server application which we wish to secure.  As there
>are only
>a few clients I think we can act as the CA.  I have followed the
>examples in
>the Book "Network Security with OpenSSL" but do not understand what all
>the files
>I have created are for.
>
>I would be grateful for some assistance and hopefully I will soon
>understand things enough to ask some more specific questions.
>
>TIA, Mark.
>  
>
>------------------------------------------------------------------------
>
>
># mkdir $ROOT_DIR
># cd $ROOT_DIR
># mkdir certs private
># chmod g-rwx,o-rwx private
># echo ‘01’ > serial
># touch index.txt
>
>
>Contents of file $ROOT_DIR/openssl.cnf.....
>-------------------------------------------------------------------------------------------------
>
>[ca ]
>default_ca              = testca
>
>[ testca ]
>dir                     = /webserver/opt/testca
>certificate             = $dir/cacert.pem
>database                = $dir/index.txt
>new_certs_dir           = $dir/certs
>private_key             = $dir/private/cakey.pem
>serial                  = $dir/serial
>
>default_crl_days        = 7
>default_days            = 365
>default_md              = md5
>
>policy                  = testca_policy
>x509_extensions         = certificate_extensions
>
>[ testca_policy ]
>commonName              = supplied
>stateOrProvinceName     = supplied
>countryName             = supplied
>emailAddress            = supplied
>organizationName        = supplied
>organizationalUnitName  = optional
>
>[ certificate_extensions ]
>basicConstraints        = CA:false
>
>[ req ]
>default_bits            = 2048
>default_keyfile         = /webserver/opt/testca/private/cakey.pem # Must use full path!
>default_md              = md5
>
>prompt = no
>distinguished_name      = root_ca_distinguished_name
>
>x509_extensions         = root_ca_extensions
>
>[ root_ca_distinguished_name ]
>commonName              = test Test
>stateOrProvinceName     = test
>countryName             = CH
>emailAddress            = [hidden email]
>organizationName        = Root Certification Authority
>
>[ root_ca_extensions ]
>basicConstraints        = CA:true
>
>-------------------------------------------------------------------------------------------------
># OPENSSL_CONF=${ROOT_DIR}/openssl.cnf
>
># cd $ROOT_DIR
># openssl req –x509 –newkey rsa:2048 –out cacert.pem –outform PEM –nodes
>
>
># cd $ROOT_DIR
># unsetenv OPENSSL_CONF
># openssl req -newkey rsa:1024 -keyout nuckey.pem -keyform PEM -out nucreq.pem -nodes -outform PEM
>
># setenv OPENSSL_CONF $ROOT_DIR/openssl.cnf
># openssl ca -in nucreq.pem
>
>
>  
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

dinesh.kallath
In reply to this post by Mark-62
Mark,

I am assuming that you are aware of the need for certificates (need for
public key Cryptography).

Now reg ur query on creating those files to set up a CA, the need for a
CA (in u r client server arch and very simple terms) is to provide all
the clients with some credentials that will provide a level of trust for
the server when a communication channel is to be established and vice
versa if we need client authentication. For this to happen all the
clients must have some credentials (which is the certificate signed by
the CA). This is in general about the need for a CA.

Now the different files u need to create for setting up the CA,

dir                     = /webserver/opt/testca
The dir where u want all the details regarding this ca will be stored...

certificate             = $dir/cacert.pem
Every client or a server can be identified using the certificate
provided by that machine/user. A certificate will contain two parts
public and private keys, as the name implies the public can be provided
to anyone and the private should be kept confidential. Here the CA must
have these keys setup before they could be used as a CA. The file
created here is the ca's public key (public certificate). The pem is the
file format.

database                = $dir/index.txt
This is for the CA to keep a track of all the entities who has requested
CA for the service and who the CA has provided the service. In here the
CA will contain all the clients that they have certified ( certification
is the process of signing the public key with the CA's private key..
Just to provide a trust to other 3rd party tat CA has validated the
credentials provided by this entity and is trustworthy... )

new_certs_dir           = $dir/certs
This dir will contain the list of public keys that this CA has
certified. In your case this will contain all the public key (public
certificate) of u r clients ..

private_key             = $dir/private/cakey.pem
This file will contain the private key corresponding to the cacert.pem
file. (this is the ca's private key)

serial                  = $dir/serial
Every certificate which CA sign's must have a serial number for the CA
to validate any details in future.. This file is created with some
values normally 01. which is like the starting number for the serial
numbers. The serial number gets incremented as and when u use this ca to
sign certificate for u r clients. And each clients are identified by the
serial number by the CA.

I could keep explaining on and on ... But I will leave it now and wait
for u to come back with more specific doubts...  Hope this helped..

Cheers,
Dinesh Kallath


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Mark
Sent: 21 November 2005 15:25
To: [hidden email]
Subject: Certificates


Hi,

I am trying to add SSL to a propriatory tcp/ip application.  I am
reasonably confident in the programming side but I am utterly confused
with regards to certificates.  The more I read about this the more
confused I get :-(

I hope someone can help me understand how to set things up.

We have a client server application which we wish to secure.  As there
are only a few clients I think we can act as the CA.  I have followed
the examples in the Book "Network Security with OpenSSL" but do not
understand what all the files I have created are for.

I would be grateful for some assistance and hopefully I will soon
understand things enough to ask some more specific questions.

TIA, Mark.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
Hi Dinesh & All,

> Now the different files u need to create for setting up the CA,
>

ok, I think understand the purpose of the files cacert.pem (public key),
private/cakey.pem (private key), index.txt and serial.

What I don't understand is what files require signing and what to do
with the private keys that are created as a result of a request.

I have seen many examples which differ.  For example some examples
take the root CA public and private keys and concatenate them
before signing them both.  What is the reason for this?

In addition I am not sure what is involved in creating a certificate for
the client.

I have more questions but I'll leave these for now.

TIA, Mark.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Perry L. Jones
Mark,

I am not sure why you would want to sign the private key but I am sure
there might be a reason some where.

All you should need to sign is the certificate request (cert.req) after
signing the certificate request it is likely that you will want to put
your related certificates and keys into some storage format such as a
pkcs12 keystore.  You don't have to include the CA public certificate
but it is good if you are creating a keystore to include all of the
public certificates in the store up to some trust point (Trusted CA or
self signed Root cert).

cat CA_public_cert.pem new_cert.pem new_cert_private_key.pem >> new_cert.pem

openssl pkcs12 -export -in new_cert.pem -out new_cert.p12

This p12 file should contain all of the information need to create an
ssl connection.

Perry

Mark wrote:

>Hi Dinesh & All,
>
>  
>
>>Now the different files u need to create for setting up the CA,
>>
>>    
>>
>
>ok, I think understand the purpose of the files cacert.pem (public key),
>private/cakey.pem (private key), index.txt and serial.
>
>What I don't understand is what files require signing and what to do
>with the private keys that are created as a result of a request.
>
>I have seen many examples which differ.  For example some examples
>take the root CA public and private keys and concatenate them
>before signing them both.  What is the reason for this?
>
>In addition I am not sure what is involved in creating a certificate for
>the client.
>
>I have more questions but I'll leave these for now.
>
>TIA, Mark.
>
>
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>User Support Mailing List                    [hidden email]
>Automated List Manager                           [hidden email]
>
>  
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
> 1) you create a private key ( this is the secret key ... )
>
> 2) you create a public key corresponding to the private key. This key
> can not be reversed to get a private key, tat is the main advantage of
> public key cryptography.

Ok. I understand this.  Would the following command do these two steps
in one (combined with my openssl.cnf file)?

# openssl req -x509 -newkey rsa:2048 -out cacert.pem -outform PEM -nodes
 
> Effectively these 2 keys are enough for u to communicate to
> any others.
> But there are potential vulnerabilities on using a self signed
> certificate

What are the potential vulnerabilities?

> okie now wat is a self signed certificate.. As of now u
> have only 2 keys pub and priv .. Now u have to convert a pub key to a
> certificate.. Here u create a certificate by signing the
> public key with
> u r private key.. If u do it with the same private key corr to the pub
> key then it is called a self signed certificate.. Confusing..
> Okie think
> it like this..
>
> Pub (mark) -- public key of urs
> Priv (mark) - Private key of urs...
>
> U sign [ pub(mark) ] with the priv (mark) to get a self signed cert..
> There are diff types or cert format .. Some certificate format like
> x.509 does not need a private key to bundle with the public key.. Some
> format like PKCS 12 need both pub and private key to be bundled
> together.. It is not a very gud option to bundle the private
> key because u do not want any one to see u r private key..

I'm not sure what X509 or PKCS12 are.
 
> Now u need to have a certificate signed by a CA.. In this case u will
> send the pub(mark) to the CA and CA signs it with the Priv (CA)..  For
> that CA must verify tat u r public key is derived from u r private key
> else I can impose tat I am Mark..  For this purpose u prob
> use a PKCS 12
> format or even a CSR.. Certification sign request.. This is a format
> which will show to the CA tat the person who has requested the CSR
> contain both pub and priv key...  Make sense !!!! ...

I am beginning to get confused again!  What is a CSR?

The following command seems to create a new public and private key:

# openssl req -newkey rsa:1024 -keyout nuckey.pem -keyform PEM -out
nucreq.pem -nodes -outform PEM

What are these key files for?

How can I create a certificate for a client?

TIA, Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Bernhard Fröhlich-2
Mark wrote:

>>1) you create a private key ( this is the secret key ... )
>>
>>2) you create a public key corresponding to the private key. This key
>>can not be reversed to get a private key, tat is the main advantage of
>>public key cryptography.
>>    
>>
>
>Ok. I understand this.  Would the following command do these two steps
>in one (combined with my openssl.cnf file)?
>
># openssl req -x509 -newkey rsa:2048 -out cacert.pem -outform PEM -nodes
>
>  
>
>>Effectively these 2 keys are enough for u to communicate to
>>any others.
>>But there are potential vulnerabilities on using a self signed
>>certificate
>>    
>>
>
>What are the potential vulnerabilities?
>  
>
Ahh, now I think we are coming back to the thing that seems to confuse
most beginners. There are two problems in cryptography, one is secrecy
(encryption) and the other is authenticity.
The best encryption algorithms will not help you anything if you are
encrypting your data with the key of your evil adversary. If you do this
the evil one can intercept the message, decrypt it with his private key,
re-encrypt it (after having read it) with the true key of your trusted
partner and resent it to him.
So you have to be sure that the public key you are using to encrypt
really belongs to your trusted partner and not your evil adversary. This
is where a CA enters the game. A CA signs other public keys and assures
that they belong to those entities which are described in the
certificate in form of a Canonical Name (CN). So a CA is something like
a government which issues passports so you can be sure that the person
on the other side on the desk is the one described in the passport if
his face is the one on the passport's photo.
If you choose to trust a CA you assume that this CA is doing good work
and will not let itself trick into signing keys of your evil adversary
which contain the CN of your trusted partner. So you do not have to
check all your partner's keys yourself.

Now a self signed certificate is something like someone saying  "I am
your Trusted Partner. You can trust me because I have a passport which I
issued myself". You can believe in this if for example you can check the
key's fingerprints with your partner over telephone. But if you received
the certificate (which, by the way, contains the public keys) in an
unauthenticated eMail this eMail cold as well have been sent by your
evil adversary...

>>[...]
>>    
>>
>
>I'm not sure what X509 or PKCS12 are.
>  
>
Those are standards on how to format certificates and how to package
public and private keys.

> [...]
>I am beginning to get confused again!  What is a CSR?
>  
>
It's a Certificate Signing Request. A file containing the public key and
additional data (for example the CN) about the owner of this key. A CA
should check if those additional data indeed describes the owner and if
it is so the CA can generate a certificate (and send this certificate to
the owner) which the owner of the key can use to authenticate himself
(or herself).

>The following command seems to create a new public and private key:
>
># openssl req -newkey rsa:1024 -keyout nuckey.pem -keyform PEM -out
>nucreq.pem -nodes -outform PEM
>
>What are these key files for?
>
>How can I create a certificate for a client?
>  
>
You described it yourself, by doing "openssl ca -in nucreq.pem". But I
guess your problem is how to use this certificate/key in an application
like an internet browser or mail client. If this is so there are
different ways depending on your application. You should be more
specific on your (client and server) applications...

Hope it helps,
Ted
;)

--
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
Hi,

> Now a self signed certificate is something like someone saying  "I am
> your Trusted Partner. You can trust me because I have a
> passport which I
> issued myself". You can believe in this if for example you
> can check the
> key's fingerprints with your partner over telephone. But if
> you received
> the certificate (which, by the way, contains the public keys) in an
> unauthenticated eMail this eMail cold as well have been sent by your
> evil adversary...

Thanks for the info.  I guess a self signed certificate would be ok for
us since we are developing a client-server application for which we want
to control all the communications.  We need to authenticate the clients
and provide a secure tunnel from end to end.

> >The following command seems to create a new public and private key:
> >
> ># openssl req -newkey rsa:1024 -keyout nuckey.pem -keyform PEM -out
> >nucreq.pem -nodes -outform PEM
> >
> >What are these key files for?

I'm still not sure what these files are for.  I guess that the
nuckey.pem
is a private key (does this need loading with
SSL_CTX_use_certificate_chain_file?).
I guess the nucreq.pem is the public key which requires signing.  Do I
need to sign only this?

> >How can I create a certificate for a client?
> >  
> >
> You described it yourself, by doing "openssl ca -in
> nucreq.pem". But I
> guess your problem is how to use this certificate/key in an
> application
> like an internet browser or mail client. If this is so there are
> different ways depending on your application. You should be more
> specific on your (client and server) applications...

I was trying to create a certificate for the server in the above line
:-)
Is the procedure the same for a client?  I would have thought some of
it must be done on the client otherwise where would the client's
private key reside?

What really confuses me is the examples I have seen which seem to
all be different.  Many seem to concatenate certificate or key files
and I don't know why and whether I should be doing this.

The application is not web based.  We have already developed a server
application which uses a propriatory protocol over tcp/ip. We have
also developed a companion client API (which our clients use). Now
we have the requirement to secure this communication channel hence
the adoption of OpenSSL.

Cheers, Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Katie Lucas
On Tue, Nov 22, 2005 at 09:14:58AM -0000, Mark wrote:

> I'm still not sure what these files are for.  I guess that the
> nuckey.pem
> is a private key (does this need loading with
> SSL_CTX_use_certificate_chain_file?).
> I guess the nucreq.pem is the public key which requires signing.  Do I
> need to sign only this?

There are two halves to the keys. The client (lets call him Fred)
generates a public and a private half.

The public half gets added into the certificate request. That request
gets turned into a certificate (lets call it the "client certificate")
by using the private key of the cert authority.

The public half of the cert auth key is publicly available in their
"self signed" root certificate.

Hence you can look at a certificate, and if you trust the root cert
(which you have to) you now know that that certificate was issued by
them (because only they have their private key to sign it with).

Knowing that their public key is definitely theirs, you now know that
the "client certificate" really does contain a public key matching the
details listed for it. So you're now sure that you have Fred's public
key.

How do you know that the person giving you Fred's certificate is Fred?
After all, certificates are easy to copy.

This is where Fred's private key comes in. Only Fred has it. You now
KNOW you have Fred's public key, so Fred can encrypt something using
his private key and if the certificate's public key decodes it... the
person HAS to have Fred's private key. All you can assume from that is
that he's Fred.

> The application is not web based.  We have already developed a server
> application which uses a propriatory protocol over tcp/ip. We have
> also developed a companion client API (which our clients use). Now
> we have the requirement to secure this communication channel hence
> the adoption of OpenSSL.

This is what we're doing as well.

We're signing the certificates for users. They call up the servers and
present a certificate which authorises them. The root certificate is
stored on the servers, and the fingerprint of it is stored in custom
silicon (so no-one can change the entire heirarchy). This is because
some of the systems are not online and hence can't "call home" to
check they have the correct root CA and one concern is physical
subversion of the CA cert stored on the server's hard drive (both the
users and the servers are out of our physical control, in essence).

The user certificates contain a list of servers they're allowed to
access, along with which IPs they can do it from (so that stealing a
copy of the certificate AND the private key won't let you access a
server illicitly).

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
Hi,

Thanks for all the help everyone.

> We're signing the certificates for users. They call up the servers and
> present a certificate which authorises them. The root certificate is
> stored on the servers, and the fingerprint of it is stored in custom
> silicon (so no-one can change the entire heirarchy). This is because
> some of the systems are not online and hence can't "call home" to
> check they have the correct root CA and one concern is physical
> subversion of the CA cert stored on the server's hard drive (both the
> users and the servers are out of our physical control, in essence).
>
> The user certificates contain a list of servers they're allowed to
> access, along with which IPs they can do it from (so that stealing a
> copy of the certificate AND the private key won't let you access a
> server illicitly).

Could you give me some examples of how this is achieved. I am still
unsure of the exact commands/parameters to use, especially when it
comes to set up the client(s).

Cheers, Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Goetz Babin-Ebell
In reply to this post by Mark-62
Mark wrote:

> Hi,
>
>>> The following command seems to create a new public and private key:
>>>
>>> # openssl req -newkey rsa:1024 -keyout nuckey.pem -keyform PEM -out
>>> nucreq.pem -nodes -outform PEM
>>>
>>> What are these key files for?
>
> I'm still not sure what these files are for.  I guess that the
> nuckey.pem
> is a private key (does this need loading with
> SSL_CTX_use_certificate_chain_file?).
It needs loading with SSL_CTX_use_PrivateKey()...

SSL_CTX_use_certificate_chain_file() loads the CA certificates
that issued your server certificate...

> I guess the nucreq.pem is the public key which requires signing.  Do I
> need to sign only this?
Somehow you have to turn this request in an certificate.
So you need to sign it...

> I was trying to create a certificate for the server in the above line
> :-)
> Is the procedure the same for a client?  I would have thought some of
> it must be done on the client otherwise where would the client's
> private key reside?

There you have a small problem:
In client authentication the server sends a list of CA certificate DNs
it will accept as signer for client certificates...

I don't know if self signed client certificates will work with this...
(could be, because the client certs have them self as issuer)

On the client you generate a client private key and a request.
This request you turn into a certificate.
(you can also use the -x509 option in openssl req to output a self
  signed certificate)
Now you must somehow make sure that the server has access to the
certificate that issued the client certificate:
Either by transporting the clients CA certificate to the server
(in self signed client certs the client cert)
or by transporting the client request to your CA and have it signed
there (and transport the client cert back to the client).

> What really confuses me is the examples I have seen which seem to
> all be different.  Many seem to concatenate certificate or key files
> and I don't know why and whether I should be doing this.

Some programs / examples expect the private key to be in the same
file than the certificate.
This has the advantage to keep both data's at the same place
but the big disadvantage to have the data that must be private
in the same place than the data that must be public...

Bye

Goetz

--
DMCA: The greed of the few outweighs the freedom of the many

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Katie Lucas
In reply to this post by Mark-62
On Tue, Nov 22, 2005 at 01:35:22PM -0000, Mark wrote:

> Hi,
>
> Thanks for all the help everyone.
>
> > We're signing the certificates for users. They call up the servers and
> > present a certificate which authorises them. The root certificate is
> > stored on the servers, and the fingerprint of it is stored in custom
> > silicon (so no-one can change the entire heirarchy). This is because
> > some of the systems are not online and hence can't "call home" to
> > check they have the correct root CA and one concern is physical
> > subversion of the CA cert stored on the server's hard drive (both the
> > users and the servers are out of our physical control, in essence).
> >
> > The user certificates contain a list of servers they're allowed to
> > access, along with which IPs they can do it from (so that stealing a
> > copy of the certificate AND the private key won't let you access a
> > server illicitly).
>
> Could you give me some examples of how this is achieved. I am still
> unsure of the exact commands/parameters to use, especially when it
> comes to set up the client(s).

I wrote a makefile for it;


.PRECIOUS:      %.priv %.req

SSL_ROOT := /home/katie/share/Apps/openssl-0.9.8
SSL_APPS_DIR := $(SSL_ROOT)/apps
OPENSSL := $(SSL_APPS_DIR)/openssl
KEY_LEN:=       512
CA_DIR := ca/
CA_CERTS_DIR := $(CA_DIR)/certs/
CA_CONFIG := $(CA_DIR)/CAss.cnf
CA_PRIV_DIR := $(CA_DIR)/priv/

CLIENT_KEY      := cl.priv
SERVER_KEY      := sv.priv
CA_KEY  := $(CA_PRIV_DIR)/ca.priv

CLIENT_CERT     := cl.cert
SERVER_CERT     := sv.cert
ROOT_CERT       :=  $(CA_DIR)/certs/root.cert

ALL_KEYS        := $(CLIENT_KEY) $(SERVER_KEY) $(CA_KEY)

OPENSSL_CONF    :=      $(CA_CONFIG)
export OPENSSL_CONF

certs:  $(ALLKEYS) $(ROOT_CERT) $(SERVER_CERT) $(CLIENT_CERT) certificates

.PRECIOUS:      %.priv %.req

%.priv:
        @echo "----------------------------------------------------"
        @echo "       Creating a keypair"
        @echo "----------------------------------------------------"
        $(OPENSSL) genrsa -out $*.priv $(KEY_LEN)
        $(OPENSSL) rsa -in $*.priv -pubout -out $*.pub

%.req:  %.cnf   %.priv
        @echo "----------------------------------------------------"
        @echo "       Creating a certificate request"
        @echo "----------------------------------------------------"
        $(OPENSSL) req -config $*.cnf -new -key $*.priv -out $*.req -outform PEM

$(ROOT_CERT):   $(CA_KEY)
        @echo "----------------------------------------------------"
        @echo "       Creating a root certificate"
        @echo "----------------------------------------------------"
        $(OPENSSL) req -x509 -new -days 10000 -key $(CA_KEY) -out $(ROOT_CERT) -outform PEM  -config $(CA_CONFIG)
        $(OPENSSL) x509 -noout -text -in $(ROOT_CERT)

%.cert:         $(ROOT_CERT) %.req
        @echo "----------------------------------------------------"
        @echo "       Signing a certificate"
        @echo "----------------------------------------------------"
        $(OPENSSL) ca -batch -in $*.req -out $*.cert -config $(CA_CONFIG)

certificates:   $(ROOT_CERT)
        mkdir -p certificates
        hash=`openssl x509 -hash -in $(ROOT_CERT) | head -1`;cp $(ROOT_CERT) certificates/$$hash.0

%.reqshow:
        $(OPENSSL) req -in $*.req -text -noout

%.certshow:
        $(OPENSSL) x509 -in $*.cert -text -noout


And then we say "make certs" and it makes the certificates up to date.

You do this;


At the CA end, we create ca.pub and ca.priv which are our keys.
        We turn ca.priv into a self signed root certificate.
        The line involving the "hash" command makes a certificate named by digest (?) which is XXXXXXX.0 which is
                used when you point at a directory for the certs.

Create cl.pub and cl.priv which are the keys.
        cl.priv and cl.cnf (the request configuration) make cl.req which is a certificate request.
        cl.req gets turned into cl.cert by using the ca.cert and ca.priv.

sv.* (the server's end) uses exactly the same processes.


       
At actual connection time, each end loads;

        Its certificate (cl.cert, say) using SSL_CTX_use_certificate_file
                This is presented to the other end.
        Its private key (cl.priv) using SSL_CTX_use_PrivateKey_file
                This is so we can verify we are the certificate holder.
        It then points at the directory containing the digest-named CA certs using SSL_CTX_load_verify_locations
                This is so we can check the other end's cert was signed by the CA we trust.

There's a slight asymmetry in that you have to faff with the
PEER_mumble flags to get the client end to present a cert, and hand
check if one arrived or not (the server end is handled by
OpenSSL). ITSR it's something like you can set failure if a client
cert arrived and wasn't valid, but not if it just didn't send one.

Once all that's happened, both ends are talking to each other, they're
both authenticated, and then we get the certs from the connections using;

        SSL_get_peer_certificate

And then read out verification data using

        X509_get_ext_d2i

etc. All our extension data is just plain strings which we then hand off for more processing.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
Hi,

> >>> # openssl req -newkey rsa:1024 -keyout nuckey.pem
> >>> -keyform PEM -out nucreq.pem -nodes -outform PEM
> >>>
> >>> What are these key files for?
> >
> > I'm still not sure what these files are for.  I guess that the
> > nuckey.pem is a private key (does this need loading with
> > SSL_CTX_use_certificate_chain_file?).
>
> It needs loading with SSL_CTX_use_PrivateKey()...

Thanks.  I was actually trying to load the private key of the root
certificate here.

> SSL_CTX_use_certificate_chain_file() loads the CA certificates
> that issued your server certificate...

In my case is that the self-signed root certificate?

> > I guess the nucreq.pem is the public key which requires
> > signing.  Do I need to sign only this?

> Somehow you have to turn this request in an certificate.
> So you need to sign it...
>
> > I was trying to create a certificate for the server in the
> > above line :-)
> > Is the procedure the same for a client?  I would have
> > thought some of
> > it must be done on the client otherwise where would the client's
> > private key reside?
>
> There you have a small problem:
> In client authentication the server sends a list of CA certificate DNs
> it will accept as signer for client certificates...

Is this done automatically in SSL_accept()?

> I don't know if self signed client certificates will work with this...
> (could be, because the client certs have them self as issuer)
>
> On the client you generate a client private key and a request.
> This request you turn into a certificate.
> (you can also use the -x509 option in openssl req to output a self
>   signed certificate)
> Now you must somehow make sure that the server has access to the
> certificate that issued the client certificate:
> Either by transporting the clients CA certificate to the server
> (in self signed client certs the client cert)
> or by transporting the client request to your CA and have it signed
> there (and transport the client cert back to the client).

I think the latter would suffice since we want to retain control.
It does seem rather cumbersome though.

> > What really confuses me is the examples I have seen which seem to
> > all be different.  Many seem to concatenate certificate or key files
> > and I don't know why and whether I should be doing this.
>
> Some programs / examples expect the private key to be in the same
> file than the certificate.
> This has the advantage to keep both data's at the same place
> but the big disadvantage to have the data that must be private
> in the same place than the data that must be public...

Yes.  That seems very odd to me!

Thanks for the help.

Regards,
   Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
Thanks Katie,

> And then we say "make certs" and it makes the certificates up to date.

I tried your makefile but it did not work for me (I did change the paths
and fix the missing TABs) but it failed with the error. The rule for
%.cert
looks ok to me:

gmake: *** No rule to make target `sv.cert', needed by `certs'.  Stop.

(I use GNU make 3.79).

> There's a slight asymmetry in that you have to faff with the
> PEER_mumble flags to get the client end to present a cert, and hand
> check if one arrived or not (the server end is handled by
> OpenSSL). ITSR it's something like you can set failure if a client
> cert arrived and wasn't valid, but not if it just didn't send one.

What are "PEER_mumble" flags?  I can't find any reference to these.

> Once all that's happened, both ends are talking to each other, they're
> both authenticated, and then we get the certs from the
> connections using;
>
> SSL_get_peer_certificate
>
> And then read out verification data using
>
> X509_get_ext_d2i
>
> etc. All our extension data is just plain strings which we
> then hand off for more processing.

I have a look at the manual pages for these, thanks.

Regards,
   Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Goetz Babin-Ebell
In reply to this post by Mark-62
Mark wrote:
> Hi,
Hello,

>>>>> # openssl req -newkey rsa:1024 -keyout nuckey.pem
>>>>> -keyform PEM -out nucreq.pem -nodes -outform PEM
>>>>>
>>>>> What are these key files for?
>>> I'm still not sure what these files are for.  I guess that the
>>> nuckey.pem is a private key (does this need loading with
>>> SSL_CTX_use_certificate_chain_file?).
>> It needs loading with SSL_CTX_use_PrivateKey()...
>
> Thanks.  I was actually trying to load the private key of the root
> certificate here.
This is only good if the root key is identical to your server key.
(Normally the root key is not available on the server ;-) )

>> SSL_CTX_use_certificate_chain_file() loads the CA certificates
>> that issued your server certificate...
>
> In my case is that the self-signed root certificate?

Yes.
And using an self signed certificate you really don't need
this function:
It is for loading CA certificates that are between the
server cert and the root cert:

root -> CA -> .. -> server

You load the server cert with SSL_CTX_use_certificate_file()
and the CA... certs with SSL_CTX_use_certificate_chain_file()
Normally you don't have to load the root because the
client has to have the root cert to verify the chain...

>>> I was trying to create a certificate for the server in the
>>> above line :-)
>>> Is the procedure the same for a client?  I would have
>>> thought some of
>>> it must be done on the client otherwise where would the client's
>>> private key reside?
>> There you have a small problem:
>> In client authentication the server sends a list of CA certificate DNs
>> it will accept as signer for client certificates...
>
> Is this done automatically in SSL_accept()?
If the server has a list of accepted client CA certs and
sets the flags
SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT|SSL_VERIFY_CLIENT_ONCE
in his SSL_CTX_set_verify(),
handshake fails if the client has no cert signed by a CA
the server set as trusted...

>> Now you must somehow make sure that the server has access to the
>> certificate that issued the client certificate:
>> Either by transporting the clients CA certificate to the server
>> (in self signed client certs the client cert)
>> or by transporting the client request to your CA and have it signed
>> there (and transport the client cert back to the client).
>
> I think the latter would suffice since we want to retain control.
> It does seem rather cumbersome though.

in OPENSSL_DIR/ssl/misc is a demo script that does something like
a very small and dump CA...

Bye

Goetz

--
DMCA: The greed of the few outweighs the freedom of the many

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Katie Lucas
In reply to this post by Mark-62
On Wed, Nov 23, 2005 at 02:41:17PM -0000, Mark wrote:
> Thanks Katie,

> I tried your makefile but it did not work for me (I did change the paths
> and fix the missing TABs) but it failed with the error. The rule for
> %.cert
> looks ok to me:
>
> gmake: *** No rule to make target `sv.cert', needed by `certs'.  Stop.
>
> (I use GNU make 3.79).

It's probably having trouble working out one of the
pre-requisites. make -d should point out what's up.

It's possible I've broken something while fiddling with it since I
last ran the thing from scratch; but the commands should give you an
indication of how to do the transforms. They're mostly just pulled out
of the O'reilly OpenSSL book and names changed.

> > There's a slight asymmetry in that you have to faff with the
> > PEER_mumble flags to get the client end to present a cert, and hand
> > check if one arrived or not (the server end is handled by
> > OpenSSL). ITSR it's something like you can set failure if a client
> > cert arrived and wasn't valid, but not if it just didn't send one.
>
> What are "PEER_mumble" flags?  I can't find any reference to these.

PEER_VERIFY_something.. Can't recall the exact names, sorry..


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
Hi,

> You load the server cert with SSL_CTX_use_certificate_file()
> and the CA... certs with SSL_CTX_use_certificate_chain_file()
> Normally you don't have to load the root because the
> client has to have the root cert to verify the chain...

How does the client get the root certificate?  Is it automatically sent
to the client during the handshake or does the client need to load if
from some file?
 
> in OPENSSL_DIR/ssl/misc is a demo script that does something like
> a very small and dump CA...

I don't seem to have this directory.

Cheers, Mark

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Katie Lucas
On Thu, Nov 24, 2005 at 03:06:05PM -0000, Mark wrote:

> Hi,
>
> > You load the server cert with SSL_CTX_use_certificate_file()
> > and the CA... certs with SSL_CTX_use_certificate_chain_file()
> > Normally you don't have to load the root because the
> > client has to have the root cert to verify the chain...
>
> How does the client get the root certificate?  Is it automatically sent
> to the client during the handshake or does the client need to load if
> from some file?

You point at it in the context before the handshake. You can either
point at a dir full of digest named ones or a specific root cert file.

It CANNOT turn up as part of the handshake; otherwise, the client is
effectively saying "here's my certificate of authenticity, and you can
check it using this certificate..."

It's like when someone turns up and says they're from the electric
company, and hands you a phone number to call to verify that they
are...

You can't trust the phone number, since you don't trust them
yet. Instead you get a phone number from the phone book to call -- in
this case, the phonebook is being the "certificate authority", which
you trust.

It's important that the root cert on the handshakee can't be tampered
with. If it can be replaced by an attacker, they can write "authentic"
login certificates which will pass verification. This is akin to the
intruder printing a new phone book with his accomplice's number in it
and delivering it to you before he attempts to gain entry.

The easiest way of preventing this is to have many copies of your
public root cert about, and have the handshakee go and find one on the
internet and check that the one they have really is the real one.

Since our systems don't necessarily have internet access, we've opted
for putting the root cert's fingerprint in custom silicon; duplicating
the silicon with the fingerprint of a forged root cert is deemed
beyond the means of a reasonable attacker for the system. The CIA
might be able to do it but we're not defending against the CIA.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Certificates

Mark-62
In reply to this post by Mark-62
Hi Katie,

Thanks again for your help.

> > How does the client get the root certificate?  Is it
> automatically sent
> > to the client during the handshake or does the client need
> to load it from some file?
>
> You point at it in the context before the handshake. You can either
> point at a dir full of digest named ones or a specific root cert file.

Strangely I tried the former which did not work.  The latter method
appears to work fine (it connected and exchanged data anyway).

Thanks also for the useful analogies.

Best Regards,
Mark Williams                   Tech OP ltd


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Certificates

Goetz Babin-Ebell
In reply to this post by Mark-62
Mark wrote:
>> in OPENSSL_DIR/ssl/misc is a demo script that does something like
>> a very small and dump CA...
>
> I don't seem to have this directory.

Replace OPENSSL_DIR with the installation path of your openssl
version...

Bye

Goetz

--
DMCA: The greed of the few outweighs the freedom of the many

smime.p7s (4K) Download Attachment
12