自动回复: Re: OpenSSL 1.1.1 Windows dependencies

[kjjhh7 via openssl-users]

这是一封自动回复邮件。已经收到您的来信，我会尽快回复。

Re: OpenSSL 1.1.1 Windows dependencies

[Viktor Dukhovni]

On Wed, Oct 26, 2022 at 11:50:16AM -0400, Viktor Dukhovni wrote:
> On Wed, Oct 26, 2022 at 11:15:25AM +0100, Matt Caswell wrote:
> 
> > > I'm not promising anything. But if you send me the captures I can take a 
> > > look at them.
> > 
> > I've taken a look at the captures for the working and non-working scenarios.
> > 
> > Do I understand correctly that your application is acting as the server 
> > in this setup?
> > 
> > I have compared the working and non-working captures. In both cases the 
> > ClientHello is successfully received, and the server responds with a 
> > ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message. 
> > Aside from normal variations between one session and another, AFAICT, 
> > the ClientHello and the server's response messages all look identical 
> > other than the server obviously has a different Certificate. The 
> > Certificates themselves also look identical to each other other than the 
> > subject/subjectaltname being for a different server. The intermediate 
> > certs are the same in both cases.
> >
> > Following the server's ServerHelloDone the client continues with a 
> > ClientKeyExchange message in the working case. In the non-working case 
> > the the client immediately closes the TCP connection without sending any 
> > kind of alert.
> 
> See longish thread at:
> 
> https://marc.info/?l=postfix-users=166584042429636=2
> 
> which describes a remarkably similar set of symptoms observed after a
> Microsoft patch update.  Today the OP posted that a more follow-on patch
> appears to have resolved the problem.

TL;DR: progress on identifying the issue begins with:

https://marc.info/?l=postfix-users=166585652703462=2

-- 
Viktor.

自动回复: Re: OpenSSL 1.1.1 Windows dependencies

[kjjhh7 via openssl-users]

这是一封自动回复邮件。已经收到您的来信，我会尽快回复。

Re: OpenSSL 1.1.1 Windows dependencies

[Viktor Dukhovni]

On Wed, Oct 26, 2022 at 11:15:25AM +0100, Matt Caswell wrote:

> > I'm not promising anything. But if you send me the captures I can take a 
> > look at them.
> 
> I've taken a look at the captures for the working and non-working scenarios.
> 
> Do I understand correctly that your application is acting as the server 
> in this setup?
> 
> I have compared the working and non-working captures. In both cases the 
> ClientHello is successfully received, and the server responds with a 
> ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message. 
> Aside from normal variations between one session and another, AFAICT, 
> the ClientHello and the server's response messages all look identical 
> other than the server obviously has a different Certificate. The 
> Certificates themselves also look identical to each other other than the 
> subject/subjectaltname being for a different server. The intermediate 
> certs are the same in both cases.
>
> Following the server's ServerHelloDone the client continues with a 
> ClientKeyExchange message in the working case. In the non-working case 
> the the client immediately closes the TCP connection without sending any 
> kind of alert.

See longish thread at:

https://marc.info/?l=postfix-users=166584042429636=2

which describes a remarkably similar set of symptoms observed after a
Microsoft patch update.  Today the OP posted that a more follow-on patch
appears to have resolved the problem.


> This really looks like a problem on the client side to me.

Yes, the client just hangs up.  A known.  Disabling session tickets on
server appears to help in some cases (for no obvious reason).  Applying
the follow-on update is a better solution if applicable.

-- 
Viktor.

Re: OpenSSL 1.1.1 Windows dependencies

[Matt Caswell]

On 24/10/2022 10:17, Matt Caswell wrote:



On 22/10/2022 16:02, David Harris wrote:

On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:


That was my initial thought too, except that if it were
firewall-related, the initial port 587 connection would be blocked,
and it isn't - the failure doesn't happen until after STARTTLS has
been issued.


Not necessarily. That's true for a first-generation port-blocking
firewall, but not for a packet-inspecting one. There are organizations
which use packet-inspecting firewalls to block STARTTLS because they
enforce their own TLS termination, in order to inspect all incoming
traffic for malicious content and outgoing traffic for exfiltration.


I now have wireshark captures showing the exchanges between the working
instance and the non-working instance respectively; the problem is 
definitely

happening after STARTTLS has been issued and during the TLS handshake.
I'm not high-level enough to be able to make any sense of the 
negotiation data
though. The wireshark capture is quite short (22 items in the list) 
and I don't

mind making it available if it would be useful to anyone.


I'm not promising anything. But if you send me the captures I can take a 
look at them.


I've taken a look at the captures for the working and non-working scenarios.

Do I understand correctly that your application is acting as the server 
in this setup?


I have compared the working and non-working captures. In both cases the 
ClientHello is successfully received, and the server responds with a 
ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message. 
Aside from normal variations between one session and another, AFAICT, 
the ClientHello and the server's response messages all look identical 
other than the server obviously has a different Certificate. The 
Certificates themselves also look identical to each other other than the 
subject/subjectaltname being for a different server. The intermediate 
certs are the same in both cases.


Following the server's ServerHelloDone the client continues with a 
ClientKeyExchange message in the working case. In the non-working case 
the the client immediately closes the TCP connection without sending any 
kind of alert.


This really looks like a problem on the client side to me. Or at least 
that's where attention will have to be focused for now to figure out 
what went wrong. The client side has made the decision to close the 
connection (or plausibly some middlebox has, but this seems unlikely 
given that the handshakes up until that point look virtually identical).


Is there any possibility of getting any logs from the client side to see 
why it has decided to abort the connection?


Matt

Re: OpenSSL 1.1.1 Windows dependencies

[Matt Caswell]

On 22/10/2022 16:02, David Harris wrote:

On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:


That was my initial thought too, except that if it were
firewall-related, the initial port 587 connection would be blocked,
and it isn't - the failure doesn't happen until after STARTTLS has
been issued.


Not necessarily. That's true for a first-generation port-blocking
firewall, but not for a packet-inspecting one. There are organizations
which use packet-inspecting firewalls to block STARTTLS because they
enforce their own TLS termination, in order to inspect all incoming
traffic for malicious content and outgoing traffic for exfiltration.


I now have wireshark captures showing the exchanges between the working
instance and the non-working instance respectively; the problem is definitely
happening after STARTTLS has been issued and during the TLS handshake.
I'm not high-level enough to be able to make any sense of the negotiation data
though. The wireshark capture is quite short (22 items in the list) and I don't
mind making it available if it would be useful to anyone.


I'm not promising anything. But if you send me the captures I can take a 
look at them.


Matt





Furthermore, the OpenSSL
configuration is identical between the systems/combinations of
OpenSSL that work and those that don't.


Do you know that for certain? There's no openssl.cnf from some other
source being picked up on the non-working system?


I'm pretty certain, but I'll get the customer to double-check.

Cheers!

-- David --

RE: OpenSSL 1.1.1 Windows dependencies

[Michael Wojcik via openssl-users]

> From: openssl-users  On Behalf Of David
> Harris
> Sent: Saturday, 22 October, 2022 09:02
> 
> I now have wireshark captures showing the exchanges between the working
> instance and the non-working instance respectively; the problem is definitely
> happening after STARTTLS has been issued and during the TLS handshake.

A packet-inspecting firewall can monitor a TLS handshake (for TLS prior to 1.3) 
and terminate the conversation if it sees something in the unencrypted messages 
- ClientHello, ServerHello, ServerCertificate, etc - that it doesn't like. It's 
not beyond imagining that an organization would have a packet-inspecting 
firewall that terminates conversations using particular cipher suites, for 
example.

> I'm not high-level enough to be able to make any sense of the negotiation
> data though. The wireshark capture is quite short (22 items in the list)
> and I don't mind making it available if it would be useful to anyone.

Someone might be able to tell something from it.

Not much else is coming to mind, I'm afraid. It would help to know what system 
call is failing, with what errno value, but that's going to be a bit tough to 
determine on Windows. ProcMon, maybe? And it's curious that the OpenSSL error 
stack is empty, but without being able to debug you probably couldn't track 
that down, short of instrumenting a bunch of the OpenSSL code.

-- 
Michael Wojcik

Re: OpenSSL 1.1.1 Windows dependencies

[David Harris]

On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:

> > That was my initial thought too, except that if it were
> > firewall-related, the initial port 587 connection would be blocked,
> > and it isn't - the failure doesn't happen until after STARTTLS has
> > been issued.
> 
> Not necessarily. That's true for a first-generation port-blocking
> firewall, but not for a packet-inspecting one. There are organizations
> which use packet-inspecting firewalls to block STARTTLS because they
> enforce their own TLS termination, in order to inspect all incoming
> traffic for malicious content and outgoing traffic for exfiltration.

I now have wireshark captures showing the exchanges between the working 
instance and the non-working instance respectively; the problem is definitely 
happening after STARTTLS has been issued and during the TLS handshake. 
I'm not high-level enough to be able to make any sense of the negotiation data 
though. The wireshark capture is quite short (22 items in the list) and I don't 
mind making it available if it would be useful to anyone.

> > Furthermore, the OpenSSL
> > configuration is identical between the systems/combinations of
> > OpenSSL that work and those that don't.
> 
> Do you know that for certain? There's no openssl.cnf from some other
> source being picked up on the non-working system?

I'm pretty certain, but I'll get the customer to double-check.

Cheers!

-- David --

RE: OpenSSL 1.1.1 Windows dependencies

[Michael Wojcik via openssl-users]

> From: David Harris 
> Sent: Friday, 21 October, 2022 01:42
>
> On 20 Oct 2022 at 20:04, Michael Wojcik wrote:
> 
> > I think more plausible causes of this failure are things like OpenSSL
> > configuration and interference from other software such as an endpoint
> > firewall. Getting SYSCALL from SSL_accept *really* looks like
> > network-stack-level interference, from a firewall or similar
> > mechanism.
> 
> That was my initial thought too, except that if it were firewall-related, the
> initial port 587 connection would be blocked, and it isn't - the failure 
> doesn't
> happen until after STARTTLS has been issued.

Not necessarily. That's true for a first-generation port-blocking firewall, but 
not for a packet-inspecting one. There are organizations which use 
packet-inspecting firewalls to block STARTTLS because they enforce their own 
TLS termination, in order to inspect all incoming traffic for malicious content 
and outgoing traffic for exfiltration.

> Furthermore, the OpenSSL
> configuration is identical between the systems/combinations of OpenSSL that
> work and those that don't.

Do you know that for certain? There's no openssl.cnf from some other source 
being picked up on the non-working system?

-- 
Michael Wojcik

Re: OpenSSL 1.1.1 Windows dependencies

[David Harris]

On 21 Oct 2022 at 7:27, Richard Levitte wrote:

> Let me ask you this: on what Windows version was your application
> built?  Common wisdom would be to build on the oldest version...

My application is a very traditional Win32 application, and at the moment (and 
until circumstances *force* me to change) I build it in a Windows 7 SP2 VM. 
There's really no build-related reason why it shouldn't work on Server 2012, 
especially since the 1.1.1g build (which DOES work on the affected system) is 
built in exactly the same VM.

It's a puzzle, for sure.

Thanks for taking the time to look into this for me Richard.

Cheers!

-- David --

Re: OpenSSL 1.1.1 Windows dependencies

[David Harris]

On 20 Oct 2022 at 20:04, Michael Wojcik wrote:

> OpenSSL 1.1.1 uses Windows cryptographic routines in two areas I'm
> aware of: rand_win.c and the CAPI engine. I don't offhand see a way
> that a problem with the calls in rand_win.c would cause the particular
> symptom you described. My guess is that you're not using the CAPI
> engine, but you might check your OpenSSL configuration on the failing
> system.

For a variety of reasons to do with redistributables, I build OpenSSL as 
no-shared, and because of the compiler I prefer to use (an older build of 
Visual 
C), I have to compile with no-capi as well, so CAPI clearly isn't an issue in 
this 
case. But to be sure, I tried rebuilding OpenSSL with Visual C 2022 (using 
Visual C 2019 as the compile unit) and according to the customer, the result 
was the same.

> I think more plausible causes of this failure are things like OpenSSL
> configuration and interference from other software such as an endpoint
> firewall. Getting SYSCALL from SSL_accept *really* looks like
> network-stack-level interference, from a firewall or similar
> mechanism.

That was my initial thought too, except that if it were firewall-related, the 
initial 
port 587 connection would be blocked, and it isn't - the failure doesn't happen 
until after STARTTLS has been issued. Furthermore, the OpenSSL 
configuration is identical between the systems/combinations of OpenSSL that 
work and those that don't.

> Personally, if I ran into this, I'd just build OpenSSL for debug and
> debug into it. But I know that's not everyone's cup of tea.

Unfortunately, I don't have that level of access to the customer's systems. 

I was really just wondering if the combination of factors rang any bells with 
anyone before I started digging much deeper; it's altogether possible that I 
might 
just have to write this one off to experience and tell the user to use a 1.1.1g 
build 
of OpenSSL (which I build exactly the same way, and which works correctly in 
the same setup).

Thanks for the help - appreciated.

Cheers!

-- David --

Re: OpenSSL 1.1.1 Windows dependencies

[Richard Levitte]

Hi David,

I just did a check to see what Windows libraries the openssl.exe app
depends on, going back to look in 1.0.2, and looking at the current
development branch (master).

1.0.2:

  ws2_32.lib(cond: no-sock)
  gdi32.lib advapi32.lib crypt32.lib user32.lib
  bufferoverflowu.lib   (cond: cl version 14+)
  unicows.lib   (cond: win32 && -DUNICODE)

master:

  ws2_32.lib(cond: no-sock)
  gdi32.lib advapi32.lib crypt32.lib user32.lib
  bufferoverflowu.lib   (cond: cl version 14+)

As you can see, it hasn't changed much (the unicows.lib dependency was
there for Win9x compatibility, according to comments).

But, it's quite possible that those libraries have dependencies of
their own that have changed in newer Windows versions.

Let me ask you this: on what Windows version was your application
built?  Common wisdom would be to build on the oldest version...

Cheers,
Richard

On Thu, 20 Oct 2022 02:54:19 +0200,
David Harris wrote:
> 
> Up front, I'd like to apologize if this is an FAQ or has been answered 
> elsewhere 
> on this list: my workload means that I simply can't keep as up-to-date as I 
> would 
> like.
> 
> I have a situation where my application fails to accept an incoming SSL 
> handshake on Windows Server 2012, but the identical software running on 
> Server 2019 accepts the same connection from the same remote client without 
> a problem. Other types of client software (such as Thunderbird) connect to 
> either system without any problems. The connecting client is a Windows Cash 
> Register using Window's built-in crypto facilities. If I downgrade my app to 
> OpenSSL 1.1.1g or earlier, the problem doesn't happen. With 1.1.1k or 1.1.1q, 
> I 
> get the error (I haven't built any versions of OpenSSL between k and q). In 
> case 
> it helps, the connection is an incoming SMTP connection on port 587, and 
> STARTTLS is used to begin SSL negotiation.
> 
> SSL_accept returns -1, with an extended error of "SSL_ERROR_SYSCALL" (5), 
> which I understand to be largely what it returns when it doesn't have a clear 
> idea 
> of what's gone wrong. The error queue is completely empty in this situation. 
> The 
> cert is a LetsEncrypt cert that loads without errors and works fine with 
> other 
> clients.
> 
> Do recent versions of OpenSSL 1.1.1 have dependencies on some Windows 
> facility (winsock and wincrypt seem likely candidates) that might work on 
> Server 
> 2019 but fail on Server 2012?
> 
> The version of my application that is in public release uses 1.1.1g, so isn't 
> affected by this issue, but I'm slightly worried that I'm going to see an 
> uptick in 
> this type of problem if I release builds based on later versions of 1.1.1.
> 
> Does this ring any bells with anyone? Again, apologies if this is answered 
> elsewhere - I *did* spend some time in Google but couldn't find anything that 
> seemed relevant.
> 
> Thanks in advance for any advice.
> 
> Cheers!
> 
> -- David --
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

RE: OpenSSL 1.1.1 Windows dependencies

[Michael Wojcik via openssl-users]

> From: openssl-users  On Behalf Of David
> Harris
> Sent: Wednesday, 19 October, 2022 18:54
> 
> Do recent versions of OpenSSL 1.1.1 have dependencies on some Windows
> facility (winsock and wincrypt seem likely candidates) that might work on
> Server 2019 but fail on Server 2012?

OpenSSL on Windows has always had a dependency on Winsock/Winsock2 (see 
b_sock.c, e_os.h, sockets.h) for supporting socket BIOs. Obviously OpenSSL used 
for TLS is going to be interacting with Winsock. I can't think of any 
difference between Server 2012 and Server 2019 that would be relevant to the 
issue you describe.

OpenSSL 1.1.1 uses Windows cryptographic routines in two areas I'm aware of: 
rand_win.c and the CAPI engine. I don't offhand see a way that a problem with 
the calls in rand_win.c would cause the particular symptom you described. My 
guess is that you're not using the CAPI engine, but you might check your 
OpenSSL configuration on the failing system.

I think more plausible causes of this failure are things like OpenSSL 
configuration and interference from other software such as an endpoint 
firewall. Getting SYSCALL from SSL_accept *really* looks like 
network-stack-level interference, from a firewall or similar mechanism.

Personally, if I ran into this, I'd just build OpenSSL for debug and debug into 
it. But I know that's not everyone's cup of tea.

-- 
Michael Wojcik

Re: OpenSSL 1.1.1g Windows build slow rsa tests

[Jan Just Keijser]

Hi Dan,

On 21/01/21 19:22, Dan Heinz wrote:

[...]


Thank you all for the helpful suggestions. When I removed no-asm and 
built using nmake in the Developer Command Prompt for Visual Studio 
2015, I ended up getting an error "VC-WIN64A X86 conflicts with target 
x64". From the command prompt I ran cl and saw this "Microsoft (R) 
C/C++ Optimizing Compiler Version 19.00.24215.1 for x86". So I was 
building for x86? I'm not sure why it built with no-asm, but it did.

Once I ran the correct command prompt (I used Visual Studio x64 Native Tools 
Command Prompt), I saw a huge speed increase.  For example, 2048 bits:
Doing 2048 bits private rsa's for 10s: 8384 2048 bits private RSA's in 10.02s
Doing 2048 bits public rsa's for 10s: 236090 2048 bits public RSA's in 9.98s

Previously, I saw:
Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s

For further testing, I added back no-asm and my speed tests were in line with 
the downloaded openssl binary I was testing with.
Doing 2048 bits private rsa's for 10s: 1868 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 71338 2048 bits public RSA's in 10.02s

You can see removing no-asm does make a pretty large speed increase too.

In summary, using the correct build tools helps (although I am surprised it 
built with no-asm).  And removing no-asm sped things up.


Not sure why you'd want to do a 'no-asm' build to begin with, but 
another thing worth testing with your "asm" build is to run the speed 
test like this:

 set OPENSSL_ia32cap=0
 openssl speed rsa
(Linux/UNIX:  OPENSSL_ia32cap=0 openssl speed rsa)

On my (10th gen Intel ) laptop this gives me a ~35% performance hit. 
Explanation:
- no-asm build -> compiler generates all code, no hand-tuned assembly 
used at all; should be slowest


- asm build + OPENSSL_ia32cap=0  -> no newer CPU features used, but 
hand-tuned assembly is used. Especially AES encryption takes a hit if 
you disable these newer features


- asm build -> hand-tuned assemby, including the use of all new CPU 
features such as AES, SHA etc.


I've found that this sometimes helps manage expectations when the "build 
environment" CPU and the "runtime environment" CPU are very different. 
I've seen a developer claim his/her code runs blazingly fast on his/her 
Core i7 bla bla but when deploying it on a cheaper runtime device 
performance is terrible.


Note that no-asm + OPENSSL_ia32cap=0 should not have any effect compared 
to "no-asm".


JM2CW,

JJK / Jan Just Keijser

RE: OpenSSL 1.1.1g Windows build slow rsa tests

[Dan Heinz]

-Original Message-
From: openssl-users  On Behalf Of Michael 
Wojcik
Sent: Thursday, January 21, 2021 9:28 AM
To: openssl-users@openssl.org
Subject: RE: OpenSSL 1.1.1g Windows build slow rsa tests

> >From: openssl-users  On Behalf Of 
> >Dr Paul Dale
> >Sent: Wednesday, 20 January, 2021 19:28
>>
>> I'd suggest giving a build without the no-asm option a try.  The 
>> performance difference is usually quite significant.

>I agree. It just doesn't explain what Dan's email claims.

>> Statis vs dynamic builds wouldn't normally be associated with such a 
>> large difference.  If the difference were routinely this large, nobody 
>> would use dynamic linking.

>In this case it's the static-linked version which is slower. But I'd be 
>surprised if that's actually the cause.

Thank you all for the helpful suggestions.  When I removed no-asm and built 
using nmake in the Developer Command  Prompt for Visual Studio 2015, I ended up 
getting an error "VC-WIN64A X86 conflicts with target x64".  From the command 
prompt I ran cl and saw this "Microsoft (R) C/C++ Optimizing Compiler Version 
19.00.24215.1 for x86".  So I was building for x86?  I'm not sure why it built 
with no-asm, but it did.

Once I ran the correct command prompt (I used Visual Studio x64 Native Tools 
Command Prompt), I saw a huge speed increase.  For example, 2048 bits:
Doing 2048 bits private rsa's for 10s: 8384 2048 bits private RSA's in 10.02s
Doing 2048 bits public rsa's for 10s: 236090 2048 bits public RSA's in 9.98s

Previously, I saw:
Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s

For further testing, I added back no-asm and my speed tests were in line with 
the downloaded openssl binary I was testing with.  
Doing 2048 bits private rsa's for 10s: 1868 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 71338 2048 bits public RSA's in 10.02s

You can see removing no-asm does make a pretty large speed increase too.

In summary, using the correct build tools helps (although I am surprised it 
built with no-asm).  And removing no-asm sped things up.

RE: OpenSSL 1.1.1g Windows build slow rsa tests

[Michael Wojcik]

> From: openssl-users  On Behalf Of Dr Paul
> Dale
> Sent: Wednesday, 20 January, 2021 19:28
>
> I'd suggest giving a build without the no-asm option a try.  The
> performance difference is usually quite significant.

I agree. It just doesn't explain what Dan's email claims.

> Statis vs dynamic builds wouldn't normally be associated with such a
> large difference.  If the difference were routinely this large, nobody
> would use dynamic linking.

In this case it's the static-linked version which is slower. But I'd be 
surprised if that's actually the cause.

--
Michael Wojcik

Re: OpenSSL 1.1.1g Windows build slow rsa tests

[Dr Paul Dale]

I'd suggest giving a build without the no-asm option a try.  The 
performance difference is usually quite significant.


Statis vs dynamic builds wouldn't normally be associated with such a 
large difference.  If the difference were routinely this large, nobody 
would use dynamic linking.



Pauli

On 21/1/21 10:37 am, Michael Wojcik wrote:

From: openssl-users  On Behalf Of Dr Paul
Dale
Sent: Wednesday, 20 January, 2021 16:19

Try building without the no-asm configuration option.


That was my first thought, but according to Dan's message, the firedaemon 
version is also built with no-asm.

The only relevant differences I see between the two builds are static (Dan's) 
versus dynamic (firedaemon's) linkage:


On 21/1/21 6:18 am, Dan Heinz wrote:



compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090
/nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


/MT uses the static-linked MSVC runtime.


Here is the downloaded binary from
https://kb.firedaemon.com/support/solutions/articles/4000121705
:
compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
/O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


/MD uses the dynamic-linked MSVC runtime.


Here are my configure parameters:
Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2
no-ssl3 no-zlib no-comp no-pinshared no-ui-console
   -DOPENSSL_NO_DEPRECATED --api=1.1.0

And their configure parameters:
Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console
--api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl
-DOPENSSL_NO_DEPRECATED


Assuming the lack of a space between "VC_WIN64A" and "no-asm" is a typo, 
they're also building with no-asm, and the only significant difference for this case that I can see 
is no-shared. (no-pinshared looks even less likely to affect this test, and does it even have any 
effect when building no-shared?)

Linking with /MT will affect code size and layout, which could adversely affect 
code caching. It's not impossible that would have a factor-of-four penalty on 
compute-bound code. I'm reluctant to conclude that's the problem, though, 
without more evidence.

Unfortunately tracking this down would likely require profiling.

That's assuming Dan is correct about the firedaemon build being configured with 
no-asm.

--
Michael Wojcik

RE: OpenSSL 1.1.1g Windows build slow rsa tests

[Michael Wojcik]

> From: openssl-users  On Behalf Of Dr Paul
> Dale
> Sent: Wednesday, 20 January, 2021 16:19
>
> Try building without the no-asm configuration option.

That was my first thought, but according to Dan's message, the firedaemon 
version is also built with no-asm.

The only relevant differences I see between the two builds are static (Dan's) 
versus dynamic (firedaemon's) linkage:

> On 21/1/21 6:18 am, Dan Heinz wrote:

> > compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090
> > /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED

/MT uses the static-linked MSVC runtime.

> > Here is the downloaded binary from
> > https://kb.firedaemon.com/support/solutions/articles/4000121705
> > :
> > compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED

/MD uses the dynamic-linked MSVC runtime.

> > Here are my configure parameters:
> > Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2
> > no-ssl3 no-zlib no-comp no-pinshared no-ui-console
> >   -DOPENSSL_NO_DEPRECATED --api=1.1.0
> >
> > And their configure parameters:
> > Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console
> > --api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl
> > -DOPENSSL_NO_DEPRECATED

Assuming the lack of a space between "VC_WIN64A" and "no-asm" is a typo, 
they're also building with no-asm, and the only significant difference for this 
case that I can see is no-shared. (no-pinshared looks even less likely to 
affect this test, and does it even have any effect when building no-shared?)

Linking with /MT will affect code size and layout, which could adversely affect 
code caching. It's not impossible that would have a factor-of-four penalty on 
compute-bound code. I'm reluctant to conclude that's the problem, though, 
without more evidence.

Unfortunately tracking this down would likely require profiling.

That's assuming Dan is correct about the firedaemon build being configured with 
no-asm.

--
Michael Wojcik

Re: OpenSSL 1.1.1g Windows build slow rsa tests

[Dr Paul Dale]

Try building without the no-asm configuration option.

Pauli

On 21/1/21 6:18 am, Dan Heinz wrote:

Hello,

I’m building openssl 1.1.1g  on multiple platforms and I found that the 
rsa speed tests are significantly slower in my build than on the other 
OS platforms (Linux and macOS).


I downloaded a Windows 64-bit binary distribution of openssl from 
https://kb.firedaemon.com/support/solutions/articles/4000121705 
 as 
they include the configure parameters used for their build.


I ran the speed rsa tests on their openssl Windows 64-bit binary and 
they were much faster than the tests on my build.


Here’s some output.
My openssl binary executed with openssl speed rsa:

Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s

Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s

Doing 4096 bits private rsa's for 10s: 60 4096 bits private RSA's in 10.00s

Doing 4096 bits public rsa's for 10s: 4316 4096 bits public RSA's in 10.02s

OpenSSL 1.1.1g  21 Apr 2020

built on: Wed Jan 20 18:38:14 2021 UTC

options:bn(64,64) rc4(int) des(long) aes(partial) blowfish(ptr)

compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090 
/nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


   sign    verify    sign/s verify/s

rsa 2048 bits 0.024450s 0.000639s 40.9   1563.9

rsa 4096 bits 0.17s 0.002321s  6.0    430.9

Here is the downloaded binary from 
https://kb.firedaemon.com/support/solutions/articles/4000121705 
:
Doing 2048 bits private rsa's for 10s: 1622 2048 bits private RSA's in 
10.02s


Doing 2048 bits public rsa's for 10s: 72622 2048 bits public RSA's in 10.00s

Doing 4096 bits private rsa's for 10s: 255 4096 bits private RSA's in 10.03s

Doing 4096 bits public rsa's for 10s: 18976 4096 bits public RSA's in 10.00s

OpenSSL 1.1.1j-dev  xx XXX 

built on: Wed Jan  6 11:11:12 2021 UTC

options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr)

compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo 
/O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


   sign    verify    sign/s verify/s

rsa 2048 bits 0.006175s 0.000138s    161.9   7262.2

rsa 4096 bits 0.039338s 0.000527s 25.4   1897.6

That is a little over 4 times faster.

Here are my configure parameters:
Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2 
no-ssl3 no-zlib no-comp no-pinshared no-ui-console 
  -DOPENSSL_NO_DEPRECATED --api=1.1.0


And their configure parameters:
Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console 
--api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl 
-DOPENSSL_NO_DEPRECATED


Both my build and theirs are built with Visual Studio 2015.

Any ideas why my build is so much slower?  Is there something in my 
configuration that might cause this?

Re: [openssl-users] Windows 7 cryptbase.dll failing to load

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jakob Bohm
> Sent: Thursday, June 14, 2018 15:58
>
> Thus your 1.1.0 build runs on NT6.02 but not NT6.01, possibly due to
> references to NT6.02-only APIs

Sometimes the subsystem version information inserted by the linker is 
pessimistic for no reason (other than Microsoft's desire to get people to 
upgrade). Depends on the version of the Microsoft SDK installed, among other 
things.

So the OP might just try linking the DLL with /VERSION:6.1.

I'm not currently building a 1.1 OpenSSL, so I can't say what would need to be 
done with Configure to get that into the generated makefile.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


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

Re: [openssl-users] Windows 7 cryptbase.dll failing to load

[Jakob Bohm]

On 14/06/2018 18:39, Vollaro, John via openssl-users wrote:


Hi OpenSSL team,

Our team has successfully built Window dlls for OpenSSL code version 
1.0.2n.


The dll names where libeay32.dll & ssleay32.dll.

They worked on Windows 7 and Windows Server 2012 OS.

Our team has built Window dlls for the OpenSSL code using version 1.1.0h.

The dll names where libcrypt0-1_1-x64.dll & libssl-1_1-x64.dll

These dlls worked on  Windows Server 2012 OS.

These dlls do **not** load on Windows 7 OS.

I suspect an issue with Windows library cryptbase.dll



Note the translation table for Windows version names:

DosWindows 1.01 == Windows 1.0
DosWindows 1.02
DosWindows 1.03
DosWindows 1.04
DosWindows 2.03
DosWindows 2.10
DosWindows 2.11
DosWindows 3.00
DosWindows 3.10 == Janus == Sparta == Winball
DosWindows 3.11 == Snowball
DosWindows 4.00.950/3.95 == Windows 95== MS-DOS 7.00 == Chicago
DosWindows 4.00./3.9? == Windows 95 OSR2== MS-DOS 7.01 == Detroit
DosWindows 4.10.1998/3.9? == Windows 98 == Memphis
DosWindows 4.10./3.9? == Windows 98 SE
DosWindows 4.90.3000/3.9? == Windows ME
NT 3.10.528 == Razzle
NT 3.50.807 == Daytona
NT 3.51.1057
NT 4.00.1381
NT 4.00.1381SP3 == NT4.00 and NT4.00 Terminal Server Edition == Hydra
NT 5.00.2195 == Windows 2000
NT 5.01.2600 == Windows XP (x86 and IA64) == maybe special Server 200x 
for IA64 == Whistler

NT 5.02.37?? == Windows XP (x64) == Server 2003 == Server 2003 R2
NT 6.00.6000 == Windows Vista == Server 2008 == Longhorn
NT 6.01.7600 == Windows 7 == Server 2008 R2 == Blackcomb == Vienna
NT 6.02.9200 == Windows 8 == Server 2012
NT 6.03.9600 == Windows 8.1 == Server 2012 R2 == WinBlue
NT 10.00.10240 (1507) == Windows 10 original== LTSB 2015 == Threshold 1
NT 10.00.10586 (1511) == Windows 10 November update == Threshold 2
NT 10.00.14393 (1607) == Windows 10 Anniversary update== LTSB 2016 == 
Windows Server 2016 == V2 (Redstone)

NT 10.00.15063 (1703) == Windows 10 Creators update == Redstone 2
NT 10.00.16299 (1709) == Windows 10 Fall Creators update == Redstone 3
NT 10.00.17134 (1803) == Windows 10 April 2018 update == Redstone 4

Thus your 1.1.0 build runs on NT6.02 but not NT6.01, possibly due to 
references to NT6.02-only APIs


Any suggestion on getting this to work on Windows 7?

Has anyone else encountered this issue?



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Windows shared libraries version information needs some fixes

[RTT]

After your forth commit, seems all is working fine. Exe and dlls with, 
and correct, version information now. Thanks.


On 21/03/2018 02:08, Salz, Rich via openssl-users wrote:

Please look athttps://github.com/openssl/openssl/pull/5704  and see if it fixes 
the issues.



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

Re: [openssl-users] Windows shared libraries version information needs some fixes

[Matt Caswell]

On 21/03/18 09:36, Matt Caswell wrote:
> 
> 
> On 21/03/18 00:45, RTT wrote:
>> Hello,
>>
>> Building the shared libraries (version 1.1.1 pre 3) for Windows with
>> Visual Studio, targets VC-WIN32 or VC-WIN64A, result in DLLs with
>> version information with outdated copyright date, i.e. "Copyright
>> 1998-2016 The OpenSSL Authors. All rights reserved", and the file
>> description as "OpenSSL application" instead of "OpenSSL shared library".
>>
>> The version information resource file seems to be generated by the
>> script "util\mkrc.pl", that indeed has this old copyright date
>> hardcoded, and the logic that selects the file description that seems to
>> expect a call with a file extension (i.e. mkrc.pl libcrypto.dll, mkrc.pl
>> openssl.exe, ...), but the build.info file is not specifying any file
>> extension to these calls.
>>
>> Also, why the openssl.exe doesn't include version information?
>>
> 
> Please could you raise this as an issue on github so that it gets
> properly tracked?
> 
> https://github.com/openssl/openssl/issues

Ignore this. I see Rich has already created a PR to fix this.

Matt

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

Re: [openssl-users] Windows shared libraries version information needs some fixes

[Matt Caswell]

On 21/03/18 00:45, RTT wrote:
> Hello,
> 
> Building the shared libraries (version 1.1.1 pre 3) for Windows with
> Visual Studio, targets VC-WIN32 or VC-WIN64A, result in DLLs with
> version information with outdated copyright date, i.e. "Copyright
> 1998-2016 The OpenSSL Authors. All rights reserved", and the file
> description as "OpenSSL application" instead of "OpenSSL shared library".
> 
> The version information resource file seems to be generated by the
> script "util\mkrc.pl", that indeed has this old copyright date
> hardcoded, and the logic that selects the file description that seems to
> expect a call with a file extension (i.e. mkrc.pl libcrypto.dll, mkrc.pl
> openssl.exe, ...), but the build.info file is not specifying any file
> extension to these calls.
> 
> Also, why the openssl.exe doesn't include version information?
> 

Please could you raise this as an issue on github so that it gets
properly tracked?

https://github.com/openssl/openssl/issues

Thanks

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

Re: [openssl-users] Windows shared libraries version information needs some fixes

[Salz, Rich via openssl-users]

Please look at https://github.com/openssl/openssl/pull/5704 and see if it fixes 
the issues.

On 3/20/18, 8:52 PM, "RTT"  wrote:

Hello,

Building the shared libraries (version 1.1.1 pre 3) for Windows with 
Visual Studio, targets VC-WIN32 or VC-WIN64A, result in DLLs with 
version information with outdated copyright date, i.e. "Copyright 
1998-2016 The OpenSSL Authors. All rights reserved", and the file 
description as "OpenSSL application" instead of "OpenSSL shared library".

The version information resource file seems to be generated by the 
script "util\mkrc.pl", that indeed has this old copyright date 
hardcoded, and the logic that selects the file description that seems to 
expect a call with a file extension (i.e. mkrc.pl libcrypto.dll, mkrc.pl 
openssl.exe, ...), but the build.info file is not specifying any file 
extension to these calls.

Also, why the openssl.exe doesn't include version information?

-- 
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

Re: [openssl-users] Windows 1.1.1 binaries and web server

[Angus Robertson - Magenta Systems Ltd]

> This is very useful!  Can you post an udate to the wiki?  
> https://wiki.openssl.org/index.php/Binaries

Wiki has been updated with details of the binaries and download
locations. 

Angus

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

Re: [openssl-users] Windows 1.1.1 binaries and web server

[Salz, Rich via openssl-users]

This is very useful!  Can you post an udate to the wiki?  
https://wiki.openssl.org/index.php/Binaries


On 2/21/18, 8:57 AM, "Angus Robertson - Magenta Systems Ltd" 
 wrote:

Windows developers may be interested in our Win32 build of OpenSSL
1.1.1-pre1 (alpha), the binaries are digitally code signed 'Open Source
Developer, François PIETTE', the lead developer for the Delphi Internet
Component Suite project.  About half way down the page at:

http://wiki.overbyte.eu/wiki/index.php/ICS_Download

The latest 1.0.2 and 1.1.0 are also available, digitally code signed. 

I have also built my Windows ICS web application server to use
1.1.1-pre1 (alpha) so it can be used for testing TLSv1.3, the
information page shows the protocol you connect with, the ciphers
available and the OpenSSL and draft version being used. 

Currently most browsers still connect with TLSv1.2.  

https://www2.telecom-tariffs.co.uk/serverinfo.htm

Angus

-- 
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

Re: [openssl-users] Windows Compile Fails

[Michael Wojcik]

 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
 Of Jay Foster
 Sent: Friday, June 19, 2015 15:51
 
 I got my application to compile and link.  It seemed to run OK, but when
 I tried to run it on a different Windows machine, it failed with a pop
 up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I was
 statically linking this library, but apparently not.  I have no idea how
 it worked on the one machine.  What is the magic incantation to get
 Visual Studio to statically link the OpenSSL libraries?

The OpenSSL libraries have to be built as static libraries.

If you configure the OpenSSL build for static libraries, that's what you'll get.

If you configure it for dynamic libraries, you'll get libeay32.dll and 
ssleay32.dll, and a pair of import libraries named libeay32.lib and 
ssleay32.lib. You won't get static libraries at all. Note the static libraries 
and the import libraries have the same name.

When you link a library to a Windows executable, you provide either a static 
library or an import library. In the latter case, the executable will do an 
implicit load of the corresponding DLL at startup.

So if you want to statically link with OpenSSL, you have to configure it for 
static linkage and build it that way. Then the libeay32.lib and ssleay32.lib 
you get should be true static libraries and not import libraries.

I think no-shared is the Configure option you need. We actually have a script 
that changes some of the OpenSSL makefiles after configuring, so our process is 
a bit different from yours.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


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

Re: [openssl-users] Windows Compile Fails

[Sergio NNX]

 I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
 1.0.2c for Windows, but get a linking error

 My goal is to obtain a static library(ies) and associated header files
 that I can use to compile my application that uses OpenSSL on Windows.
 Where can I obtain these pre-built binaries?

 What is the magic incantation to get Visual Studio to statically link the 
 OpenSSL libraries?
 The OpenSSL libraries have to be built as static libraries.

Dear Jay,

We have been building OpenSSL on Windows, both statically and dynamically, for 
some time now without issues. We don't use Visual Studio though. The question 
is: does OpenSSL have to be built using Visual Studio only? If the answer is 
'no', we could render some assistance. Just let us know.

Cheers.

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

Re: [openssl-users] Windows Compile Fails

[Michael Wojcik]

 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
 Of Jay Foster
 Sent: Friday, June 19, 2015 17:09
 
  I think no-shared is the Configure option you need. We actually have a
  script that changes some of the OpenSSL makefiles after configuring, so our
  process is a bit different from yours.
 
 That sounds like what I'm running into.  I rebuilt the OpenSSL libraries
 with the no-shared option, but this made no difference. Does that work
 for Windows?

Hmm. I thought it did, but as I said we're using a customized process. We run 
Configure but then make some changes.

You can check to see whether a LIB file is an import or static library using 
the lib tool that's included with Visual Studio. lib /list libeay32.lib 
will show a bunch of object file names if it's a static library; if it's an 
import library, it will just print libeay32.dll a bunch of times.

The static library will also be a lot bigger. My libeay32.lib is around 14 MB. 
I don't have an import one here, but it should be much smaller, since it's 
basically just a list of function signatures.

Is it possible your build created both static and dynamic versions? Do you have 
two different versions of libeay32.lib in the build directory?

What version of OpenSSL are you building?

-- 
Michael Wojcik
Technology Specialist, Micro Focus


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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 1:11 PM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 15:51
I got my application to compile and link.  It seemed to run OK, but when
I tried to run it on a different Windows machine, it failed with a pop
up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I was
statically linking this library, but apparently not.  I have no idea how
it worked on the one machine.  What is the magic incantation to get
Visual Studio to statically link the OpenSSL libraries?

The OpenSSL libraries have to be built as static libraries.

If you configure the OpenSSL build for static libraries, that's what you'll get.

If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and 
a pair of import libraries named libeay32.lib and ssleay32.lib. You won't get 
static libraries at all. Note the static libraries and the import libraries have the same 
name.

When you link a library to a Windows executable, you provide either a static 
library or an import library. In the latter case, the executable will do an 
implicit load of the corresponding DLL at startup.

So if you want to statically link with OpenSSL, you have to configure it for 
static linkage and build it that way. Then the libeay32.lib and ssleay32.lib 
you get should be true static libraries and not import libraries.

I think no-shared is the Configure option you need. We actually have a script 
that changes some of the OpenSSL makefiles after configuring, so our process is a bit 
different from yours.

That sounds like what I'm running into.  I rebuilt the OpenSSL libraries 
with the no-shared option, but this made no difference. Does that work 
for Windows?

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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 2:09 PM, Jay Foster wrote:

On 6/19/2015 1:11 PM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
Behalf

Of Jay Foster
Sent: Friday, June 19, 2015 15:51
I got my application to compile and link.  It seemed to run OK, but 
when

I tried to run it on a different Windows machine, it failed with a pop
up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I 
was
statically linking this library, but apparently not.  I have no idea 
how

it worked on the one machine.  What is the magic incantation to get
Visual Studio to statically link the OpenSSL libraries?

The OpenSSL libraries have to be built as static libraries.

If you configure the OpenSSL build for static libraries, that's what 
you'll get.


If you configure it for dynamic libraries, you'll get libeay32.dll 
and ssleay32.dll, and a pair of import libraries named libeay32.lib 
and ssleay32.lib. You won't get static libraries at all. Note the 
static libraries and the import libraries have the same name.


When you link a library to a Windows executable, you provide either a 
static library or an import library. In the latter case, the 
executable will do an implicit load of the corresponding DLL at startup.


So if you want to statically link with OpenSSL, you have to configure 
it for static linkage and build it that way. Then the libeay32.lib 
and ssleay32.lib you get should be true static libraries and not 
import libraries.


I think no-shared is the Configure option you need. We actually 
have a script that changes some of the OpenSSL makefiles after 
configuring, so our process is a bit different from yours.


That sounds like what I'm running into.  I rebuilt the OpenSSL 
libraries with the no-shared option, but this made no difference. 
Does that work for Windows?

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


I see OpenSSL build output that looks like this:

cl /Fotmp32dll\a_sign.obj  -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 
-DOPENSSL
_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 
-DWIN32_L
EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK 
-I. -DO
PENSSL_NO_IDEA -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 
-DOPENSSL_NO_S
SL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE 
-DOPENSSL_NO_STATIC_E
NGINE /Zi /Fdtmp32dll/lib -D_WINDLL  -DOPENSSL_BUILD_SHLIBCRYPTO -c 
.\crypto\asn

1\a_sign.c
a_sign.c

Should the /MD be /MT?
Is -DOPENSSL_BUILD_SHLIBCRYPTO right?
is -D_WINDLL right?

Do I need to specify enable-static-engine or no-dso?
Jay
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Windows Compile Fails

[Michael Wojcik]

 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
 Of Jay Foster
 Sent: Friday, June 19, 2015 17:31
 
 I see OpenSSL build output that looks like this:
 
  cl /Fotmp32dll\a_sign.obj  -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2
 -DOPENSSL
 _THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -
 DOPENSSL_SYSNAME_WIN32
 -DWIN32_L
 EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -
 DOPENSSL_USE_APPLINK
 -I. -DO
 PENSSL_NO_IDEA -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 -
 DOPENSSL_NO_MD2
 -DOPENSSL_NO_S
 SL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE
 -DOPENSSL_NO_STATIC_E
 NGINE /Zi /Fdtmp32dll/lib -D_WINDLL  -DOPENSSL_BUILD_SHLIBCRYPTO -c
 .\crypto\asn
 1\a_sign.c
 a_sign.c
 
 Should the /MD be /MT?

Probably not. This depends on other considerations that are outside the scope 
of statically or dynamically linking OpenSSL itself. /MD tells VC to put a 
reference to the DLL version of the Microsoft C Runtime (CRT) into the object 
file; /MT tells VC to put a reference to the static version of the CRT in. 
Usually even static libraries should be linked with the DLL version of the CRT, 
unless you know the final executable will always be linked with the static CRT.

 Is -DOPENSSL_BUILD_SHLIBCRYPTO right?

Not sure.

 is -D_WINDLL right?

Probably. Again, even with OpenSSL built for static linking, it's usually best 
to tell VC that you're building for eventual dynamic linking, if the final 
executable will have a mix of static and dynamic objects.

 Do I need to specify enable-static-engine

No, unless you know you're using one or more engines, and you know you need 
them linked statically rather than loaded dynamically. Start by assuming no.

The engine feature supports external cryptographic providers. Those can be 
software systems like Microsoft's Crypto API, or hardware systems like card 
readers that use the PKCS#11 API. Modern versions of OpenSSL load engines 
dynamically, on request; enable-static-engine links them in statically instead.

 or no-dso?

I don't know what that option does, off the top of my head. Doesn't look like 
our build uses it.


-- 
Michael Wojcik
Technology Specialist, Micro Focus


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

Re: [openssl-users] Windows Compile Fails

[Thomas J. Hruska]

On 6/19/2015 12:51 PM, Jay Foster wrote:

On 6/19/2015 10:52 AM, Jay Foster wrote:

On 6/19/2015 8:55 AM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 11:49
I started over from a clean directory and the build completed.  On
linux, I would end up with two libraries (libssl, libcrypto). I don't
see these on Windows in the out32dll directory.  Does Windows create
different library names?  I'm looking for the equivalent static
libraries for libssl and libcrypto to link with my application.

The Windows static libraries are named libeay32.lib and ssleay32.lib,
for historical reasons. At any rate, that's what I have in my Windows
build directory; I believe those are the standard names.


Thanks, I see those.

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


I got my application to compile and link.  It seemed to run OK, but when
I tried to run it on a different Windows machine, it failed with a pop
up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I was
statically linking this library, but apparently not.  I have no idea how
it worked on the one machine.  What is the magic incantation to get
Visual Studio to statically link the OpenSSL libraries?

Jay


Use nt.mak, not ntdll.mak.

You can search the Internets for Windows binaries.

Also, Dependency Walker is very useful for identifying what DLLs a DLL 
or EXE depends on.


In my opinion, you shouldn't really link against static versions if you 
can avoid it.  Static linking makes it harder for end-users to stay up 
to date.


--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Windows Compile Fails

[Jeremy Farrell]

From: Jay Foster Sent: Friday, June 19, 2015 15:51

I got my application to compile  and link.  It seemed to run OK, but

 when I tried to run it on a different Windows machine, it failed
 with a pop up dialog complaining it could not find LIBEAY32.dll.  I
 'thought' I was statically linking this library, but apparently not.
  I have no idea how it worked on the one machine.  What is the magic
 incantation to get Visual Studio to statically link the OpenSSL
 libraries?

You'd save us a lot of guesswork, and probably get where you want to be 
more quickly, if you would

1) tell us what version of OpenSSL you're trying to build
2) tell us what build environment you're using (presumably some command 
prompt started from VS)
3) tell us the exact sequence of commands you're executing to build it, 
starting from the tarball


Have you read INSTALL.W32? It's probably well out of date in detail, but 
still valuable to point you in the right direction. As long as you're 
using the nt.mak makefile, you should get static libraries.


Regards,
jjf

--
J. J. Farrell

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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/18/2015 7:55 PM, Thomas J. Hruska wrote:

On 6/18/2015 4:46 PM, Jay Foster wrote:

I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error

tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target machine type 'x64'

I googled for this error, but the solutions mention changing parameters
in the VC Studio project, but I'm building from the command line with
nmake.

I'm configuring for 32-bit (perl Configure VC-WIN32 ...).  I think the
Windows system I'm compiling on is a 64-bit OS.  I know I have built
32-bit applications on it in the past from VC Studio.  Is there some
obvious fix?

Jay


What Command Prompt are you running?  You have to use the correct 
Native Tools for the target hardware type.  If you are building 
VC-WIN32, then you are targeting 32-bit hardware and need to run the 
x86 Native Tools Command Prompt (not the x64 version).  You can't mix 
and match targets.


If you don't want to build it yourself, there are also prebuilt 
binaries and libraries.


I tried again, but it then failed trying to compile an assembly file 
(i586 something).  It complained about an unknown operand.


I tried again adding no-asm to my configuration.  It seemed to compile 
fine, but again failed at the link with several undefined symbols:
_OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, 
_sha1_block_data_order, _sha256_block_data_order, and 
_sha512_block_data_order.


My goal is to obtain a static library(ies) and associated header files 
that I can use to compile my application that uses OpenSSL on Windows.  
Where can I obtain these pre-built binaries?


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

Re: [openssl-users] Windows Compile Fails

[Michael Wojcik]

 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
 Of Thomas J. Hruska
 Sent: Thursday, June 18, 2015 22:56
 
 On 6/18/2015 4:46 PM, Jay Foster wrote:
  I'm new to building OpenSSL with Windows.  I'm trying to build OpenSSL
  1.0.2c for Windows, but get a linking error
 
 What Command Prompt are you running?  You have to use the correct
 Native Tools for the target hardware type.  If you are building
 VC-WIN32, then you are targeting 32-bit hardware and need to run the x86
 Native Tools Command Prompt (not the x64 version).  You can't mix and
 match targets.

More generally, the compiler bitness has to match the bitness you configure the 
OpenSSL build for. The Visual Studio command prompt shortcuts set up the 
appropriate environment, but you can also do it using the various batch files 
supplied with VS (vcvars32.bat, etc), or by setting the appropriate paths and 
other environment variables manually. (I build OpenSSL for Windows from a 
Cygwin bash shell, using Visual Studio, and I have bash functions that set up 
the appropriate build environments.)

The bitness of the OS doesn't matter. You can cross-compile x64 binaries on 
32-bit Windows and vice versa. When we build OpenSSL for Windows as part of our 
integration / automated build process, we have our own wrapper scripts that 
build both bitnesses in separate build directories, using the same build 
machine.

A quick check is to run cl with no parameters from the command line you're 
using for OpenSSL. It will say something like Microsoft (R) C/C++ Optimizing 
Compiler Version 17.00.61030 for x86 or ... for x64.

-- 
Michael Wojcik
Technology Specialist, Micro Focus

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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 8:30 AM, Jay Foster wrote:

On 6/18/2015 7:55 PM, Thomas J. Hruska wrote:

On 6/18/2015 4:46 PM, Jay Foster wrote:

I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error

tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target machine type 'x64'

I googled for this error, but the solutions mention changing parameters
in the VC Studio project, but I'm building from the command line with
nmake.

I'm configuring for 32-bit (perl Configure VC-WIN32 ...).  I think the
Windows system I'm compiling on is a 64-bit OS.  I know I have built
32-bit applications on it in the past from VC Studio.  Is there some
obvious fix?

Jay


What Command Prompt are you running?  You have to use the correct 
Native Tools for the target hardware type.  If you are building 
VC-WIN32, then you are targeting 32-bit hardware and need to run the 
x86 Native Tools Command Prompt (not the x64 version).  You can't mix 
and match targets.


If you don't want to build it yourself, there are also prebuilt 
binaries and libraries.


I tried again, but it then failed trying to compile an assembly file 
(i586 something).  It complained about an unknown operand.


I tried again adding no-asm to my configuration.  It seemed to 
compile fine, but again failed at the link with several undefined 
symbols:
_OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, 
_sha1_block_data_order, _sha256_block_data_order, and 
_sha512_block_data_order.


My goal is to obtain a static library(ies) and associated header files 
that I can use to compile my application that uses OpenSSL on 
Windows.  Where can I obtain these pre-built binaries?


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

I started over from a clean directory and the build completed.  On 
linux, I would end up with two libraries (libssl, libcrypto).  I don't 
see these on Windows in the out32dll directory.  Does Windows create 
different library names?  I'm looking for the equivalent static 
libraries for libssl and libcrypto to link with my application.


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

Re: [openssl-users] Windows Compile Fails

[Michael Wojcik]

 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
 Of Jay Foster
 Sent: Friday, June 19, 2015 11:49
 
 I started over from a clean directory and the build completed.  On
 linux, I would end up with two libraries (libssl, libcrypto).  I don't
 see these on Windows in the out32dll directory.  Does Windows create
 different library names?  I'm looking for the equivalent static
 libraries for libssl and libcrypto to link with my application.

The Windows static libraries are named libeay32.lib and ssleay32.lib, for 
historical reasons. At any rate, that's what I have in my Windows build 
directory; I believe those are the standard names.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 8:55 AM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 11:49
I started over from a clean directory and the build completed.  On
linux, I would end up with two libraries (libssl, libcrypto).  I don't
see these on Windows in the out32dll directory.  Does Windows create
different library names?  I'm looking for the equivalent static
libraries for libssl and libcrypto to link with my application.

The Windows static libraries are named libeay32.lib and ssleay32.lib, for 
historical reasons. At any rate, that's what I have in my Windows build 
directory; I believe those are the standard names.


Thanks, I see those.

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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 10:52 AM, Jay Foster wrote:

On 6/19/2015 8:55 AM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
Behalf

Of Jay Foster
Sent: Friday, June 19, 2015 11:49
I started over from a clean directory and the build completed.  On
linux, I would end up with two libraries (libssl, libcrypto). I don't
see these on Windows in the out32dll directory.  Does Windows create
different library names?  I'm looking for the equivalent static
libraries for libssl and libcrypto to link with my application.
The Windows static libraries are named libeay32.lib and ssleay32.lib, 
for historical reasons. At any rate, that's what I have in my Windows 
build directory; I believe those are the standard names.



Thanks, I see those.

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

I got my application to compile and link.  It seemed to run OK, but when 
I tried to run it on a different Windows machine, it failed with a pop 
up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I was 
statically linking this library, but apparently not.  I have no idea how 
it worked on the one machine.  What is the magic incantation to get 
Visual Studio to statically link the OpenSSL libraries?


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

Re: [openssl-users] Windows Compile Fails

[Thomas J. Hruska]

On 6/18/2015 4:46 PM, Jay Foster wrote:

I'm new to building OpenSSL with Windows.  I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error

tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target machine type 'x64'

I googled for this error, but the solutions mention changing parameters
in the VC Studio project, but I'm building from the command line with
nmake.

I'm configuring for 32-bit (perl Configure VC-WIN32 ...).  I think the
Windows system I'm compiling on is a 64-bit OS.  I know I have built
32-bit applications on it in the past from VC Studio.  Is there some
obvious fix?

Jay


What Command Prompt are you running?  You have to use the correct 
Native Tools for the target hardware type.  If you are building 
VC-WIN32, then you are targeting 32-bit hardware and need to run the x86 
Native Tools Command Prompt (not the x64 version).  You can't mix and 
match targets.


If you don't want to build it yourself, there are also prebuilt binaries 
and libraries.


--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: OpenSSL For Windows CE

[Panthers Rock]

I have never compiled OpenSSL for Windows CE.  However, it seems that you
need to change compiler and linker options to say it is for an ARM
processor.   Look for CFLAGS and LFLAGS and make appropriate changes.


On Mon, Jul 21, 2008 at 10:28 AM, Amir [EMAIL PROTECTED] wrote:

 Hi,

 I saw your message in the openssl-dev mailing list about building openSSL
 for windows CE and i'm trying to do the same thing.

 I want to buil the openSSL libraries for Windows CE following those steps :

 Building
 

 Setup the eMbedded Visual C++ environment.  There are batch files for doing
 this installed with eVC++.  For an ARM processor, for example, execute:

  C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN\WCEARM.BAT

 Next indicate where wcecompat is located:

  set WCECOMPAT=C:\wcecompat

 Next you should run Configure:

  perl Configure VC-CE

 Next you need to build the Makefiles:

  ms\do_ms

 If you get errors about things not having numbers assigned then check the
 troubleshooting section in INSTALL.W32: you probably won't be able to
 compile
 it as it stands.

 Then from the VC++ environment at a prompt do:

 - to build static libraries:

  nmake -f ms\ce.mak

 When i try to excute the last step : nmake -f ms\ce.mak, i got the
 following problem :

 tmp32_\md2test.obj: fatal error LINK1112: module machine type 'X86'
 conflicts with target machine type 'ARM'.

 Please, did you have any idea about solving this problem?

 or did you know where can i get the openSSL library already builded for
 Windows CE?

 Thanks,
 Amir,

RE: Openssl and Windows Timezones

[David Schwartz]

 Hi Everyone,

 My problem is with Windows 200x generated certificates.  The Windows
 servers are set to local time, but when I import or use these
 certificates within OpenSSL they appear to be set to GMT time.  The
 certificate's validity is not valid between the offset of GMT to the
 localtime of the Linux machine.

 Does OpenSSL know how to use the localtime to verify certificates, or
 does it always use GMT?

Certificates *always* use GMT. If certificates contained local time, you'd
have to know what time zone they were created in to know when they were
valid, which would create all kinds of ugliness.

If your certificate contain in them the local time they are valid, they are
erroneous. Make sure the error is in the certificate and not in the viewing
tool (that may convert them to local time for display convenience or think
they are in local time).

Windows servers should be set to local time, but they should also know their
correct timezone so that they can generate GMT for those things that require
them.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: OpenSSL with Windows subordinates

[Aaron Barnes]

Wonderful!
I redid the root CA setup using ca.pl, modified the openssl.cnf file to
CA:TRUE in the v3_ca section, and signed the subordinate request using
the previous command:
(ca -config /path/openssl.cnf -out thecertificate.pem -in
requestfile.req -extensions v3_ca).  I imported the the pem file for the
subordinate, and also the root cert, and the Windows services started up
just fine.  
I was also able to verify its functionality by requesting some user
certs from it.

Is there much difference between signing with the openssl command above
and the ca.pl perl script?  It seems to me it is mainly helpful for
automating the process.

One last question if you don't mind.  I noticed the keysize for my
subordinate is 1024 bits.  Where can I indicate the keysize when signing
the request?  In the openssl.cnf file I used, I have 4096 listed in the
req section, but does this need to be placed elsewhere?  It didn't work
when I placed it in the v3_ca section.

Thanks,
Aaron
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson
Sent: Thursday, December 28, 2006 15:47
To: openssl-users@openssl.org
Subject: Re: OpenSSL with Windows subordinates



Yes the root CA has basicConstraints CA:FALSE on it which is causing the
error.

I'd suggest you redo the root CA and the subordinate using CA.pl: CA.sh
is an older script that isn't maintained any more.

The command CA.pl -signCA automatically signs a request as a CA instead
of an end entity cert.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with Windows subordinates

[Dr. Stephen Henson]

On Fri, Dec 29, 2006, Aaron Barnes wrote:

 Wonderful!
 I redid the root CA setup using ca.pl, modified the openssl.cnf file to
 CA:TRUE in the v3_ca section, and signed the subordinate request using
 the previous command:
 (ca -config /path/openssl.cnf -out thecertificate.pem -in
 requestfile.req -extensions v3_ca).  I imported the the pem file for the
 subordinate, and also the root cert, and the Windows services started up
 just fine.  
 I was also able to verify its functionality by requesting some user
 certs from it.
 
 Is there much difference between signing with the openssl command above
 and the ca.pl perl script?  It seems to me it is mainly helpful for
 automating the process.
 

Yes that's its main point: to make it easier to setup the appropriate file
structure and perform some common operations without having to delve into
the complexities of some of the commands.

 One last question if you don't mind.  I noticed the keysize for my
 subordinate is 1024 bits.  Where can I indicate the keysize when signing
 the request?  In the openssl.cnf file I used, I have 4096 listed in the
 req section, but does this need to be placed elsewhere?  It didn't work
 when I placed it in the v3_ca section.
 

The key is contained in the request so when it is signed it uses whatever key
is present. So if you want a larger key size you'll need to redo the request.

If the root CA also has a key size of 1024 bits you should increase that too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: OpenSSL with Windows subordinates

[Aaron Barnes]

I think we're making some progress with resolving this problem.   I
signed a new request with the switch you mentioned and loaded it onto
the subordinate.  I don't receive the old ASN1 error, which is good, but
now I've received one I've never seen before, A certificate's basic
constraint extension has not been observed.  Does this mean I may have
something configured incorrectly in the openssl.cnf file?  

One bit of good news though is that I no longer have to export the
certificate into .der format;  the .pem file worked just fine.

Aaron




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson
Sent: Wednesday, December 27, 2006 15:04
To: openssl-users@openssl.org
Subject: Re: OpenSSL with Windows subordinates

 

Yes the signing command is incorrect. By default the certificate is an
end entity certificate for OpenSSL not a CA certificate.

Try the command line switch: -extensions v3_ca 

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with Windows subordinates

[Dr. Stephen Henson]

On Thu, Dec 28, 2006, Aaron Barnes wrote:

 I think we're making some progress with resolving this problem.   I
 signed a new request with the switch you mentioned and loaded it onto
 the subordinate.  I don't receive the old ASN1 error, which is good, but
 now I've received one I've never seen before, A certificate's basic
 constraint extension has not been observed.  Does this mean I may have
 something configured incorrectly in the openssl.cnf file?  
 

Did you install a root CA onto that system too? If so that might be a problem
depending on how you created it.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: OpenSSL with Windows subordinates

[Aaron Barnes]

Yes I did.  I had to install that yesterday also in order for the
subordinate to trust the root.

I was reading on the web site (specifically on this web page:
http://www.openssl.org/docs/apps/x509v3_config.html# )  It would seem to
indicate one should modify the basicConstraints lines in the openssl.cnf
file, but again I am not terribly familiar with this option.  The only
things I have modified in my openssl.cnf file so far are the lines to
include email address, location, directory structure , changed policy
fields to optional, and the key size.  

If I am understanding this correctly, the OpenSSL root issued the
certificate as a simple 'machine' cert, not as a subordinate CA.  Am I
on the right track?  

Aaron

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson
Sent: Thursday, December 28, 2006 11:55
To: openssl-users@openssl.org
Subject: Re: OpenSSL with Windows subordinates

On Thu, Dec 28, 2006, Aaron Barnes wrote:

 I think we're making some progress with resolving this problem.   I
 signed a new request with the switch you mentioned and loaded it onto 
 the subordinate.  I don't receive the old ASN1 error, which is good, 
 but now I've received one I've never seen before, A certificate's 
 basic constraint extension has not been observed.  Does this mean I 
 may have something configured incorrectly in the openssl.cnf file?
 

Did you install a root CA onto that system too? If so that might be a
problem depending on how you created it.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with Windows subordinates

[Dr. Stephen Henson]

On Thu, Dec 28, 2006, Aaron Barnes wrote:

 Yes I did.  I had to install that yesterday also in order for the
 subordinate to trust the root.
 
 I was reading on the web site (specifically on this web page:
 http://www.openssl.org/docs/apps/x509v3_config.html# )  It would seem to
 indicate one should modify the basicConstraints lines in the openssl.cnf
 file, but again I am not terribly familiar with this option.  The only
 things I have modified in my openssl.cnf file so far are the lines to
 include email address, location, directory structure , changed policy
 fields to optional, and the key size.  
 
 If I am understanding this correctly, the OpenSSL root issued the
 certificate as a simple 'machine' cert, not as a subordinate CA.  Am I
 on the right track?  
 

If you used the CA.pl script to generate the certificates it should just do
the right thing. The standard openssl.cnf has some sensible defaults which
should suit most purposes.

That includes using basicConstraints for a CA certificate.

If you've used other commands (all manner of weird stuff is recommended by
some cookbooks) then the certificates may not suit your purpose.

If you do:

openssl x509 -in cert.pem -text -noout

you should see the basicConstraints extension. It must have CA:TRUE for both
the root CA and the subordinate. If that doesn't help just post (or mail me
privately) with the two certificates you have created.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: OpenSSL with Windows subordinates

[Aaron Barnes]

I think I see what you're getting at now.  I reviewed the text of the
root and the subordinate certs;  the root does NOT have the CA:TRUE
(false obviously), the subordinate does have CA:TRUE.   So I guess this
tells me I must have installed the root CA incorrectly.

I didn't use CA.pl, but rather CA.sh.  I'll list each step I did to set
up OpenSSL and the root.

1. ./config
2. make
3. make test
4. make install
5.  ./CA.sh -newca
6.  ./CA.sh -sign

It sounds like I'll probably need to redo the root setup, but let me
know if there is an adjustment I need to make based on how many tiers I
want to set up in the overall PKI.
I'll also email you copies of the certificates separately.
Aaron


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson
Sent: Thursday, December 28, 2006 12:34
To: openssl-users@openssl.org
Subject: Re: OpenSSL with Windows subordinates


If you used the CA.pl script to generate the certificates it should just
do the right thing. The standard openssl.cnf has some sensible
defaults which should suit most purposes.

That includes using basicConstraints for a CA certificate.

If you've used other commands (all manner of weird stuff is recommended
by some cookbooks) then the certificates may not suit your purpose.

If you do:

openssl x509 -in cert.pem -text -noout

you should see the basicConstraints extension. It must have CA:TRUE for
both the root CA and the subordinate. If that doesn't help just post (or
mail me
privately) with the two certificates you have created.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with Windows subordinates

[Dr. Stephen Henson]

On Thu, Dec 28, 2006, Aaron Barnes wrote:

 I think I see what you're getting at now.  I reviewed the text of the
 root and the subordinate certs;  the root does NOT have the CA:TRUE
 (false obviously), the subordinate does have CA:TRUE.   So I guess this
 tells me I must have installed the root CA incorrectly.
 
 I didn't use CA.pl, but rather CA.sh.  I'll list each step I did to set
 up OpenSSL and the root.
 
 1. ./config
 2. make
 3. make test
 4. make install
 5.  ./CA.sh -newca
 6.  ./CA.sh -sign
 
 It sounds like I'll probably need to redo the root setup, but let me
 know if there is an adjustment I need to make based on how many tiers I
 want to set up in the overall PKI.
 I'll also email you copies of the certificates separately.

Yes the root CA has basicConstraints CA:FALSE on it which is causing the
error.

I'd suggest you redo the root CA and the subordinate using CA.pl: CA.sh is an
older script that isn't maintained any more.

The command CA.pl -signCA automatically signs a request as a CA instead of an
end entity cert.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with Windows subordinates

[Kyle Hamilton]

Don't forget Path Length.

-Kyle H

On 12/28/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote:

On Thu, Dec 28, 2006, Aaron Barnes wrote:

 Yes I did.  I had to install that yesterday also in order for the
 subordinate to trust the root.

 I was reading on the web site (specifically on this web page:
 http://www.openssl.org/docs/apps/x509v3_config.html# )  It would seem to
 indicate one should modify the basicConstraints lines in the openssl.cnf
 file, but again I am not terribly familiar with this option.  The only
 things I have modified in my openssl.cnf file so far are the lines to
 include email address, location, directory structure , changed policy
 fields to optional, and the key size.

 If I am understanding this correctly, the OpenSSL root issued the
 certificate as a simple 'machine' cert, not as a subordinate CA.  Am I
 on the right track?


If you used the CA.pl script to generate the certificates it should just do
the right thing. The standard openssl.cnf has some sensible defaults which
should suit most purposes.

That includes using basicConstraints for a CA certificate.

If you've used other commands (all manner of weird stuff is recommended by
some cookbooks) then the certificates may not suit your purpose.

If you do:

openssl x509 -in cert.pem -text -noout

you should see the basicConstraints extension. It must have CA:TRUE for both
the root CA and the subordinate. If that doesn't help just post (or mail me
privately) with the two certificates you have created.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]




--

-Kyle H
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with Windows subordinates

[Dr. Stephen Henson]

On Wed, Dec 27, 2006, Aaron Barnes wrote:

 I have an OpenSSL CA running on a BSD 6.1 machine as the root, and am 
 trying to have that act as the parent to subordinate Windows online 
 enterprise CAs. 
 
 
 The installation went fine. I signed the Windows subordinate CA cert 
 request with SSL, then converted it to pkcs12 to be installed. That's 
 where I get the problem. When I try to installed the pkcs12 cert on the 
 Windows machine, it doesn't like it, giving me an ASN1 unexpected end 
 of data. 
 
 
 I suspect that possibly it is because it isn't seeing the private key 
 when OpenSSL converts to pkcs12. I was actually only able to get the 
 .pem - .p12 conversion to work by using the -nokeys option. 
 
 
 So let me walk you through each step. 
 
 
 1. Received Windows CA generated request file (.der). 
 2. Signed it using ca -config blahblah/openssl.cnf -in 
 windowsreqfile.der -out newcert.pem 
 3. Converted it using pkcs12 -export -in newcert.pem -out 
 newercert.p12 -nokeys 
 
 
 So as I said I could only get the conversion command to work using the 
 nokeys option. If I didn't, it would error out on me saying unable to 
 load private key. This tells me I may have missed a step in the 
 signing process, but I'm unsure what exactly. Do I need to execute 
 another command after step 2 to output a separate private key file? 
 Shouldn't the private key be included in the .pem file in step 2? 

The private key resides on the Windows machine and doesn't leave it which is
as it should be. A PKCS#12 file is only really used when the private key and
matching certificate are present.

You really need to just install the certificate and have Windows associate the
key with it.

How you do that depends on exactly what you did in Step #1. You may be able to
just install the newcert.pem file or you can convert it to DER using:

openssl x509 -in newcert.pem -outform DER -out newcert.der

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: OpenSSL with Windows subordinates

[Aaron Barnes]

With Windows certificate services, upon installation it will ask you to
select the type of CA the server is to become from 4 different options.
I've chosen an enterprise online CA, however its parent is offline, so
of course I cannot make an online certificate request.  I saved the
actual certificate request as a .der file (Windows defaults to .req I
believe) and copied to the OpenSSL parent box.

Perhaps my signing command was in error.  I used ca -config
/pathtoconfigfile/openssl.cnf -out thecertificate.pem -in
windowsrequestfile.der.

When installing the subordinate's certificate, it does not like .pem
files...which doesn't really surprise me.  The available options are
.cer, .crt, .p12, .pfx and .p7b.  I was using pkcs12 as it indicated
there was an available export option for that command.  When I tried to
use the .pem file it would give me the error The certificate is not a
CA certificate.  

I also executed the command you suggested and tried installing the .der
file; it gives the same error.

Regards,
Aaron
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson
Sent: Wednesday, December 27, 2006 11:24
To: openssl-users@openssl.org
Subject: Re: OpenSSL with Windows subordinates


The private key resides on the Windows machine and doesn't leave it
which is as it should be. A PKCS#12 file is only really used when the
private key and matching certificate are present.

You really need to just install the certificate and have Windows
associate the key with it.

How you do that depends on exactly what you did in Step #1. You may be
able to just install the newcert.pem file or you can convert it to DER
using:

openssl x509 -in newcert.pem -outform DER -out newcert.der

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with Windows subordinates

[Dr. Stephen Henson]

On Wed, Dec 27, 2006, Aaron Barnes wrote:

 With Windows certificate services, upon installation it will ask you to
 select the type of CA the server is to become from 4 different options.
 I've chosen an enterprise online CA, however its parent is offline, so
 of course I cannot make an online certificate request.  I saved the
 actual certificate request as a .der file (Windows defaults to .req I
 believe) and copied to the OpenSSL parent box.
 
 Perhaps my signing command was in error.  I used ca -config
 /pathtoconfigfile/openssl.cnf -out thecertificate.pem -in
 windowsrequestfile.der.
 
 When installing the subordinate's certificate, it does not like .pem
 files...which doesn't really surprise me.  The available options are
 .cer, .crt, .p12, .pfx and .p7b.  I was using pkcs12 as it indicated
 there was an available export option for that command.  When I tried to
 use the .pem file it would give me the error The certificate is not a
 CA certificate.  
 
 I also executed the command you suggested and tried installing the .der
 file; it gives the same error.
 

Yes the signing command is incorrect. By default the certificate is an end
entity certificate for OpenSSL not a CA certificate.

Try the command line switch: -extensions v3_ca 

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: openssl for windows file separator

[Kyle Hamilton]

How do you mean?  Windows will support the forward slash convention,
as will openssl.  If you use backslashes, you may need to double them.
If you are using a space in any of the directory or filenames, the
full path must be surrounded by doublequotes or else OpenSSL will
interpret it as two different arguments.

I don't recall the specifics at this moment, unfortunately --
allergies plus chlortrimeton make for bad memory.  However, try the
suggestions that I mention above, and report back with your findings.
:)

-Kyle H

On 6/23/06, larry.dalton [EMAIL PROTECTED] wrote:



What arguments do you use when using openssl for windows to make full path
to the file in the openssl arguments work?

[EMAIL PROTECTED]



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: openssl for windows file separator

[larry.dalton]

Tried that, only with single quotes. Forward slashes, 
back, and double back. Doesn't seem anything works for the pc, at least what I 
use. UNIX works, PC only works if all files are in the same 
directory.

  - Original Message - 
  From: 
  Kyle Hamilton 
  
  To: openssl-users@openssl.org 
  Sent: Friday, June 23, 2006 10:04 
PM
  Subject: Re: openssl for windows file 
  separator
  How do you mean? Windows will support the forward slash 
  convention,as will openssl. If you use backslashes, you may need to 
  double them.If you are using a space in any of the directory or 
  filenames, thefull path must be surrounded by doublequotes or else OpenSSL 
  willinterpret it as two different arguments.I don't recall the 
  specifics at this moment, unfortunately --allergies plus chlortrimeton 
  make for bad memory. However, try thesuggestions that I mention 
  above, and report back with your findings.:)-Kyle HOn 
  6/23/06, larry.dalton [EMAIL PROTECTED] 
  wrote: What arguments do you use when using openssl 
  for windows to make full path to the file in the openssl arguments 
  work? [EMAIL PROTECTED]__OpenSSL 
  Project 
  http://www.openssl.orgUser Support 
  Mailing 
  List 
  openssl-users@openssl.orgAutomated 
  List 
  Manager 
  [EMAIL PROTECTED]-- 
  No virus found in this incoming message.Checked by AVG Free 
  Edition.Version: 7.1.394 / Virus Database: 268.9.3/374 - Release Date: 
  6/23/2006

Re: Openssl on windows MingW

[Thomas J. Hruska]

At 11:40 AM 6/6/2004 -0400, Jato writeth:
Have anyone ever tried to compile openssl-0.9.7d (or any other) with
MinGW? How to build a shared library with MingW?


http://www.slproweb.com/products/Win32OpenSSL.html

Contains default binaries of the latest OpenSSL builds that come with MinGW
libraries to link against.  The MinGW version uses DLLs built with MSVC++,
so you have to use BIOs for file I/O with certificates (not a big deal and
makes code more portable anyway).


Hope this helps!


  Thomas J. Hruska -- [EMAIL PROTECTED]
Shining Light Productions -- Meeting the needs of fellow programmers
 http://www.slproweb.com/

`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~
  Why spend more for the same functionality that is in ColdFusion?
  Try Nuclear Vision today!

  http://www.slproweb.com/products/nvml.html

  Announcing Nuclear Vision v2.0:
  Easy to learn, easy to use, and has unlimited precision math
  capabilities.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Openssl on windows vc++ project

[ahmad hassan]

Hello,
The links you sent were really helpful. Now i have a dsw but i would like to 
know that what these 2 lines are for.

perl Configure VC-WIN32
ms\do_ms
Couldn't i do without them i now know that the dsw has 50 projects but only 
useful to me or which i have to use are:
libeay32.dll and ssleay32.dll

if we are already building in vc++ environment after including then what's 
the use of perl build.

And if afterwards i take my project to some other machine and then build it 
then what do i have to do, install perl again.

What if i don't have perl installed. What does perl thing do.
I atleast know this that if you take the put those to dlls in the project 
debug folder and link with them openssl works if you go on other machine.

Thanks.
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Openssl on windows vc++ project

[Marcus Carey]

http://www.openssl.org/related/
http://www.iconsinc.com/~agray/ossldev/


- Original Message - 
From: ahmad hassan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 04, 2004 8:24 AM
Subject: Openssl on windows vc++ project


 Hello,
 I would like to know that is it possible to compile and build openssl
files
 on windows.
 I would like to be adding only the h and c files in the project. I have
come
 through research on internet that it is possible to use it under windows
 using vc++ by making dll files or lib file using perl but i don't want
that
 way. I want it in such a way that i have header and c files in my project
 and i do a compile on them and build them.

 Plz a detailed answer is needed.

 Waiting for an urgent reply.

 Thank You.

 _
 Tired of spam? Get advanced junk mail protection with MSN 8.
 http://join.msn.com/?page=features/junkmail

 __
 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: openssl and windows 2000 and visual basic and winsock

[Frédéric Giudicelli]

Under Windows and vb SSPI is your friend !

[EMAIL PROTECTED] wrote:

I wrote an vb script which GETs and POSTs to http urls using the winsock in visual basic..

is there anyway at all I can do the same thing for https urls ?

can openssl help ?

prem

please see below for the code that I'm using now

---

Function called for establishing the connection:

Private Sub cmdGet_Click()
Dim tmp_port As Integer
Dim chk As Integer
Dim tmp_str As String
Dim ret_chr As String
tmp_port = Val(Text2.Text)
Text4.Text = 
socket_hdl = modWinsock.socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
'MsgBox socket_hdl
'MsgBox socket_hdl
If Val(socket_hdl)  0 Then
MsgBox Socket problem
Else

connection_hdl = vbConnect(socket_hdl, Text1.Text, tmp_port)
'MsgBox connection_hdl

If (connection_hdl = 0) Then
MsgBox Successfull Connection
Else
MsgBox Connection Unsuccessfull
End If

ret_chr = vbCrLf

tmp_str = POST /first/wrt_file.php HTTP/1.0  vbCrLf _
 User-Agent: Mozilla/4.0  vbCrLf _
 Content-Type: application/x-www-form-urlencoded  vbCrLf _
 Content-Length: 12  vbCrLf  vbCrLf _
 name=kishore  vbCrLf

Text3.Text = tmp_str



   chk = modWinsock.vbSend(socket_hdl, Text3.Text)
'chk = modWinsock.vbSend(socket_hdl, tmp_str)
If (chk  -1) Then
MsgBox Message sent successfully. Number of bytes=  chk
Timer1.Enabled = True
Else
MsgBox Message not sent
End If
End If

End Sub



Timer Function to check the status of the socket for response:
==
Private Sub Timer1_Timer()
Dim udtRead_fds As fd_set
Dim udtWrite_fdsAs fd_set
Dim udtError_fdsAs fd_set
Dim lngRetValue As Long
Dim lngBytereceived As Long
Dim recv_str As String
udtRead_fds.fd_array(1) = socket_hdl
udtRead_fds.fd_count = 1
udtWrite_fds.fd_array(1) = socket_hdl
udtWrite_fds.fd_count = 1
udtError_fds.fd_array(1) = socket_hdl
udtError_fds.fd_count = 1
lngRetValue = vbselect(0, udtRead_fds, udtWrite_fds, udtError_fds, 0)

'MsgBox out

If lngRetValue = SOCKET_ERROR Then
'
'If the function returned value of SOCKET_ERROR
'just show a message box with error description
'
MsgBox (Err.LastDllError)
'
ElseIf lngRetValue  0 Then
'Check for readable sockets
'MsgBox here
If udtRead_fds.fd_count  0 Then
'
'Get the socket handle
lngSocket = udtRead_fds.fd_array(1)
'
'MsgBox Socket is ready to read
'
lngByterecived = vbRecv(lngSocket, recv_str)

If lngBytereceived = SOCKET_ERROR Then
MsgBox Err.LastDllError
Else
Text4.Text = Text4.Text  recv_str
Timer1.Enabled = False
End If

End If
End If

End Sub
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


--
Frédéric Giudicelli
http://www.newpki.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl and windows 2000 and visual basic and winsock

[Ng Pheng Siong]

On Fri, Feb 20, 2004 at 04:51:21AM -0400, [EMAIL PROTECTED] wrote:
 I wrote an vb script which GETs and POSTs to http urls using the winsock
 in visual basic..
 
 is there anyway at all I can do the same thing for https urls ?

2 possibilities:

Easier: Use the MSIE ActiveX already installed on your computer. 

More work: Interface libcurl from VB.

HTH.

-- 
Ng Pheng Siong [EMAIL PROTECTED] 

http://firewall.rulemaker.net -+- Firewall Change Management  Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto  SSL
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl and windows 2000 and visual basic and winsock

[M.E. Post]

- Original Message - 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, February 20, 2004 9:51 AM
Subject: openssl and windows 2000 and visual basic and winsock


 I wrote an vb script which GETs and POSTs to http urls using the winsock
in visual basic..

 is there anyway at all I can do the same thing for https urls ?

 can openssl help ?

 prem

Use the WinHTTP object, see http://p2p.wrox.com/topic.asp?TOPIC_ID=6193 for
an example and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winhttp/http/about_winhttp.asp
 for microsoft documentation.

cheers,

Meint

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL and Windows XP

[Dr. Stephen Henson]

On Thu, Nov 27, 2003, [EMAIL PROTECTED] wrote:

 I currently use OpenSSL from a C prompt under Windows NT4. Can Anyone
 confirm that it will runs under XP?
 

Yes.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL and Windows XP

[Thomas J. Hruska]

At 04:34 PM 11/27/2003 +, [EMAIL PROTECTED] writeth:
I currently use OpenSSL from a C prompt under Windows NT4. Can Anyone
confirm that it will runs under XP?

XP = NT 5.1

So, yes, it will work for you...and works for me.  I run XP (SP1) here and
OpenSSL works fine with ProtoNova.

Hope this helps!


  Thomas J. Hruska -- [EMAIL PROTECTED]
Shining Light Productions -- Meeting the needs of fellow programmers
  http://www.shininglightpro.com/

`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~.,_,.~-*'`'*-~
  Tired of expensive, buggy web servers that you have to constantly patch
  (e.g. Microsoft Internet Information Services web server (IIS))?
  Try ProtoNova today!

  http://internal.shininglightpro.com/search.nvm?searchname=ProtoNova

  Announcing ProtoNova v1.31, the secure alternative to IIS and Apache.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: openssl for windows ce tchar problem

[Steven Reddie]

Can you give me an example of an OpenSSL function that uses a char type
where you expect to be able to use a TCHAR type?

Regards,

Steven

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Antonio d'Errico
Sent: Thursday, 19 June 2003 7:48 PM
To: [EMAIL PROTECTED]
Subject: openssl for windows ce tchar problem


Hi,

i'm building a windows ce project for pocket pc 2002 with the openssl 0.9.7b
e wcecompat support.
I have some problems using TCHAR type in functions defined in openssl
include files (.h) and libraries, but i must use TCHAR type for the correct
visualization about the device!
Why openssl libraries for windows ce using char type and not TCHAR type?
it's normal? How I do?
Thanks for any suggestions

_
MSN Foto: condividi, ritocca e stampa le tue foto online
http://photos.msn.it

__
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: openssl for windows ce tchar problem

[Steven Reddie]

In anticipation of your response...  char is the type that has been used to
represent a character in C for a very long time now, in fact I've read that
it dates back to the same time as C's if keyword.  TCHAR is a newish type
defined by Microsoft that is equivalent to a char when doing a non-Unicode
build and equivalent to a wide char (WCHAR) when doing a Unicode build.
OpenSSL is platform-independant and therefore does not use such
Microsoft-specific types in it's interface.  If you wish to use OpenSSL on a
Unicode system such as Windows CE you may at times need to convert between
ASCII char's and Unicode WCHAR's.  This is not a problem specific to
OpenSSL, nor To Windows CE; it is a requirement of mixing ASCII and Unicode
in a single program.  The Win32 functions WideCharToMultiByte and
MultiByteToWideChar will help you with the conversions.

Regards,

Steven

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Steven Reddie
Sent: Friday, 20 June 2003 12:22 AM
To: [EMAIL PROTECTED]
Subject: RE: openssl for windows ce tchar problem


Can you give me an example of an OpenSSL function that uses a char type
where you expect to be able to use a TCHAR type?

Regards,

Steven

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Antonio d'Errico
Sent: Thursday, 19 June 2003 7:48 PM
To: [EMAIL PROTECTED]
Subject: openssl for windows ce tchar problem


Hi,

i'm building a windows ce project for pocket pc 2002 with the openssl 0.9.7b
e wcecompat support.
I have some problems using TCHAR type in functions defined in openssl
include files (.h) and libraries, but i must use TCHAR type for the correct
visualization about the device!
Why openssl libraries for windows ce using char type and not TCHAR type?
it's normal? How I do?
Thanks for any suggestions

_
MSN Foto: condividi, ritocca e stampa le tue foto online
http://photos.msn.it

__
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]

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl on windows

[joe speigle]

On Sun, Jul 07, 2002 at 03:37:19AM -0400, Vorster, Vian wrote:
 Hi
 
 I would like to know if it is possible to use openssl on a windows
 platform?In the past I have used SSH on a Linux box to run openssl.
what do you want to do with it?  
 
 Thanks
 V
 
 
 EMAIL DISCLAIMER 
 
 Please Note: The information contained in this message may be privileged and
 confidential, protected from disclosure, and/or intended only for the use of
 the individual or entity named above. If the reader of this message is not
 the intended recipient, or an employee or agent responsible for delivering
 this message to the intended recipient, you are hereby notified that any
 disclosure, distribution, copying or other dissemination of this
 communication is strictly prohibited. If you received this communication in
 error, please immediately reply to the sender, delete the message and
 destroy all copies of it.
 
 Thank You
 __
 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: OpenSSL Asynchronous Windows Sockets

[Justin Kagan]

Daryl,

I'm currently implementing a server using overlapped I/O completion ports.
Have you personally had any success in getting OpenSSL to work with that
sort of application?  I've searched the list archives for info on this
topic, and the little I could find about using BIOs was extremely vague.

Thanks - Justin



-Original Message-
From: Daryl Odnert [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, March 14, 2002 10:05 AM
To: '[EMAIL PROTECTED]'
Subject: RE: OpenSSL  Asynchronous Windows Sockets

Common wisdom on this topic seems to be that you should
handle the I/O in your own code and use BIO pairs to do the
handshake/encryption/decryption.

If you search the list archives for the keyword overlapped
or completion port you will find a couple of good
descriptions of what to do.

Daryl Odnert
[EMAIL PROTECTED]
Tumbleweed Communications
Redwood City, California

-Original Message-
From: agent [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 7:00 AM
To: [EMAIL PROTECTED]
Subject: OpenSSL  Asynchronous Windows Sockets


1. Will OpenSSL work with Windows Asynchronous Sockets?
2. I mean, will the WSAAsyncSelect()... work when using ssl?
I am halfway in implementing the asynchronous sockets in my project...
so it won't be a disaster to switch to another method...
3. Can anyone give me advice what is the best method to handle sockets
in non-blocking manner which will work correctly with OpenSSL?

__
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: OpenSSL Asynchronous Windows Sockets

[Daryl Odnert]

Common wisdom on this topic seems to be that you should
handle the I/O in your own code and use BIO pairs to do the
handshake/encryption/decryption.

If you search the list archives for the keyword overlapped
or completion port you will find a couple of good
descriptions of what to do.

Daryl Odnert
[EMAIL PROTECTED]
Tumbleweed Communications
Redwood City, California

-Original Message-
From: agent [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 7:00 AM
To: [EMAIL PROTECTED]
Subject: OpenSSL  Asynchronous Windows Sockets


1. Will OpenSSL work with Windows Asynchronous Sockets?
2. I mean, will the WSAAsyncSelect()... work when using ssl?
I am halfway in implementing the asynchronous sockets in my project...
so it won't be a disaster to switch to another method...
3. Can anyone give me advice what is the best method to handle sockets
in non-blocking manner which will work correctly with OpenSSL?

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: openssl for windows?

[Imran Badr]

http://www.iconsinc.com/~agray/ossldev/



  -Original Message-From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On 
  Behalf Of park hkSent: Wednesday, October 31, 2001 5:51 
  PMTo: [EMAIL PROTECTED]Subject: openssl for 
  windows?
  I'm poor at English.
  I'd like to know there is the openssl for 
  windows.
  
  Thank you!!

Re: openssl for windows

[ukoeppe]

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 28, 2000 6:50 PM
Subject: openssl for windows


 Anybody know where I can get openssl already compiled for WIndows? I don't
 have perl installed, have no interest in having it installed, so I can't
 compile the source for Windows.

Wow, a kindred spirit G.
There is some version (I think from May 1999) at
http://mail-archive.cashcow.dk/msg00114.html   , look for openssl.zip. Tell
you what, if you know where to put the openssl.cnf let me know, OK?

Uli Koeppe mailto [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]