how to generate key pair at client browser (IE)
Title: Message Hi, I have a requirement like this. Users/clients will access a web site, fill in a form, generate a keypair and send it to server. the csr is done at the server. client cert is created in the server and sent back thru email. Is this a proper approach ? If so, I would like to get some help in constructing the setup. I have openssl ready and working. Only thing is web (site) interface for the html form. Also, how to generate the keypair at the client (browser) ? I cant find that certenr3.dll. Is there any other java/javascript program to do it without depending on microsoft dlls ? Any help will be highly appreciated. First I would like to try generating key pair with just a html page in Win2K. regards Sarath
Re: how to generate key pair at client browser (IE)
Sarath Chandra M wrote: Hi, I have a requirement like this. Users/clients will access a web site, fill in a form, generate a keypair and send it to server. the csr is done at the server. client cert is created in the server and sent back thru email. Is this a proper approach ? If so, I would like to get some help in constructing the setup. I have openssl ready and working. Only thing is web (site) interface for the html form. Also, how to generate the keypair at the client (browser) ? I cant find that certenr3.dll. Is there any other java/javascript program to do it without depending on microsoft dlls ? Any help will be highly appreciated. First I would like to try generating key pair with just a html page in Win2K. You use Xenroll, info on MS site new MS OSes have Xenroll installed as standard. The CSR must be created on the client (which is what Xenroll can do) because only it has access to the private key. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openssl-users@openssl.org
Title: °Ù´óǧÀïÂí ÏàÖªÔÚ°Ù´ó ;;; ;;; ;;; ;;; ;;; ;;; ;;; ;;; ;;;
Re: PKI book in relation to VPNs
On Wed, 5 Dec 2001, Matt Sauve-Frankel wrote: maybe I should have targetted SSL and TLS differently :)) God forbid, your book is about as good as it ever gets... thank you for writing it, it's a gem... Hear, hear! There is plenty of material out there for people who want to buy something off the shelf, slam it in, do five minutes of cookbook setup, and forget it ever happened. It's much harder to find books which promote actual *understanding*. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Our lives are forever changed. But *that* is exactly as it always was. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Cryptology Questions
Title: Cryptology Questions Hi all, I was wondering if someone could help me out. I have to speak with some cryptology experts later today and was wondering if some answers could be answered. 1. What is the normal/(most secure) way to store private keys and protect them? Right now I store them in .pem format in a file and encrypt them with DES-CBC. 2. What does it mean if I need someone asks me if we support 'importing X.509 certificate from an external CA'. I thought that you just sign certificates with the CA not import them? Or am I missing something. 3. What is the normal/(most secure) way to validate the presented partners certificates when a SSL connection is established. Now my understanding was the defacto way was to include the ip/hostname in the CN? Is this correct and does it work both ways meaning. Can the server check to see if it's certificates have been move, i.e. if I copy public/private pairs from server a to server b, should server b check the ip/hostname to see if they really belong. And the client should check the certificate obtained from Server A, to see if it's really Server A correct? Ok that's enough with the homework questions. Heh, it's not really homework but im sure that the answers are so easy that it seems like it. :) I bought Eric Rescorla's book 'SSL and TLS' and ive been trying to read that but I don't see where he goes into more detail about 'storing keys' and ensuring safety. Of course I could of just blown right by that chapter, I tend to read books backwards. Now for my own interest. I see many names being thrown around. I'll tell you what I 'think' I know and please correct me if im wrong. RSA is a public key cryptology. I take this to mean that the public and private keys ( i.e. certificate/key ) is encrypted over the wire with RSA? Actual application ( for my example we will say application ) data is encoded into a message and then encrypted with a Message Digest? Which can be either MD5 or SHA-1 for RSA but only SHA-1 for DSS. Now this is where I get confused. RSA is also used like DH, in that it's used to negotiate a session key? Is that correct? So basically RSA does two things while DSS relies on DH to be complete? Let me see if I can translate this cipher: EDH-DSS-DES-CBC3-SHA. I take this to mean that the session key is negotiated with Emperhal DH meaning it's randomly generated on one side and not known by both parties. It uses DSS for public key encryption, DES for the actual data stream. I don't know what CBC3 means. But the Message Digest is SHA. Now what's the difference between encypting with a message digest with SHA but encrypting the data with DES? I thought the message was the data. Also reading in Eric's book he says 1024-bit assymetric keys are about as strong as 80-bit symmertic keys. So why is assymetric used? I assume its because of performance. It would probably take to long if everything was encrypted with 3DES correct? I do apologize for all these questions but I really want to learn SSL and in general Security and Cryptology inside and out but all the different encyptions are throwing me for a loop. I always just thought of cryptology in the terms of using RSA, DES or 3DES but I see there is a lot more to it. THANKS! - Andrew - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485
remove
- Original Message - From: support [EMAIL PROTECTED] Sent: Wednesday, December 05, 2001 9:48 PM Subject: ¹úÄÚÍâóÒ׶¯Á¦Ö®Ô´ [ ÈôÄú²»¸ºÔðÕâ·½ÃæµÄÒµÎñ, ÇëתÏà¹ØÒµÎñ»ò²¿ÃŵĸºÔðÈË£¬Íò·Ö¸Ðл ] [ Èô±¾Óʼþ´òÈÅÁËÄú£¬ÎÒÃÇÍò·Ö±§Ç¸ ] £££££££££££££££££££££££££££££££££ ¹úÄÚÍâóÒ׶¯Á¦Ö®Ô´** ¡°ÓʼþѲ²¶¡±ÊÇInternet¶¨Ïò¿Í»§ËÑË÷¹¤¾ß£¬ÄúÖ»ÐèÒªÊäÈëËÑË÷¹Ø¼ü×Ö£¬ ¾Í¿ÉÒÔ×Ô¶¯µØÔÚ»¥ÁªÍøÉϽøÐÐËÑË÷£¬²»µ½¼¸ÃëÖÓ£¬ÓʼþµØÖ· ¾Í»áÔ´Ô´²»¶ÏµÄ³öÏÖÔÚÄúÃæÇ°¡£ 1 ¶¨ÏòÐÔ£¬Ö»ËÑË÷ͬÄúÒµÎñÏà¹Ø¹«Ë¾µÄÍøÕ¾ºÍEmail. 2 ËÑË÷Ëٶȿì: ¶àÏß³ÌËÑË÷£¬Ã¿Ð¡Ê±¿ÉÒÔËÑË÷³ÉǧÉÏÍòµÄEmail¡£ 3 ¼¯³É21¸ö¶¥¼¶ËÑË÷ÒýÇ棺ÐÂÀË£¬ËÑ»¡£¬ÍøÒ×£¬21CN, 263, YahooµÈµÈ 4 ·µ»ØÐÅÏ¢·á¸»£º²»½öÊÕ¼¯ÓʼþµØÖ·£¬Í¬Ê±»¹Ìṩ¸ÃµØÖ·µÄÀ´Ô´ÍøÖ·¡£ 5 ¶àÓïÖÖÖ§³Ö£º¼´¿ÉËÑË÷ÖÐÎÄÐÅÏ¢£¬ÓÖ¿ÉËÑË÷Ó¢ÎÄ£¬µÂÎĵÈÍâÎÄÐÅÏ¢. 6 ¿ÉÒÔÈÃÄúÇáËɽ¨Á¢¿Í»§Ô´£¬À©´óÒµÎñÁ¿£¬ÌáÉý¾ºÕùÁ¦¡£ ²»¹ÜÄúÊÇ×ö¹úÄÚÒµÎñ»¹Êǹú¼ÊÒµÎñ£¬ÓʼþѲ²¶¶¼ÊÇÄúÇ¿ÓÐÁ¦µÄÖúÊÖ¡£ --- ÓʼþÌØ¿ì: .Ç¿´óµÄÖ±½Ó·¢ËÍÄÜÁ¦¡£ÄÚ½¨Óʼþ·¢ËÍ·þÎñÆ÷£¬²»ÐèÄúµÄSMTP·þÎñÆ÷ Ö±½Ó°ÑÓʼþ·¢¸øÊÕ¼þÈË¡£ .¸ßËÙÌؿ죬ÿСʱÈη¢ËÍ5,6ÍòÓʼþ .רҵÐÔÒ»¶ÔÒ»·¢ËÍ -- ÓʼþУÑéר¼Ò: ÊÇÒ»¿îרҵ¿ìËÙÓʼþµØÖ·ÕýÈ·ÐÔУÑéÈí¼þ. .ʹÓöàÏ̼߳¼Êõ£¬Ã¿Ð¡Ê±Äܹ»Ð£Ñ鼸ʮÍò·ÝÓʼþ. .ÌÞ³ý´íÎó²»´æÔÚµÄÖظ´µÄÓʼþµØÖ·£¬Ìá¸ßÓʼþ·¢Ë͵ÄÓÐЧÐÔ¡£ .½ÚÊ¡ÈËÁ¦ÎïÁ¦¡£ »¶ÓÃâ·ÑÏÂÔØÊÔÓà http://www.email-tool.com/china/download.html ¶©¹º http://www.email-tool.com/china/order.html µç»°£º86-755-6568917 ÁªÏµÈË£º·ëÏÈÉú ÉîÛÚÊÐÒ×ÍØÒÀ¿Æ¼¼¿ª·¢ÓÐÏÞ¹«Ë¾ http://www.email-tool.com Dear [Email], We are the software development company: Target Customer Search Expert Integrated with 21 top search engine to find your customers' web addresses and email addresses. Invaluable Internet Marketing Tool. If you are interested to buy or to be an agent to sell our software, please contact with me. Indetail introduction, please access http://www.email-tool.com/ [ Very sorry to matter you in such style] [remove please replywith subject: remove] [ Èô±¾Óʼþ´òÈÅÁËÄú£¬ÎÒÃÇÍò·Ö±§Ç¸ ] [ ³ý·ÇÓÐÄúµÄÔÊÐí£¬·ñÔòÎÒÃDz»»áÔٴδòÈÅÄú£¬Ôٴαíʾ±§Ç¸] - ÓʼþѲ²¶£º¼¯³É21¸öËÑË÷ÒýÇ棬¶¨ÏòËÑË÷ÓʼþµØÖ·¡£ http://www.emailspidereasy.com/china/ -- ±¾ÓʼþÓÉ¿Í»§×ÔÐÐÀûÓÃÍØÒ×ÓʼþÌØ¿ì·¢ËÍ,·¢Ëͼ°ÄÚÈݾùÓë±¾¹«Ë¾Î޹ء£ --- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Cryptology Questions
Title: Cryptology Questions hmmm...a tall order for us busy folks...but I'll help you out some. 1. Provided you are using a "strong" password to encrypt your key when using DES-CBC you are pretty secure. Remember that if I can get access to, orcopy, your .pem file from off your machine I can run a dictionary attack against it, searching for your encryption password. If I find that, I can impersonate you. 2. Importing a certificate to me sounds like you are being asked if you are adding the cert to either your browser's trusted store or your server's cert chain. Some additional info would help clear that up a bit. 3. First, It is very important that, when validating a cert, you first check that the issuer of that cert is trusted by you. OpenSSL does this rather easily for you, once you've informed it of the CA certs you trust. You must do this because I can easily create a certificate containing www.verisign.comas the issuer but would have to somehow convince you to store my fake CA cert within your store. The entire issue of trust within the PKI framework begins with the CA certs you trust. If you don't understand this completely, please read up more on this topic at either Verisign's or RSA's web site. They have decent tutorials on PKI. Second, you then check that the cert has not expired. The notBefore/notAfter time periods contained within the cert indicate what period of time the cert can be valid. Of course, this is how the major CA's make their money, by limiting this period to usually one year from issuance. Third, you check the CN of the cert to ensure that it is indeed the site you are intent on conversing with. You can do additional checks if you wish to enforce certificate extensions. However I've not had much experience using those so I'll defer to others... RSA is an algorithm create to use apublic/private key pair where, if using one key for encryption, you use the other for decryption. If I know your public key, I can encrypt data and send it to you, confident that ONLY you can decrypt it. However, it is a slow algorithm compared to the symmetrical ones. That is why it is using only during the SSL handshakefor certificate verification and fortransferring the SSL session keys. It is not used for bulk data encryption likeDES/AES/RC4/etc... Regarding your thoughts on MD5, it is a Message Digest (the MD) of the content being sent. It is not encrypting the data, per say, but rather creating a strong "checksum", if you will,of the contents. You can then encrypt the MD with your private key and send it along with your message. Upon receiving your message I woulddecrypt the MD using your public key, re-compute the MD of the message sent, and compare it to the decrypted MD. If they are identical, I know that a) the message has not been tampered with and b) it could only have been sent by you since only you would have the corresponding private key to encrypt the MD in the first place. I know I've glossed over the many details here but hope this is the clarification you are looking for. If not, ask again. HTH, Rob -Original Message-From: Andrew Finnell [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 06, 2001 9:17 AMTo: 'Openssl ([EMAIL PROTECTED])'Subject: Cryptology Questions Hi all, I was wondering if someone could help me out. I have to speak with some cryptology experts later today and was wondering if some answers could be answered. 1. What is the normal/(most secure) way to store private keys and protect them? Right now I store them in .pem format in a file and encrypt them with DES-CBC. 2. What does it mean if I need someone asks me if we support 'importing X.509 certificate from an external CA'. I thought that you just sign certificates with the CA not import them? Or am I missing something. 3. What is the normal/(most secure) way to validate the presented partners certificates when a SSL connection is established. Now my understanding was the defacto way was to include the ip/hostname in the CN? Is this correct and does it work both ways meaning. Can the server check to see if it's certificates have been move, i.e. if I copy public/private pairs from server a to server b, should server b check the ip/hostname to see if they really belong. And the client should check the certificate obtained from Server A, to see if it's really Server A correct? Ok that's enough with the homework questions. Heh, it's not really homework but im sure that the answers are so easy that it seems like it. :) I bought Eric Rescorla's book 'SSL and TLS' and ive been trying to read that but I don't see where he goes into more detail about 'storing keys' and ensuring safety. Of course I could of just blown right by that chapter, I tend to read books backwards. Now for my own interest. I see many names being thrown around. I'll tell you what I 'think'
RE: Cryptology Questions
Title: RE: Cryptology Questions Neff, Thanks for the quick response. You actually helped me understand some aspects that I didnt truely understand before. For example the message digest. I did not know it was a checksum to validate that the data wasn't altered. --- More questions( better questions I guess? ) Regarding brute force attacks on the private key, what other mechanism is there to protect these keys and distribute them for that matter. For instance is it valid to have a server send a client it's public/private key pairs to use. Then reconnect the server with those keys. The security would come into play because the client needs to know the password to decrypt the private key that it was sent. Is this a good way to distribute client public/private keys? Sneaker footing/emailing the keys or methods that aren't automated or easy to use isn't really available to me. As for importing the X.509 certificate, I am focusing on adding it to the certificate chain. How are most certificates stored? Is it just as simple as opening up the certificate.pem(client cert) file and performing some openssl operations to add a cacert.pem(server cert) to the chain? This seems to easy and to prone to attacks. Anyone could just open the file and add there ca. BTW, thanks for the help anyone can give me. I know everyone is busy and I dont demand that people answer :) I just find that mailing lists like these are full of people that have the answers. - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485 -Original Message- From: Neff Robert A [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 10:20 AM To: '[EMAIL PROTECTED]' Subject: RE: Cryptology Questions hmmm...a tall order for us busy folks...but I'll help you out some. 1. Provided you are using a strong password to encrypt your key when using DES-CBC you are pretty secure. Remember that if I can get access to, or copy, your .pem file from off your machine I can run a dictionary attack against it, searching for your encryption password. If I find that, I can impersonate you. 2. Importing a certificate to me sounds like you are being asked if you are adding the cert to either your browser's trusted store or your server's cert chain. Some additional info would help clear that up a bit. 3. First, It is very important that, when validating a cert, you first check that the issuer of that cert is trusted by you. OpenSSL does this rather easily for you, once you've informed it of the CA certs you trust. You must do this because I can easily create a certificate containing www.verisign.com as the issuer but would have to somehow convince you to store my fake CA cert within your store. The entire issue of trust within the PKI framework begins with the CA certs you trust. If you don't understand this completely, please read up more on this topic at either Verisign's or RSA's web site. They have decent tutorials on PKI. Second, you then check that the cert has not expired. The notBefore/notAfter time periods contained within the cert indicate what period of time the cert can be valid. Of course, this is how the major CA's make their money, by limiting this period to usually one year from issuance. Third, you check the CN of the cert to ensure that it is indeed the site you are intent on conversing with. You can do additional checks if you wish to enforce certificate extensions. However I've not had much experience using those so I'll defer to others... RSA is an algorithm create to use a public/private key pair where, if using one key for encryption, you use the other for decryption. If I know your public key, I can encrypt data and send it to you, confident that ONLY you can decrypt it. However, it is a slow algorithm compared to the symmetrical ones. That is why it is using only during the SSL handshake for certificate verification and for transferring the SSL session keys. It is not used for bulk data encryption like DES/AES/RC4/etc... Regarding your thoughts on MD5, it is a Message Digest (the MD) of the content being sent. It is not encrypting the data, per say, but rather creating a strong checksum, if you will, of the contents. You can then encrypt the MD with your private key and send it along with your message. Upon receiving your message I would decrypt the MD using your public key, re-compute the MD of the message sent, and compare it to the decrypted MD. If they are identical, I know that a) the message has not been tampered with and b) it could only have been sent by you since only you would have the corresponding private key to encrypt the MD in the first place. I know I've glossed over the many details here but hope this is the clarification you are looking for. If not, ask again. HTH, Rob -Original Message- From: Andrew Finnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 9:17 AM To: 'Openssl ([EMAIL PROTECTED])' Subject:
RE: Cryptology Questions
On Thu, 6 Dec 2001, Andrew Finnell wrote: digest. I did not know it was a checksum to validate that the data wasn't altered. It's more robust than the usual checksums (CRC). You can easily fool a CRC32, but fooling a cryptographic digest is another matter... In fact, for MD5 and SHA1, nobody managed to show a collision. Regarding brute force attacks on the private key, what other mechanism is there to protect these keys and distribute them for that matter. For instance is it valid to have a server send a client it's public/private key pairs to use. Then reconnect the server with those keys. The security would come into play because the client needs to know the password to decrypt the private key that it was sent. Is this a good way to distribute client public/private keys? Sneaker footing/emailing the keys or methods that aren't automated or easy to use isn't really available to me. You generally don't distribute the private keys. The private/public key is generated by the client, and the public key is then sent to a CA, which signs it along with identity informations (so that the identity is bound to the public key). The private key is never distributed... As for importing the X.509 certificate, I am focusing on adding it to the certificate chain. How are most certificates stored? Is it just as simple as opening up the certificate.pem(client cert) file and performing some openssl operations to add a cacert.pem(server cert) to the chain? This seems to easy and to prone to attacks. Anyone could just open the file and add there ca. It depends of what you understood about the certificate chain. A certificate chain is not built by the running program (for example like a linked list of objects in memory). In fact, a certificate chain exists even if you don't have the certificates. Certificates A and B belong to the same chain if they have a common parent, and this cannot be fooled. You won't be able to make me believe that C belongs to the A's chain if C and A have no parent in common. The only entity that should be incontionally trusted is the root. All the other certificates are implicitely trusted because the root is trusted. If anobody could come on your PC and make your software trust a new root, too bad... The security of the whole chain is equal to the security of it's weakest link. Here, it's the protection you put to avoid someone getting access to your PC. In some cases, the weakest link is the user itself, who doesn't understand what it does... -- Erwann ABALEA [EMAIL PROTECTED] RSA PGP Key ID: 0x2D0EABD5 - (A)bort, (R)etry, (S)mack the @#$*! thing! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OCSP verification
Hello, I am looking at verifying the OCSP responses, in regard to verifying the OCSP signer certificate. I have been looking at OCSP_basic_verify, but can't figure it out, and there's no documentation. Can anyone shed any light? Also, are there any code examples of walking up a CA chain and verifying certs along the way? Tat. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cryptology Questions
Erwann ABALEA [EMAIL PROTECTED] writes: On Thu, 6 Dec 2001, Andrew Finnell wrote: digest. I did not know it was a checksum to validate that the data wasn't altered. It's more robust than the usual checksums (CRC). You can easily fool a CRC32, but fooling a cryptographic digest is another matter... In fact, for MD5 and SHA1, nobody managed to show a collision. That's MOSTLY true. Hans Dobbertin showed a single compression in the MD5 compression function but noone in the open community knows how he got it. Of course, it's obvious that there must be collisions and for MD5 at least it's technically possible to find them by brute force, since the birthday attack is 2^64 hard. This doesn't mean that the use of MD5 in SSL is insecure. The only property that SSL really requires of MD5 is irreversibility which is 2^128 hard. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Sending/Detecting CA Certificate to client
Hi folks! I created a CA Certiicate that a plan to use to sign all certificates that I'll use on our services. My major problem is how can I detect if the client as already the CA cert (so I can decide if I should send the certificate to him or not). Thanks, -- Paulo Matos --- -- |Sys Net Admin| Serviço de Informática | |Faculdade de Ciências e Tecnologia | Tel: +351-21-2948596 | |Universidade Nova de Lisboa| Fax: +351-21-2948548 | |P-2829-516 Caparica| e-Mail: [EMAIL PROTECTED] | --- -- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
countryName field rejected by openssl w/ keytool
I am having trouble signing a client key created with Java's keytool with a CA key created with openssl. I get the message The countryName field needed to be the same in the CA certificate (US) and the request (US), which doesn't make sense since they ARE the same. I am including a transcript of the process I used so that maybe someone can tell me where it went wrong. Thanks for any help!!! = TRANSCRIPT FOLLOWS = [rich@localhost testssl]$ openssl genrsa -rand -des -out ca.key 1024 0 semi-random bytes loaded Generating RSA private key, 1024 bit long modulus .++ .++ e is 65537 (0x10001) [rich@localhost testssl]$ openssl req -new -x509 -days 365 -key ca.key -out ca.crt Using configuration from /usr/share/ssl/openssl.cnf You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:California Locality Name (eg, city) []:San Francisco Organization Name (eg, company) [Internet Widgits Pty Ltd]:3Com Organizational Unit Name (eg, section) []:HR Common Name (eg, your name or your server's hostname) []:mickey Email Address []:[EMAIL PROTECTED] [rich@localhost testssl]$ keytool -keystore test -genkey -alias node1 Enter keystore password: 3com3com What is your first and last name? [Unknown]: Richard Hassinger What is the name of your organizational unit? [Unknown]: HR What is the name of your organization? [Unknown]: 3Com What is the name of your City or Locality? [Unknown]: San Francisco What is the name of your State or Province? [Unknown]: California What is the two-letter country code for this unit? [Unknown]: US Is CN=Richard Hassinger, OU=HR, O=3Com, L=San Francisco, ST=California, C=US correct? [no]: yes Enter key password for node1 (RETURN if same as keystore password): [rich@localhost testssl]$ keytool -keystore test -certreq -alias node1 -file node1.crs Enter keystore password: 3com3com [rich@localhost testssl]$ openssl ca -config /openssl.cnf -in node1.crs -out node1.crs.pem -keyfile ca.key Using configuration from /openssl.cnf Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :ASN.1 12:'US' stateOrProvinceName :ASN.1 12:'California' localityName :ASN.1 12:'San Francisco' organizationName :ASN.1 12:'3Com' organizationalUnitName:ASN.1 12:'HR' commonName:ASN.1 12:'Richard Hassinger' The countryName field needed to be the same in the CA certificate (US) and the request (US) [rich@localhost testssl]$ __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cryptology Questions
Andrew Finnell [EMAIL PROTECTED] writes: I was wondering if someone could help me out. I have to speak with some cryptology experts later today and was wondering if some answers could be answered. 1. What is the normal/(most secure) way to store private keys and protect them? Right now I store them in .pem format in a file and encrypt them with DES-CBC. Well, there's normal and there's most secure. Normal is to store them in a PEM file encrypted under a password. Essentially you take the password and run it through a hash function to get a DES (or better yet, 3DES) key. This has a number of problems, the two foremost being: (1) Someone who gets your .pem file can try to password search to get the private key. This won't work if you've used a strong password but those can be hard to generate and remember. (2) Someone who breaks into your computer while it's running the server can the private key out of memory. The most secure way is to store the keys in some hardware device which is designed to let you perform public key ops with the key but never to give up the key -- and to zero itself if you tamper with it. They can also be designed to be unusable without a passphrase. This material is covered in section 5.11 of SSL and TLS, pp. 146-154. 2. What does it mean if I need someone asks me if we support 'importing X.509 certificate from an external CA'. I thought that you just sign certificates with the CA not import them? Or am I missing something. Ok. Roughly speaking there are two ways to get a certificate: (1) issue it yourself and (2) use CA. Issue it yourself means that you create a self-signed certificate when you generate your key. Using a CA means you generate a certificate signing request, give it to your CA and the CA gives back a certificate. You then have to load that certificate into your software. A degenerate case of a CA is a local CA in which you run your own. You might use a private protocol between you and your CA and not be able to support CAs run by third parties such as VeriSign. (For instance, your system might have custom extensions that need to be in the certs). What this question _might_ mean is can you use certificates issued by a third party CA. 3. What is the normal/(most secure) way to validate the presented partners certificates when a SSL connection is established. Now my understanding was the defacto way was to include the ip/hostname in the CN? Yes. See SSL and TLS S 9.14 pp 307-314. Is this correct and does it work both ways meaning. Can the server check to see if it's certificates have been move, i.e. if I copy public/private pairs from server a to server b, should server b check the ip/hostname to see if they really belong. And the client should check the certificate obtained from Server A, to see if it's really Server A correct? The client ALWAYS needs to check this stuff. The server might want to check it's own certificate in order to detect misconfigurations but it's not really necessary. Ok that's enough with the homework questions. Heh, it's not really homework but im sure that the answers are so easy that it seems like it. :) I bought Eric Rescorla's book 'SSL and TLS' and ive been trying to read that but I don't see where he goes into more detail about 'storing keys' and ensuring safety. Of course I could of just blown right by that chapter, I tend to read books backwards. Most of this material is covered (though I want to talk more about real world certificate policy in 2ed). The following material is all covered in SSL and TLS, mostly in Chapter 1,3, and 4 but I'll take a stab at summarizing. RSA is a public key cryptology. I take this to mean that the public and private keys ( i.e. certificate/key ) is encrypted over the wire with RSA? Not quite. Say we have some message (M) that we want to send from Alice to Bob. If we use ordinary (symmetric) cryptography then Alice and Bob need to share a key, K, and we do: Ciphertext=Esymmetric(K,M). If we use public key (assymetric) crypto then Bob has a Public Key (Kpub) and a Private Key (Kpriv). Alice can send a message to Bob that only Bob can decrypt (even Alice can't) doing: Ciphertext=Ersa(Kpub,M) Bob can decrypt it doing: M=Drsa(Kpriv,Ciphertext) However, for a number of technical reasons (mainly performance) RSA isn't really suitable for encrypting actual ASCII messages. Instead you encrypt symmetric keys with RSA and then use the symmetric keys to encrypt the message. E.g. Ciphertext=Ersa(Kpub,Ksymmetric) + Esymmetric(Ksymmetric,Message) RSA can also do another trick, which is that if you encrypt with the private key you get something that can only be decrypted with the public key (and could only have been generated with the private key). This can be used to prove that the sender had the private key and is called a digital signature. I.e. Signature=Ersa(Kpriv,Message) To verify you
RE: Cryptology Questions
Title: RE: Cryptology Questions Yes, the digest is used to validate that the data wasn't altered. Remember that anyone can calculate the digest of a message. If the digest wasn't encrypted with your private key, then someone could change the data, recompute the digest, and exchange the original digest with the newly computed one. Encrypting the MD with your private key prevents that from occurring. That, in a nutshell, is digitally signing a document. Regarding key distribution, no one but the owner should have access to the private key. What reason would the server have for sending a client their public AND private key? To ensure confidentiality and integrity, the key pair should (must?) be generated by the client. It is the job of the CA to sign the certificate (which contains among other things the owner's public key). The private key itself is not contained within the cert. You should read up on certificate requests to clarify some issues. For whatever reason, if you are attempting to generate and supply both keys to you clients, you have to have a very secure environment. More problematic is that, because you have both keys, I am not guaranteed that someone at your company couldn't impersonate me if I were a client... Certificates themselves are public. Anyone can, and does, have knowledge of their contents. OpenSSL comes with some of the major CA signing certificates in use. You will find them in the openssl/certs directory. You indicate to OpenSSL which of these certs you trust to sign other certs. You can obtain these certs directly from the vendor if you don't trust the ones in the distribution. It is the public key contained within these CA certs that is used to decrypt the MD of the server certificate received during the SSL connection that was encrypted (signed)with theissuing CA's private key. And yes, a possible attack would be that someone could addtheir own version of a "verisign" root cert to your store, hijack a DNS server to reroute your IP connection to another server, then use that server to act as a proxy to the original server. Fortunately, this is not an easy thing to accomplish since many machines need to be compromised. The attacker would still not have access to your private key though. Sleep tight! hehe Cheers, Rob -Original Message-From: Andrew Finnell [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 06, 2001 10:40 AMTo: '[EMAIL PROTECTED]'Subject: RE: Cryptology Questions Neff, Thanks for the quick response. You actually helped me understand some aspects that I didnt truely understand before. For example the message digest. I did not know it was a checksum to validate that the data wasn't altered. --- More questions( better questions I guess? ) Regarding brute force attacks on the private key, what other mechanism is there to protect these keys and distribute them for that matter. For instance is it valid to have a server send a client it's public/private key pairs to use. Then reconnect the server with those keys. The security would come into play because the client needs to know the password to decrypt the private key that it was sent. Is this a good way to distribute client public/private keys? Sneaker footing/emailing the keys or methods that aren't "automated" or easy to use isn't really available to me. As for importing the X.509 certificate, I am focusing on adding it to the certificate chain. How are most certificates stored? Is it just as simple as opening up the certificate.pem(client cert) file and performing some openssl operations to add a cacert.pem(server cert) to the chain? This seems to easy and to prone to attacks. Anyone could just open the file and add there ca. BTW, thanks for the help anyone can give me. I know everyone is busy and I dont demand that people answer :) I just find that mailing lists like these are full of people that have the answers. - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485 * DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator.
Re: Sending/Detecting CA Certificate to client
On Thu, 6 Dec 2001, Paulo Matos wrote: Hi folks! I created a CA Certiicate that a plan to use to sign all certificates that I'll use on our services. My major problem is how can I detect if the client as already the CA cert (so I can decide if I should send the certificate to him or not). You should provide a special link to let the user install the CA. The CA certificate is a special one: the trust of all the chain is based on it. So it *must* be treated differently. Unfortunately, this cannot be automatized, you have to manually deploy it. -- Erwann ABALEA [EMAIL PROTECTED] RSA PGP Key ID: 0x2D0EABD5 - What we have here is a failure to communicate. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OCSP verification
Tat Sing Kong wrote: Hello, I am looking at verifying the OCSP responses, in regard to verifying the OCSP signer certificate. I have been looking at OCSP_basic_verify, but can't figure it out, and there's no documentation. Can anyone shed any light? Also, are there any code examples of walking up a CA chain and verifying certs along the way? apps/ocsp.c has an example of the use of this function. Its use is similar to PKCS7_verify() which is also currently undocumented :-) Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
