how to see the SSL handshake
Hello Forum, I am currently running the samples(client1,server1) , is there any environmental variables that i need to export so that i can get the SSL handshake tracing? -Thanks mithun
decrypt with a public key
Hi, In public key cryptography, a message encrypted with a private key can be decrypted with a public key, and so I tried: openssl rsautl -encrypt -inkey private-key -in message -out cryptogram openssl rsautl -decrypt -inkey public-key -pubin -in cryptogram The problem is that the second command gives me: A private key is needed for this operation Why can't one decrypt with a public key? I do realize that I can convince the recipient of the message that the message is indeed mine by signing the message. Thanks, Irek -- Ireneusz (Irek) Szczesniak http://www.irkos.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: decrypt with a public key
On Wed, Dec 28, 2011, Ireneusz Szcze??niak wrote: Hi, In public key cryptography, a message encrypted with a private key can be decrypted with a public key, and so I tried: openssl rsautl -encrypt -inkey private-key -in message -out cryptogram openssl rsautl -decrypt -inkey public-key -pubin -in cryptogram The problem is that the second command gives me: A private key is needed for this operation Why can't one decrypt with a public key? I do realize that I can convince the recipient of the message that the message is indeed mine by signing the message. Try the -sign and -verify options instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: decrypt with a public key
Thank you, Steve, for your post. Let me explain what I'm trying to do. In the public key cryptography: message = Dprv(Epub(message)) = Dpub(Eprv(message) D stands for decrypt, E for encrypt prv - private key, pub - private key And so I tried to do this with the openssl command. On 28.12.2011 18:28, Dr. Stephen Henson wrote: On Wed, Dec 28, 2011, Ireneusz Szcze??niak wrote: Hi, In public key cryptography, a message encrypted with a private key can be decrypted with a public key, and so I tried: openssl rsautl -encrypt -inkey private-key -in message -out cryptogram openssl rsautl -decrypt -inkey public-key -pubin -in cryptogram The problem is that the second command gives me: A private key is needed for this operation Why can't one decrypt with a public key? I do realize that I can convince the recipient of the message that the message is indeed mine by signing the message. Try the -sign and -verify options instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Ireneusz (Irek) Szczesniak http://www.irkos.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: decrypt with a public key
On Wed, Dec 28, 2011, Ireneusz Szcze??niak wrote: Thank you, Steve, for your post. Let me explain what I'm trying to do. In the public key cryptography: message = Dprv(Epub(message)) = Dpub(Eprv(message) D stands for decrypt, E for encrypt prv - private key, pub - private key And so I tried to do this with the openssl command. The public key decrypt and private encrypt operations correspond to the -verify and -sign options to rsautl which is why I suggested them. The default padding is however different in accordance with the PKCS#1 standard. That can be changed on the commmand line too. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
req insists on a config file now?
It looks like there's been a recent change that's causing 'req' to insist on a config file, presumably for reading the OID info from. Is there a way to get the interactive mode back? openssl genrsa -out server.key 2048 WARNING: can't open config file: /usr/local/openssl/openssl.cnf Generating RSA private key, 2048 bit long modulus ..+++ +++ e is 65537 (0x10001) openssl req -new -key server.key -out server.csr WARNING: can't open config file: /usr/local/openssl/openssl.cnf Unable to load config info from /usr/local/openssl/openssl.cnf ls -l server.csr ls: server.csr: No such file or directory openssl version WARNING: can't open config file: /usr/local/openssl/openssl.cnf OpenSSL 1.0.0e 6 Sep 2011 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: decrypt with a public key
When you use public key algorithms: You encrypt with the recipient's public key and the recipient decrypts with their private key. You sign with your private key and the recipient verifies with your public key. owner-openssl-us...@openssl.org wrote on 12/28/2011 01:43:17 PM: From: Ireneusz Szcześniak irek.szczesn...@gmail.com To: openssl-users@openssl.org, Date: 12/28/2011 01:45 PM Subject: Re: decrypt with a public key Sent by: owner-openssl-us...@openssl.org Thank you, Steve, for your post. Let me explain what I'm trying to do. In the public key cryptography: message = Dprv(Epub(message)) = Dpub(Eprv(message) D stands for decrypt, E for encrypt prv - private key, pub - private key And so I tried to do this with the openssl command. On 28.12.2011 18:28, Dr. Stephen Henson wrote: On Wed, Dec 28, 2011, Ireneusz Szcze??niak wrote: Hi, In public key cryptography, a message encrypted with a private key can be decrypted with a public key, and so I tried: openssl rsautl -encrypt -inkey private-key -in message -out cryptogram openssl rsautl -decrypt -inkey public-key -pubin -in cryptogram The problem is that the second command gives me: A private key is needed for this operation Why can't one decrypt with a public key? I do realize that I can convince the recipient of the message that the message is indeed mine by signing the message. Try the -sign and -verify options instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Ireneusz (Irek) Szczesniak http://www.irkos.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: decrypt with a public key
On 28.12.2011 19:50, Dr. Stephen Henson wrote: The public key decrypt and private encrypt operations correspond to the -verify and -sign options to rsautl which is why I suggested them. Now I understand. I mistakenly thought that -sign and -verify were used to attach and examine an encrypted hash of the message, i.e. a message signature. Thank you for your help! -- Ireneusz (Irek) Szczesniak http://www.irkos.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Supporting oldwithold, newwithnew CA certificates Reg.
From: owner-openssl-us...@openssl.org On Behalf Of Ashok C Sent: Tuesday, 27 December, 2011 06:20 But regarding this: Important note: make sure the old and new root certs have different names. (Same for intermediate CAs, which your example doesn't have.) OpenSSL looks-up using Issuer name only. snip rest I actually tested this particular scenario in my testbed and found that it is not necessary that the old and new CA certs have different names. snip scenarios The last time I tried a rollover with the same name, it did fail for me, but that was quite a few years ago. Possibly something has changed since. I don't have time to retest now. If it works for you fine. One more clarification: If OpenSSL client has cert-and-pkey configured and receives CertReq, it sends that cert regardless of any CAlist the server asked for; that cert may be accepted or not depending on the server. And if callback or engine is used it appears (but I haven't tested) that can similarly select any cert regardless of what the server asked. Are you indicating here that the client can have multiple end entity certificates? Till now I had the assumption that the server/client can have only a single end entity certificate. Yes. There are several good reasons for multiple certs (and keys). 1. (Really) different CAs e.g. server A accepts only certs from a private/internal A-CA that enforces company-A rules about which clients get certs, but client also connects to server B in a different company which understandably won't rely on A-CA and demands a public CA or even a similar but different private/internal B-CA. Similarly but less often a server may use an internal-CA cert for internal clients who know about and trust that CA, but a public one for other clients. 2. Different algorithms: server has one key-and-cert for RSA suites and different one for DSS (DSA) suites and maybe a third for ECDSA, and client similarly. In years past this was sometimes a political issue: systems in or connected to the US government were required to use DSA and not RSA, and some people in other places who didn't like the US government would use RSA but not DSA (including places where the US-issued patent on RSA wasn't enforced). Today this has died down and pretty much everybody trusts everybody at least for the cryptography, although there are still some places where ECDSA (and ECDH) aren't yet implemented versus others which insist on them because of bandwidth or power concerns e.g. mobile devices. 3. Rollover/replacement much like your scenario; sometimes it isn't possible to cut a new CA (generation) all at once and there is a transition period where e.g. client needs new-cert for server A but old-cert for server B which hasn't been updated yet. 4. Or you can do it just because you want to; the protocol only requires *a* server cert (unless anon) and *a* client cert (if client-auth used) that work, it doesn't care what others exist. Also, if the server can ask client to send selective certificates, wouldn't it be applicable that the client also can request the server for specific certificates? The original (SSL) protocol didn't provide for this beyond the algorithm selection inherent in the Client/ServerHello exchange. OpenSSL server can be configured with all three algorithms and will use whichever one (first) agrees with the client request; I'm not sure if OpenSSL client can offer more than one (I have never needed to try that). TLS extensions (RFC3546 in 2003, but optional in OpenSSL until about 2008 as I recall) adds among other features: - ClientHello can specify logical server name; in particular for HTTPS this is the domain name from the URL, useful in cases where a single actual server supports multiple virtual hosts. - ClientHello can specify trusted CA keys, either as a CA DN or several other methods. - EC (RFC4492 in 2006) adds extensions to limit the curves and formats the client supports, which if the server disagrees should result in not selecting an EC suite (and if no other suites are shared, handshake failure). Are there separate openSSL APIs for this or we have to use the same family of ssl_ctx_set_client* family of APIs for this purpose also? For restricting cipher algorithms, *_set_cipher_list. For the server-name extension, SSL_set_tlsext_host_name in client. In server you provide a callback, with arg, to handle reception. OpenSSL apparently does not implement the explicit CA keys extension, and I don't know if anyone else does either. I haven't tracked through completely, but I believe OpenSSL always uses the correct values for EC curves and formats, i.e. OpenSSL supports what it supports and you don't change it. (You can of course choose to not use EC suites at all.)
RE: req insists on a config file now?
From: owner-openssl-us...@openssl.org On Behalf Of Matthew Pounsett Sent: Wednesday, 28 December, 2011 13:24 It looks like there's been a recent change that's causing 'req' to insist on a config file, presumably for reading the OID info from. Is there a way to get the interactive mode back? This isn't recent. Assuming by interactive mode you mean prompting for entity-name (DN) fields and other request attributes, this is driven BY the config file, and that's exactly why a config file is needed with -new and has been at least 5 years. What is recent is 1.0.0 gives the warning even when it DOESN'T need the config file i.e. without -new (but continues okay). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
From: owner-openssl-us...@openssl.org On Behalf Of Mick Sent: Monday, 26 December, 2011 14:01 snip: CA-vs-EE DN string types I seem to have overcome the original problem. Now both the cacert and signed client certificates are formatted in the same way. I used -policy policy_anything to avoid complaints from openssl ca. Unfortunately the problem of authenticating on the VPN gateway remains. :-( I would be grateful for some advice, as I am not sure if I am following the correct steps. I have created a request for a client certificate: == openssl req -config ./openssl_VPN.cnf -new -newkey rsa:2048 -keyout VPN_test_key.pem -days 1095 -out VPN_test_cert.req == Aside: for req -new without -x509, -days is ignored and useless. Then signed it with the cacert: Nits: it isn't actually the request that's signed and the CI isn't actually signed with the cert, but we know what you mean. == openssl ca -config ./openssl_VPN.cnf -extensions usr_cert -days 1095 -cert cacert_VPN.pem -keyfile VPN_CA/private/cakey_VPN.pem -policy policy_anything - infiles VPN_test_cert.req snip However, trying to verify it brings up some errors: == openssl verify -verbose -CAfile cacert_VPN.pem -x509_strict -policy_print - issuer_checks VPN_test_cert.pem VPN_test_cert.pem: C = GB, O = Sundial, CN = VPN_test_XPS error 29 at 0 depth lookup:subject issuer mismatch C = GB, O = Sundial, CN = VPN_test_XPS error 29 at 0 depth lookup:subject issuer mismatch C = GB, O = Sundial, CN = VPN_test_XPS error 29 at 0 depth lookup:subject issuer mismatch OK == -issuer_checks can be misleading; these errors are the results of internal tests for a root cert (i.e. issued by itself) and thus quite normal. Since the final result is OK, OpenSSL is happy. and the asn1parser fails too: == openssl asn1parse -in VPN_test_cert.pem Error in encoding 139747192850088:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:150: == Make sure you asn1parse a file/input containing ONLY valid data (here dashed-BEGIN, b64 cert, dashed-END). All(?) other openssl PEM functions accept and ignore comments or garbage before BEGIN or after END, but not asn1parse. And some openssl functions including ca PUT such comments. You can avoid editing a copy by: awk '/-BEGIN/,/-END/' filewithextra | openssl asn1parse on any *nix, and on Windows if you add an awk port. The cacert does not suffer from such verification or parsing errors, but certificates signed by it, do. The errors that the router authentication shows are: snip But as far as pleasing your router, I have no clue, sorry. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
