Re: [Crypt::SSLeay] proxy with https
Namsuk kim wrote:
> ...
> Now, I have new problem that I didn't have before. First, the
> environment values for userid and passwd are not read and passed to the
> proxy. The other problem is that it seems CA repository information is
> not also read. Looks like I'm missing some components here. if I use
> "proxy_authorization_basic("", "");", proxy
> authentication goes through. But, it will bomb out at CA verification
> part giving me error like below.
> ...
I have comments about your code below which may help.
The gist I got from your mail was that you didn't care if
you got a CA verification error, you just wanted to get
through to the site via the proxy.
> Following is the part of the code.
>
> -
>
> # PROXY SUPPORT
> $ENV{HTTPS_PROXY} = 'http://proxy:8080';
>
good
> # PROXY_BASIC_AUTH
> $ENV{HTTPS_PROXY_USERNAME} = '***';
> $ENV{HTTPS_PROXY_PASSWORD} = '***';
>
good
> # DEFAULT SSL VERSION
> $ENV{HTTPS_VERSION} = '3';
>
I don't think you need this. Comment it out until
you know that you do.
> # CLIENT CERT SUPPORT
> $ENV{HTTPS_CERT_FILE} = 'certs/notacacert.pem';
> $ENV{HTTPS_KEY_FILE} = 'certs/notacakeynopass.pem';
>
You probably don't want to set these client certs as they
may just cause errors on the other end unless valid.
> # CA CERT PEER VERIFICATION
> $ENV{HTTPS_CA_FILE} = 'certs/ca.crt';
> $ENV{HTTPS_CA_DIR}= 'certs/';
>
You probably don't want to set this since you want to
ignore CA verification errors, right? This will
create an error if verification fails.
> $ua->env_proxy();
You don't need this with Crypt::SSLeay. In fact it
may cause problems.
>
> my $req = new HTTP::Request('GET', 'https://www.optisvalue.com/');
>
good.
> #$req->proxy_authorization_basic("", "");
> $req->authorization_basic('share', 'share');
>
Don't set authorization_basic for the proxy here, only for the
web page on the other side if necessary.
Also, you can set
$ENV{HTTPS_DEBUG} = 1;
for Crypt::SSLeay debug output to work through this issue.
If you want further help on this, you might want to take
this offline with me, and get me the URL that you are
trying to connect to, so I can see if I can get to it
over a local proxy setup.
--Josh
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Tru64 4.0f BN_sqr test fail
Once upon a time, Todd Williams <[EMAIL PROTECTED]> said: > Actually, I'm encountering the same exact problem as Keith. Clean build, > but fails the Square test. Look familiar? > ... > test BN_rshift > test BN_sqr > Square test failed! > make: *** [test_bn] Error 1 > > But I don't think it's a gcc issue. I get the same result on two different > Tru64 machines using the Compaq compiler... > > OSF1 V5.1 732 alpha: > Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732) > Compiler Driver V6.3-026 (sys) cc Driver > > OSF1 V4.0 1530 alpha: > Compaq C V6.4-214 (dtk) on Digital UNIX V4.0G (Rev. 1530) > Compiler Driver V6.4-014 (dtk) cc Driver I'm having the same problem with openssl-0.9.6b on Tru64 5.1A with the Compaq C compiler: OSF1 V5.1 1885 alpha Compaq C V6.4-009 on Compaq Tru64 UNIX V5.1A (Rev. 1885) Compiler Driver V6.4-008 (sys) cc Driver I installed GNU bc, but that has nothing to do with the problem because the test never gets to running bc; it fails in running bntest. The end of the output of bntest looks like: test BN_sqr print "test BN_sqr\n" -8C * -8C - 4DA8FEE60001 2BEFF * 2BEFF - 6159F8795207C11108201 Square test failed! 1 Any ideas? -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Crypt::SSLeay: Code works on Linux but not Solaris.. HELP!
Del Simmons wrote:
>
> Ok, got past that one.. OpenSSL was looking for the certs.pem file where
> it didn't exist.. copied that over to the proper location and this
> problem was fixed.. Now I have hit an even uglier snag..
...
> 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
> 500 (Internal Server Error) read failed:
> Net::SSL::die_with_error('Net::SSL=GLOB(0x356870)', 'read failed')
> called at /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/Net/SSL.pm line
> 211
If its working on Linux, but not Solaris, I would make sure
that your versions of openssl & Crypt::SSLeay are exactly
the same. If they are, I don't know why they would behave
differently. Check that your perl versions are the same too.
The former problem tends to be more relevant in case you
linked to an older version of OpenSSL before on one box,
and though you might have installed the latest OpenSSL,
Crypt::SSLeay is still using the old one.
--Josh
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Crypt::SSLeay: Peer Certificate Verification?
Del Simmons wrote:
>
> Hey guys,
>
> Sorry if this has been answered already. I'm using LWP to post data to a
> https server. The client cert and key is passed properly and the server
> verify's me fine when I submit my POST, but I always get the following
> warning header from LWP/Protocol/https.pm: "Client-SSL-Warning: Peer
> certificate not verified". After seeing a post by Lutz Jaenicke, it
> seems that the bottom line is that Crypt::SSLeay doesn't support the
> certificate verification process.
>
Crypt::SSLeay does support peer cert verification via
environment variable configuration. But, you will still
end up with the Client-SSL-Warning, as that it automatically
set in the LWP layer.
# CA CERT PEER VERIFICATION
$ENV{HTTPS_CA_FILE} = 'certs/ca.crt';
$ENV{HTTPS_CA_DIR}= 'certs/';
The perl XS code looks like:
SSL_CTX_set_verify(ctx)
...
CAfile=getenv("HTTPS_CA_FILE");
CAdir =getenv("HTTPS_CA_DIR");
if(!CAfile && !CAdir) {
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);
} else {
SSL_CTX_load_verify_locations(ctx,CAfile,CAdir);
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
}
I believe that when the CA verification is occuring,
there will be an error if the CA cert is not verified.
You can use the ./net_ssl_test script with a special
argument -CAfile, perldoc Crypt::SSLeay for more info,
and check out the CERT section.
--Josh
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
DSA_generate_parameters not returning a better seed?
Hi openssl-users, I'm using the crypto lib and am trying to generate good DSA key data sets with the seed and cnt. According to the function description of DSA_generate_parameters (), if I give it a rotten seed value, it should stuff a better one back to me? Or so it seems from the description. But I can't seem to get it to return a seed value back to me? If this isn't the case, how can I retrieve the seed and count information from the key I generate using the crypto libs? Also I passed DSA_generate_parameters a FIPS seed value and sure enough, I can reproduce the cnt value so at least that works. Thanks in advance, Francis.
Re: configuration problems - jsse....
"Nancy Pawlowski" <[EMAIL PROTECTED]> writes: > Does anyone recognize this error? > > I've had jsse with tomcat configured under linux - and it is running ok; >but am having problems running it under windows2000. This isn't an OpenSSL issue. Why are you posting it here? -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
configuration problems - jsse....
Does anyone recognize this error? I've had jsse with tomcat configured under linux - and it is running ok; but am having problems running it under windows2000. when i startup tomcat - i get an error right away. - have my jsse jars loaded; - have my java.security file configured: security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.net.ssl.internal.ssl.Provider - have my tomcat startup file configured/server.xml: ERROR: Running Tomcat with a SecurityManager... ERROR reading c:\java\jakarta-tomcat-3.2.1\conf\server.xml At Line 252 /Server/ContextManager/Connector/Parameter/ FATAL: configuration error java.lang.reflect.InvocationTargetException: java.lang.NoClassDef oundError: com/sun/net/ssl/internal/ssl/Provider at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at org.apache.tomcat.service.PoolTcpConnector.string2SocketFactory(PoolTcpConne ctor.java:417)> > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: rsa signature values
Bill, one good way to get this resolved is to outline ISO signature, namely data format, digest and padding used as well as other relevant details. A signature example (and the key used to make it) could also help. What is "intermediate signature"? regards, Vadim On Mon, 8 Oct 2001 [EMAIL PROTECTED] wrote: > Hi, > > I am attempting to utilise the OpenSSL RSA functionality to verify UN > standard Edifact files with AUTACK messages containing a signature which has > been generated using the SHA-1 digest. Also I need to produce a > corresponding outgoing AUTACK with an embedded signature attached to the Ack > or Nak message. > > I have been able to sign and verify locally using the SSL software but my > problem is the intermediate signature does not match that expected by the > 3rd parties we deal with. Indeed they do not match examples given by the > Edifact documentation in the worked examples. I get the expected digest > values but the RSA generated signature is completely different. > > The Edifact documentation says the RSA verification should comply with > ISO9796-1. I can find no mention of ISO standards at all in the release so > maybe you can confirm whether or not this might be the problem. > > Thanks in advance, > > > > Bill Cotton > > > _ > Notice to recipient: > This e-mail is meant for only the intended recipient of the transmission, > and may be a communication privileged by law. If you received this e-mail in > error, any review, use, dissemination, distribution, or copying of this > e-mail is strictly prohibited. > > When addressed to our clients any opinions or advice contained in this > internet e-mail are subject to the terms and conditions expressed in any > applicable governing terms of business or client engagement letter issued by > Bank of America. > > Both Bank of America, N.A and Banc of America Securities Limited are > regulated by The Securities and Futures Authority. > _ > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: About libssl.so.2 and libcrypto.so.2
On Mon, Oct 08, 2001 at 09:28:52AM +0100, [EMAIL PROTECTED] wrote:
[...]
> "Rawhide" is not another version of Linux, it is simply the name of a
> repository for optional updates to the current version of RedHat Linux. Of
> course, that question is a little off-topic for this list.
No, it's not optional updates to the current release. It's
an alpha thread that you use at your own risk. It's basically a
pre-beta rolling release. It is definitely a good spot to catch up
on recent kernel releases before they make it to the main updates site.
> As I have said repeatedly, openssl is included with RedHat 7.1. openssh,
> sendmail and bind all rely on the package being there. This has been the
> case since RedHat 7.0, and will undoubtedly be the case for 7.2. I haven't
> checked out roswell (aka 7.1.93) yet, as RedHat have locked off the file
> permissions on their ftp site!
Looks like they just did that a couple of days ago. I had downloaded
both Beta1 and Beta2 from ftp.redhat.com:/pub/redhat/linux/beta/roswell but
permissions are now set to deny. Simultanious to that, a 7.2 directory has
now appeared as /pub/redhat/linux/7.2 also with access permissions denied.
Looks like we are on the verge of the 7.2 release and they are preping the
site... :-) Wheee...
> RPM packages contain either pre-built binaries or a source package that will
> compile in a pre-arranged way (specified in a "spec" file). They are useful
> for maintaining a common installation on multiple systems, or for
> administrators who haven't a clue what "make" or "configure" does.
> Anyone who upgrades or changes openssl without using the RedHat updates
> (details at www.redhat.com/errata/) runs the risk of breaking a lot of code.
> Also, the version of openssl with RedHat 7.1 is "hobbled" and does not
> include all the cipher support. I've asked an employee of RedHat who has
> OK'd the making available of a package that contains all the support for
> non-US users. I've yet to get round to doing that though.
Relative to the latest RawHide SRPMS (openssl-0.9.6b-9.src.rpm)...
1) Replace the openssl-engine-0.9.6b-usa.tar.bz2 source ball
with the real thing from the OpenSSL site. (The source
tarball with the RPM has had some things stripped. That's
part of the hobbling.)
2) Edit the spec file and remove the "-usa" from "Source".
2) Down in %prep, kill off %{SOURCE1} by commenting it out. (That's
another part of the hobbling).
3) Remove no-idea, no-rc5, etc on the config line. (Last part of
the hobbling.)
4) Build. All the RedHat "patches" seem to be compatible with the
non-crippled source tarball.
5) Enjoy.
> -
> John Airey
> Internet systems support officer, ITCSD, Royal National Institute for the
> Blind,
> Bakewell Road, Peterborough PE2 6XU,
> Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED]
[...]
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: nonblocking sockets + peek
Wirta Ville <[EMAIL PROTECTED]> writes: > Yes, there is someone listening. And the whole thing works if client > doesn't use non blocking sockets. For some reason non blocking > BIO_do_connect doesn't send anything with it's first few attempts (it's > fourth or fifth time that makes things work) and that's why (I suppose) > got = recv (conn->s, buf, 100, MSG_PEEK); > hangs and doesn't see anything coming from the socket. > > Theres something terrible wrong and I bet I have caused it as usual > :-) I just can't figure out what am I missing here. Have you tried doing a tcpdump to see what's actually happening on the wire? -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
MIME encoding and CMS
I need to be able to do the following: Encrypt Data - Convert a stream of bytes to the MIME encoding - Encrypt MIME encoded bytes using normal CMS rules - Use encrypted bytes as the value of the EncryptedContent field within EnvelopedData Sign Data - Convert a stream of bytes to the MIME encoding - Sign MIME encoded bytes using CMS object of type ContentInfo - Possibly add countersignature attribute Can I use OpenSSL routines to do this? If so, can you please tell me what routines I need to call? Thank you, Don __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
libssl.so , mod_ssl.c ???
Hello everyone. I'm new to this list. I'm running SuSE 7.2 and have installed openssl and openssh. I'm am trying to use SSL for https security but my httpd.conf is looking for the shared object libssl.so to load. I don't find this object on my system anywhere. Also, ssh and sshd seem to work fine. But I haven't completely figured out why sftp keeps on asking for a password. I've generated all the keys and installed where I think they're supposed to go but still no luck. Do the users on each system have to be the same - johnx is sftp'ing to johnx. I need it to sftp to work without a password. Thanks for any help and ideas. David
rsa signature values
Hi, I am attempting to utilise the OpenSSL RSA functionality to verify UN standard Edifact files with AUTACK messages containing a signature which has been generated using the SHA-1 digest. Also I need to produce a corresponding outgoing AUTACK with an embedded signature attached to the Ack or Nak message. I have been able to sign and verify locally using the SSL software but my problem is the intermediate signature does not match that expected by the 3rd parties we deal with. Indeed they do not match examples given by the Edifact documentation in the worked examples. I get the expected digest values but the RSA generated signature is completely different. The Edifact documentation says the RSA verification should comply with ISO9796-1. I can find no mention of ISO standards at all in the release so maybe you can confirm whether or not this might be the problem. Thanks in advance, Bill Cotton _ Notice to recipient: This e-mail is meant for only the intended recipient of the transmission, and may be a communication privileged by law. If you received this e-mail in error, any review, use, dissemination, distribution, or copying of this e-mail is strictly prohibited. When addressed to our clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by Bank of America. Both Bank of America, N.A and Banc of America Securities Limited are regulated by The Securities and Futures Authority. _ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: About libssl.so.2 and libcrypto.so.2
Hi, I've written up a page which hopefully answers these questions: http://www.manyfish.co.uk/openssl.html Let me know if anything is not clear. As John said, the RPM you need is from Raw Hide, so none of this stuff is supported or recommended by Red Hat. On your own head be it... Regards, joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: About libssl.so.2 and libcrypto.so.2
>-Original Message- >From: Xia Shang [mailto:[EMAIL PROTECTED]] >Sent: 05 October 2001 13:55 >To: [EMAIL PROTECTED] >Subject: About libssl.so.2 and libcrypto.so.2 > > >Hello,everyone >I know now that KDE 2.2 is not for Redhat 7.1 but for Roswell, >but what is Rawhide? >Another version of Redhat Linux? >I have downloaded "openssl0.9.6b" from www.openssl.org and >unpacked it, but I still >can't find "libssl.so.2" and "libcrypto.so.2". >I guess I must install it so that these two files can be >created. Am I right? >Another foolish question:What's the difference between the >installations from "*.rpm" >package and from "*.tar.gz" package(with "make", >"install" and so on)? >Thank you > Correction to my previous post, RawHide is indeed another version of Linux, but it is not supported, might destroy all your data, etc. However, I have taken packages from it (apache-mod_ssl 1.3.20-2.8.4 for example) and they've worked for me. Details are at ftp://ftp.redhat.com/pub/redhat/linux/rawhide/README - John Airey Internet systems support officer, ITCSD, Royal National Institute for the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] - NOTICE: The information contained in this email and any attachments is confidential and may be legally privileged. If you are not the intended recipient you are hereby notified that you must not use, disclose, distribute, copy, print or rely on this email's content. If you are not the intended recipient, please notify the sender immediately and then delete the email and any attachments from your system. RNIB has made strenuous efforts to ensure that emails and any attachments generated by its staff are free from viruses. However, it cannot accept any responsibility for any viruses which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: About libssl.so.2 and libcrypto.so.2
>-Original Message- >From: Xia Shang [mailto:[EMAIL PROTECTED]] >Sent: 05 October 2001 13:55 >To: [EMAIL PROTECTED] >Subject: About libssl.so.2 and libcrypto.so.2 > > >Hello,everyone >I know now that KDE 2.2 is not for Redhat 7.1 but for Roswell, >but what is Rawhide? >Another version of Redhat Linux? >I have downloaded "openssl0.9.6b" from www.openssl.org and >unpacked it, but I still >can't find "libssl.so.2" and "libcrypto.so.2". >I guess I must install it so that these two files can be >created. Am I right? >Another foolish question:What's the difference between the >installations from "*.rpm" >package and from "*.tar.gz" package(with "make", >"install" and so on)? >Thank you > "Rawhide" is not another version of Linux, it is simply the name of a repository for optional updates to the current version of RedHat Linux. Of course, that question is a little off-topic for this list. As I have said repeatedly, openssl is included with RedHat 7.1. openssh, sendmail and bind all rely on the package being there. This has been the case since RedHat 7.0, and will undoubtedly be the case for 7.2. I haven't checked out roswell (aka 7.1.93) yet, as RedHat have locked off the file permissions on their ftp site! RPM packages contain either pre-built binaries or a source package that will compile in a pre-arranged way (specified in a "spec" file). They are useful for maintaining a common installation on multiple systems, or for administrators who haven't a clue what "make" or "configure" does. Anyone who upgrades or changes openssl without using the RedHat updates (details at www.redhat.com/errata/) runs the risk of breaking a lot of code. Also, the version of openssl with RedHat 7.1 is "hobbled" and does not include all the cipher support. I've asked an employee of RedHat who has OK'd the making available of a package that contains all the support for non-US users. I've yet to get round to doing that though. - John Airey Internet systems support officer, ITCSD, Royal National Institute for the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] - NOTICE: The information contained in this email and any attachments is confidential and may be legally privileged. If you are not the intended recipient you are hereby notified that you must not use, disclose, distribute, copy, print or rely on this email's content. If you are not the intended recipient, please notify the sender immediately and then delete the email and any attachments from your system. RNIB has made strenuous efforts to ensure that emails and any attachments generated by its staff are free from viruses. However, it cannot accept any responsibility for any viruses which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
client connection through proxy
I have a terrible problem with my server program. It works absolutely fine for the connections made to it from the browser with in the intranet.But if the browser makes connection through a proxy server I am getting connection refused by the peer (i.e SSL_read() returns -1 with the error saying connection refused by the peer). I would be very greatful if anybody could help me in going about with this problem. I am blocked at this. Thanks very much kalyan ***Confidential Notice This e-mail communication may contain information that is confidential and privileged. The information is intended to be for the use of the addressee only. If you are not the named addressee you should not disseminate, distribute or copy this e-mail: to do so could be a breach of confidence. Kshema Technologies Ltd., # 1, Global Village, Mylasandra, Mysore Road, Bangalore 560059, INDIA. Tel: (91)-80-8603600-17 Fax: (91)-80-8603372 ** SeshaKalyan Manyam.vcf Description: Binary data
