Sebastian Use their public key to encrypt the data. When they receive the data they will use the same key to decrypt the data. So all you need is their private key.
Marcus ----- Original Message ----- From: "Sebastian Muņiz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Marcus Carey" <[EMAIL PROTECTED]> Sent: Tuesday, May 27, 2003 12:04 PM Subject: RE: Cannot generate Certificate!! HELP !!!!! > 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] > --- 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]
