Re: Question about intermediate certificate chain
Please note that s_client is used for debugging connections not certs and might connect EVEN IF the server certificate is not good. http://www.openssl.org/docs/apps/s_client.html#item__verify Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure. For checking your certificate chains I recommend OpenSSL's verify command. http://www.openssl.org/docs/apps/verify.html P On 22 May 2013 03:06, Somesh Chakrabarti itsmesom...@gmail.com wrote: In your s_client command, you still need to include the -CAfile parameter and point it to just the self-signed Root certificate. Your server is sending the intermediates but the client is not able to verify the chain up to a Root. You may want to edit cacerts.pem to include only the Root certificate and try again. On Tue, May 21, 2013 at 5:50 PM, Jorge Ventura jorge.araujo.vent...@gmail.com wrote: That is what I have when I don't include the intermediate in the command: openssl s_client -connect 10.10.10.10:443 -verify 5 -state -showcerts verify depth is 5 CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify error:num=27:certificate not trusted verify return:1 depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify error:num=21:unable to verify the first certificate verify return:1 And this one when I include the two intermediate at cacerts.pem. openssl s_client -connect 10.10.10.10:443 -verify 5 -CAfile cacerts.pem -showcerts verify depth is 5 CONNECTED(0003) depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify return:1 depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA verify return:1 depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify return:1 --- Certificate chain 0 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA On Tue, May 21, 2013 at 7:26 PM, Wim Lewis w...@omnigroup.com wrote: On 21 May 2013, at 5:02 PM, Jorge Ventura wrote: Because the client trust the connection when I inform the intermediate, I suppose the server is not sending the intermediate, only the first certificate in the chain and in this case the command fail. That is a reasonable conclusion. You can check for sure using the -showcerts option to openssl s_client. __ 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How to create CSR with SN attribute
That question has been answered a few days ago. Here's an example: openssl req -new -newkey rsa:2048 -keyout dumb.key -nodes -out dumb.req -subj /C=UT/O=Whatever/GN=Per/SN=Edlund -- Erwann ABALEA Le 20/05/2013 16:47, Per Edlund a écrit : Hello! I need to create a key and a csr with SN=x but can't find any way to do this. Does anyone know how to do this? Kind regards /Per Edlund __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Smart card support with Openssl
On 5/18/2013 2:09 PM, Rajeswari K wrote: Hello Users/dev Team, Need some urgent help to program openssl for smart card/HSM. Our smart card never shares private keys. All crypto operations such as encryption,decryption will be performed by smart card. And any such actions from openssl needs to be redirected to smart card. Only certicate is left open. Have read about pkcs11 crypto engine support at openssl. Currently we are using openssl 0.9.8q. Does this version supports pkcs11 engine support? If supports, can you provide which part of the code needs to be changed to have successful handshake using smart card. Currently our openssl code is expecting a private key to perform handshake. When smart card is used, private_key is updated with NULL at SSL_ACCEPT(). Hence, its throwing as no shard cipher during handshake. Please provide a sample application how to program openssl for smart card where private key is not known. Thanks in advance. Have a look at https://www.opensc-project.org/opensc/wiki/engine_pkcs11 This is an engine that can call pkcs11, either the OpenSC or some other PKCS#11 implementation. Rajeswari. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Hi
Hi, I am Lavanya working for Mistral solution, I am using openssl code in our project, the function in pmeth_lib.c OBJ_bsearch_pmeth returns 0, May I know the possible reasons for it, In FIPS mode our product fails on RSA signature verification throwing out unsupported algorithm, while tracing the code I found the above mention function returns 0. Help me fixing this issue. I am using openssl-1.0.1e version. Thanks, Lavanya __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [SOLVED] Question about intermediate certificate chain
In the past, I was not using Intermediate certificate and the code below works with no problem. /* Load the CAs we trust*/ if(!(SSL_CTX_load_verify_locations(ctx, *NULL*, CA_PATH))) berr_exit(Couldn't read CA list/path); SSL_CTX_set_verify_depth(ctx,*1*); Now that I have a chain of intermediate certificates, I have to inform about that in the SSL_CTX_load_verify_locations and it's what I am doing with the code below. /* Load the CAs we trust*/ if(!(SSL_CTX_load_verify_locations(ctx, *str_keyfile.data()*, CA_PATH))) berr_exit(Couldn't read CA list/path); SSL_CTX_set_verify_depth(ctx,*5*); Thank you all for the suggestions; all of that helps me to understand the concept of intermediate certificates and how is the interaction with the client side. On Tue, May 21, 2013 at 7:02 PM, Jorge Ventura jorge.araujo.vent...@gmail.com wrote: I have an application (server) that is working using SSLv23 with a regular certificate. Now I have to use one chain of two intermediate certificates but for any reason, openssl library is not sending the chain and the only way to work correctly is when I inform to the client side about the intermediate. If I am understanding correctly, as long as the client trust in the last certificate, it will trust on all intermediate. Below is a result using the command openssl s_client The client has only the Equifax root certificate; all other GeoTrust are intermediate. The file cacerts.pem in the command below has the two intermediate informed to force the command to succeed but in the real case, I don't have such information at client side. Because the client trust the connection when I inform the intermediate, I suppose the server is not sending the intermediate, only the first certificate in the chain and in this case the command fail. $ openssl s_client -connect 10.10.10.10:443 -verify 5 -state -CAfile cacerts.pem verify depth is 5 SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify return:1 depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA verify return:1 depth=0 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A CONNECTED(0003) --- Certificate chain 0 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA --- Server certificate -BEGIN CERTIFICATE- (the server certificate) -END CERTIFICATE- subject=/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior Lake/O=ACME, INC/CN=www.acme.com issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA --- No client certificate CA names sent --- SSL handshake has read 1539 bytes and written 447 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: AES256-SHA Session-ID: 5FB55650BEEAE091441A5CEF4047A0243EE9D57AE8F0485CC1F951E2E97CAE06 Session-ID-ctx: Master-Key: 06B036B9D47B297D2086CB6370108BB60102CD0FD7649F92351E15324D96E8614C566BF9040296177E2BDCA0A189472C Key-Arg : None Start Time: 1369178367 Timeout : 300 (sec) Verify return code: 0 (ok) --- read:errno=0 SSL3 alert write:warning:close notify
Re: Hi
On 5/22/2013 11:54 AM, Lavanya Sundararajan wrote: I am Lavanya working for Mistral solution, I am using openssl code in our project, the function in pmeth_lib.c OBJ_bsearch_pmeth returns 0, May I know the possible reasons for it, In FIPS mode our product fails on RSA signature verification throwing out unsupported algorithm, while tracing the code I found the above mention function returns 0. Help me fixing this issue. I am using openssl-1.0.1e version. That is simply the function that searches the list of registered/available signature methods, and it returns 0 because the signature type you are trying to verify is not available. However you did not specify which kind of RSA signature you were trying to verify, and this makes all the difference when it comes to FIPS availability: 1. How many bits are your RSA public key (the modulus), this is also the number of bits in the signature. 2. Which hash algorithm (such as MD5 or SHA-256) is used by the signature you are trying to verify? 3. Which RSA padding scheme is used when converting the raw hash value into RSA input? For example are you using PKCS#1 v. 1.x padding, PSS (PKCS#1 v. 2.1), or one of the ISO 9796 schemes. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS enabled OpenSSL fails to load libeay32.dll in Windows CE 6
On Tue, 21 May 2013 16:12:45 +0530 Abhijit Ray Chaudhury abhijit.ray.chaudh...@gmail.com wrote: Hi, I have compiled openssl-fips and openssl in Windows CE 6. But when I run fips_premain_dso.exe libeay32.dll in target environment I get following error: = 217450134:error:2507606A:DSO support routines:WIN32_BIND_FUNC:could not bind to the requested symbol name:.\crypto\dso\dso_win32.c:296:symname(FINGERPRINT_premain) 217450134:error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name:.\crypto\dso\dso_lib.c:294: = Which means GetProcAddress is failing for symbol name FINGERPRINT_premain. But if I do dumpbin /exports libeay32.dll, I can see the symbol FINGERPRINT_premain exported. You are correct (from dumpbin), which leads me to question whether you hadn't run the fips_premain_dso.exe binary in the CE 6 emulation environment, but perhaps ran a win32 flavor of fips_premain_dso. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl-fips-ecp-2.0.2 and DSA
1) I'm wondering why the FIPS_selftest_dsa() function in fips_dsa_selftest.c uses EVP_sha384 with a 2048-bit DSA key during the fips_pkey_signature_test()? If I'm reading the NIST standards (FIPS 186-3 and SP 800-57 Part 1) correctly, it looks like it is more usual for 2048-bit DSA keys to be paired with SHA 224 or SHA 256 during digital signature operations. As far as I can tell there is no prohibition against using SHA 384 (or SHA 512) with 2048-bit DSA keys, but FIPS 186-3 states that differing relative strengths of keys and hashes should only be used if an agreement has been made between participating entities to use a stronger hash function. 2) It seems that the DSA_generate_parameters() implementation supports 'q' values of 160 or 256 but not 224. Is that correct? Thanks.
RE: Similar issuer dn mod_ssl client authentication issue
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: openssl 1..0.1e -bad sig size 32 32 for DSA 2048 keys
From: owner-openssl-us...@openssl.org On Behalf Of Cipher Sent: Monday, 20 May, 2013 11:07 I built and installed openssl 1.0.1e. When i try to connect using ssh with 2048 DSA keys, i get *bad sig size 32 32* error. Is this a bug? Here is how i created the keys. openssh (through 6.2) ssh-dss.c limits sig parts to 20 bytes (matching a SHA1 hash), consistent with RFC 4253 6.6 which specifies SHA1 and 160-bit (20-byte) r s. Note 4253 was issued in 2006 well before DSS was updated by 186-3 in 2009 with groups1k subgroups160 (and SHA2). On checking I see 6668 less than a year ago defines new *data* hmacs for SHA-256/512, but no change to pubkey auth. So there doesn't appear to be any standard or interoperable SSH protocol using 186-3, nor any openssh extension. You may have hit the difference because openssl 1.0.0 supported |p|1024 as a then-nonstandard extension, but still |q|=160 and SHA1 for signing (because of API issue). Newer openssl does |q|=256 SHA-2 -- incompatible with (open)ssh. In 1.0.0 unless you use what is intended as an internal routine you can't generate parameters for 2048/160. But if you use parameters generated by 0.9.8 (or some other thing that can do 2048/160), and generate a key, the sign and verify logic and thus I expect (probably) openssh can use it. But you don't get any security benefit; SP800-57 rates 2048/224 or 2048/256 as 112-bit strength, but using 2048/160 will reduce it to 80-bit strength no better than 1024/160. And you may or may not be interoperable, because another implementation may have coded to FIPS 186-2 as specified. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Determine CMS/PKCS7 type
I'm in the process of refactoring my code to use the new CMS API instead of
PKCS7.
In my code before I was able to determine the type of pkcs7, and even
distinguish between a signed data (.p7m), signature (.p7s) and cert chain
(.p7b), using this function:
PKCS7Type determine_pkcs7_type(PKCS7* p7)
{
int nid = OBJ_obj2nid(p7-type);
switch( nid ) {
case NID_pkcs7_data:
return PKCS7Type_Data;
case NID_pkcs7_enveloped:
case NID_pkcs7_encrypted:
return PKCS7Type_EncData;
case NID_pkcs7_digest:
return PKCS7Type_Digest;
case NID_pkcs7_signed:
if( p7-d.sign-contents
OBJ_obj2nid(p7-d.sign-contents-type) == NID_pkcs7_data
p7-d.sign-contents-d.data != NULL )
return PKCS7Type_SignedData;
if( sk_PKCS7_SIGNER_INFO_num(p7-d.sign-signer_info) 0 )
return PKCS7Type_Signature;
if( sk_X509_num(p7-d.sign-cert) 0 ||
sk_X509_CRL_num(p7-d.sign-crl) 0 )
return PKCS7Type_Certs;
return PKCS7Type_UNKNOWN;
}
return PKCS7Type_UNKNOWN;
}
Now I am trying to do the same thing with CMS, but the struct contents are
encapsulated from me (yes yes, that is good I know), so I'm currently at a
loss as to how to differentiate the types, see below:
PKCS7Type determine_pkcs7_type(CMS_ContentInfo* cms)
{
int nid = OBJ_obj2nid(CMS_get0_type(cms));
switch( nid ) {
case NID_pkcs7_data:
return PKCS7Type_Data;
case NID_id_smime_ct_compressedData:
return PKCS7Type_CompData;
case NID_pkcs7_enveloped:
case NID_pkcs7_encrypted:
return PKCS7Type_EncData;
case NID_pkcs7_digest:
return PKCS7Type_Digest;
case NID_pkcs7_signed:
{
// HELP!! How can I tell if this is a signed data, or just
a signature (i.e., a .p7s with no data), or it is a cert chain (i.e., a
.p7b with just certs)
}
}
return PKCS7Type_UNKNOWN;
}
Thanks,
Phillip
CMS_get0_signers() badly named?
Looking at the implementation of CMS_get0_signers(), it looks like it creates a new stack of X509 that I will have to free. Isn't the convention to use a 1 if the return values needs to be freed, and 0 if not? So shouldn't this function be named CMS_get1_signers()? (Note that CMS_get1_crls() is correctly named with a 1.) Probably too late to change it now though, huh? Phillip
