On Fri, Sep 12, 2014 at 11:42:51AM -0400, John Lane Schultz wrote:
> In my full-duplex, non-blocking application, I'd like to avoid renegotiation
> because my application doesn't need it and the complexity it seems to add.
>
> I was wondering, if neither side ever explicitly causes renegotiation
I hate compiling stuff on Solaris 10. The gcc version in /usr/sfw/bin is
so old. And it uses the Solaris linker in /usr/ccs/bin if if you use
/usr/sfw/bin/gmake instead of /usr/ccs/bin/make. Sometimes I can
work around issues by renaming /usr/ccs/bin/ld and creating a symlink
ld-> /usr
In my full-duplex, non-blocking application, I’d like to avoid renegotiation
because my application doesn’t need it and the complexity it seems to add.
I was wondering, if neither side ever explicitly causes renegotiation to occur
(e.g. - SSL_renegotiate), is it still possible with existing vers
On Fri, Sep 12, 2014 at 04:31:13AM -0400, Dave Thompson wrote:
> *If* you are now using a legacy-format encrypted private-key (and your
> original
>
> error message suggested you might need some form of private key, which does
>
> necessarily mean legacy-format encrypted) yes 76 chars is a pr
You are right, that the toplevel API doesn't have take a digest parameter. The
only kind of signature you get is the "default" where default is defined
per-key-type.
We should probably have PKCS7_sign_ex() that took a "const EVP_MD*" parameter.
It'd be trivial to do this. Same for CMS_sign.
Hello,
From the man page, it looks like signing packages always use SHA1, and
there is no argument to pkcs7_sign and cms_sign functions which would
allow to chose the algorithm.
May be I missed something... Or is there some method to sign with
another hsah algorithm ?
Thanks in advance.
Best
Hi All,
While fips build on soalris, I am getting variour errors:
Sun-Intel:
FIPSLD_CC=gcc FIPSLD_LINK=g++
/unixhome/upg/Unix/SunOS/i386/OpenSource/ssl-1.0.1h/bin/fipsld -fPIC
-shared -g -O2 -o libImpl.so.10.0.0 -lcrypto
Text relocation remains referenced
against sy
*If* you are now using a legacy-format encrypted private-key (and your original
error message suggested you might need some form of private key, which does
necessarily mean legacy-format encrypted) yes 76 chars is a problem.
The example(s) I saw earlier were certificates, where 76 chars works
-fingerprint is the hash of the whole cert. The question was hash of issuer
name.
If youre satisfied with hash of the issuer name >as encoded<, which should
not
but can differ from the canonicalized form OpenSSL uses for lookup, you can:
- use asn1parse to find the byte position of the issu
