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 > 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 > 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: 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
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: 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. > > 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. 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: 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: 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 > 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 >
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
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
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: > 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
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
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
