Re: Digital certificate with more than 1 year validity
I do it all the time. -days 3650 as I recall. -- Sent from my mobile phone. Please excuse my brevity. Charles Wim Lewis wrote: On 17 Sep 2012, at 9:13 PM, Santhosh AP wrote: > Kindly help us to create digital certificate having more than 365 day’s > validity. At present we are using OpenSSL 0.9.7a Feb 19 2003 version. Kindly > confirm is it possible to cross the certificate validity more than 1 year, if > it’s possible how to do it. I don't think there is anything preventing you from specifying a longer validity period, either on the command line to the 'ca' command or in the relevant ca section of the config file. (Some documentation says to specify it when creating the CSR, but this is wrong: the CSR does not carry that information as far as I know. The validity period is chosen by the CA when it creates the certificate.) This is more of a openssl-users question than a openssl-dev question, so I've cc:'d that list; it's probably best if replies go there. _ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Enabling Logging in OpenSSL
>From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar >Sent: Tuesday, 18 September, 2012 00:37 >Hello Dave, >Below is what i see in Server Logs >"Encryption is required to connect to this server but the >client library does not support encryption; the connection >has been closed. Please upgrade your client library. >Error: 17835, Severity: 20, State: 1" >Do you have any pointers? Have you encountered any time before >such errors in forum? I've never seen it, no. The first several google hits for SQL server error 17835 strongly suggest that the error might be that the client "library" (aka driver) isn't *configured* correctly, not that it doesn't actually support encryption. I would try to check that first. If you're using one of the several Microsoft "only and forever solution"s, you'll have to find the correct instructions for it, or someone who knows it. I can't help you there (and no one else has chimed in). If the problem is truly that the client doesn't support it -- and it appears your client would have to be older than about 2005 for that to be the case -- then you need a better client. If MS, I would stick with it and upgrade -- upgrading existing product "in place" is one thing MS usually does pretty well. If you're using some third-party product see if it can be upgraded, and if not change to something else, like MS -- or ask to get the encryption requirement relaxed, although depending on the data on this server that may not be possible in the current world of increasing attacks and liability or penalty for breaches. If for some reason you can't use an MS driver and can't find or use a third-party driver, and are left to implement it yourself, you will have to implement TDS *and* SSL. You can use OpenSSL for the SSL part, but I doubt anyone here can help you for TDS. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Converting BIO* to PKCS7*
>From: Mohammad khodaei [mailto:m_khod...@yahoo.com]
>Sent: Tuesday, 18 September, 2012 06:52
>Thanks for the response. The encryption is also done by me.
>I have generated the cipher text as below:
> in = BIO_new_mem_buf(pchContent, iPriKeyLen);
> if (!in) { //
> p7 = PKCS7_encrypt(recips, in, EVP_des_ede3_cbc(), flags);
> if (!p7) { //
> char* chEnc = new char[1000];
> BIO* memorybio = BIO_new(BIO_s_mem());
> BIO* base64bio = BIO_new(BIO_f_base64());
> BIO* outbio = BIO_push(base64bio, memorybio);
> long ll = i2d_PKCS7_bio(outbio, p7);
> BIO_flush(outbio);
> BIO_set_flags(memorybio, BIO_FLAGS_MEM_RDONLY);
> int iLength = BIO_get_mem_data(memorybio, &chEnc);
Asides: I'm pretty sure you don't actually need to set RDONLY
to do get_mem_data, and maybe not even flush beforehand.
And BIO_get_mem_data overwrites the pointer you give it,
so your new char[1000] is leaked.
>The encrypted value is generated like this:
> MIGkBgkqhkiG9w0BBwOggZYwgZMCAQAxfDB6AgEAMGQwVzELMAkGA1UEBhMCVUsx
> EjAQBgNVBAcTCVRlc3QgQ2l0eTEWMBQGA1UEChMNT3BlblNTTCBHcm91cDEcMBoG
> A1UEAxMTVGVzdCBTL01JTUUgUm9vdCBDQQIJAJ+rfmEoLQRhMA0GCSqGSIb3DQEB
> AQUABAAwEAYJKoZIhvcNAQcBMAMGAQA=
That is not DER, at least not plain DER; it's base64 *of* DER.
>And I feed chEnc to the decryption procedure to be decrypted.
>Is it correct? Any idea if the encoding is incorrect.
To decode (and decrypt) that, you need to decode base64 first,
*then* decode DER. If/since you have it in memory, basically do
the reverse of your creation: BIO_new_mem_buf of the base64 data,
BIO_push a base64BIO on the memBIO, and d2i from the result.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Digital certificate with more than 1 year validity
On 17 Sep 2012, at 9:13 PM, Santhosh AP wrote: > Kindly help us to create digital certificate having more than 365 day’s > validity. At present we are using OpenSSL 0.9.7a Feb 19 2003 version. Kindly > confirm is it possible to cross the certificate validity more than 1 year, if > it’s possible how to do it. I don't think there is anything preventing you from specifying a longer validity period, either on the command line to the 'ca' command or in the relevant ca section of the config file. (Some documentation says to specify it when creating the CSR, but this is wrong: the CSR does not carry that information as far as I know. The validity period is chosen by the CA when it creates the certificate.) This is more of a openssl-users question than a openssl-dev question, so I've cc:'d that list; it's probably best if replies go there. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Building FIPS capable openssl for iOS Armv7
Hi,
I built FIPS canister as per the instructions from 2.0 user guide.
I also set the FIPS_SIG environment variable to in core.sh / incore_macho.
When I try to build the openssl with fips, with following commands.
cd openssl-1.0.1c
./config fips
make depend
make install
I get following error in console,
engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS})
usage: /Users/Vinay/Desktop/SVN/temp/FIPS/incore_macho [--debug][-exe | -dso]
executable
make[2]: *** [link_app.] Error 1
make[1]: *** [openssl] Error 2
make: *** [build_apps] Error 1
This error is coming because the incore script is not invoked with correct
arguments.
Is this a problem in build script in openssl, or do I need to set any variables?
Any help would be greatly appreciated.
Thanks
Vinay
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Memory issues with ssl handshake
Hi again, I've changed the code to reuse the SSL contexts but in terms of memory consumption/release it did not change much - if anything at all. By the way, is there a way to "unload" a certificate once it has been loaded into a SSL context via SSL_CTX_use_certificate() ? I didn't find anything in the docs and simply specifying NULL as cert parameter caused a crash in OpenSSL. The only places left that cause memory leaks are reported inside OpenSSL as in at 0x68EAC8B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==27041==by 0x6C472DB: default_malloc_ex (mem.c:79) ==27041==by 0x6C4795F: CRYPTO_malloc (mem.c:306) ==27041==by 0x6C73940: bn_expand_internal (bn_lib.c:336) ==27041==by 0x6C73AE0: bn_expand2 (bn_lib.c:451) ==27041==by 0x6C73BB2: BN_set_bit (bn_lib.c:730) ==27041==by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514) ==27041==by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552) ==27041==by 0x6C95B56: RSA_eay_mod_exp (rsa_eay.c:782) ==27041==by 0x6C96422: RSA_eay_private_decrypt (rsa_eay.c:565) ==27041==by 0x6C97EDF: RSA_private_decrypt (rsa_lib.c:303) ==27041==by 0x6942918: ssl3_get_client_key_exchange (s3_srvr.c:2038) ==27041==by 0x6946693: ssl3_accept (s3_srvr.c:529) ==27041==by 0x69513CA: ssl3_read_bytes (s3_pkt.c:941) ==27041==by 0x694C688: ssl3_read_internal (s3_lib.c:3274) ==27041==by 0x69642E8: SSL_read (ssl_lib.c:954) Sometimes these are flagged "still reachable" and sometimes "indirectly lost", usually both types are reported as I get a large amount of these traces. One thing I noticed is that all goes well if I cause the code to run sequentially (e.g. cause requests to come one ater another). Yet it starts eating up memory like crazy if I cause several (HTTPS) requests to come at once. I'm at a loss here. Valgrind insists the leaks happen in OpenSSL code. I'll be happy to supply more information if anyone has an idea of how to approach this. Regards, Thomas On 09/13/2012 12:30 PM, Michel wrote: Hi again Thomas, Do you really need to free your context each time you free your TLS session ? I believe it is not needed and at least not usual. If you need several *DIFFERENT* contexts, implying different TLS configurations/setup, wich, I think, is not so common, you can keep them 'alive' during all your app 'run', even in multi-threaded programs. It would allow you to access some activity informations like the ones documented in : http://www.openssl.org/docs/ssl/SSL_CTX_sess_number.html Hope this helps, Regards Le 13/09/2012 10:39, Thomas a écrit : Hi Michel, Thanks for trying to help, I really appreciate it :-) "Does your app setup and free a context each time a client is connecting ?" The context is created only when a client requests a HTTPS connection and is destroyed together with the SSL session once the connection goes down. It is rather related to connections then to clients since one client can open several connections but I think you implied one connection per client and then the answer is 'yes'. I will try freeing the session before the context and come back with the results. Regards, Thomas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Converting BIO* to PKCS7*
Thanks for the response. The encryption is also done by me. I have generated
the cipher text as below:
in = BIO_new_mem_buf(pchContent, iPriKeyLen);
> if (!in) {
> return 0;
> }
>
>
> /* encrypt content */
> p7 = PKCS7_encrypt(recips, in, EVP_des_ede3_cbc(), flags);
> if (!p7) {
> return 0;
> }
>
>
> char* chEnc = new char[1000];
> BIO* memorybio = BIO_new(BIO_s_mem());
> BIO* base64bio = BIO_new(BIO_f_base64());
> BIO* outbio = BIO_push(base64bio, memorybio);
>
>
> long ll = i2d_PKCS7_bio(outbio, p7);
> BIO_flush(outbio);
> BIO_set_flags(memorybio, BIO_FLAGS_MEM_RDONLY);
> int iLength = BIO_get_mem_data(memorybio, &chEnc);
The encrypted value is generated like this:
MIGkBgkqhkiG9w0BBwOggZYwgZMCAQAxfDB6AgEAMGQwVzELMAkGA1UEBhMCVUsx
>EjAQBgNVBAcTCVRlc3QgQ2l0eTEWMBQGA1UEChMNT3BlblNTTCBHcm91cDEcMBoG
>A1UEAxMTVGVzdCBTL01JTUUgUm9vdCBDQQIJAJ+rfmEoLQRhMA0GCSqGSIb3DQEB
>AQUABAAwEAYJKoZIhvcNAQcBMAMGAQA=
And I feed chEnc to the decryption procedure to be decrypted. Is it correct?
Any idea if the encoding is incorrect.
Thanks
From: Dave Thompson
To: openssl-users@openssl.org
Sent: Monday, September 17, 2012 8:45 PM
Subject: RE: Converting BIO* to PKCS7*
>From: owner-openssl-us...@openssl.org On Behalf Of Mohammad Khodaei
>Sent: Monday, 17 September, 2012 05:01
>I've got a problem regarding BIO* to PKCS7* conversion. I want to
>call PKCS7_decrypt() function to decrypt a cipher text. Before that,
>I have this section of code:
>in = BIO_new_mem_buf(chEnc, iLength);
>if (!in) {
>p7 = d2i_PKCS7_bio(in, NULL);
>if (!p7) {
>140172957116064:error:0D0680A8:asn1 encoding routines:
ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1319:
>140172957116064:error:0D07803A:asn1 encoding routines:
ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:381:Type=PKCS7
>Any idea how to fix it? Is it the problem due to encoding?
>or is it a conversion problem?
Yes, it is encoding. The data you supplied isn't correct DER --
perhaps not DER at all, that's an easy way to get this wrong.
Check your data is DER and is exactly, octet for octet, that
produced by a correct sender (encoder).
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
