Re: [openssl-users] Help with making a SHA >1 certificate

[warron.french]

Charles, thanks for clarifying.  I was on the correct track, but for some
reason couldn't confirm it.  (I chalk it up to being tired.  That's my
story and I'm sticking to it.  lol).



--
Warron French


On Tue, Nov 7, 2017 at 9:37 AM, Charles Mills  wrote:

> The CA’s certificate validity is
>
>
>
> Not After : Nov 18 17:39:38 2024 GMT
>
>
>
> *Charles*
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *warron.french
> *Sent:* Monday, November 6, 2017 4:02 PM
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Help with making a SHA >1 certificate
>
>
>
> Charles, I am no expert either - sorry.
>
>
>
> However, the question about why is your signed certificate at least not
> getting to be over 1 year in "length?"   What is the duration of the CA's
> certificate?
>
> --
> 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

[openssl-users] Help compiling on HPUX

[Dan Freed]

I see that there are a few posts about compiling openssl on HP-UX, so I’m 
hopeful that someone can help me out.



I’m having issues getting things to completely finish the compilation process. 
There is an issue that some folks on Git-hub helped me resolve that was caused 
by some incompatibilities with HP’s make utility, but I have that resolved now 
(https://github.com/openssl/openssl/issues/4689).



Now I'm seeing an issue with what I think is the final link step that I cannot 
find a solution to, and those people on Git-Hub were unable to help with. The 
issue changed - and of course I cannot figure out why, but the current scenario 
is below.



Any help would be much appreciated.



I'm using all HP utilities, which mean their make and the aCC compiler to build 
the package.

I'm configuring with:

HP-UX : B.11.31 ia64



CFLAGS=+DD64

LDOPTS=+b /usr/local/epic/Epic2018/lib -L/usr/local/epic/Epic2018/lib

PERL=/usr/local/epic/Epic2018/bin/perl

./config no-ssl3 no-zlib no-zlib-dynamic --prefix=/usr/local/epic/Epic2018/ 
--libdir=lib -D_FORTIFY_SOURCE=2



Make errors out with the following (this is just the last bits of the output):



cc -I. -Iinclude -Iapps -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM

-D_FORTIFY_SOURCE=2 -D_REENTRANT 
-DOPENSSLDIR="\"/usr/local/epic/Epic2018/ssl\"" 
-DENGINESDIR="\"/usr/local/epic/Epic2018/lib/engines-1.1\"" -Ae +DD64 +Olit=all 
-z -DB_ENDIAN +O3 -D_REENTRANT -c -o apps/x509.o apps/x509.c

rm -f apps/openssl

make -f ./Makefile.shared -e \

PERL="/usr/local/epic/Epic2018/bin/perl" SRCDIR=. \

APPNAME=apps/openssl OBJECTS="apps/app_rand.o apps/apps.o apps/asn1pars.o 
apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o 
apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o 
apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o 
apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o 
apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o 
apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o 
apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o 
apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o 
apps/verify.o apps/version.o apps/x509.o" \

LIBDEPS=' '" -L. -lssl -L. -lcrypto"' -ldl -lpthread ' \

CC='cc' CFLAGS='-DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM

-D_FORTIFY_SOURCE=2 -D_REENTRANT 
-DOPENSSLDIR="\"/usr/local/epic/Epic2018/ssl\"" 
-DENGINESDIR="\"/usr/local/epic/Epic2018/lib/engines-1.1\"" -Ae +DD64 +Olit=all 
-z -DB_ENDIAN +O3 -D_REENTRANT ' \

LDFLAGS='' \

link_app.hpux-shared

LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -D_FORTIFY

_SOURCE=2 -D_REENTRANT -DOPENSSLDIR="/usr/local/epic/Epic2018/ssl" 
-DENGINESDIR="/usr/local/epic/Epic2018/lib/engines-1.1" -Ae +DD64 +Olit=all -z 
-DB_ENDIAN +O3 -D_REENTRANT -Wl,+s,+cdp,../:,+cdp,./: -o apps/openssl 
apps/app_ran

d.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o 
apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o 
apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o app

s/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o 
apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o 
apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o 
apps/req.o apps

/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o 
apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o 
apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -L. 
-lssl -L. -lc

rypto -ldl -lpthread

ld: (Warning) Unsatisfied symbol "bn_mul_comba4" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_mul_comba8" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_sqr_comba4" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_sqr_comba8" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "OPENSSL_cpuid_setup" in file 
./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_sub_words" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_sqr_words" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_mul_words" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_add_words" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "bn_div_words" in file ./libcrypto.so.1.1

ld: (Warning) Unsatisfied symbol "CRYPTO_memcmp" in file ./libssl.so

ld: (Warning) 

Re: [openssl-users] cms utility "-sign" doesn't include signed content

[lists]

On 10/20/2017 10:00 PM, Chris Marget wrote:

I'm struggling with a PKCS7 signing operation using openssl 1.0.2g.

I want to create signed messages like the one in my 'original' file 
(below). It seemed like extracting and then re-signing this message 
would be a good start.


I'm able to verify/unpack the original message, but not able to sign 
the unpacked message to get back to where I started. I have access to 
the signer's certificate and private key.


I hope somebody can point me in the right direction?

I'm extracting the message with:

openssl cms -verify -CAfile CA_cert.pem -inform pem -in original -out 
extracted



I thought I'd be able to re-sign this message using something like:

openssl cms -sign -md sha1 -in extracted -inkey signer_key -signer 
signer_cert -outform pem



This 'sign' operation completes successfully, but produces an output 
that's missing the payload. Using the same procedure to sign 1MB of 
random data produces a result that's only 1396 bytes long:




I think you want to add the option  "-nodetach"

dd if=/dev/urandom bs=1M count=1 | openssl cms -sign -md sha1 -inkey 
signer_key -signer signer_cert -outform pem | grep -v -- -- | base64 
--decode | wc -c


1396


Clearly this 'sign' function doesn't do what I thought it did.

How can I sign blob of data so that it looks like my 'original'?

The files I'm using:
original https://pastebin.com/raw/CNPLyqcm
CA_cert.pem https://pastebin.com/raw/HiE6gMTN
signer_key https://pastebin.com/raw/tnCXeYHg (the correct key, but not 
an actual secret)

signer_cert https://pastebin.com/raw/ACtTVHdp

Thank you!




-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help with making a SHA >1 certificate

[Charles Mills]

The CA’s certificate validity is 

 

Not After : Nov 18 17:39:38 2024 GMT

 

Charles

 

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
warron.french
Sent: Monday, November 6, 2017 4:02 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Help with making a SHA >1 certificate

 

Charles, I am no expert either - sorry.

 

However, the question about why is your signed certificate at least not getting 
to be over 1 year in "length?"   What is the duration of the CA's certificate?

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

[Salz, Rich via openssl-users]

There is something strange with the RSA private key or it’s BN_CONT object.  
Are you sure that you are properly releasing all OpenSSL objecdts in your code? 
   

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help with making a SHA >1 certificate

[Salz, Rich via openssl-users]

➢ -days on req when generating a request does noting, and should perhaps
produce a warning, since this option is only meaningful when used with
the -x509 option to produce a self-signed cert instead of a request.

https://github.com/openssl/openssl/pull/4692


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

[Matt Caswell]

On 07/11/17 10:01, Wang wrote:
> Hello Rich,
> 
> Thank you for trying to help. 
> 
> My product is running on Linux. The following leak was detected by Valgrind.
> Valgrind only reportes
> the leak in threaded mode. I run 'top' on linux to monitor the memory usage
> of my product. I can see the memory usage increases quickly.
> 
> ==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of 
> 1,294 
> ==9721==at 0x4A0817C: malloc (vg_replace_malloc.c:298) 
> ==9721==by 0x5B29CD0: comn_malloc (comalloc.c:28) 
> ==9721==by 0x58E7DD2: comn__csi_malloc (netenc2.c:52) 
> ==9721==by 0xBBC37EA: local_malloc (csi_provider_common.c:624) 
> ==9721==by 0xBC1747F: default_malloc_ex (mem.c:79) 
> ==9721==by 0xBC17BA6: CRYPTO_malloc (mem.c:350) 
> ==9721==by 0xBC2648F: bn_expand_internal (bn_lib.c:303) 
> ==9721==by 0xBC266AA: bn_expand2 (bn_lib.c:431) 
> ==9721==by 0xBC26FF6: BN_set_bit (bn_lib.c:736) 
> ==9721==by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494) 
> ==9721==by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544) 
> ==9721==by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763) 
> ==9721==by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554) 
> ==9721==by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111) 

Is this the "bottom" of the OpenSSL stack? i.e. your application calls
RSA_private_decrypt() directly? Do you share a single RSA object across
multiple threads?

Matt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to know maximum sendable fragment size?

[Matt Caswell]

On 07/11/17 03:56, J Decker wrote:
> I've been developing this NodeJS plugin, it implements HTTPS server and
> now client.  I was having an issue with HTTPS request getting ECONNRESET
> for no apparent reason; so I implemented my own request, and ran into
> the same sort of issue.  What I was requesting was some .js files from
> the server, and apparently my most recent changes to those files made
> them larger than some magic number greater than 4096 but less than
> 6561.  The server was sending using OpenSSL (statically linked in the
> NodeJS executable) on CentOS, and it was sending the full length of the
> file as one buffer.  I'm using memory BIO to interact with the SSL
> object; The buffer was transmitted as one block. With my own client,
> (where I could add debugging) was receiving the full count of bytes from
> the server but in two blocks, the first 4096 and the second
> 2472(something like that).  Because my network read buffer was
> only 4096 So the first read was short, and caused SSL_read to fail,

What do you mean this cause SSL_read() to fail? You got a <= 0 return
value? This should not happen. It is perfectly valid to read less bytes
than OpenSSL has available.


> which I had initially treated as a failure and terminated my
> connection.  I then
> found I could (almost) check using SSL_pending before getting an
> error (really I ended up doing SSL_read( ssl, NULL, 0 ) and then
> SSL_pending(ssl)
> ).  But after receiving the full count of bytes and having nothing else
> to receive, the message never completed (read return -1, and error 2,
> pending
> returned 0 ).

I'm not sure sure what you mean by "the message never completed". Do you
mean you were expecting more bytes but they never came?

> I manually broke up the transmission to 4356 (3*1452 -29)
> bytes so it ends up sending in 3 full tcp buffer units, and that works. 
> (it's http protocol so it's got higher level gathering for the
> fragments).  It also works if I revert to using the NodeJS HTTPS request
> object instead of my own.
> 
> So - how do I know what the maximum amount of data I can send is?

TLS is a stream protocol. There is no maximum amount of data you can
send in one go. Internally the protocol breaks up the data into a number
of records. The maximum amount of plaintext data sent in a single record
is SSL3_RT_MAX_PLAIN_LENGTH (16384) bytes. This can be changed by your
application (to something smaller - not larger) but you have to
explicitly do that. However changing this should have no impact on the
functional behaviour of your application.

> 
> Node TLS object (on which HTTPS is based)
> has tlsSocket.setMaxSendFragment(size)(which defaults to 16384)  but
> that's about sending, not receiving, so I really have no idea how big
> the receive buffer is actually (same as SSL send fragment default)
> 
> I did
> find 
> https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_split_send_fragment.html
> 
>  but
> there's no get_for fragment size I could find.  (this would be on
> the server side that I need to know how much I can send).
> 
> how do I set how big of a fragment I can receive?

The TLS protocol defines the size of the maximum fragment so no well
behaved implementation will ever send more than that. The OpenSSL
buffers are sized accordingly. In normal operation you should never need
to play around with these settings. Currently it is not possible to
change the size of the receive fragment - the sender is always allowed
to send any size up the to the maximum, so the receive buffers must
always be at least as big as that. In 1.1.1 (in development) there is a
feature which allows the client and server to negotiate a smaller
fragment size if they wish - but this is typically only useful in
resource constrained environments.

>  Like what if I tried
> to send 100's of Meg as a single fragment?   (I guess it should auto
> fragment to like 16k)

If you send a large amount of data in an SSL_write() call then OpenSSL
will automatically break that up into a series of records containing the
maximum amount of data until all of the data has been sent.

> 
> I guess there (will be) SSL_CTX_set_default_read_buffer_len() (1.1.0)

Unless you are doing pipelining with an engine that can support it then
you do not need to call this function.

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

[Wang]

Hello Rich,

Thank you for trying to help. 

My product is running on Linux. The following leak was detected by Valgrind.
Valgrind only reportes
the leak in threaded mode. I run 'top' on linux to monitor the memory usage
of my product. I can see the memory usage increases quickly.

==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of 
1,294 
==9721==at 0x4A0817C: malloc (vg_replace_malloc.c:298) 
==9721==by 0x5B29CD0: comn_malloc (comalloc.c:28) 
==9721==by 0x58E7DD2: comn__csi_malloc (netenc2.c:52) 
==9721==by 0xBBC37EA: local_malloc (csi_provider_common.c:624) 
==9721==by 0xBC1747F: default_malloc_ex (mem.c:79) 
==9721==by 0xBC17BA6: CRYPTO_malloc (mem.c:350) 
==9721==by 0xBC2648F: bn_expand_internal (bn_lib.c:303) 
==9721==by 0xBC266AA: bn_expand2 (bn_lib.c:431) 
==9721==by 0xBC26FF6: BN_set_bit (bn_lib.c:736) 
==9721==by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494) 
==9721==by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544) 
==9721==by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763) 
==9721==by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554) 
==9721==by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111) 

Regards,
Wang



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users