how to use diffrent certificate chain for every client in my SSL server (API)
Hi all, I am using server certificate "X" problematically with following API for each SSL * session. X is dynamically generated for each client, when its CA(s) as always same. SSL_use_certificate(this_ssl, X); It works fine when there is single CA certificate "A" who sign "X", but when I want to use intermediate CA "B" child of "A", then I am sure above API wont work. To make it work I found following APIs from documentation. 1) int SSL_CTX_use_certificate_chain_file(SSL_CTX *ctx, const char *file); 2) long SSL_CTX_add_extra_chain_cert(SSL_CTX ctx, X509 *x509) 3) int SSL_use_certificate_file(SSL *ssl, const char *file, int type); But seems 1 & 2 both works only on SSL_CTX *while I need API that work on SSL * , I want to give different certificate chain for each client. And 3 wont be applicable for me as I am loading certificates from memory and not from the file. Have anybody any idea how to load several certificates to SSL *ssl, to form complete Chain (note: I have my all CA certificates "A" and "B" in memory). Thanks, Saurabh __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to find correct issuer certificate in multi-level hierarchy?
Thank you Jacob and Stephen.
That brings one more question which was posted by Klaus sometime back:
"Hi!
I wrote a small program which dumps all root certificates from Windows
certificate store into a file. Then I use openssl to connect to Google and
validate its certificate:
openssl s_client -connect www.google.com:443 -CAfile dump.crt
When using openssl0.9.8k or openssl0.9.8x everything works as expected.
When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails
with:
Verify return code: 10 (certificate has expired)
CONNECTED(016C)
depth=2 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary
Certification Authority
verify error:num=10:certificate has expired
notAfter=Jan 7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
When analyzing the cafile with the dumped certificates from Windows
certificate store, I found out that there are two certificates for Verisign
with identical subject, whereas one is expired, the other not.
X.509 Certificate Information:
Version: 1
Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Wed Jan 07 23:59:59 UTC 2004
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA
X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA
Thus, it seems that openssl 0.9.8 just ignores the expired certificate and
searches if there is another valid one whereas openssl 1.0.0 stop with the
first expired certificate.
Is the new behavior the intended behavior? Is it possible to have the old
behavior also in new opensslversions?
Thanks
Klaus"
Is this behaviour intended in openssl-1.0.0 ?
--
Ashok
On Fri, Aug 3, 2012 at 3:28 AM, Dr. Stephen Henson wrote:
> On Thu, Aug 02, 2012, Ashok C wrote:
>
> > Hi,
> >
> > Is there a way in which I can determine the correct issuer certificate of
> > an issued certificate(either intermediate CA or end entity) based on
> > comparing immediate pair alone.
> > Eg:
> > My hierarchy is like this:
> >
> > Root
> > Intermediate CA 1
> > Intermediate CA 2
> > End entity
> >
> > Is it possible to determine that Intermediate CA2 is the issuer of the
> End
> > entity certificate without having to traverse the full hierarchy?
> >
> > I do not want to depend upon issuername-subjectname comparisons alone(As
> > this is not deterministic and conclusive).
> > I do not want to depend upon Authority Key Identifier /Subject Key
> > Identifier's keyId fields(As most CAs seem to not have this extension at
> > all)
> >
> > Basically I want some signature check method from openSSL can take two
> > certificates as input and tell me if one has issued the other:
> >
> > int openSSL_signature_check(X509* issuer_certificate, X509*
> > issued_certificate)
> > {
> > int return_code = signature_check(issuer_certificate,
> > issued_certificate)
> > if (0 == return_code)
> > return YES_ISSUER_IS_CORRECT;
> >else
> > return NO_ISSUER_IS_NOT_CORRECT;
> > }
> >
> > Is something like this already available in openSSL?
> >
>
> You can use the function X509_verify to do this but you have to extract the
> public key from the issuer using X509_get_pubkey.
>
> > One more question:
> > Given a certificate and trust store, openSSL's verify utility currently
> > returns OK in case the verification was successful. Is there a way in
> which
> > I can retrieve the formed and verified chain of certificates back?
> >
>
> There isn't a command line option to do this but the API call
> X509_STORE_CTX_get1_chain will retrieve the chain from an X509_STORE_CTX
> structure.
>
> 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
>
RE: TLS server/client with self-signed certificate
>From: owner-openssl-us...@openssl.org On Behalf Of Harald Latzko >Sent: Thursday, 02 August, 2012 03:03 > self-signed certificate as attached to this mail (can be retrieved >from the TLS server 87.236.105.37:6619). My TLS client uses the >following options: >SSL_CTX_load_verify_locations(ctx, NULL, tls_root_certpath) Aside: it's a good thing you gave the server, because Outlook (which we use) blocks *.cer. I wish it didn't, but it does. > The server certificate is trusted in a directory where trusted certificates >reside. In my application, a connect try ends with the following error: Is the server cert in the directory named by tls_root_certpath *with a hashlink (or hashname)*? For the correct major version of OpenSSL? (hashes for 1.0.0+ are different from 0.9.8) >certificate verify error 20: unable to get local issuer certificate: >My opinion is that the self-signed certificate has the X509v3 basic constraint >CA flag set to "false": >A connect via "openssl s_client" also fails with You show only the last part (resulting SSL-Session). I got as the first thing (except DN trimmed for posting): CONNECTED(0003) depth=0 emailAddress = deiningermichae...@johndeere.com, ... verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 emailAddress = deiningermichae...@johndeere.com, ... verify error:num=21:unable to verify the first certificate verify return:1 Note that you get error=20 first, and only after s_client overrides (which your app presumably doesn't) then you get error=21. Error=20 means it didn't find the cert in the truststore. As above, check it is in the directory with the correct hash. Errors in cert attributes (like BC) give other error codes. >Is my assumption correct that the "CA"-flag must be set to "true" >in order to work as a self-signed server certificate? I don't want >to change my verify_callback function just in order to get it work >(which could be easy). Conformity should be the first goal. No. CA:true, and (usually) KeyUsage:certSign, are required IF a cert (often, but not necessarily, selfsigned) is used to issue *other* (child) certs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ECDSA testing with s_client/s_server
> From: owner-openssl-us...@openssl.org On Behalf Of Erik Tkal > Sent: Wednesday, 01 August, 2012 16:33 > I'm playing around to see if I can observe client and server > under various conditions when negotiating TLS 1.2 with newer > certs. I created a root and server cert as ecdsa-with-SHA256. > > openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key > eserver1.key -debug > > openssl s_client -CAfile eroot1.pem -debug > Aside: s_server doesn't need CAfile if you don't do client-auth. > However, the server issues a handshake alert and says no > shared cipher. I see the client is sending a large set of > suites but apparently none that the server wants. How do I > do this properly? Only thing I can see that would fail silently is if your key doesn't use a named curve. In general OpenSSL server will skip ECC suites if the (certified) key is in a format not offered by the client in SupportedFormats, but s_client (at least) offers all defined formats; or using a curve not offered by the client in SupportedCurves, and s_client offers all named curves but not ad-hoc ones. Also it will skip EECDH suites if your temp ECDH key uses a curve not offered by the client, but s_server always does temp named curves (NIST/X962 P256 by default). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: command line hmac with key in hex
Hi, >You can achieve this using the generalised MAC interface to HMAC like this: > >openssl dgst -sha1 -mac HMAC -macopt hexkey:aabbcc I'm ashamed of my mail. Thank you for your advice. Yours, Shigeo __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: command line hmac with key in hex
On Thu, Aug 02, 2012, MITSUNARI Shigeo wrote: > Hi, > I tried to use openssl command to generate an HMAC with a key > contains '\0', but failed. > > >openssl dgst -sha1 -hmac `cat ` > > I'm happy if dgst command supports binary format like enc command. > So I appended -hmachex option as the followings: > > >openssl dgst -sha1 -hmachex aabbcc0011223344 > How about this patch? > You can achieve this using the generalised MAC interface to HMAC like this: openssl dgst -sha1 -mac HMAC -macopt hexkey:aabbcc 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
Re: How to find correct issuer certificate in multi-level hierarchy?
On Thu, Aug 02, 2012, Ashok C wrote:
> Hi,
>
> Is there a way in which I can determine the correct issuer certificate of
> an issued certificate(either intermediate CA or end entity) based on
> comparing immediate pair alone.
> Eg:
> My hierarchy is like this:
>
> Root
> Intermediate CA 1
> Intermediate CA 2
> End entity
>
> Is it possible to determine that Intermediate CA2 is the issuer of the End
> entity certificate without having to traverse the full hierarchy?
>
> I do not want to depend upon issuername-subjectname comparisons alone(As
> this is not deterministic and conclusive).
> I do not want to depend upon Authority Key Identifier /Subject Key
> Identifier's keyId fields(As most CAs seem to not have this extension at
> all)
>
> Basically I want some signature check method from openSSL can take two
> certificates as input and tell me if one has issued the other:
>
> int openSSL_signature_check(X509* issuer_certificate, X509*
> issued_certificate)
> {
> int return_code = signature_check(issuer_certificate,
> issued_certificate)
> if (0 == return_code)
> return YES_ISSUER_IS_CORRECT;
>else
> return NO_ISSUER_IS_NOT_CORRECT;
> }
>
> Is something like this already available in openSSL?
>
You can use the function X509_verify to do this but you have to extract the
public key from the issuer using X509_get_pubkey.
> One more question:
> Given a certificate and trust store, openSSL's verify utility currently
> returns OK in case the verification was successful. Is there a way in which
> I can retrieve the formed and verified chain of certificates back?
>
There isn't a command line option to do this but the API call
X509_STORE_CTX_get1_chain will retrieve the chain from an X509_STORE_CTX
structure.
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
Re: How to find correct issuer certificate in multi-level hierarchy?
On 8/2/2012 10:04 AM, Ashok C wrote:
Hi,
Is there a way in which I can determine the correct issuer certificate
of an issued certificate(either intermediate CA or end entity) based
on comparing immediate pair alone.
Eg:
My hierarchy is like this:
Root
Intermediate CA 1
Intermediate CA 2
End entity
Is it possible to determine that Intermediate CA2 is the issuer of the
End entity certificate without having to traverse the full hierarchy?
I do not want to depend upon issuername-subjectname comparisons
alone(As this is not deterministic and conclusive).
I do not want to depend upon Authority Key Identifier /Subject Key
Identifier's keyId fields(As most CAs seem to not have this extension
at all)
Those two are the standard ways though (specifically, doing both if
Authority Key Identifier is present).
Basically I want some signature check method from openSSL can take two
certificates as input and tell me if one has issued the other:
int openSSL_signature_check(X509* issuer_certificate, X509*
issued_certificate)
{
int return_code = signature_check(issuer_certificate,
issued_certificate)
if (0 == return_code)
return YES_ISSUER_IS_CORRECT;
else
return NO_ISSUER_IS_NOT_CORRECT;
}
In other words you are looking for a function to verify a certificate
given exactly one possible issuer.
Is something like this already available in openSSL?
I guess it at least exists as an internal function called from the
verify code, so look at the source code for that and see if you find a
call to a function that does what you want.
Alternatively, you could set up a "certificate collection" object in
memory containing only the suspected issuer certificate and then pass
that as the trusted certificate collection to the certificate verify
function.
One more question:
Given a certificate and trust store, openSSL's verify utility
currently returns OK in case the verification was successful. Is there
a way in which I can retrieve the formed and verified chain of
certificates back?
I sure hope so, as it is very useful on the client side to decide which
certificates to provide to the other end.
--
Ashok
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
How to find correct issuer certificate in multi-level hierarchy?
Hi,
Is there a way in which I can determine the correct issuer certificate of
an issued certificate(either intermediate CA or end entity) based on
comparing immediate pair alone.
Eg:
My hierarchy is like this:
Root
Intermediate CA 1
Intermediate CA 2
End entity
Is it possible to determine that Intermediate CA2 is the issuer of the End
entity certificate without having to traverse the full hierarchy?
I do not want to depend upon issuername-subjectname comparisons alone(As
this is not deterministic and conclusive).
I do not want to depend upon Authority Key Identifier /Subject Key
Identifier's keyId fields(As most CAs seem to not have this extension at
all)
Basically I want some signature check method from openSSL can take two
certificates as input and tell me if one has issued the other:
int openSSL_signature_check(X509* issuer_certificate, X509*
issued_certificate)
{
int return_code = signature_check(issuer_certificate,
issued_certificate)
if (0 == return_code)
return YES_ISSUER_IS_CORRECT;
else
return NO_ISSUER_IS_NOT_CORRECT;
}
Is something like this already available in openSSL?
One more question:
Given a certificate and trust store, openSSL's verify utility currently
returns OK in case the verification was successful. Is there a way in which
I can retrieve the formed and verified chain of certificates back?
--
Ashok
TLS server/client with self-signed certificate
Hell,I've got a question regarding self-signed X509v3 certificates used in a TLS1.0 server/client environment. A communication partner uses a self-signed certificate as attached to this mail (can be retrieved from the TLS server 87.236.105.37:6619). My TLS client uses the following options: SSL_CTX_load_verify_locations(ctx, NULL, tls_root_certpath) SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, verify_callback); SSL_CTX_set_verify_depth(ctx, 9); SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TICKET );The server certificate is trusted in a directory where trusted certificates reside. In my application, a connect try ends with the following error:certificate verify error 20: unable to get local issuer certificate: depth=0, subject: /emailAddress=deiningermichae...@johndeere.com/CN=jd_edi_gw.deere.com/OU=EDI/O=John Deere/L=Mannheim/ST=BW/C=DE, issuer: /emailAddress=deiningermichae...@johndeere.com/CN=jd_edi_gw.deere.com/OU=EDI/O=John Deere/L=Mannheim/ST=BW/C=DEMy opinion is that the self-signed certificate has the X509v3 basic constraint CA flag set to "false": (openssl x509 -in John_Deere_OFTP2_Prod_3.cer -noout -text) X509v3 Basic Constraints: critical CA:FALSEA connect via "openssl s_client" also fails with this message:openssl s_client -connect 87.236.105.37:6619 -tls1 -msg -debug -verify 9 -CApath /tmp/rootcerts/SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 501A2574C23B04543CC2CEAE6B930BB34B9A7A7A752213E32469399F77690FC8 Session-ID-ctx: Master-Key: 72CE5564EC8B591BE7E7B9156610379E73177615F26FCDEE0B58D81AB3C301DED5B0B4AF7881489E9E4D4D654554B72C Key-Arg : None Start Time: 1343890805 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate)---Is my assumption correct that the "CA"-flag must be set to "true" in order to work as a self-signed server certificate? I don't want to change my verify_callback function just in order to get it work (which could be easy). Conformity should be the first goal.Regards,Harald John_Deere_OFTP2_Prod_3.cer Description: application/x509-ca-cert
