Re: [openssl-users] private key difference: openssl genrsa vs opnessl req newkey
tx for the support. I will try a solution with the problematic software. Best regards Michele MAsè On Tue, Aug 1, 2017 at 6:55 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > On Wed, Jul 26, 2017 at 09:21:43PM +0200, Michele Mase' wrote: > > > So, what should be the command line to use in order to obtain the same > key? > > openssl genrsa > > This creates keys in a legacy RSA algorithm-specific format. > > > openssl req -nodes -newkey rsa:2048 some_extra_parameters > > This creates keys in the preferred standard PKCS#8 format. > > You can use "openssl pkey" to read legacy RSA keys and output > PKCS#8 keys. Or you can use "openssl genpkey" to generate > PKCS#8 keys directly: > > # RSA > (umask 077; openssl genpkey -algorithm rsa -pkeyopt > rsa_keygen_bits:2048 -out key.pem) > > # ECDSA P-256 > (umask 077; openssl genpkey -algorithm ec -pkeyopt > ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -out key.pem) > > # ECDSA P-384 > (umask 077; openssl genpkey -algorithm ec -pkeyopt > ec_paramgen_curve:secp384r1 -pkeyopt ec_param_enc:named_curve -out key.pem) > > # ECDSA P-521 > (umask 077; openssl genpkey -algorithm ec -pkeyopt > ec_paramgen_curve:secp521r1 -pkeyopt ec_param_enc:named_curve -out key.pem) > > It is unfortunate that OpenSSL 1.0.2 does not accept curve name > aliases for ec_paramgen_curve. Thus, for example, only "prime256v1" > is accepted for P-256 and not any of its other names. > > I've not checked whether this is fixed in OpenSSL 1.1.0. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] private key difference: openssl genrsa vs opnessl req newkey
Anyone? On Wed, Jul 26, 2017 at 9:21 PM, Michele Mase' <michele.m...@gmail.com> wrote: > Tx. > So, what should be the command line to use in order to obtain the same key? > openssl genrsa > openssl req -nodes -newkey rsa:2048 some_extra_parameters > Michele MAsè > > On Wed, Jul 26, 2017 at 6:29 PM, Benjamin Kaduk <bka...@akamai.com> wrote: > >> On 07/26/2017 10:13 AM, Michele Mase' wrote: >> >> During the generation of x509 certificates, both commands give the same >> results: >> >> Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key -out >> example.csr -subj "/C=GB/ST=London/L=London/O=Global Security/OU=IT >> Department/CN=example.com >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM=SvmGwnxF6Arf5U_XmN1vPPpie6IFH3h5CkVhveCn26I=AMT2W-m9xgiUsKMETv-WcWALqfQnX1rujJdNTJsVz1E=> >> " >> Command "b": openssl genrsa -out example.key >> >> Both commands give me a private key without password, a key that is not >> encrypted. >> To remove the passphrase from private key, I use the >> Command "c":openssl rsa -in example.key -out example2.key >> >> The command "c" against the example.key generated by command "a", gives >> the same private key with different content between --BEGIN RSA and --END >> RSA. Simply, try the following: >> diff example.key example2.key, the files are different. >> >> The command "c" against example.key generate by the command "b" produces >> the same file. No differences. >> >> Why? >> Perhaps I missed something in openssl manual ... :( >> These differenced gave me troubles using custom certificates in some >> software. >> Any suggestion? >> >> >> The output from openssl req includes an additional layer of encoding and >> the rsaEncryption OID around the actual key parameters, as can be seen >> using openssl asn1parse. The conversion with 'openssl rsa' removes that >> extra encoding. >> >> -Ben >> > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] private key difference: openssl genrsa vs opnessl req newkey
Tx. So, what should be the command line to use in order to obtain the same key? openssl genrsa openssl req -nodes -newkey rsa:2048 some_extra_parameters Michele MAsè On Wed, Jul 26, 2017 at 6:29 PM, Benjamin Kaduk <bka...@akamai.com> wrote: > On 07/26/2017 10:13 AM, Michele Mase' wrote: > > During the generation of x509 certificates, both commands give the same > results: > > Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key -out > example.csr -subj "/C=GB/ST=London/L=London/O=Global Security/OU=IT > Department/CN=example.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM=SvmGwnxF6Arf5U_XmN1vPPpie6IFH3h5CkVhveCn26I=AMT2W-m9xgiUsKMETv-WcWALqfQnX1rujJdNTJsVz1E=> > " > Command "b": openssl genrsa -out example.key > > Both commands give me a private key without password, a key that is not > encrypted. > To remove the passphrase from private key, I use the > Command "c":openssl rsa -in example.key -out example2.key > > The command "c" against the example.key generated by command "a", gives > the same private key with different content between --BEGIN RSA and --END > RSA. Simply, try the following: > diff example.key example2.key, the files are different. > > The command "c" against example.key generate by the command "b" produces > the same file. No differences. > > Why? > Perhaps I missed something in openssl manual ... :( > These differenced gave me troubles using custom certificates in some > software. > Any suggestion? > > > The output from openssl req includes an additional layer of encoding and > the rsaEncryption OID around the actual key parameters, as can be seen > using openssl asn1parse. The conversion with 'openssl rsa' removes that > extra encoding. > > -Ben > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] private key difference: openssl genrsa vs opnessl req newkey
During the generation of x509 certificates, both commands give the same results: Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key -out example.csr -subj "/C=GB/ST=London/L=London/O=Global Security/OU=IT Department/CN=example.com" Command "b": openssl genrsa -out example.key Both commands give me a private key without password, a key that is not encrypted. To remove the passphrase from private key, I use the Command "c":openssl rsa -in example.key -out example2.key The command "c" against the example.key generated by command "a", gives the same private key with different content between --BEGIN RSA and --END RSA. Simply, try the following: diff example.key example2.key, the files are different. The command "c" against example.key generate by the command "b" produces the same file. No differences. Why? Perhaps I missed something in openssl manual ... :( These differenced gave me troubles using custom certificates in some software. Any suggestion? Regards Michele MAsè -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Similar issuer dn mod_ssl client authentication issue
Dear openssl group, could you solve this issue regarding mod_ssl? Michele Masè On Thu, May 23, 2013 at 10:11 AM, Michele Mase' michele.m...@gmail.com wrote: Okay, openssl works, but mod_ssl doesn't. Is this a real problem? Instead try hacking mod_ssl code ... Could I ask for a bug/improvement so that mod_ssl could finally work? Michele MAsè On Thu, May 23, 2013 at 1:22 AM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' Sent: Tuesday, 21 May, 2013 04:16 I was wrong! Does it work with client=Firefox using client certs under both CAs? I would expect at least one to fail. Note that s_server -verify doesn't *require* client cert, it only *allows* it; how did you check Firefox is actually using your client cert(s)? I've tested it with both smart card I went back and set up a (modified) test and ... I was wrong! The lookup as such does use the canonical DN and returns only one, sometimes the wrong one. But I didn't realize X509_STORE_get1_issuer hiddenly caches *all* the matches and tries them, and (given you have AKI) *does* select the correct one. So actually your earlier tries should have worked, or at least not failed for this reason. The certificates you attached are CA roots and have no AKI. snip pardon, my mistake, I forgot to send the clients certs :( As attachment, there are the client certificates I used. And those do indeed have AKI (correctly matching the roots). I don't know what exclusive mode means here. virtualhost1 has the ca's bundle made with all certificates + ca1 (for smart card1) virtualhost2 has the ca's bundle made with all certificates + ca2, (for smart card2); the or (exclusive) means you can try virtualhost1 with smart card1 or virtualhost2 with scard2 Okay. RFC3280 - is it correct? snip 4.1.2.4 about case-insensitive and space-insignificant Actually, 3280 has been superseded by 5280, which has more complicated rules to handle internationalization using Unicode and IDN, but for this simple (ASCII) case boils down to the same thing. But, as above and contrary to what I said before, openssl *should* work for this case after all, which means you don't need the CA to change, which is probably good. (I think it's still confusing to people to have almost-identical DNs, but since most people won't even know how to look at a certificate, that's less of a problem.) s_server.out is the output of the openssl s_server command. The only error this shows is that one client cert (and card) -- I assume client2006.pem -- is rejected for cert expired. Which it is; the notAfter is Oct 12 23:59:59 2011 GMT. In order to convince the ca's supplier to change the old scard I should: 1) Show him the rfc 2) Inform all scard users to stop using the old scard 3) Give all scard users the new scard Are there some better argumentations to persuade the sa's supplier? If it were necessary I'd say probably yes, but as above I don't think it's necessary. Try using cards (certs) that are under the old 2006 root but NOT expired, and (now) I'll bet they do work. Sorry for the unnecessary alarm and confusion. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
Okay, openssl works, but mod_ssl doesn't. Is this a real problem? Instead try hacking mod_ssl code ... Could I ask for a bug/improvement so that mod_ssl could finally work? Michele MAsè On Thu, May 23, 2013 at 1:22 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' Sent: Tuesday, 21 May, 2013 04:16 I was wrong! Does it work with client=Firefox using client certs under both CAs? I would expect at least one to fail. Note that s_server -verify doesn't *require* client cert, it only *allows* it; how did you check Firefox is actually using your client cert(s)? I've tested it with both smart card I went back and set up a (modified) test and ... I was wrong! The lookup as such does use the canonical DN and returns only one, sometimes the wrong one. But I didn't realize X509_STORE_get1_issuer hiddenly caches *all* the matches and tries them, and (given you have AKI) *does* select the correct one. So actually your earlier tries should have worked, or at least not failed for this reason. The certificates you attached are CA roots and have no AKI. snip pardon, my mistake, I forgot to send the clients certs :( As attachment, there are the client certificates I used. And those do indeed have AKI (correctly matching the roots). I don't know what exclusive mode means here. virtualhost1 has the ca's bundle made with all certificates + ca1 (for smart card1) virtualhost2 has the ca's bundle made with all certificates + ca2, (for smart card2); the or (exclusive) means you can try virtualhost1 with smart card1 or virtualhost2 with scard2 Okay. RFC3280 - is it correct? snip 4.1.2.4 about case-insensitive and space-insignificant Actually, 3280 has been superseded by 5280, which has more complicated rules to handle internationalization using Unicode and IDN, but for this simple (ASCII) case boils down to the same thing. But, as above and contrary to what I said before, openssl *should* work for this case after all, which means you don't need the CA to change, which is probably good. (I think it's still confusing to people to have almost-identical DNs, but since most people won't even know how to look at a certificate, that's less of a problem.) s_server.out is the output of the openssl s_server command. The only error this shows is that one client cert (and card) -- I assume client2006.pem -- is rejected for cert expired. Which it is; the notAfter is Oct 12 23:59:59 2011 GMT. In order to convince the ca's supplier to change the old scard I should: 1) Show him the rfc 2) Inform all scard users to stop using the old scard 3) Give all scard users the new scard Are there some better argumentations to persuade the sa's supplier? If it were necessary I'd say probably yes, but as above I don't think it's necessary. Try using cards (certs) that are under the old 2006 root but NOT expired, and (now) I'll bet they do work. Sorry for the unnecessary alarm and confusion. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
If these are the roots you attached -- with names that differ only in case of one letter -- they should have gotten the same hashvalue (with suffixes .0 and .1); did they? yes Does it work with client=Firefox using client certs under both CAs? I would expect at least one to fail. Note that s_server -verify doesn't *require* client cert, it only *allows* it; how did you check Firefox is actually using your client cert(s)? I've tested it with both smart card The certificates you attached are CA roots and have no AKI. AKI can/should be on the *child* certs i.e. your client certs. (The root has *SKI*, which the child AKI normally uses.) But as I said AKI won't fix this with openssl, which uses AKI only as an added check not as a way to select among parent certs. pardon, my mistake, I forgot to send the clients certs :( I don't know what exclusive mode means here. virtualhost1 has the ca's bundle made with all certificates + ca1 (for smart card1) virtualhost2 has the ca's bundle made with all certificates + ca2, (for smart card2); the or (exclusive) means you can try virtualhost1 with smart card1 or virtualhost2 with scard2 RFC3280 - is it correct? 4.1.2.4 Issuer ... This specification requires only a subset of the name comparison functionality specified in the X.500 series of specifications. Conforming implementations are *REQUIRED* to implement the following name comparison rules: (a) attribute values encoded in different types (e.g., PrintableString and BMPString) MAY be assumed to represent different strings; (b) attribute values in types other than PrintableString are case sensitive (this permits matching of attribute values as binary objects); (c) *attribute values in PrintableString are not case sensitive* (e.g., Marianne Swanson is the same as MARIANNE SWANSON); and (d) attribute values in PrintableString are compared after removing leading and trailing white space and converting internal substrings of one or more consecutive white space characters to a single space. As attachment, there are the client certificates I used. s_server.out is the output of the openssl s_server command. In order to convince the ca's supplier to change the old scard I should: 1) Show him the rfc 2) Inform all scard users to stop using the old scard 3) Give all scard users the new scard Are there some better argumentations to persuade the sa's supplier? Best regards Michele Masè On Sat, May 18, 2013 at 12:20 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' Sent: Friday, 17 May, 2013 10:04 What I did: openssl: Commandline for the openssl s_server (sorry for my typo) before starting www server: c_rehash /some/path #where I've put 2 pem encoded CA's certificates If these are the roots you attached -- with names that differ only in case of one letter -- they should have gotten the same hashvalue (with suffixes .0 and .1); did they? start the simple www server openssl s_server -www -key /some/path/file.key -cert /some/path/www.example.com.crt -CApath /some/path -state -verify 10 and testing it with any client (ie firefox) it finally works! Does it work with client=Firefox using client certs under both CAs? I would expect at least one to fail. Note that s_server -verify doesn't *require* client cert, it only *allows* it; how did you check Firefox is actually using your client cert(s)? apache + mod_ssl No one version worked for me: 2.2.x - 2.4.x (openssl 0.9.8.x - openssl 1.x) in various linux configurations (centos[56], ubuntu 13.04) Not surprising. This logic hasn't changed in openssl for a long time, and is the same no matter what program calls it unless the caller overrides openssl's lookup and/or chain validation. apache + mod_gnutls (have to try it) It could also be using AKI in chain build, if you have it in your certs (I didn't try to go through your script to see). OpenSSL *checks* AKI if present but doesn't use for lookup. I attach the original certificates; AKI seems to be ok. But this not solves my problem. The certificates you attached are CA roots and have no AKI. AKI can/should be on the *child* certs i.e. your client certs. (The root has *SKI*, which the child AKI normally uses.) But as I said AKI won't fix this with openssl, which uses AKI only as an added check not as a way to select among parent certs. The solution(s) - all put in or (exclusive mode): I don't know what exclusive mode means here. 1) hack mod_ssl or wait indefinitely somebody will do it :( The chain validation logic is in openssl. You or someone would have to change openssl, or else change mod_ssl to replace (override) at least the lookup logic in OpenSSL and probably the whole chain validation (because I think the lookup logic uses already canonicalized DN). 2) use mod_gnutls If, as I said, GNUTLS can handle the name-matching differently and nonstandardly. I don't know if it does. 3
Re: Similar issuer dn mod_ssl client authentication issue
Tx. for the response. Now I try to explain what I should do ... What I did: openssl: Commandline for the openssl s_server (sorry for my typo) before starting www server: c_rehash /some/path #where I've put 2 pem encoded CA's certificates start the simple www server openssl s_server -www -key /some/path/file.key -cert /some/path/www.example.com.crt -CApath /some/path -state -verify 10 and testing it with any client (ie firefox) it finally works! apache + mod_ssl No one version worked for me: 2.2.x - 2.4.x (openssl 0.9.8.x - openssl 1.x) in various linux configurations (centos[56], ubuntu 13.04) apache + mod_gnutls (have to try it) It could also be using AKI in chain build, if you have it in your certs (I didn't try to go through your script to see). OpenSSL *checks* AKI if present but doesn't use for lookup. I attach the original certificates; AKI seems to be ok. But this not solves my problem. The solution(s) - all put in or (exclusive mode): 1) hack mod_ssl or wait indefinitely somebody will do it :( 2) use mod_gnutls 3) put 2 virtualhosts under apache+mod_ssl using two different cacertifcatefile filename.pem (I must change the server name) 4) use IIS (fool) 5) change the issuer DN in CA's Some details: Unfortunately those (bad) CA's are provided by a thirdy part. They sign a tons of smart cards. Sould I ask (force) them to make new brand smart card using another CA? Could I oblige them to replace all the wrong smart card? Michele Masè On Wed, May 15, 2013 at 2:28 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' Sent: Monday, 13 May, 2013 05:33 I'm testing a client authentication using [Apache with 1.0.0-fips] I have 2 CA's x509 pem files, bundled. CA1 signs client1 certificate files CA2 signs client2 certificate files I should use two different CA with a similar issuer DN_OU in a bundle (file /path/to/pemfile.pem) openssl x509 -noout -in one.pem -issuer snip/O=Example S.p.A./OU=CA Organization Unit/snip openssl x509 -noout -in one.pem -issuer snip/O=Example S.p.A./OU=CA organization Unit/snip The only difference between 2 CAs is the capital letter in OU field. You probably shouldn't. According to RFC 3280 and 5280, X.509 or X.somethingrelated requires matching of Distinguished Name including child-Issuer to parent-Subject be case-insensitive and ignore insignificant (leading,trailing,multiple) spaces. So what you actually have there is one CA with two certs, presumably with different (public) keys. If so, certs issued under one can't verify under the other. OpenSSL does cert (chain) lookup using canonicalized DN and takes the first one found, so if you have canonically-equal names like these (which both match) it can only use one. When i try to use this configuration I receive a 403 error: headerAH02261: Re-negotiation handshake failed: Not accepted by client!? That looks like a different error or at least a confusing message. The only way it works is without [requiring client auth] or Using only one CA in the file (file /path/to/pemfile.pem) As expected, see above. But I'm still unable to retrieve client cert data; I don't know if the client is authenticated or not. I don't know what if anything mod_ssl gives you if it receives a client cert that doesn't validate. But I would focus on getting client auth to work first, and then see if you have a problem with getting the auth result. The same configuration using openssl_server works, it seems like an uncorrect (or incomplete) mod_ssl openssl's implementation. Do you mean commandline s_server? That shouldn't verify a client cert that mod_ssl doesn't with the same truststore, but it *will* proceed with a session even if a cert fails to verify, whereas a proper SSL application will refuse to continue or at least treat as unauthorized. Look to see if s_server reported any verify error: If you mean something else, you'll have to explain. [If] The bundle file contains CA1 and CA2; client certificates signed by CA1 (client1) work, client certificates signed by CA2 (client2) don't work. [and if reversed the reverse] As expected, OpenSSL uses only the first matching CA cert. The same site under iis works :( I don't know much about IIS but I would guess it uses the same Windows logic for trust as browsers like IE and Chrome, and I know those do find alternate chains in some cases OpenSSL's method does not -- even for identical CA-name, so I would expect also for canonically-equal CA-name. It could also be using AKI in chain build, if you have it in your certs (I didn't try to go through your script to see). OpenSSL *checks* AKI if present but doesn't use for lookup. How could I solve it using apache? I doubt you can use those CAs with vanilla mod_ssl and openssl. You could build and use a hacked version of openssl that does (more) exact lookup and match. If you want this to work over time you'd have
Similar issuer dn mod_ssl client authentication issue
I'm testing a client authentication using: SSLCACertificateFile /path/to/pemfile.pem LocationMatch /test SSLVerifyClient require SSLVerifyDepth 2 /LocationMatch My env: CentOS 6.4, OpenSSL 1.0.0-fips 29 Mar 2010, Server version: Apache/2.4.3 (Unix) - Server built: Feb 7 2013 14:32:46 I have 2 CA's x509 pem files, bundled. CA1 signs client1 certificate files CA2 signs client2 certificate files I should use two different CA with a similar issuer DN_OU in a bundle (file /path/to/pemfile.pem) openssl x509 -noout -in one.pem -issuer /C=IT/ST=MyState/L=MyTown/CN=Example Root CA Temporary 90days/O=Example S.p.A./OU=CA *O*rganization Unit/emailAddress=i...@example.com openssl x509 -noout -in one.pem -issuer /C=IT/ST=MyState/L=MyTown/CN=Example Root CA Temporary 90days/O=Example S.p.A./OU=CA *o*rganization Unit/emailAddress=i...@example.com The only difference between 2 CAs is the capital letter in OU field. When i try to use this configuration I receive a 403 error: [Mon May 06 09:33:28.115455 2013] [ssl:error] [pid 5120:tid 139860297901824] [client 10.0.2.2:59798] AH02261: Re-negotiation handshake failed: Not accepted by client!? The only way it works is without the SSLRequire directive. or Using only one CA in the file (file /path/to/pemfile.pem) or using SSLVerifyClient optional|optional_no_ca But I'm still unable to retrieve client cert data; I don't know if the client is authenticated or not. The same configuration using openssl_server works, it seems like an uncorrect (or incomplete) mod_ssl openssl's implementation. Addendum: The bundle file contains CA1 and CA2; client certificates signed by CA1 (client1) work, client certificates signed by CA2 (client2) don't work. If I change the order of the two certificates in the /path/to/pemfile.pem, it happens that: The budle file contains CA2 and CA1; client certificates signed by CA2 (client2) work, client certificates signed by CA1 (client1) don't work. The same site under iis works :( How could I solve it using apache? Some suggestions? Regards Michele Masè ps: no aswer from apache mailing list :( I've attached a sample script to create CA's and client certificates. cert-gen.sh Description: Bourne shell script
