verify error:num=18:self signed certificate--how to make a self singed ,dynamicly generate certificate to be trusted

[sara bai]

hi all , I created a certificate dynamicly in this way  (python-twisted
)

dn = ssl.DistinguishedName(commonName="test dn")
dn.inspect() # add by myself
keypair = ssl.KeyPair.generate()
req = keypair.certificateRequest(dn)

def verify(dn):
return True

serialno = 1110

isuser= ssl.DistinguishedName(commonName="test dn")  # isuser  ->dni
 The certificate is not trusted because it is self-signed.
certData = keypair.signCertificateRequest(isuser, req, verify, serialno)
  #The certificate is only valid for 'test dn'


cert = keypair.newCertificate(certData)

contextFactory = cert.options()

reactor.listenSSL(, EchoFactory(), contextFactory)


- test it  :openssl s_client -ssl3 -connect 127.0.0.1:

got this error  :
"
4204:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1053:SSL alert number 40
4204:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:530:   "


and  then i use tls1 method the error is like this :
"
...TLS 1.0 Handshake [length 0010], Finished...
...
verify error:num=18:self signed certificate "



is there any way to make a dynamicly generate certificate to be trusted ?
need help  thanks

RE: ERROR LINK2019

[芦翔]

Dear William,

   I am sorry for the last intercepted email. I tried the way as your 
instruction. But the problem is still there. If there is another reason for my 
question. I am not sure if the openssl lib is not compiled. Thank you.

 

Best Regards,

Xiang
 
> Subject: RE: ERROR LINK2019
> Date: Tue, 13 Apr 2010 16:34:35 -0700
> From: jfarr...@pillardata.com
> To: openssl-users@openssl.org
> CC: luxiang...@hotmail.com
> 
> 
> 
> > From: William A. Rowe Jr.
> > 
> > On 4/13/2010 4:49 PM, 芦翔 wrote:
> > > Dear all,
> > > I am trying to add the security flavor to an 
> > application. To achieve
> > > this objective, I wrote the codes to establish a security 
> > tunnel between
> > > the server and the client with VC2008. When I build the 
> > whole project,
> > > there are tens of similar errors. All of them are as follows:
> > > 
> > >>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free
> > > referenced in function "int __cdecl
> > > SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
> > > (?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z
> > > 
> > )
> > 
> > That signature is consistent with C++ argument folding.
> > 
> > The openssl headers you've used probably were missing this decoration
> > 
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> > 
> > ...
> > 
> > #ifdef __cplusplus
> > }
> > #endif
> > 
> > So you should put your #include references in between the 
> > snippets above
> > (in place of the ... elipses).
> 
> He's clearly calling then from C++, but the names it can't find don't look 
> C++ decorated to me - _BIO_free looks like a normal Microsoft C reference.
> 
> Isn't the problem here just that he's not linking against the OpenSSL 
> libraries?
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
  
_
约会说不清地方？来试试微软地图最新msn互动功能！
http://ditu.live.com/?form=TL&swm=1

RE: ERROR LINK2019

[芦翔]

Dear William,

   I tried to add "extern" in C parts. But, the error is still there. I am not 
sure if there is another reason for my question. My files is organized as the 
following way.

   There are four files: main.cpp, a.h, b.h, b.cpp. Among them, b.h and b.cpp 
are programed by C. The functions  
> Date: Tue, 13 Apr 2010 17:57:27 -0500
> From: wr...@rowe-clan.net
> To: openssl-users@openssl.org
> CC: luxiang...@hotmail.com
> Subject: Re: ERROR LINK2019
> 
> On 4/13/2010 4:49 PM, 芦翔 wrote:
> > Dear all,
> > I am trying to add the security flavor to an application. To achieve
> > this objective, I wrote the codes to establish a security tunnel between
> > the server and the client with VC2008. When I build the whole project,
> > there are tens of similar errors. All of them are as follows:
> > 
> >>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free
> > referenced in function "int __cdecl
> > SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
> > (?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z
> > )
> 
> That signature is consistent with C++ argument folding.
> 
> The openssl headers you've used probably were missing this decoration
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> ...
> 
> #ifdef __cplusplus
> }
> #endif
> 
> So you should put your #include references in between the snippets above
> (in place of the ... elipses).
> 
  
_
SkyDrive电子画册，带你领略精彩照片，分享“美”时“美”刻!
http://www.windowslive.cn/campaigns/e-magazine/ngmchina/?a=c

RE: ERROR LINK2019

[芦翔]

hi,

  Thank you for your notes. Yes, my code is composed of both C and C++ code. 
For the openssl part, it is programed by C. And the other part is from C++. 
Should I only use "extern" for those C-realated  "#include", or all the C code 
should be embraced in the "extern"? Thank you so much.

 

Best Regards,

Xiang
 
> Date: Tue, 13 Apr 2010 17:57:27 -0500
> From: wr...@rowe-clan.net
> To: openssl-users@openssl.org
> CC: luxiang...@hotmail.com
> Subject: Re: ERROR LINK2019
> 
> On 4/13/2010 4:49 PM, 芦翔 wrote:
> > Dear all,
> > I am trying to add the security flavor to an application. To achieve
> > this objective, I wrote the codes to establish a security tunnel between
> > the server and the client with VC2008. When I build the whole project,
> > there are tens of similar errors. All of them are as follows:
> > 
> >>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free
> > referenced in function "int __cdecl
> > SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
> > (?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z
> > )
> 
> That signature is consistent with C++ argument folding.
> 
> The openssl headers you've used probably were missing this decoration
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> ...
> 
> #ifdef __cplusplus
> }
> #endif
> 
> So you should put your #include references in between the snippets above
> (in place of the ... elipses).
> 
  
_
SkyDrive电子画册，带你领略精彩照片，分享“美”时“美”刻!
http://www.windowslive.cn/campaigns/e-magazine/ngmchina/?a=c

Re: openSSL and PKCS #12 certificates

[Mounir IDRASSI]

Hi Remi,

I don't know what the inputs of your python module are, but from the 
error message I guess that it's expecting the PEM file to contain also 
the certificate of the private key and the associated CA chain. For 
that, I advice you to replace the option "-nocerts" in your command line 
with "-nodes". Thus:
- The output PEM file will contain the private key AND its certificate 
along with any associated CAs
- You will not be asked for a password a second time because the private 
key in the output PEM file will be unencrypted.


After that, you will have to open the output PEM file in a text editor 
in order to ensure that the certificate that comes just after the 
private key block is the one associated with the key and not a CA 
certificate ( a cut and past is almost necessary to put everything in 
the right order).


I hope that with all this steps, you will finally be able to perform 
your client authentication.


Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr



On 4/13/2010 6:45 PM, Rémi Després-Smyth wrote:

Mounir,
Thank you so much for your answer.

I did extract the key into a pem file (using command: c:\openssl\bin\openssl
pkcs12 -in cert.pfx -nocerts -out cert_key.pem), and tried to connect using
the key file as output.  It got further along in the process - I was
prompted to enter my PEM pass phrase - but a different error came up:

   File "C:\python26\lib\ssl.py", line 113, in __init__
 cert_reqs, ssl_version, ca_certs)
ssl.SSLError: [Errno 336445449] _ssl.c:351: error:140DC009:SSL
routines:SSL_CTX_use_certificate_chain_file:PEM lib

Would you have any insight in regards to the problem here?


I should also note that while I was creating the key file, I noticed that I
was prompted to "Enter Import Password", but also to "Enter PEM pass
phrase".  Does this mean the private key found in the pfx file is actually
in PEM format to begin with?  Does this change your advice at all?

Regards,
Remi.


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Mounir IDRASSI
Sent: April 13, 2010 11:29 AM
To: openssl-users@openssl.org
Subject: Re: openSSL and PKCS #12 certificates

Hi,

OPENSSL supports PKCS#12 files. Look at the header pkcs12.h that
contains functions for parsing and exporting private keys and
certificates from a PKCS#12 file (like d2i_PKCS12 and PKCS12_parse).

Concerning the error you are getting, it appears that the phython module
you are using is calling SSL_CTX_use_PrivateKey_file by giving it the
PKCS#12 file name. This is does not because SSL_CTX_use_PrivateKey_file
only accepts two formats : SSL_FILETYPE_PEM and SSL_FILETYPE_ASN1.
In order to correct this, you have two solutions :
- Either feed the python module with the private key in a PEM file.
- Or modify the source code of this python module in order to use the
PKCS#12 functions I mentioned above to extract the private key as an
EVP_PKEY and then call SSL_use_PrivateKey instead of
SSL_CTX_use_PrivateKey_file, along with SSL_use_certificate for setting
the associated certificate.

The first solution is the easiest because you can simply use the OPENSSL
command line utility in order to extract the private key and its
certificate from the PKCS#12 file as PEM files and then give them as
input to your python module.

I hope this will help.
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr


On 4/13/2010 2:55 PM, Rémi Després-Smyth wrote:
   

Hello.

I’ve been trying to setup client authentication using a PKCS #12
certificate, and I’ve been having some trouble.  I’m trying to determine
whether its because its something unsupported in openSSL, or if it’s a
problem with the wrapper library I’m using (Python’s httplib).  I’d
appreciate it if anyone might be able to provide some insight.



I’m getting an error raised by the openSSL library when the wrapper class
 

is
   

trying to instantiate and wrap a socket, and from what I’ve been able to
gather to-date, the error appears to be coming from openSSL:



Ssl.SSLError: [Errno 336265225] _sll.c:337: error:140B0009:SSL
routines:SSL_CTX_use_PrivateKey_file:PEM lib



Is PKCS #12 supposed to be supported by openSSL?  I would guess yes; I dug
around in the source and found that “PEM lib” is the error text for
ERR_R_PEM_LIB (defined in err_str.c), and I also noticed ERR_R_PKCS12_LIB
 

in
   

there.  This gives me the impression that openSSL is incorrectly trying to
load the PKCS #12 cert as a PEM cert, and thus the error – which leads me
 

to
   

believe that the wrapper library may not be calling openSSL properly, if
PKCS #12 certificates should be supported.  (Otherwise, why would openSSL
 

be
   

returning an error related to PEM certs and not PKCS #12 certs?)



Can anyone tell me whether or not openSSL should be able to work with
PKCS#12 certs?  Any advice anyone might have is welcome. (Sorry if this is
vague; this is the first time I dig into the openSSL project.)



The certificate app

RE: ERROR LINK2019

[Jeremy Farrell]

 

> From: William A. Rowe Jr.
> 
> On 4/13/2010 4:49 PM, 芦翔 wrote:
> > Dear all,
> >I am trying to add the security flavor to an 
> application. To achieve
> > this objective, I wrote the codes to establish a security 
> tunnel between
> > the server and the client with VC2008. When I build the 
> whole project,
> > there are tens of similar errors. All of them are as follows:
> >  
> >>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free
> > referenced in function "int __cdecl
> > SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
> > (?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z
> > 
> )
> 
> That signature is consistent with C++ argument folding.
> 
> The openssl headers you've used probably were missing this decoration
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> ...
> 
> #ifdef __cplusplus
> }
> #endif
> 
> So you should put your #include references in between the 
> snippets above
> (in place of the ... elipses).

He's clearly calling then from C++, but the names it can't find don't look C++ 
decorated to me - _BIO_free looks like a normal Microsoft C reference.

Isn't the problem here just that he's not linking against the OpenSSL libraries?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: ERROR LINK2019

[John R Pierce]

芦翔 wrote:
> Dear all,
> I am trying to add the security flavor to an application. To achieve
> this objective, I wrote the codes to establish a security tunnel
> between the server and the client with VC2008. When I build the whole
> project, there are tens of similar errors. All of them are as follows:
>
> >SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free
> referenced in function "int __cdecl
> SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
> (?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z
> )
the API's are C, not C++. for some reason your compiler is trying to
turn them into C++ decorated methods. I thought __cdecl supressed this
behavior but I stopped working in vc++ about 10 years ago.





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

Re: ERROR LINK2019

[William A. Rowe Jr.]

On 4/13/2010 4:49 PM, 芦翔 wrote:
> Dear all,
>I am trying to add the security flavor to an application. To achieve
> this objective, I wrote the codes to establish a security tunnel between
> the server and the client with VC2008. When I build the whole project,
> there are tens of similar errors. All of them are as follows:
>  
>>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free
> referenced in function "int __cdecl
> SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
> (?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z
> )

That signature is consistent with C++ argument folding.

The openssl headers you've used probably were missing this decoration

#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif

So you should put your #include references in between the snippets above
(in place of the ... elipses).

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

ERROR LINK2019

[芦翔]

Dear all,
   I am trying to add the security flavor to an application. To achieve this 
objective, I wrote the codes to establish a security tunnel between the server 
and the client with VC2008. When I build the whole project, there are tens of 
similar errors. All of them are as follows:

 

>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free
referenced in function "int __cdecl
SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
(?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_SSL_CTX_use_PrivateKey referenced in function "int __cdecl
SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
(?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_PEM_read_bio_PrivateKey referenced in function "int __cdecl
SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
(?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_ctrl
referenced in function "int __cdecl
SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
(?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_new
referenced in function "int __cdecl
SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
(?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _BIO_s_file
referenced in function "int __cdecl
SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *)"
(?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
__imp__pthread_self referenced in function "struct ptw32_handle_t __cdecl
pthreads_thread_id(void)" (?pthreads_thread_id@@YA?AUptw32_handle_t@@XZ)
1>SSLServer.obj : error LNK2019: unresolved external symbol
__imp__pthread_mutex_unlock referenced in function "void __cdecl
pthreads_locking_callback(int,int,char const *,int)"
(?pthreads_locking_callback@@yaxhhp...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
__imp__pthread_mutex_lock referenced in function "void __cdecl
pthreads_locking_callback(int,int,char const *,int)"
(?pthreads_locking_callback@@yaxhhp...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
__imp__pthread_exit referenced in function "void * __cdecl
thread_main(void *)" (?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _SSL_free
referenced in function "void * __cdecl thread_main(void *)"
(?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _SSL_read
referenced in function "void * __cdecl thread_main(void *)"
(?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _X509_free
referenced in function "void * __cdecl thread_main(void *)"
(?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_X509_get_issuer_name referenced in function "void * __cdecl
thread_main(void *)" (?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _CRYPTO_free
referenced in function "void * __cdecl thread_main(void *)"
(?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_X509_NAME_oneline referenced in function "void * __cdecl thread_main(void
*)" (?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_X509_get_subject_name referenced in function "void * __cdecl
thread_main(void *)" (?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_SSL_get_peer_certificate referenced in function "void * __cdecl
thread_main(void *)" (?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_SSL_CIPHER_get_name referenced in function "void * __cdecl
thread_main(void *)" (?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol
_SSL_get_current_cipher referenced in function "void * __cdecl
thread_main(void *)" (?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _SSL_accept
referenced in function "void * __cdecl thread_main(void *)"
(?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _SSL_get_fd
referenced in function "void * __cdecl thread_main(void *)"
(?thread_main@@yapax...@z)
1>SSLServer.obj : error LNK2019: unresolved external symbol _SSL_CTX_free
referenced in function "int __cdecl SSL_Initialization(void)"
(?SSL_Initialization@@YAHXZ)
1>SSLServer.obj : error LNK2019: unresolved external symbol
__imp__pthread_detach referenced in function "int __cdecl
SSL_Initialization(void)" (?SSL_Initialization@@YAHXZ)
1>SSLServer.obj : error LNK2019: unresolved external symbol
__imp__pthread_create referenced in function "int __cdecl
SSL_Initializatio

Re: OpenSSL 1.0.0 patch for enabling "*:123" host syntax and ephemeral ports with Win32

[Ger Hobbelt]

Your diff is fine as others use that too.

The address to post bug reports, patches and such to is

  r...@openssl.org

You'll get a moderated auto-response from that once it has passed the
[spam]filters there, I guess, and it will then end up being forwarded to the
developers mailing list of openssl while having an issue number attached in
the subject line, so that you and others can track the item.


Couple of things to consider:

- zeroeth: might help the team decide & prioritize when you mention against
which version of openssl this has been tested.
I'm most definitely not on the team, so this is your captain who's directing
from the sidewalk (at least that's what the Dutch would say; don't know the
English/American version of that saying), but I guess mentioning you've
tested it against, say, CVS HEAD of date /mm/dd might get some hands
together, as would listing other (released) versions. Even when those
versions have few or no diffs among them at a spot where you worked on, it
just helps people to see what your base was and how far you've gone in
testing this baby and will give them a bit of a feeling how much it would
take to integrate and test the bugger, that's all.

- first: make sure your bug report /patch/ ... has a easily understandable
subject line; this is your '2 seconds elevator pitch' line. (I'd say yours
is very fine.)

- second, don't expect instant 'done!' responses. I believe the few people
working on OpenSSL are a tad overloaded  so a bit of very
gentle nudging after a while may help keep your item in the front ranks. And
even then, it may be a long wait. If nothing else helps, consider Zen. Um
mani padme Um. The guys just don't like getting kicking off their mortgages
any better than you do, so that is the bottomest bottom line in OpenSSL RT
triage, I'ld say.

- third: attach patch files (as you already did! Excellent!) instead of
inlining them; helps extraction and processing as email is not a nice medium
for inline source exchange.

- fourth: If you haven't already, you might want to subscribe to the dev
mailing list; though 'proper procedure'[*] would be to send any replies
regarding the item through rt@ again for total tracability, we all glitch
every once in a while so replies can end up in openssl-dev@ alone (and not
RT).


[*]) nope, don't ask me where that SOP is written down because I only
'gleaned' that one from leeching the lists for ages. The Internet is so
great because it not only allows you to see but above all /overlook/ a lot
of relevant detail.

And if this 'documentation' is not on the net yet, than hopefully I got it
right and some poor soul will copy it into the FAQ or thereabouts for those
searching and seeking to find.




On Tue, Apr 13, 2010 at 8:28 PM, Modem Man  wrote:

> Hi,
>
> I found and fixed a small bug in "crypto\bio\b_sock.c" and want to ask
> where to post the patch / fix.
>
> please note:
> I can not guarantee of production grade quality of my fix, but it works
> pretty well with my implementation of an FTP server.
>
> regards,
> Maik,
> the modem-man
>
>
> B.T.W.: what is preferred diff format here? I used "diff -bw -u". Okay?



-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--
web:http://www.hobbelt.com/
   http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--

OpenSSL 1.0.0 patch for enabling "*:123" host syntax and ephemeral ports with Win32

[Modem Man]

Hi,

I found and fixed a small bug in "crypto\bio\b_sock.c" and want to ask
where to post the patch / fix.

please note:
I can not guarantee of production grade quality of my fix, but it works
pretty well with my implementation of an FTP server.

regards,
Maik,
the modem-man


B.T.W.: what is preferred diff format here? I used "diff -bw -u". Okay?


--- 1.0.0\b_sock.c  Thu Jan 07 14:15:40 2010
+++ 1.0.0.patchw32asteriskhost\b_sock.c Fri Apr 09 21:02:18 2010
@@ -672,7 +672,21 @@
 #endif
}
else if (h[0]=='*' && h[1]=='\0')
+ {
+# ifdef _WIN32 /* modem-man patch, sure for windows. not sure for other OS 
*/
+   /* h="0.0.0.0"; */ /* quick hack, but dirty! */
+   hint.ai_flags |= AI_PASSIVE;  /* better way of '*' 
handling! */
+# else /* modem-man patch */
h=NULL;
+# endif /* modem-man patch */
+ }
+   }
+   if (p && (p[0]=='*' && p[1]=='\0'))
+   {
+# ifdef _WIN32 /* modem-man patch */
+   p="0"; /* ephemeral port number */
+   hint.ai_flags |= AI_PASSIVE;  /* better way of '*' 
handling! */
+# endif /* modem-man patch */
}
 
if ((*p_getaddrinfo.f)(h,p,&hint,&res)) break;

Re: problem verifying OCSP signature

[Chris Bare]

> Additional candidate signer certificates  need to be included in the
> -verify_other option.
> 
> If the OCSP signing certificate is self signed then it needs to be explicitly
> trusted which is the -VAfile option if you use that it will also be searched
> as a signer.

doesn't putting it in the CApath also mean it's explicitly trusted?

I tracked down this code in crypto/ocsp/ocsp_vfy.c:
static int ocsp_find_signer(X509 **psigner, OCSP_BASICRESP *bs, STACK_OF(X509)
*certs, X509_STORE *st, unsigned long flags)
{
X509 *signer;
OCSP_RESPID *rid = bs->tbsResponseData->responderId;
if ((signer = ocsp_find_signer_sk(certs, rid)))
{
*psigner = signer;
return 2;
}
if(!(flags & OCSP_NOINTERN) &&
(signer = ocsp_find_signer_sk(bs->certs, rid)))
{
*psigner = signer;
return 1;
}
/* Maybe lookup from store if by subject name */

*psigner = NULL;
return 0;
}

It looks like implementing the "Maybe" case would solve my problem. Would it
be incorrect to look in the store also here? I'd be glad to work on a patch.

I understand I can make the command line tool with with -verify_other, but in
my code I have no handy way to do that. My users are going to dump all trusted
certs, regardless of purpose, into the trusted store.
-- 
Chris Bare
ch...@bareflix.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: problem verifying OCSP signature

[Dr. Stephen Henson]

On Tue, Apr 13, 2010, Chris Bare wrote:

> This command works:
> 
> openssl ocsp -issuer issuer.pem -VAfile trusted_dir/ocsp_signer.pem -url 
> http://ocsp.test.com -cert cert.pem -resp_text
> 
> but this fails:
> openssl ocsp -issuer issuer.pem -CApath trusted_dir -url http://ocsp.test.com 
> -cert cert.pem -resp_text
> 
> with:
> 3077556488:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate 
> not found:ocsp_vfy.c:85:
> 
> since the signer cert is in the trusted dir, shouldn't the second version be
> able to find it there?
> 
> ocsp_signer.pem is a self-signed cert, does that matter?
> 
> I ran strace on the second command and I never see it even open the
> directory.

Additional candidate signer certificates  need to be included in the
-verify_other option.

If the OCSP signing certificate is self signed then it needs to be explicitly
trusted which is the -VAfile option if you use that it will also be searched
as a signer.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

problem verifying OCSP signature

[Chris Bare]

This command works:

openssl ocsp -issuer issuer.pem -VAfile trusted_dir/ocsp_signer.pem -url 
http://ocsp.test.com -cert cert.pem -resp_text

but this fails:
openssl ocsp -issuer issuer.pem -CApath trusted_dir -url http://ocsp.test.com 
-cert cert.pem -resp_text

with:
3077556488:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate 
not found:ocsp_vfy.c:85:

since the signer cert is in the trusted dir, shouldn't the second version be
able to find it there?

ocsp_signer.pem is a self-signed cert, does that matter?

I ran strace on the second command and I never see it even open the
directory.
-- 
Chris Bare
ch...@bareflix.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: openSSL and PKCS #12 certificates

[Rémi Després-Smyth]

Mounir,
Thank you so much for your answer.

I did extract the key into a pem file (using command: c:\openssl\bin\openssl
pkcs12 -in cert.pfx -nocerts -out cert_key.pem), and tried to connect using
the key file as output.  It got further along in the process - I was
prompted to enter my PEM pass phrase - but a different error came up:

  File "C:\python26\lib\ssl.py", line 113, in __init__
cert_reqs, ssl_version, ca_certs)
ssl.SSLError: [Errno 336445449] _ssl.c:351: error:140DC009:SSL
routines:SSL_CTX_use_certificate_chain_file:PEM lib

Would you have any insight in regards to the problem here?


I should also note that while I was creating the key file, I noticed that I
was prompted to "Enter Import Password", but also to "Enter PEM pass
phrase".  Does this mean the private key found in the pfx file is actually
in PEM format to begin with?  Does this change your advice at all?

Regards,
Remi.


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Mounir IDRASSI
Sent: April 13, 2010 11:29 AM
To: openssl-users@openssl.org
Subject: Re: openSSL and PKCS #12 certificates

Hi,

OPENSSL supports PKCS#12 files. Look at the header pkcs12.h that 
contains functions for parsing and exporting private keys and 
certificates from a PKCS#12 file (like d2i_PKCS12 and PKCS12_parse).

Concerning the error you are getting, it appears that the phython module 
you are using is calling SSL_CTX_use_PrivateKey_file by giving it the 
PKCS#12 file name. This is does not because SSL_CTX_use_PrivateKey_file 
only accepts two formats : SSL_FILETYPE_PEM and SSL_FILETYPE_ASN1.
In order to correct this, you have two solutions :
- Either feed the python module with the private key in a PEM file.
- Or modify the source code of this python module in order to use the 
PKCS#12 functions I mentioned above to extract the private key as an 
EVP_PKEY and then call SSL_use_PrivateKey instead of 
SSL_CTX_use_PrivateKey_file, along with SSL_use_certificate for setting 
the associated certificate.

The first solution is the easiest because you can simply use the OPENSSL 
command line utility in order to extract the private key and its 
certificate from the PKCS#12 file as PEM files and then give them as 
input to your python module.

I hope this will help.
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr


On 4/13/2010 2:55 PM, Rémi Després-Smyth wrote:
> Hello.
>
> I’ve been trying to setup client authentication using a PKCS #12
> certificate, and I’ve been having some trouble.  I’m trying to determine
> whether its because its something unsupported in openSSL, or if it’s a
> problem with the wrapper library I’m using (Python’s httplib).  I’d
> appreciate it if anyone might be able to provide some insight.
>
>
>
> I’m getting an error raised by the openSSL library when the wrapper class
is
> trying to instantiate and wrap a socket, and from what I’ve been able to
> gather to-date, the error appears to be coming from openSSL:
>
>
>
> Ssl.SSLError: [Errno 336265225] _sll.c:337: error:140B0009:SSL
> routines:SSL_CTX_use_PrivateKey_file:PEM lib
>
>
>
> Is PKCS #12 supposed to be supported by openSSL?  I would guess yes; I dug
> around in the source and found that “PEM lib” is the error text for
> ERR_R_PEM_LIB (defined in err_str.c), and I also noticed ERR_R_PKCS12_LIB
in
> there.  This gives me the impression that openSSL is incorrectly trying to
> load the PKCS #12 cert as a PEM cert, and thus the error – which leads me
to
> believe that the wrapper library may not be calling openSSL properly, if
> PKCS #12 certificates should be supported.  (Otherwise, why would openSSL
be
> returning an error related to PEM certs and not PKCS #12 certs?)
>
>
>
> Can anyone tell me whether or not openSSL should be able to work with
> PKCS#12 certs?  Any advice anyone might have is welcome. (Sorry if this is
> vague; this is the first time I dig into the openSSL project.)
>
>
>
> The certificate appears correct, as I’ve tested it by adding it to MSIE
and
> Firefox and I’m able to connect to the server.
>
>
>
> Regards,
>
> Remi.
>
>
>
>
>

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@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: 1.0.0 EVP_PKEY_assign_RSA() segfault

[Dr. Stephen Henson]

On Mon, Apr 12, 2010, Kenneth Goldman wrote:

> 
> I have some fairly basic code that is now segfaulting reliably with 1.0.0.
> It has worked for years with all 0.9.8 releases.
> 
> 1 - Did something change that I should know about?  Before I compile
> openssl for debug and step through it, is there something I should look
> for?
> 
> 2 - The meta-question:  Is there an 0.9.8 -> 1.0.0 porting guide.  I'm
> debugging, but it looks like a long chore.
> 
>   RSA *rsa;
>   EVP_PKEY pkey;
>   ...
>   (software that constructs the RSA key structure)
>   ...
>   OpenSSL_add_all_algorithms();
>   EVP_PKEY_assign_RSA(&pkey, rsa);
> 

Applications shouldn't reference EVP_PKEY structures like that. They should be
pointers allocated with EVP_PKEY_new() and freed with EVP_PKEY_free().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

decript returned https string

[peter23452345]

hi all,
i have another problem. i am currently writing a php script to act as a
client and log in to a https site (not under my control). i originally
started writing the script with php curl, however i came accross a bug in
php curl which prevents me from getting to a certiain page when attempting
to send a large post string (see here for the bug description:
http://curl.haxx.se/mail/lib-2003-12/0294.html) so anyway i have decided to
switch to using php sockets - i know it really is re-inventing the wheel but
i need to keep my scripts in php and there arent many other options
available.

so far with my socket script i connect fine to the remote server and it
returns an encrypted response. my question is - how can i decript the
response text? the certificate information for the site (as obtained with
openssl s_client -connect host:443) is:

CONNECTED(0003)
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0
s:/1.3.6.1.4.1.311.60.2.1.3=AU/1.3.6.1.4.1.311.60.2.1.2=./1.3.6.1.4.1.311.60.2.1.1=./2.5.4.15=V1.0,
Clause 5.(b)/serialNumber=000 032 128/C=AU/postalCode=2000/ST=New South
Wales/L=Sydney/streetAddress=L24, 2 Market Street/O=Caltex Australia
Petroleum Pty Ltd/OU=Marketing/CN=partner.caltex.com.au
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation
SSL SGC CA
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation
SSL SGC CA
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
---
Server certificate
-BEGIN CERTIFICATE-
MIIGhDCCBWygAwIBAgIQX5s93gJYvsugIfWWMZYIODANBgkqhkiG9w0BAQUFADCB
vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
[i deleted a chunk to save space here].
s8sKB67BrjHEPlxxnUwxWquHD7fouRIDR07l+iiX6dYKFRPa1m4rAaift9E9LxRE
3tIcvP1+bXOfb3baY/Ig//ZR+S91wnVr3KEWQKLxIfQ/TVvK+qFd5x2+NWcfi3Ag
CojbYNh1M8IbKTMGvLJZ8PnpVmhlQQoe8piCHsV7aNKKyZEZ4cMGSg==
-END CERTIFICATE-
subject=/1.3.6.1.4.1.311.60.2.1.3=AU/1.3.6.1.4.1.311.60.2.1.2=./1.3.6.1.4.1.311.60.2.1.1=./2.5.4.15=V1.0,
Clause 5.(b)/serialNumber=000 032 128/C=AU/postalCode=2000/ST=New South
Wales/L=Sydney/streetAddress=L24, 2 Market Street/O=Caltex Australia
Petroleum Pty Ltd/OU=Marketing/CN=partner.caltex.com.au
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation
SSL SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 4687 bytes and written 428 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-MD5
Session-ID:
A802165D870DAD6C9BB67C3B3BE5F38606B2CEF3ABCF4F9F8A6ECA0D3E8C
Session-ID-ctx:
Master-Key:
8B32C9515EDD084815E8250910177DBC8FE41BE5825E42AD9D3C4C14ED22F74BB7DCB99FEDDFCA3164D3E3A762975F83
Key-Arg   : None
Start Time: 1271143626
Timeout   : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---

if someone else has already asked this please feel free to direct me to
their question with solution. thanks for your help!
-- 
View this message in context: 
http://old.nabble.com/decript-returned-https-string-tp28219431p28219431.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

1.0.0 EVP_PKEY_assign_RSA() segfault

[Kenneth Goldman]

I have some fairly basic code that is now segfaulting reliably with 1.0.0.
It has worked for years with all 0.9.8 releases.

1 - Did something change that I should know about?  Before I compile
openssl for debug and step through it, is there something I should look
for?

2 - The meta-question:  Is there an 0.9.8 -> 1.0.0 porting guide.  I'm
debugging, but it looks like a long chore.

RSA *rsa;
EVP_PKEY pkey;
...
(software that constructs the RSA key structure)
...
OpenSSL_add_all_algorithms();
EVP_PKEY_assign_RSA(&pkey, rsa);

--
Ken Goldman   kg...@watson.ibm.com
914-784-7646 (863-7646)

Re: openSSL and PKCS #12 certificates

[Mounir IDRASSI]

Hi,

OPENSSL supports PKCS#12 files. Look at the header pkcs12.h that 
contains functions for parsing and exporting private keys and 
certificates from a PKCS#12 file (like d2i_PKCS12 and PKCS12_parse).


Concerning the error you are getting, it appears that the phython module 
you are using is calling SSL_CTX_use_PrivateKey_file by giving it the 
PKCS#12 file name. This is does not because SSL_CTX_use_PrivateKey_file 
only accepts two formats : SSL_FILETYPE_PEM and SSL_FILETYPE_ASN1.

In order to correct this, you have two solutions :
- Either feed the python module with the private key in a PEM file.
- Or modify the source code of this python module in order to use the 
PKCS#12 functions I mentioned above to extract the private key as an 
EVP_PKEY and then call SSL_use_PrivateKey instead of 
SSL_CTX_use_PrivateKey_file, along with SSL_use_certificate for setting 
the associated certificate.


The first solution is the easiest because you can simply use the OPENSSL 
command line utility in order to extract the private key and its 
certificate from the PKCS#12 file as PEM files and then give them as 
input to your python module.


I hope this will help.
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr


On 4/13/2010 2:55 PM, Rémi Després-Smyth wrote:

Hello.

I’ve been trying to setup client authentication using a PKCS #12
certificate, and I’ve been having some trouble.  I’m trying to determine
whether its because its something unsupported in openSSL, or if it’s a
problem with the wrapper library I’m using (Python’s httplib).  I’d
appreciate it if anyone might be able to provide some insight.



I’m getting an error raised by the openSSL library when the wrapper class is
trying to instantiate and wrap a socket, and from what I’ve been able to
gather to-date, the error appears to be coming from openSSL:



Ssl.SSLError: [Errno 336265225] _sll.c:337: error:140B0009:SSL
routines:SSL_CTX_use_PrivateKey_file:PEM lib



Is PKCS #12 supposed to be supported by openSSL?  I would guess yes; I dug
around in the source and found that “PEM lib” is the error text for
ERR_R_PEM_LIB (defined in err_str.c), and I also noticed ERR_R_PKCS12_LIB in
there.  This gives me the impression that openSSL is incorrectly trying to
load the PKCS #12 cert as a PEM cert, and thus the error – which leads me to
believe that the wrapper library may not be calling openSSL properly, if
PKCS #12 certificates should be supported.  (Otherwise, why would openSSL be
returning an error related to PEM certs and not PKCS #12 certs?)



Can anyone tell me whether or not openSSL should be able to work with
PKCS#12 certs?  Any advice anyone might have is welcome. (Sorry if this is
vague; this is the first time I dig into the openSSL project.)



The certificate appears correct, as I’ve tested it by adding it to MSIE and
Firefox and I’m able to connect to the server.



Regards,

Remi.




   


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

openSSL and PKCS #12 certificates

[Rémi Després-Smyth]

Hello.

I’ve been trying to setup client authentication using a PKCS #12
certificate, and I’ve been having some trouble.  I’m trying to determine
whether its because its something unsupported in openSSL, or if it’s a
problem with the wrapper library I’m using (Python’s httplib).  I’d
appreciate it if anyone might be able to provide some insight.

 

I’m getting an error raised by the openSSL library when the wrapper class is
trying to instantiate and wrap a socket, and from what I’ve been able to
gather to-date, the error appears to be coming from openSSL:

 

Ssl.SSLError: [Errno 336265225] _sll.c:337: error:140B0009:SSL
routines:SSL_CTX_use_PrivateKey_file:PEM lib

 

Is PKCS #12 supposed to be supported by openSSL?  I would guess yes; I dug
around in the source and found that “PEM lib” is the error text for
ERR_R_PEM_LIB (defined in err_str.c), and I also noticed ERR_R_PKCS12_LIB in
there.  This gives me the impression that openSSL is incorrectly trying to
load the PKCS #12 cert as a PEM cert, and thus the error – which leads me to
believe that the wrapper library may not be calling openSSL properly, if
PKCS #12 certificates should be supported.  (Otherwise, why would openSSL be
returning an error related to PEM certs and not PKCS #12 certs?)

 

Can anyone tell me whether or not openSSL should be able to work with
PKCS#12 certs?  Any advice anyone might have is welcome. (Sorry if this is
vague; this is the first time I dig into the openSSL project.)

 

The certificate appears correct, as I’ve tested it by adding it to MSIE and
Firefox and I’m able to connect to the server.

 

Regards,

Remi.

 

Re: error: ASN1_mbstring_copy:string too long:a_mbstr.c:154:maxsize=2 _only_ when using config file and prompt off

[Christian Hohnstaedt]

Hi,

On Tue, Apr 13, 2010 at 12:13:49AM -0700, Alex Lam wrote:
> Hi all,
> 
> For some strange reasons, when I disable prompt in the cnf file, I run into
> the  "error: ASN1_mbstring_copy:string too
> long:a_mbstr.c:154:maxsize=2" error.
> Digging around on the net showed that my counter code is longer that 2
> characters, which is not true. The following is my country name.
> 
> [ req_distinguished_name ]
> countryName = Country Name (2 letter code)
> countryName_default = US
> countryName_min= 2
> countryName_max= 2
> 
> However, if I enable prompt, and just hit ENTER for the same default value,
> everything went fine.
> 
> any idea what is going wrong here?

Try:
countryName_value   = US


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

error: ASN1_mbstring_copy:string too long:a_mbstr.c:154:maxsize=2 _only_ when using config file and prompt off

[Alex Lam]

Hi all,

For some strange reasons, when I disable prompt in the cnf file, I run into
the  "error: ASN1_mbstring_copy:string too
long:a_mbstr.c:154:maxsize=2" error.
Digging around on the net showed that my counter code is longer that 2
characters, which is not true. The following is my country name.

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
countryName_min= 2
countryName_max= 2

However, if I enable prompt, and just hit ENTER for the same default value,
everything went fine.

any idea what is going wrong here?

thanks,
alex.