fips_premain_dso hanging

2009-03-13 Thread ABDUL BASIT
Hello,

I am compiling OpenSSL FIPS-1.2 natively on PPC, the build blocks forever at
:-

+ /bin/rm -f ./libcrypto.so.0.9.8
+ gcc /fips-lib///fipscanister.o /fips-lib/fips_premain.c -fPIC
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DOPENSSL_NO_ERR -DB_ENDIAN
-DTERMIO -O3 -Wall -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_CAPIENG
-DOPENSSL_NO_CAST -DOPENSSL_NO_CMS -DOPENSSL_NO_EC -DOPENSSL_NO_ECDH
-DOPENSSL_NO_ECDSA -DOPENSSL_NO_ENGINE -DOPENSSL_NO_GMP -DOPENSSL_NO_IDEA
-DOPENSSL_NO_JPAKE -DOPENSSL_NO_MDC2 -DOPENSSL_NO_OCSP -DOPENSSL_NO_RC5
-DOPENSSL_NO_RFC3779 -DOPENSSL_NO_RIPEMD -DOPENSSL_NO_SEED -DOPENSSL_NO_SSL2
-DOPENSSL_NO_TLSEXT -DOPENSSL_NO_UI -shared -Wl,-Bsymbolic
-Wl,-soname=libcrypto.so.0.9.8 -o libcrypto.so.0.9.8 -Wl,--whole-archive
libcrypto.a -Wl,--no-whole-archive -L. -ldl
+ fips/../fips/fips_premain_dso ./libcrypto.so.0.9.8 -- BLOCKS
HERE FOREVER

After I ran gdb, I found that it is blocked in lh_new, here is the backtrace
..

Current language:  auto; currently asm
(gdb) bt
#0  0x100400dc in lh_new ()
#1  0x10039fdc in def_get_class ()
#2  0x1003a564 in int_new_ex_data ()
#3  0x1003adb8 in CRYPTO_new_ex_data ()
#4  0x100384e8 in BIO_set ()
#5  0x100385f0 in BIO_new ()
#6  0x1bb8 in main ()

The same thing is happening to me if i compile 0.9.8j on the same system
with ./config fips taking fipscanister.o from previous build of FIPS-1.2.

Please help.

- Basit


Re: Can't recognize intermediate CA

2009-03-13 Thread Kyle Hamilton
The NSS developers (NSS being the library that Firefox uses) have
discussed the concept of OpenSSL's overspecified Authority Key
Identifier numerous times.  Most recently,
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/2ac539b4447c58cd?pli=1
has the main NSS developer's (Nelson Bolyard) thoughts on the matter.

-Kyle H

On Thu, Mar 12, 2009 at 5:39 PM, Rene Hollan rene.hol...@watchguard.com wrote:
  Yup. That fixed it.. At least as far as openssl verify -CAfile
 cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

 Oddly, firefox still rejects the end cert, even though both cacert.pem
 and intcert2.pem are in it's trust store. Is it possible that browsers
 actually ignore intermediate CA certs in their trust store and expect
 servers to provide them? That's the next thing for me to try (if only I
 can remember how to do that with openssl... :-)).


 -Original Message-
 From: owner-openssl-us...@openssl.org
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
 Sent: Thursday, March 12, 2009 4:23 PM
 To: openssl-users@openssl.org
 Subject: Re: Can't recognize intermediate CA


 If it's any consolation you aren't alone with that, it gets commented on
 quite often so much so in fact that it has an FAQ entry:

 http://www.openssl.org/support/faq.html#USER15

 You can just leave out the issuer+serial number combination from AKID
 too.

 Steve.
 --
 Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
 project core developer and freelance consultant.
 Homepage: http://www.drh-consultancy.demon.co.uk
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

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


Re: Can't recognize intermediate CA

2009-03-13 Thread Kyle Hamilton
Actually, in addition to the last link I gave,
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/31fe9768dcb00b2c/7fab610c48b40a9c?#7fab610c48b40a9c
has a link to the entire thread (which includes a couple more
questions and answers).

http://is.gd/n9o4 is a short redirect to that URL.

-Kyle H

On Thu, Mar 12, 2009 at 7:31 PM, Rene Hollan rene.hol...@watchguard.com wrote:
 Great, just great.

 My changes worked for IE, but not for Firefox.

 Apparently, Firefox does more stringent checking that IE, and indeed,
 than OpenSSL s_client ... (which gives a nice cert chain).


 -Original Message-
 From: Rene Hollan
 Sent: Thursday, March 12, 2009 6:34 PM
 To: 'openssl-users@openssl.org'
 Subject: RE: Can't recognize intermediate CA

  Sigh.

 Well, I added the intermediate CA to the cert chain sent by my proxy
 (and verified this with wireshark).

 OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443
 works and shows the trust chain.

 But, Firefox, with cacert.pem loaded into it's trust store still
 complains. :-(



 -Original Message-
 From: Rene Hollan
 Sent: Thursday, March 12, 2009 5:39 PM
 To: 'openssl-users@openssl.org'
 Subject: RE: Can't recognize intermediate CA

  Yup. That fixed it.. At least as far as openssl verify -CAfile
 cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

 Oddly, firefox still rejects the end cert, even though both cacert.pem
 and intcert2.pem are in it's trust store. Is it possible that browsers
 actually ignore intermediate CA certs in their trust store and expect
 servers to provide them? That's the next thing for me to try (if only I
 can remember how to do that with openssl... :-)).


 -Original Message-
 From: owner-openssl-us...@openssl.org
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
 Sent: Thursday, March 12, 2009 4:23 PM
 To: openssl-users@openssl.org
 Subject: Re: Can't recognize intermediate CA


 If it's any consolation you aren't alone with that, it gets commented on
 quite often so much so in fact that it has an FAQ entry:

 http://www.openssl.org/support/faq.html#USER15

 You can just leave out the issuer+serial number combination from AKID
 too.

 Steve.
 --
 Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
 project core developer and freelance consultant.
 Homepage: http://www.drh-consultancy.demon.co.uk
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

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


RE: PBE Key creation

2009-03-13 Thread brechmos

Yeah, I appreciate that.

What I can't see in the docs is how the key and IV is defined from the
password and if I can do that without calling the openssl enc call.  If the
key and IV were from an md5 then I could do echo '1234' | openssl md5. 
But it isn't md5 and I can't figure out what it is...


Dave Thompson-4 wrote:
 
 From: owner-openssl-us...@openssl.org On Behalf Of brechmos
 Sent: Thursday, 12 March, 2009 08:25
 
 I am relatively new at openssl and am just figuring out its 
 power.  One thing
 
 General suggestion: for any of the openssl commandline 
 functions, you can get a brief usage display by adding -? .
 On a Unix-type installation (I believe including cygwin) 
 there are also man pages (you may need to adjust your 
 MANPATH depending on where OpenSSL is installed).
 Note that the command for symmetric crypto is actually 'enc';
 'des3' is really 'enc -des3', 'rc2-ofb' is 'enc -rc2-ofb', etc.;
 so the man page is for 'enc' not for a specific ciphername.
 
 I do not understand is the key creation.  For example,
 
 $ openssl des3 -nosalt -P -in bob.txt 
 
 and I type in the password 1234 (not my normal password :-) and 
 it comes up  with:
 
 Verifying - enter des-ede3-cbc encryption password:
 key=81DC9BDB52D04DC20036DBD8313ED055CC5776D16A1FB6E4
 iv =AFA34B18395DA656
 
 Is there a way to create the key shown above using an ssl command line?
 
 From openssl enc -? :
 -k passphrase is the next argument
 -pass argpass phrase source
 (and elsewhere several options for arg are given including pass:value)
 Hence:
 openssl enc -des3 -k 1234 -nosalt 
 openssl enc -des3 -pass pass:1234 -nosalt
 
 
 Subject to the usual caveat: on some OSes and/or in some situations, 
 commandline parameters can be seen by other programs, and possibly
 other users on a multiuser system; this may be insecure for you.
 
 
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 
 

-- 
View this message in context: 
http://www.nabble.com/PBE-Key-creation-tp22476230p22486863.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


cannot sign csr from win2008/e2k7

2009-03-13 Thread Jens Schwepe
Hi,

i'm using the fine how-to from http://www.eclectica.ca/howto/ssl-cert-howto.php 
now for years without problems.
It's on Debian Etch, openssl version is OpenSSL 0.9.8c 05 Sep 2006:


saruman:~# dpkg -l |grep openssl
ii  openssl  0.9.8c-4etch4Secure 
Socket Layer (SSL) binary and related


Now we have a Server 2008+E2k7, which shall replace the working 2003 one. 
However, I cannot sign the CSR generated from 2008 server, it says:



saruman:~/ssl/CA# openssl ca -out mittelerde.intern.jk-works.de/cert.pem 
-config ./openssl.cnf -infiles mittelerde.intern.jk-works.de/certrequest.txt
Using configuration from ./openssl.cnf
Enter pass phrase for ./private/cakey.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName    :ASN.1 12:'mellon.jk-works.de'
organizationalUnitName:ASN.1 12:'Mail Services'
organizationName  :ASN.1 12:'JK works GbR.'
stateOrProvinceName   :ASN.1 12:'Bremen'
countryName   :PRINTABLE:'DE'
The stateOrProvinceName field needed to be the same in the
CA certificate (Bremen) and the request (Bremen)
-

This is the CSR generated from New-ExchangeCertificate cmdlet:

-BEGIN NEW CERTIFICATE REQUEST-
MIIETTCCAzUCAQAwazEbMBkGA1UEAwwSbWVsbG9uLmprLXdvcmtzLmRlMRYwFAYD
VQQLDA1NYWlsIFNlcnZpY2VzMRYwFAYDVQQKDA1KSyB3b3JrcyBHYlIuMQ8wDQYD
VQQIDAZCcmVtZW4xCzAJBgNVBAYTAkRFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAxD77mS4q3g5j+hLzm69Tvz6x52IN8eT+Vfmz9oKmSGYTlnO8Smz0
J/gJ68xXOMg7AiXXFV+0jhjRPOoKsxbnk2ryvmxHTKUQ3QfnidxYlWDrCUCCdL+G
HqPQfBwCGms2pk05+mOTOd/RV7HHallVqs6VFpAcrlPih7aLTG8ScFVam/8X2pEy
tBsXXTBaWM9mlrb91UgaPho/P0RIv1TARCH1klY5KrdHD7PYXswDLCQiwvYrIpN6
WtaaNH41rX6Igy+TyVQbZ2kJY4TbDSBBaDVF8Y5lB37PZpDzPqA83lnrzIKKmF4F
6a+ZX3JfogCNDCMq+hN9yOkZY5c2m+CZIQIDAQABoIIBmzAaBgorBgEEAYI3DQID
MQwWCjYuMC42MDAxLjIwVAYJKwYBBAGCNxUUMUcwRQIBBQwdTWl0dGVsZXJkZS5p
bnRlcm4uamstd29ya3MuZGUMEUpLV09SS1NcZXhjaGFkbWluDA5wb3dlcnNoZWxs
LmV4ZTByBgorBgEEAYI3DQICMWQwYgIBAR5aAE0AaQBjAHIAbwBzAG8AZgB0ACAA
UgBTAEEAIABTAEMAaABhAG4AbgBlAGwAIABDAHIAeQBwAHQAbwBnAHIAYQBwAGgA
aQBjACAAUAByAG8AdgBpAGQAZQByAwEAMIGyBgkqhkiG9w0BCQ4xgaQwgaEwDgYD
VR0PAQH/BAQDAgWgMGIGA1UdEQRbMFmCHW1pdHRlbGVyZGUuaW50ZXJuLmprLXdv
cmtzLmRlghJtZWxsb24uamstd29ya3MuZGWCGGF1dG9kaXNjb3Zlci5qay13b3Jr
cy5kZYIKbWl0dGVsZXJkZTAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQ53Tt9Vieq
XN6UPMDMes2E9RF+FjANBgkqhkiG9w0BAQUFAAOCAQEAdNrzTzzM4O77iUEo5vjj
ZFA6psVzoYP2ICDzwPwTiIv4+IlQglC/9YactpK/q+I6jUTIY5imspKcXJFXIeWB
RYkniewe0FKgLPr2FtK1jz1mkZ4Fhs8SJevwzxVI8hLUrjlbsVayoR9fD5NzTLZr
U8NpoNMTQdVafWwPGrWuaZGDrKyULdX31wQ30Eub78QNd/zxNO2Gua/IJMyrjoaA
YKNWG1oxSzovCAISUsy1nuzBytVOHpNdCrh/f61kTS+961j7KJPUsPox5CP3waLK
+Z9ZTVl2g2T0eh9fd7inBgcXrMbOeENytpBawznngpRsAVLAuL500yEmymPi12XJ
tQ==
-END NEW CERTIFICATE REQUEST-


A CSR generated on Server 2003+E2k7 can be signed without problems.
Can you give me a hint on what I have to do to sign the new CSR?

Thanks in advance,


Jens Schwepe
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Can't recognize intermediate CA

2009-03-13 Thread Dr. Stephen Henson
On Thu, Mar 12, 2009, Rene Hollan wrote:

  Yup. That fixed it.. At least as far as openssl verify -CAfile
 cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.
 
 Oddly, firefox still rejects the end cert, even though both cacert.pem
 and intcert2.pem are in it's trust store. Is it possible that browsers
 actually ignore intermediate CA certs in their trust store and expect
 servers to provide them? That's the next thing for me to try (if only I
 can remember how to do that with openssl... :-)).
 

Well if you had to add intermediate CAs to browser trust stores they would be
of limimted use. The whole idea is that you only need to add the root CA and
the browser will automatically trust intermediate CAs it hasn't seen before.

The SSL/TLS standards also require sending of the certificate chain (but the
root can be excluded).

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


Re: Can't recognize intermediate CA

2009-03-13 Thread Dr. Stephen Henson
On Thu, Mar 12, 2009, Rene Hollan wrote:

 True, but (a) it doesn't hurt to have both, and (b) if  the issuer
 doesn't have a SKID, AKID issuer/serial takes the place of an AKID
 keyid.
 

The disadvantage is that if you want to support more than one intermediate CA
(cross certification for example) and you have issuer+serial in AKID then
you'll get a mismatch with any new CA.

This has caused issues when some people had an intermediate CA expire before
the EE cert.

Technically AKID/SKID should just be a hint as to the correct issuer
certificate which can be ignored but some software (including OpenSSL
currently) requires a match.

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


AW: openssl-users: cannot sign csr from win2008/e2k7

2009-03-13 Thread Jens Schwepe
Dear Romek,

thank you for your answer. I don't have any experience with IIS and 
certificates yet.
All I know that the CSR generated on 2003 works, on 2008 it does not.
Additionally, the all work with the Windows Server CA (phew, who would have 
thought that *eg*).

Kind Regards,
Jens

-Ursprüngliche Nachricht-
Von: Romek [mailto:rom...@gmail.com] 
Gesendet: Freitag, 13. März 2009 13:33
An: Jens Schwepe
Betreff: Re: openssl-users: cannot sign csr from win2008/e2k7

Hi,

I have been having the same issues with Windows 2003/2008 and IIS 6.

The error in your request is that you have not got the 129 zeros
needed in the enrolmentCSP that are needed (I believe caused by no CSP
being assigned for the request) in the certificate wizard. For me, I
have found that the only way to get these requests to work is by
recreating them again and again until they do as you have no options
to change this by default.

It may be sensible that you try also with only 1 subjectAltName as you
have 4 encoded in your request which may also cause problems.

Also, I have found IIS 6 to give out badly encoded Public Keys giving
negative values. You seem to have been lucky here! With IIS 6, I am
unable to view the certificate requests with most ASN.1 viewers apart
from Gutmann's dumpasn1, but I do not find the same with your request.

I was testing with commercial CAs and not OpenSSL.

Kind regards,
Romek Szczesniak
rom...@gmail.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


OpenSSL 0.9.8e on AIX 64-bit: make test fails

2009-03-13 Thread SFNT Vivek

I did not find a place to start a new thread. Sorry for writing a problem in
reply

I'm building OpenSSL 0.9.8e on AIX 64-bit. Following 2 commands work fine.
./Configure -lpthreads aix64-gcc -maix64 --prefix=/usr/local/ssl/
--openssldir=/usr/local/ssl/
make

make test
fails with following end remarks:
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


OpenSSL 0.9.8e on AIX 64-bit: make test fails

2009-03-13 Thread SFNT Vivek

I'm building OpenSSL 0.9.8e on AIX 64-bit. Following 2 commands work fine.
./Configure -lpthreads aix64-gcc -maix64 --prefix=/usr/local/ssl/
--openssldir=/usr/local/ssl/
make

make test
fails with following end remarks:
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


TLS, BIOs, SSL_read/write

2009-03-13 Thread Nate Leon
Greetings,
I am in the process of converting an SMTP/TLS server to use Async IO.
(using IO Completion Ports on Windows)
As such, the previously working style of using SSL_accept, select, and
SSL_read / SSL_write is no longer sufficient.

Now that I am using WSARecv to do the read, my app is notified when a
buffer is filled with (encrypted) data.
Somebody suggested I stuff that data into a BIO buffer and read it out of that.
I attempted to use BIO_read but without success.
I seem to have that half working now, looking roughly like this:
(over-simplified for readability)

// SMTP client requests STARTTLS, server takes these actions:
BIO* m_bioSckt = BIO_new_socket((int)scktUpstream, BIO_NOCLOSE);
SSL* m_ssl = SSL_new(ctx);
SSL_set_accept_state(m_ssl);
SSL_set_bio(m_ssl, m_bioSckt, m_bioSckt);

// Server sends 220 go ahead to client, and waits for Client/Server
to negotiate handshake
int nRetCode = SSL_accept(m_ssl);

// This succeeds - client reports: New, TLSv1/SSLv3, Cipher is
AES256-SHA, etc...
// Now client sends command (e.g. EHLO example.org) which needs to
be decrypted
BIO* m_bioMem = BIO_new_mem_buf(encryptedData, nEncDataSize);
SSL_set_bio(m_ssl, m_bioMem, NULL);
char decryptedData[4096];
int numBytesRead = SSL_read(m_ssl, decryptedData, sizeof(decryptedData));

// SMTP server processes decryptedData and takes appropriate action -
e.g. sends a 250 OK response
// That response needs to be encrypted before it is sent (WSASend)
BIO* bioMem = BIO_new(BIO_f_buffer());
SSL_set_bio(m_ssl, NULL, bioMem);
int numBytesWritten = SSL_write(m_ssl, responseData, nRespDataSize);   // fails
BIO_flush(bioMem);

I am testing using the openssl client:
openssl s_client -starttls smtp -connect localhost:25 -crlf -msg -debug

The SSL_write seems to fail completely. :(
Am I on the right track here?
Is it the optimal way to go about it?
Also surprising, (at least to me) is that BIO_new_socket and
BIO_new_mem_buf return the identical address in memory,
which makes me think I am really not understanding how this is supposed to work.

Any pointers are much appreciated.

TIA,
n8
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: TLS, BIOs, SSL_read/write

2009-03-13 Thread Galina Goncharov
Hello,
as I can see from code you first set readBIO and writeBIO to
socket(scktUpstream ) and that makes TLS negotiation to succeed. Later you
set SSL readBIO to mem_bio, and writeBIO to NULL and then try to use
writeBIO ( calling SSL_write) - sure it will fail. During negotiation do you
receive server responses on scktUpstream?  I think so, otherwise I don't see
how it would work. Have you tried to not reset SSL BIO with memBIO but have
blocking SSL_read  - it will return once you socket finish reading.and then
just use SSL_write as you do, just  again without reseting SSL  BIO.

hope this will help.
Galina





On Fri, Mar 13, 2009 at 7:52 PM, Nate Leon n8l...@gmail.com wrote:

 Greetings,
 I am in the process of converting an SMTP/TLS server to use Async IO.
 (using IO Completion Ports on Windows)
 As such, the previously working style of using SSL_accept, select, and
 SSL_read / SSL_write is no longer sufficient.

 Now that I am using WSARecv to do the read, my app is notified when a
 buffer is filled with (encrypted) data.
 Somebody suggested I stuff that data into a BIO buffer and read it out of
 that.
 I attempted to use BIO_read but without success.
 I seem to have that half working now, looking roughly like this:
 (over-simplified for readability)

 // SMTP client requests STARTTLS, server takes these actions:
 BIO* m_bioSckt = BIO_new_socket((int)scktUpstream, BIO_NOCLOSE);
 SSL* m_ssl = SSL_new(ctx);
 SSL_set_accept_state(m_ssl);
 SSL_set_bio(m_ssl, m_bioSckt, m_bioSckt);

 // Server sends 220 go ahead to client, and waits for Client/Server
 to negotiate handshake
 int nRetCode = SSL_accept(m_ssl);

 // This succeeds - client reports: New, TLSv1/SSLv3, Cipher is
 AES256-SHA, etc...
 // Now client sends command (e.g. EHLO example.org) which needs to
 be decrypted
 BIO* m_bioMem = BIO_new_mem_buf(encryptedData, nEncDataSize);
 SSL_set_bio(m_ssl, m_bioMem, NULL);
 char decryptedData[4096];
 int numBytesRead = SSL_read(m_ssl, decryptedData, sizeof(decryptedData));

 // SMTP server processes decryptedData and takes appropriate action -
 e.g. sends a 250 OK response
 // That response needs to be encrypted before it is sent (WSASend)
 BIO* bioMem = BIO_new(BIO_f_buffer());
 SSL_set_bio(m_ssl, NULL, bioMem);
 int numBytesWritten = SSL_write(m_ssl, responseData, nRespDataSize);   //
 fails
 BIO_flush(bioMem);

 I am testing using the openssl client:
 openssl s_client -starttls smtp -connect localhost:25 -crlf -msg -debug

 The SSL_write seems to fail completely. :(
 Am I on the right track here?
 Is it the optimal way to go about it?
 Also surprising, (at least to me) is that BIO_new_socket and
 BIO_new_mem_buf return the identical address in memory,
 which makes me think I am really not understanding how this is supposed to
 work.

 Any pointers are much appreciated.

 TIA,
 n8
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org



RE: Can't recognize intermediate CA

2009-03-13 Thread Rene Hollan

Yeah, I realized that. I changed things to include an AKID if the issuer has a 
SKID, and the issuer's issuer's subject DN and issuer's serial number if not.

Got it all working finally, once I had the proxy chain it's intermediate CA. 
(When it wasn't doing this, I thought to try to add it to the trusted store of 
the browser, realizing that defeated the purpose of an intermediate CA, but 
wanted to test. That didn't work, but likely because I forgot the tell the 
browser what the trust chain rooted at the root CA was FOR.)


-Original Message-
From: owner-openssl-us...@openssl.org on behalf of Dr. Stephen Henson
Sent: Fri 3/13/2009 5:14 AM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA
 
On Thu, Mar 12, 2009, Rene Hollan wrote:

 True, but (a) it doesn't hurt to have both, and (b) if  the issuer
 doesn't have a SKID, AKID issuer/serial takes the place of an AKID
 keyid.
 

The disadvantage is that if you want to support more than one intermediate CA
(cross certification for example) and you have issuer+serial in AKID then
you'll get a mismatch with any new CA.

This has caused issues when some people had an intermediate CA expire before
the EE cert.

Technically AKID/SKID should just be a hint as to the correct issuer
certificate which can be ignored but some software (including OpenSSL
currently) requires a match.

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

winmail.dat