First of all thank you for the help....
But i have a few questions about this .......
In the scenario that i mentioed earlier, both sides (A and B) should have 3
files (private key, x509 public cert and ANOTHER FILE) but i don't
understand which one is this third file....
i mean, i generate my private key which i use to generate the x509
certificate (which is public) but i've been told that i must generate a
third file which is used by the other side to decode the data that i encode
!!!
look.... they have sent me their tow files and told me that i must have two
other files like these:
1) Their public certificate (like my x509 cert)
/***************************************************************************
*****************/
Bag Attributes
localKeyID: 01 00 00 00
subject=/C=AR/ST=Capital Federal/L=Buenos Aires/O=Red Link S.A./OU=Digital
ID Class 3 - Microsoft Software Validation v2/OU=Security/CN=Red Link S.A.
issuer= /O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)01/CN=VeriSign Class 3 Code Signing 2001 CA
-----BEGIN CERTIFICATE-----
MIIEMjCCA5ugAwIBAgIQCTaXUtm0cwi74ojE2ZMqtDANBgkqhkiG9w0BAQUFADCB
etc...etc...etc...etc...etc...etc...
wnPelrFcuwH5qn+5+8tdb9rxups9Iw==
-----END CERTIFICATE-----
/***************************************************************************
*****************/
2) The file that i must generate!!!!!!
/***************************************************************************
*****************/
Bag Attributes
friendlyName: VeriSign Class 3 Public Primary CA
subject=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
-----BEGIN CERTIFICATE-----
MIICPDCCAaUCEHC65B0Q2Sk0tjjKewPMur8wDQYJKoZIhvcNAQECBQAwXzELMAkG
etc...etc...etc...etc...etc...etc...
AA9WjQKZ7aKQRUzkuxCkPfAyAw7xzvjoyVGM5mKf5p/AfbdynMk2OmufTqj/ZA1k
-----END CERTIFICATE-----
Bag Attributes: <Empty Attributes>
subject=/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)01/CN=VeriSign Class 3 Code Signing 2001-4
CA
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
-----BEGIN CERTIFICATE-----
MIIDqjCCAxOgAwIBAgIQSik+nR2MQH8XSf99YV+OdTANBgkqhkiG9w0BAQUFADBf
etc...etc...etc...etc...etc...etc...
vMdUk0D8tmtXD6Ev9Hm1aieQvnv8jqd8ZUpkLxwB
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDqDCCAxGgAwIBAgIQcXhM689aayNup9rl9TfKuDANBgkqhkiG9w0BAQUFADBf
etc...etc...etc...etc...etc...etc...
MtLj7F55Piy7+m8rmY4f5kOegPtWr7OzRCNoZA==
-----END CERTIFICATE-----
/***************************************************************************
*****************/
> -----Original Message-----
> From: Marcus Carey [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, May 27, 2003 12:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cannot generate Certificate!! HELP !!!!!
>
> Here is some information to get you started also look in the demo
> directory
> of the Openssl distribution.
>
> First you have a main/root CA. It's generated the way you generate your
> cert.pem - a self signed certificate. The key should be protected with a
> long passphrase. The certificate is root.cert and the key which is the
> most private thing is root.key and keeped in a very safe place.
>
> openssl req -new -x509 -out root.cert -keyout root.key
>
> The certificate is public to anyone involved with this client/server app
> --
> both clients and the daemon.
>
> The server application needs a certificate which should be signed with the
> root.cert:
>
> openssl req -new -out daemon.req -keyout daemon.key [-nodes]
> openssl x509 -req -in daemon.req -out daemon.cert -CA root.cert -CAkey \
> root.key -CAserial root.srl -CAcreateserial
>
> (root.srl is a file containing a serial number, the application does not
> need it (does it?))
>
> Now you have the key for the daemon with a signed certificate by the root
> CA.
> You can create the key with the -nodes option -- it won't be protected!
> But
> for an automated application you don't need it actualy.
>
> The daemon.key is private, available for read only to the daemon. The
> signed
> certificate daemon.cert is public to all clients.
>
> To allow a client to connect you must have access to the root.key AND you
> must know the passphrase:
>
> openssl req -new out client1.req -keyout client1.key
>
> While creating the request certificate you're asked for the subject
> fields,
> e.g. country, state, location, etc. I think you can use your own subject
> format, but I'm OK with this one. Maybe tweaking with openssl.cnf could
> help.
> The subject is important - it contains a name and/or e-mail which
> determines
> the user in the application (i use common name as the username in the
> daemon).
>
> openssl x509 -req -in client1.req -out client1.cert -CA root.cert -CAkey \
> root.key -CAserial root.srl
>
> Now you have a client's key/certificate pair. The client should keep his
> key
> in private place and should not tell the passphrase to anyone.
>
> What we have:
>
> root.key
> This is used only by the person who creates accounts for the
> application.
>
> root.cert
> This is public to anyone who needs to verify the peer (the daemon
> uses it to verify the clients and the client's application uses it
> to verify the daemon).
>
> daemon.key
> This is private to the daemon only and might not be protected by
> a passphrase.
>
> daemon.cert
> This is public to anyone. Client's application can use it to
> verify
> the daemon besides checking the root.cert signature.
>
> clientX.key
> clientX.cert
> Both of these are kept by the user. The certificate is not that
> private, but for a stupid client it's easier to remember to not
> give anything to anyone :)
>
> Well, for the coding part:
>
> The daemon application:
>
> SSL_CTX_load_verify_locations(ctx, "root.cert", NULL)
> This sets the location of the root CA. Every client's certificate
> will be checked if is signed with it.
>
> SSL_CTX_set_default_verify_paths(ctx)
> I don't know what this does but apps/s_server.c uses it no matter
> if
> CApath is NULL or not.
>
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT
> |
> \
> SSL_VERIFY_CLIENT_ONCE, func)
> This sets the verification method to be very strict. The last
> 'func'
> parameter is the function which will be called if the peer cannot
> be
> verified. If you want to discard any suspicious client, set it to
> NULL. Currently I'm using it for debugging reasons - just showing
> the
> error.
>
> SSL_CTX_use_certificate_file(ctx, "daemon.cert", SSL_FILETYPE_PEM)
> Load the daemon's cert.
>
> SSL_CTX_use_PrivateKey_file(ctx, "daemon.key", SSL_FILETYPE_PEM)
> Load the daemon's key. If it's protected you need to call
> SSL_CTX_set_default_password_cb() as explained in the html manual
> on www.openssl.org.
>
> SSL_CTX_check_private_key(ctx)
> Use it to check if the certificate and key match.
>
> SSL_CTX_set_client_CA_list(ctx, SSL_load_client_CA_file("root.cert"))
> This function loads all certificates from root.cert. They will be
> sent later to the client (during SSL_accept) when he's requested
> for a signed certificate.
>
> You can have more than one root CA and can give different
> privileges
> to users with different issuers (the issuer is the one who signed
> the
> client's certificate)
>
> Next you create the SSL connection, accept it, and
>
> SSL_get_verify_result(ssl)
> Returns X509_V_OK if the client's certificate is signed by one of
> the
> certificates in root.cert (if you have more than one). If the
> function
> returns something else, you should immediately disconnect the user
> and
> log his address and port.
>
> Next you can get the certificate subject (the fields you fill in when
> creating
> the client's certificate request) or you can get the certificate issuer
> (this
> is the fields you fill when creating the root's certificate) and give the
> user
> different access privileges.
>
> client_cert = SSL_get_peer_certificate(ssl);
> It's good to check this for NULL. Actualy, it's good to check
> EVERY
> function if it behaves normally.
>
> subject = X509_NAME_oneline(X509_get_subject_name(client_cert), 0, 0)
> I don't know what this exactly do, there's no docmentation, but
> you
> get a char * pointer to a ASCIIZ string (normal C string) with the
> subject. I don't know if you should free it when done using it.
> Currently, I'm forking for each client and do not care for such
> long-term memory leaks.
>
> issuer = X509_NAME_oneline(X509_get_issuer_name(client_cert), 0, 0)
> This gives you the root CA's subject.
>
> Marucs
>
> ----- Original Message -----
> From: "Sebastian Muņiz" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 27, 2003 7:50 AM
> Subject: Cannot generate Certificate!! HELP !!!!!
>
>
> > People,
> > This may be a stupid question but i'm really desperate cause i've been
> asked
> > for a file that should be generated with the openssl command line tool
> but
> i
> > don't know how to do this. I'll explain the scenario so you can
> understand
> > my problem:
> > I've been given a set of functions to encode and decode and it is used
> by
> > both sides (A and B), so A uses then "encode function" the data with A's
> > private key & B's Public Key.
> > Then when side B recieves the encoded data, it uses the "decode
> function"
> to
> > decode the data and should supply as parameters B's private key and
> another
> > file (which is the file i don't know how to generate) ...
> > The files that i have generated by the moment are:
> > * My private key
> > * My x509 Certificate ( that I have sent to B so they can encode data)
> > ---- I have to say that they asked specifically for an x509
> certificate
> > ----
> > !!!!!!!!! But B's people is still asking for another file to decode the
> data
> > !!!!!!!!!!!
> >
> > Thanks in advance!!!
> >
> > Sebastian
> >
> > ELINPAR S.A. - Serv. Prof.
> > ====================
> > Btme. Mitre 797 4to
> > Tel.: (011) 4393-3423
> > Int.: 6470
> > Cod. Postal: C1036AAM
> >
> > ______________________________________________________________________
> > OpenSSL Project http://www.openssl.org
> > User Support Mailing List [EMAIL PROTECTED]
> > Automated List Manager [EMAIL PROTECTED]
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.481 / Virus Database: 277 - Release Date: 5/14/2003
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
