Re: Client certificate chains

2011-03-21 Thread plot.lost 

On 22/03/2011 09:24, Crypto Sal wrote:
Me thinks they don't understand Client Authentication/Digital 
Certificates. The server doesn't typically need to verify up to the 
root, they provide a list of acceptable client CA names during the 
handshake.


I'm using a CAfile that has all of the certificates in - as far as I 
am aware that makes openssl trust these certificates.




Do you have them in reverse hierarchy when using '-CAfile' 
?(Intermediate(s) to Root) I have seem some systems/programs flip out 
because certificates were out of order.



Yes, they are in the usual order, with root as the final cert.


My thoughts...

When you connect using 's_client' do you use something similar to the 
following?


`openssl s_client -connect FQDN:PORT -cert CERT_FILE -key KEY_FILE 
-CAfile yourCAfile`


Have you tried just to connect to the site without the '-cert', '-key' 
and/or '-CAfile' and see if any useful information is presented by the 
server or does the connection fail outright?


Without the -CAfile then the connection to the server fails at the 
server certificate stage (self-signed cert). With the CAfile but without 
cert/key then the connection fails at the same point as if the cert/key 
had been provided.




Based on the error of 'SSL alert number 80', that you have provided 
previously, I suspect the problem is with your certificate's (client 
cert) issuing CA being unknown to the server (one that it doesn't 
directly trust and you need an appropriate hierarchy)


Those running the server are the ones that signed the client certificate 
and provided the CA and Root certificates that are in use.


== Info: SSLv3, TLS handshake, Server finished (14):
<= Recv SSL data, 4 bytes (0x4)
: 0e 00 00 00 
== Info: SSLv3, TLS handshake, Client key exchange (16):
=> Send SSL data, 102 bytes (0x66)
: 10 00 00 62 00 60 45 1d e4 bd 03 4e bb 10 f1 04 ...b.`EN
0010: 72 4f 1f 2d 0e ea 7d d4 37 ee 4b a0 3f 27 33 26 rO.-..}.7.K.?'3&
0020: 33 10 06 82 4b 66 c0 ca aa 14 68 6a f8 00 0d 89 3...Kfhj
0030: 17 92 4e ed 84 eb 82 52 e8 59 39 fe 81 4b 7c 10 ..NR.Y9..K|.
0040: e7 db 6e 54 2c 4e de 34 ff 8f 11 8e 5d 3e 5d e3 ..nT,N.4]>].
0050: 41 09 b4 06 36 78 cd 4b 33 c2 ce e4 06 a4 19 97 A...6x.K3...
0060: 5d bf 88 69 02 c8   ]..i..
== Info: SSLv3, TLS change cipher, Client hello (1):
=> Send SSL data, 1 bytes (0x1)
: 01  .
== Info: SSLv3, TLS handshake, Finished (20):
=> Send SSL data, 16 bytes (0x10)
: 14 00 00 0c 94 4e 6d 82 d8 f2 8b a0 0f 30 61 b3 .Nm..0a.
== Info: SSLv3, TLS alert, Server hello (2):
<= Recv SSL data, 2 bytes (0x2)
: 02 50   .P
== Info: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert 
internal error

== Info: Closing connection #0

I don't think they list any specific ca as part of the client cert 
requests, I think they rely on the client providing a full certificate 
chain and they then validate that using some other method. It seems that 
for some reason openssl is not sending any certificate to them.


This seems to be something specific to TLS1.1 - see:

http://lists.foaf-project.org/pipermail/foaf-protocols/2009-February/000264.html

Is this behaviour that is not supported by openssl, or am I going down 
the wrong track (again...)




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

Re: callbacks: application context

2011-03-21 Thread Victor Duchovni 
On Mon, Mar 21, 2011 at 08:49:09PM -0700, Claus Assmann wrote:

> On Mon, Mar 21, 2011, Victor Duchovni wrote:
> 
> > Can you explain a bit more clearly why you can't initialize an
> > integer index or two when the application starts?
> 
> I can, but that's not the problem.  Here's an example:
> initialize:
> SSL_load_error_strings(); ...
> ssl_ctx = SSL_CTX_new();
> myidx = SSL_CTX_get_ex_new_index();
> 
> set up and start two client instances:
> a_ctx1->a_ssl_ctx = ssl_ctx;
> a_ctx2->a_ssl_ctx = ssl_ctx;
> client(a_ctx1);
> client(a_ctx2);
> (as threads so they run concurrently)
> 
> client() has some code like this:
>   SSL_CTX_set_ex_data(a_ctx->a_ssl_ctx, myidx, a_ctx->cb_arg);

No, don't do that, the SSL_CTX application context object is global.
Why do you want to tweak it the context of an individual connection.

You should be modifying the SSL object, not the SSL_CTX object. Postfix
has:

SSL_set_ex_data(TLScontext->con, TLScontext_index, TLScontext)

> which means the "last call wins" to actually sets the application
> context for SSL_CTX, right?

Yes, but what are you trying to do? The SSL_CTX is clearly shared
application state, not per-session state.

> However, the API works ok if:
> - different SSL_CTXs are used
> - callbacks are only set for SSL which are different for each
>   client() invocation anyway.
> 
> This means for the common use case the method should work properly.

So, what's the problem?

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

Re: Client certificate chains

2011-03-21 Thread Crypto Sal 

On 03/22/2011 12:09 AM, plot.lost wrote:



Or do you simply mean you looked manually at the x509 output
(probably -text) and it looks correct to you?


Yes, using -text to manually check the chain.


Have you confirmed this alert is in response to your cert?
You can use s_client with -debug, or run a network monitor
(I recommend www.wireshark.org on Windows) to see.
And are the server people actually looking at the error
they got on your attempt(s), or just guessing?
I think they are just using a pre-set response to any questions 
regarding connectivity problems, it's that same basic response that 
comes back each time.

Verifying you-the-client is indeed the job of the server.
And if doesn't verify you, then it would better give a
more specific alert, like 'unknown CA' or 'invalid cert',
not 'internal error'. Do you know what kind of software
the server is running -- at the protocol level especially,
e.g. if it is 'Apache plus our-bus-app' you probably only
care about 'Apache', maybe 'Apache mod_ssl version N'.


Somehow I don't think I would get a meaningful answer to this question...


There are three common problems in this area but none
quite matches what you relay the server people said.

1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs
(client and/or server, and/or other kinds) directly under a root,
but most have a multi-level hierarchy: root signs level2, level2
signs user; or level2 signs level3 and level3 signs user, etc.
Each SSL system, such as this server, is configured with a set
of CA-certs it knows (and trusts), but that set may not go all
the way down. If that is the case, your client must supply the
remaining 'intermediate' cert(s) during handshake.

If you have the complete chain for your cert, or you get
it from the CA(s), you could try showing it (probably Issuer,
Serial, Subject, SubjectKeyID if any, AltName extensions if any,
and CRLDistPoint or AuthorityInfoAccess extensions if any)
to the server people and ask them to identify which cert(s)
they don't already know (if any). Then give that/those to
SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file.
Or at worst supply everything; the server should ignore
any it doesn't need, and it just takes a tiny bit longer.
However, the server must already trust the root, at least;
even if you supply the root, they can't trust that. See 3.

2. Ambiguous CA(s). A CA can have multiple (issuing) certs
for the same name. In this case a verifier, like this server,
needs to know which issuing cert (and hence key) to use.
The standard way of doing this is an extension AuthorityKeyID
abbreviated AKID in the user cert. If this is needed the CA
should have done it, and if the CA didn't you can't fix it.
x509 -text will show whether it is there, and if so help you
build (or verify) the chain as above.

3. Wrong CA. Possibly the server simply doesn't trust the CA
you used, although when you say 'required authority'
I assume you mean required *by the server people*.
s_client or monitor as above will show if the server is
specifying 'preferred' CA(s) in its CertRequest message.
If it is, and your cert is not under that or one of them
(possibly though intermediates as above), that may be
the problem. But note that OpenSSL for one configures
the 'preferred' CA(s) separately from the "trusted" CA(s),
so a mismatch with this field isn't definitive.


I've tried generating a pkcs12 file that contained the client 
certificate, ca, root and client key and sent this to them. They have 
confirmed that it is valid.


I hope you 'sent' it to them in a secure fashion or else at least 
consider that key/cert pair 'compromised'. ;)


The last response had "it seems that our server could not trust the 
certificate and failed to open the output stream at your end to pass 
the data" which does not make any sense to me. Again they say "import 
all of the certificates to your certificate trust store"


Me thinks they don't understand Client Authentication/Digital 
Certificates. The server doesn't typically need to verify up to the 
root, they provide a list of acceptable client CA names during the 
handshake.


I'm using a CAfile that has all of the certificates in - as far as I 
am aware that makes openssl trust these certificates.




Do you have them in reverse hierarchy when using '-CAfile' 
?(Intermediate(s) to Root) I have seem some systems/programs flip out 
because certificates were out of order.


For the cert option I've tried PEM encoded files that have just the 
client cert in, one that has client and ca, and one with client, ca 
and root.
I've also tried these by converting the pkcs12 back to pem, which 
added some extra bits before each certificate section, none of these 
have made any difference.


Can the pkcs12 file be used directly by s_client - the docs I have 
show that only PEM and DER are supported? Does it support having this 
chain of certificates in the client cert file?


As far as I am aware PKCS12 files can not be u

Re: Client certificate chains

2011-03-21 Thread plot.lost 

On 22/03/2011 08:09, plot.lost wrote:



Or do you simply mean you looked manually at the x509 output
(probably -text) and it looks correct to you?


Yes, using -text to manually check the chain.


Have you confirmed this alert is in response to your cert?
You can use s_client with -debug, or run a network monitor
(I recommend www.wireshark.org on Windows) to see.
And are the server people actually looking at the error
they got on your attempt(s), or just guessing?
I think they are just using a pre-set response to any questions 
regarding connectivity problems, it's that same basic response that 
comes back each time.

Verifying you-the-client is indeed the job of the server.
And if doesn't verify you, then it would better give a
more specific alert, like 'unknown CA' or 'invalid cert',
not 'internal error'. Do you know what kind of software
the server is running -- at the protocol level especially,
e.g. if it is 'Apache plus our-bus-app' you probably only
care about 'Apache', maybe 'Apache mod_ssl version N'.


Somehow I don't think I would get a meaningful answer to this question...


There are three common problems in this area but none
quite matches what you relay the server people said.

1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs
(client and/or server, and/or other kinds) directly under a root,
but most have a multi-level hierarchy: root signs level2, level2
signs user; or level2 signs level3 and level3 signs user, etc.
Each SSL system, such as this server, is configured with a set
of CA-certs it knows (and trusts), but that set may not go all
the way down. If that is the case, your client must supply the
remaining 'intermediate' cert(s) during handshake.

If you have the complete chain for your cert, or you get
it from the CA(s), you could try showing it (probably Issuer,
Serial, Subject, SubjectKeyID if any, AltName extensions if any,
and CRLDistPoint or AuthorityInfoAccess extensions if any)
to the server people and ask them to identify which cert(s)
they don't already know (if any). Then give that/those to
SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file.
Or at worst supply everything; the server should ignore
any it doesn't need, and it just takes a tiny bit longer.
However, the server must already trust the root, at least;
even if you supply the root, they can't trust that. See 3.

2. Ambiguous CA(s). A CA can have multiple (issuing) certs
for the same name. In this case a verifier, like this server,
needs to know which issuing cert (and hence key) to use.
The standard way of doing this is an extension AuthorityKeyID
abbreviated AKID in the user cert. If this is needed the CA
should have done it, and if the CA didn't you can't fix it.
x509 -text will show whether it is there, and if so help you
build (or verify) the chain as above.

3. Wrong CA. Possibly the server simply doesn't trust the CA
you used, although when you say 'required authority'
I assume you mean required *by the server people*.
s_client or monitor as above will show if the server is
specifying 'preferred' CA(s) in its CertRequest message.
If it is, and your cert is not under that or one of them
(possibly though intermediates as above), that may be
the problem. But note that OpenSSL for one configures
the 'preferred' CA(s) separately from the "trusted" CA(s),
so a mismatch with this field isn't definitive.


I've tried generating a pkcs12 file that contained the client 
certificate, ca, root and client key and sent this to them. They have 
confirmed that it is valid.


The last response had "it seems that our server could not trust the 
certificate and failed to open the output stream at your end to pass 
the data" which does not make any sense to me. Again they say "import 
all of the certificates to your certificate trust store"


I'm using a CAfile that has all of the certificates in - as far as I 
am aware that makes openssl trust these certificates.


For the cert option I've tried PEM encoded files that have just the 
client cert in, one that has client and ca, and one with client, ca 
and root.
I've also tried these by converting the pkcs12 back to pem, which 
added some extra bits before each certificate section, none of these 
have made any difference.


Can the pkcs12 file be used directly by s_client - the docs I have 
show that only PEM and DER are supported? Does it support having this 
chain of certificates in the client cert file?





Below is the output when trying to connect - I've had to obscure the 
certificate details from the server but that stage verifies ok, and is 
using the same CA/Root as the client cert is using.


CONNECTED(0003)
write to 0x983a0f8 [0x983f918] (121 bytes => 121 (0x79))
 - 80 77 01 03 01 00 4e 00-00 00 20 00 00 39 00 00   .wN... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0   8..5
0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00   ..3..2../...
0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00

Re: Client certificate chains

2011-03-21 Thread plot.lost 



Or do you simply mean you looked manually at the x509 output
(probably -text) and it looks correct to you?


Yes, using -text to manually check the chain.


Have you confirmed this alert is in response to your cert?
You can use s_client with -debug, or run a network monitor
(I recommend www.wireshark.org on Windows) to see.
And are the server people actually looking at the error
they got on your attempt(s), or just guessing?
I think they are just using a pre-set response to any questions 
regarding connectivity problems, it's that same basic response that 
comes back each time.

Verifying you-the-client is indeed the job of the server.
And if doesn't verify you, then it would better give a
more specific alert, like 'unknown CA' or 'invalid cert',
not 'internal error'. Do you know what kind of software
the server is running -- at the protocol level especially,
e.g. if it is 'Apache plus our-bus-app' you probably only
care about 'Apache', maybe 'Apache mod_ssl version N'.


Somehow I don't think I would get a meaningful answer to this question...


There are three common problems in this area but none
quite matches what you relay the server people said.

1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs
(client and/or server, and/or other kinds) directly under a root,
but most have a multi-level hierarchy: root signs level2, level2
signs user; or level2 signs level3 and level3 signs user, etc.
Each SSL system, such as this server, is configured with a set
of CA-certs it knows (and trusts), but that set may not go all
the way down. If that is the case, your client must supply the
remaining 'intermediate' cert(s) during handshake.

If you have the complete chain for your cert, or you get
it from the CA(s), you could try showing it (probably Issuer,
Serial, Subject, SubjectKeyID if any, AltName extensions if any,
and CRLDistPoint or AuthorityInfoAccess extensions if any)
to the server people and ask them to identify which cert(s)
they don't already know (if any). Then give that/those to
SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file.
Or at worst supply everything; the server should ignore
any it doesn't need, and it just takes a tiny bit longer.
However, the server must already trust the root, at least;
even if you supply the root, they can't trust that. See 3.

2. Ambiguous CA(s). A CA can have multiple (issuing) certs
for the same name. In this case a verifier, like this server,
needs to know which issuing cert (and hence key) to use.
The standard way of doing this is an extension AuthorityKeyID
abbreviated AKID in the user cert. If this is needed the CA
should have done it, and if the CA didn't you can't fix it.
x509 -text will show whether it is there, and if so help you
build (or verify) the chain as above.

3. Wrong CA. Possibly the server simply doesn't trust the CA
you used, although when you say 'required authority'
I assume you mean required *by the server people*.
s_client or monitor as above will show if the server is
specifying 'preferred' CA(s) in its CertRequest message.
If it is, and your cert is not under that or one of them
(possibly though intermediates as above), that may be
the problem. But note that OpenSSL for one configures
the 'preferred' CA(s) separately from the "trusted" CA(s),
so a mismatch with this field isn't definitive.


I've tried generating a pkcs12 file that contained the client 
certificate, ca, root and client key and sent this to them. They have 
confirmed that it is valid.


The last response had "it seems that our server could not trust the 
certificate and failed to open the output stream at your end to pass the 
data" which does not make any sense to me. Again they say "import all of 
the certificates to your certificate trust store"


I'm using a CAfile that has all of the certificates in - as far as I am 
aware that makes openssl trust these certificates.


For the cert option I've tried PEM encoded files that have just the 
client cert in, one that has client and ca, and one with client, ca and 
root.
I've also tried these by converting the pkcs12 back to pem, which added 
some extra bits before each certificate section, none of these have made 
any difference.


Can the pkcs12 file be used directly by s_client - the docs I have show 
that only PEM and DER are supported? Does it support having this chain 
of certificates in the client cert file?





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

Re: callbacks: application context

2011-03-21 Thread Claus Assmann 
On Mon, Mar 21, 2011, Victor Duchovni wrote:

> Can you explain a bit more clearly why you can't initialize an
> integer index or two when the application starts?

I can, but that's not the problem.  Here's an example:
initialize:
SSL_load_error_strings(); ...
ssl_ctx = SSL_CTX_new();
myidx = SSL_CTX_get_ex_new_index();

set up and start two client instances:
a_ctx1->a_ssl_ctx = ssl_ctx;
a_ctx2->a_ssl_ctx = ssl_ctx;
client(a_ctx1);
client(a_ctx2);
(as threads so they run concurrently)

client() has some code like this:
  SSL_CTX_set_ex_data(a_ctx->a_ssl_ctx, myidx, a_ctx->cb_arg);
which means the "last call wins" to actually sets the application
context for SSL_CTX, right?
Hence doing something like this:
  SSL_CTX_set_info_callback(a_ctx->a_ssl_ctx, clt_cb)
where clt_cb(SSL_CTX *ssl_ctx) retrieves the application context via:
  cb_arg = (cast...) SSL_CTX_get_ex_data(ssl_ctx, myidx);
will get some "random" application context.


However, the API works ok if:
- different SSL_CTXs are used
- callbacks are only set for SSL which are different for each
  client() invocation anyway.

This means for the common use case the method should work properly.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Client certificate chains

2011-03-21 Thread Dave Thompson 
> From: owner-openssl-us...@openssl.org On Behalf Of plot.lost
> Sent: Monday, 21 March, 2011 11:44

> I am having problems connecting to a system that requires a client 
> certificate. Generated the csr using the relevant openssl commands and 
> sent that to the required authority for signing. That has come back as a 
> valid certificate (can use openssl x509 to verify the certificate 

'x509' only checks that a cert is validly encoded (formatted).
It doesn't check that the cert is correctly signed by the issuer,
or if it's revoked, if it's expired only if you specifically ask,
or if it permits this type of usage namely SSL -- although if the CA 
issued it to you as an SSL-client cert, they should get that right.

'verify' does the signature/chaining and purpose checks, revocation 
for plain-old-CRLs(?), and expiration (which shouldn't be a problem 
for newly-issued, but in some cases, especially if someone gets 
a timezone wrong, you might attempt to use a newly-issued cert 
that is BEFORE its validity period, and that's also an error).

Or do you simply mean you looked manually at the x509 output 
(probably -text) and it looks correct to you? 

> content), but using that certificate does not allow the connection to 
> complete (fails with 'error:14094438:SSL 
> routines:SSL3_READ_BYTES:tlsv1 
> alert internal error' )
> 
> According to the people that run the server I am trying to connect to, 
> the problem is that my certificate 'does not have the chaining setup. 
> The Root and CA should be trusted'
> 
That combination doesn't really make sense. Note that 
'root' and 'CA' are different, although related. 

Have you confirmed this alert is in response to your cert?
You can use s_client with -debug, or run a network monitor 
(I recommend www.wireshark.org on Windows) to see.
And are the server people actually looking at the error 
they got on your attempt(s), or just guessing?

> Does this mean that somehow I am supposed to include these as part of 
> the client certificate? If so, how do I do this? Does it instead mean 
> that I should somehow be passing the CA/Root into openssl to allow it to 
> verify the client as part of the connection? (which makes no sense to 
> me, why would the client need to verify it's own certificate 
> - that must be the servers job)
> 
Verifying you-the-client is indeed the job of the server.
And if doesn't verify you, then it would better give a 
more specific alert, like 'unknown CA' or 'invalid cert', 
not 'internal error'. Do you know what kind of software 
the server is running -- at the protocol level especially,
e.g. if it is 'Apache plus our-bus-app' you probably only 
care about 'Apache', maybe 'Apache mod_ssl version N'.

> I was under the impression that the CA and Root would be held by the 
> server and that it would use those to verify the client certificate I am 
> presenting, but it seems not to be the case according to them. Can 
> anyone shed any light on this?
> 
There are three common problems in this area but none 
quite matches what you relay the server people said.

1. Intermediate CA(s). Some (smaller) CAs may issue 'user' certs 
(client and/or server, and/or other kinds) directly under a root, 
but most have a multi-level hierarchy: root signs level2, level2 
signs user; or level2 signs level3 and level3 signs user, etc.
Each SSL system, such as this server, is configured with a set 
of CA-certs it knows (and trusts), but that set may not go all 
the way down. If that is the case, your client must supply the 
remaining 'intermediate' cert(s) during handshake.

If you have the complete chain for your cert, or you get 
it from the CA(s), you could try showing it (probably Issuer, 
Serial, Subject, SubjectKeyID if any, AltName extensions if any, 
and CRLDistPoint or AuthorityInfoAccess extensions if any) 
to the server people and ask them to identify which cert(s) 
they don't already know (if any). Then give that/those to 
SSL_CTX_add_extra_chain_cert or SSL_CTX_use_certificate_chain_file.
Or at worst supply everything; the server should ignore 
any it doesn't need, and it just takes a tiny bit longer.
However, the server must already trust the root, at least; 
even if you supply the root, they can't trust that. See 3. 

2. Ambiguous CA(s). A CA can have multiple (issuing) certs 
for the same name. In this case a verifier, like this server, 
needs to know which issuing cert (and hence key) to use.
The standard way of doing this is an extension AuthorityKeyID 
abbreviated AKID in the user cert. If this is needed the CA 
should have done it, and if the CA didn't you can't fix it.
x509 -text will show whether it is there, and if so help you 
build (or verify) the chain as above.

3. Wrong CA. Possibly the server simply doesn't trust the CA 
you used, although when you say 'required authority' 
I assume you mean required *by the server people*.
s_client or monitor as above will show if the server is 
specifying 'preferred' CA(s) in its CertRequest message.

building OpenSSL on AIX53/AIX61

2011-03-21 Thread Alona Rossen 
Hi All, 

 

I built OpenSSL 0.9.8e and OpenSSL 1.0.0d on AIX 53 and AIX61. I
configured using the following Configure options:

 

 

Configure aix-cc shared

 

In the result, numerous symbols are not being exported:

 

exec(): 0509-036 Cannot load program ./GenExec because of the following
errors:

rtld: 0712-001 Symbol CRYPTO_num_locks was referenced

  from module /home/PreTest/App/libGenSys.so(), but a runtime
definition

  of the symbol was not found.

rtld: 0712-001 Symbol CRYPTO_malloc was referenced

  from module /home/PreTest/App/libGenSys.so(), but a runtime
definition

  of the symbol was not found.

rtld: 0712-001 Symbol CRYPTO_set_locking_callback was referenced

  from module /home/PreTest/App/libGenSys.so(), but a runtime
definition

  of the symbol was not found.

 

Please advise. 

 

Thank you, 

Alona

 



Alona Rossen 

Software Developer

Connectivity Solutions Group

   
Open Text Corporation

 

   

38 Leek Crescent, Richmond Hill, ON, L4B 4N8, Canada

 

Phone:

 

+1 (905) 762 6001 ext. 6908

Email:

aros...@opentext.com  

Web site:

http://connectivity.opentext.com  

 

 

 

 

 

 

 

 

 

 

 

This email is protected by domestic and international copyright laws and
treaties and is the property of Open Text Corporation, it may contain
confidential and/or trade secret information of the Open Text
Corporation and/or its subsidiaries (OTC), and may be subject to legal
privilege in favor of OTC. This email may only be lawfully received,
accessed, displayed on a computer screen, printed, copied, and/or used
by the specific addressee(s) named above ("Authorized Recipient") for
the purpose for which it was sent by OTC. All other rights and licenses
to this email are fully reserved to OTC. If you are not an Authorized
Recipient, you are required to immediately delete this email in its
entirety without printing, copying, using, and/or re-transmitting this
email, either in whole or in part. The transmission of this email by OTC
is not to be construed as a waiver by OTC and/or the individual sending
this email on behalf of OTC of any of their respective rights or
privileges at law or otherwise, howsoever arising.

 

 

<><>

RE: Error while verifying X509 certificate

2011-03-21 Thread prk j 

Hi,
 
I am wondering if anybody has a chance to look at this.
If this question is already answered in some old archives could somebody point 
me to the link please.
Any help is greatly appreciated.
 
Thanks,
Prkj 


From: prkj...@hotmail.com
To: openssl-users@openssl.org
Subject: Error while verifying X509 certificate
Date: Thu, 17 Mar 2011 22:45:54 -0700




Hi,

I have following set of certificates with X509 extensions defined for code 
signing in PKCS7 format.

Root CA - Key usage (critical): Certificate Sign, CRL Sign
CVC Sub-CA - Key usage (critical): Certificate Sign, CRL Sign
CVC cert - Key usage(critical): Digital Signature, Key Encipherment. Extended 
Key Usage(critical): Code Sigining

PKCS#7 signature includes CVC sub-CA and CVC certs. When I verify the signature 
using PKCS7_verify() I am getting
error:  "unsupported certificate purpose"

As a work-around suggested by Dr.Stephen I tried setting purpose to any and it 
works fine using following command line:

openssl smime -verify -CAfile Root-CA -purpose any -inform PEM -in pk7blob 
-content data-signed

But fails when using Openssl API's and the error is 
X509_STORE_CTX_purpose_inherit: unknown purpose id.

Following is the code snippet. Most of it is taken from PKCS7_verify() itself 
in pkcs7_smime.c

void my_verify_api(PKCS7 *pkcs7, unsigned char *signed_data, int s_len)
{
/* Root CA */
static unsigned char my_root_ca[900]={..};
BIO*bio_t;

const unsigned char *der_cert = my_root_ca;
X509_STORE  *cert_store = NULL;
X509  *x509 = NULL;

STACK_OF(X509)*signers;
X509*signer;
X509_STORE_CTXcert_ctx;
inti, k, num_signers;

if (!bio_t = BIO_new_mem_buf((void *)signed_data, s_len))) {
printf("BIO_new_mem_buf failed\n\n");
goto end;
}
OpenSSL_add_all_algorithms();

x509 = d2i_X509(NULL, &der_cert, sizeof(my_root_ca));

if (x509 == NULL) {
printf("x509 is NULL.\n");
goto end;
}

cert_store=X509_STORE_new();
if (cert_store == NULL) {
printf("Failed to create new cert store using X509_STORE_new().\n");
goto end;
}

X509_STORE_add_cert(cert_store,x509);

signers = PKCS7_get0_signers(pkcs7, NULL, 0);

if (!signers) {
printf("Error getting signers--\n");
goto end;
}
num_signers = sk_X509_num(signers);
printf("num_signers: %d\n", num_signers);

for (k = 0; k < num_signers; k++) {
signer = sk_X509_value(signers, k);
if (!X509_STORE_CTX_init(&cert_ctx, cert_store, signer, 
pkcs7->d.sign->cert)) {
printf("X509_STORE_CTX_init failed.\n");
sk_X509_free(signers);
goto end;
}

X509_STORE_CTX_set_purpose(&cert_ctx, X509_PURPOSE_ANY);

i = X509_verify_cert(&cert_ctx);

X509_STORE_CTX_cleanup(&cert_ctx);
if (i <= 0) {
unsigned long e;
const char *file = NULL, *data = NULL;
int line, flgs;

while ((e = ERR_get_error_line_data(&file, &line, &data, &flgs))) {
printf("Error: %d\nError String: %s\n", e, ERR_error_string(e, 
NULL));
if (data) {
printf("data: %s\n", data);
}
}
ERR_clear_error();
sk_X509_free(signers);
goto end;
} else {
printf("Certificate got verified--\n\n");
}
}
sk_X509_free(signers);

end:
if (x509 != NULL) {
X509_free(x509);
}
if (cert_store != NULL) {
X509_STORE_free(cert_store);
}
if (bio_t) {
BIO_flush(bio_t);
BIO_free_all(bio_t);
}
EVP_cleanup();
}

Am I doing something wrong here?

Any help is appreciated.

Thanks,
Prkj

Client certificate chains

2011-03-21 Thread plot.lost 
I am having problems connecting to a system that requires a client 
certificate. Generated the csr using the relevant openssl commands and 
sent that to the required authority for signing. That has come back as a 
valid certificate (can use openssl x509 to verify the certificate 
content), but using that certificate does not allow the connection to 
complete (fails with 'error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 
alert internal error' )


According to the people that run the server I am trying to connect to, 
the problem is that my certificate 'does not have the chaining setup. 
The Root and CA should be trusted'


Does this mean that somehow I am supposed to include these as part of 
the client certificate? If so, how do I do this? Does it instead mean 
that I should somehow be passing the CA/Root into openssl to allow it to 
verify the client as part of the connection? (which makes no sense to 
me, why would the client need to verify it's own certificate - that must 
be the servers job)


I was under the impression that the CA and Root would be held by the 
server and that it would use those to verify the client certificate I am 
presenting, but it seems not to be the case according to them. Can 
anyone shed any light on this?



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

Re: CRL validation must be skipped for certs with no CRLDPs

2011-03-21 Thread Bruce Stephens 
Jeff Saremi  writes:

[...]

> According to the RFC, is it an error for a certificate and its chain not
> to have any CRLs and CRL distribtuion points?

No, but you're perhaps confusing things by joining the two together.  On
CRL DPs, "this profile RECOMMENDS support for this extension by CAs and
applications".  On CRLs, the end of section 5 says "Conforming CAs are
not required to issue CRLs if other revocation or certificate status
mechanisms are provided."

[...]

> If the answer is no, then the body of code that is operating today on
> the Internet and is using SSL (think of it as browsers) should operate
> with no errors. In this sense, OpenSSL would be an exception because
> its default and natural implementation causes an error.

Application writers have to consider what to do about revocation.  One
option is for an application to ignore the possibility of revocation,
and OpenSSL can easily be used to do that.  Otherwise the application
must have some functionality to request OCSP, provide CRLs, etc.

And (again) this is not specific to OpenSSL.  Other certificate
verifiers will (when asked to check revocation status) also reject
certification paths where revocation status is unavailable.  Any that
don't do that are surely broken?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: CRL validation must be skipped for certs with no CRLDPs

2011-03-21 Thread Jeff Saremi 
If I just try to describe the problem in a different way it would be:

According to the RFC, is it an error for a certificate and its chain not
to have any CRLs and CRL distribtuion points?

If the answer to the above is yes, then what OpenSSL does is OK because
the programmer would have to explicitly by way of writing callbacks or
by way of disabling CRLs altogether handle the situation.

If the answer is no, then the body of code that is operating today on
the Internet and is using SSL (think of it as browsers) should operate
with no errors. In this sense, OpenSSL would be an exception because its
default and natural implementation causes an error.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: elicptic Curve Key Generation

2011-03-21 Thread Dr. Stephen Henson 
On Sun, Mar 20, 2011, Strecker, Dean A. wrote:

> 
> Steve,
> 
> The project I'm working on is not an SSL solution.  I just need to
> create keys and sign certificates and a few other cryptographic
> activities.  I'm using the OpenSSL crypto library to create/manage
> certificates.  My only remaining hurdle is to sign the certs using an
> elliptic curve key and the HSM.  Your reply seems to indicate that I
> should be able to accomplish that using the EVP_PKEY API.  I currently
> assign the elliptic curve key (EC_KEY)to an EVP_KEY using EVP_PKEY_new
> and EVP_PKEY_assign_EC_KEY. If I'm reading correctly, I might be able to
> do something like call EVP_PKEY_meth_set_sign and then call x509_sign
> with the EVP_PKEY. Could it be that easy?
>

It is rather more complex than that. If you look in crypto/ec/ec_pmeth.c
you'll get some of the code involved. You can ignore a lot of it such as the
keygen and ECDH parts. Then you have to encapsulate the result in an ENGINE.

I should point out that although this should work there is only one example at
present and that just provides new functionality (GOST ENGINE) and doesn't
provide and alternative implementation of an existing algorithm.

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: elicptic Curve Key Generation

2011-03-21 Thread Strecker, Dean A. 

Steve,

The project I'm working on is not an SSL solution.  I just need to
create keys and sign certificates and a few other cryptographic
activities.  I'm using the OpenSSL crypto library to create/manage
certificates.  My only remaining hurdle is to sign the certs using an
elliptic curve key and the HSM.  Your reply seems to indicate that I
should be able to accomplish that using the EVP_PKEY API.  I currently
assign the elliptic curve key (EC_KEY)to an EVP_KEY using EVP_PKEY_new
and EVP_PKEY_assign_EC_KEY. If I'm reading correctly, I might be able to
do something like call EVP_PKEY_meth_set_sign and then call x509_sign
with the EVP_PKEY. Could it be that easy?

Thanks,   


Dean
 
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Sunday, March 20, 2011 12:17 PM
To: openssl-users@openssl.org
Subject: Re: elicptic Curve Key Generation

On Sat, Mar 19, 2011, Strecker, Dean A. wrote:

> Steve,
> 
> Thank you for your response for creating an elliptic curve key
(EC_KEY).
> It worked well.  I'm not sure what the difference between
> EC_POINT_set_affine_coordinates_GFp and
> EC_POINT_set_affine_coordinates_GF2m.  Time for some research.
> 
> In the same vein of using an HSM for creating the elliptic key, I
would
> like to use the HSM for signing data.  In particular, I want to sign
> X509 certs.  I have studied code for X509_sign.  I think I can use
> ASN1_ITEM_rptr and  ASN1_item_i2d to extract the certificate data to
be
> signed by the HSM.  I have not figured out how to save r and s from
the
> HSM and set appropriate cert info(e.g., algorithm) for correctly
signing
> the cert.
> 

This needs to be done via an ENGINE. You currently can't redirect
signing
calls for EC in all operations[*] but you can for RSA, DSA.

You don't mess around with ASN1_item or anything like that: the data to
be
signed is sent to a callback and you send back the signed data.

Steve.
[*] It is possible through the EVP_PKEY API which is used for signing
certificates but it isn't currently used for SSL/TLS.
--
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
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org