[openssl.org #3212] smime verification failure

2014-01-06 Thread Kurt Roeckx via RT
Hi,

I received an smime signed email but I had a problem verifying the
signature.  What I get was 3 certificates in the chain, but it
didn't look for the certificate in my CApath.

The orders of the certs as shown by pkcs7 -print_certs was:
2
3
1

Where 1 was the end user certificate, 2 is the is an intermediate
CA and 3 is one in my CApath but in't a self signed certificate
but issued by an other certificate.

The problem now is that it's trying to find the issuer of
certificate 3 which is not in my CApath and then fail with this
message:
139720205891240:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify 
error:pk7_smime.c:342:Verify error:unable to get local issuer certificate

When only certificate 2 and 1 are send, I the verififcation is
succesful because it's now trying to find the issuer of 2, being
3, and does find that in my CApath.

I assume this would also work if the 3rd certificate was a self
signed version instead of the something that was signed by someone
else.  The issuer would then be itself and it would look that up.

Wouldn't it make sense to check that any of the certificates that
are send are in the CApath rather than just the issuer of the
last one in the chain?


Kurt

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


RE: [openssl.org #3212] smime verification failure

2014-01-06 Thread Dave Thompson
 From: owner-openssl-dev On Behalf Of Kurt Roeckx via RT
 Sent: Monday, January 06, 2014 04:22

 I received an smime signed email but I had a problem verifying the
 signature.  What I get was 3 certificates in the chain, but it
 didn't look for the certificate in my CApath.
 
 The orders of the certs as shown by pkcs7 -print_certs was:
 2
 3
 1
 
 Where 1 was the end user certificate, 2 is the is an intermediate
 CA and 3 is one in my CApath but in't a self signed certificate
 but issued by an other certificate.
 
 The problem now is that it's trying to find the issuer of
 certificate 3 which is not in my CApath and then fail with this
 message:
 139720205891240:error:21075075:PKCS7 routines:PKCS7_verify:certificate
 verify error:pk7_smime.c:342:Verify error:unable to get local issuer
 certificate
 
Since the issuer of 3 (call it 4 for convenience) isn't in your truststore,
yes this error is expected.

 When only certificate 2 and 1 are send, I the verififcation is
 succesful because it's now trying to find the issuer of 2, being
 3, and does find that in my CApath.
 
Are you sure the '3' in your truststore is the same as the one sent? 
If so, openssl should find 3 and then look for 4 and fail the same way.
I'd bet you actually have '3A' -- a different cert for the same CA 
name (and key), which is self signed and thus a root. In that case 
the chain 1,2,3A verifies, but the chain 1,2,3,(4) fails.

 I assume this would also work if the 3rd certificate was a self
 signed version instead of the something that was signed by someone
 else.  The issuer would then be itself and it would look that up.
 
If you have a self-signed cert in your truststore -- what I call 3A -- 
yes that should work. Note that just sending 1,2,3A in the message 
and not having 3A in your truststore would still fail. openssl must 
always find the root locally whether or not it is sent.

 Wouldn't it make sense to check that any of the certificates that
 are send are in the CApath rather than just the issuer of the
 last one in the chain?
 
In other words, try multiple or 'alternate' CA paths, not just 
the 'first' one given by the message (or other protocol).
Yes, many (most?) other SSL implementations do that. 
openssl,at least through 1.0.1, does not. There are apparently 
changes in cert/chain verification coming in 1.0.2, but I don't 
know if it includes this.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #3212] smime verification failure

2014-01-06 Thread Dr. Stephen Henson
On Mon, Jan 06, 2014, Dave Thompson wrote:

  From: owner-openssl-dev On Behalf Of Kurt Roeckx via RT
  Sent: Monday, January 06, 2014 04:22
 
  I received an smime signed email but I had a problem verifying the
  signature.  What I get was 3 certificates in the chain, but it
  didn't look for the certificate in my CApath.
  
  The orders of the certs as shown by pkcs7 -print_certs was:
  2
  3
  1
  
  Where 1 was the end user certificate, 2 is the is an intermediate
  CA and 3 is one in my CApath but in't a self signed certificate
  but issued by an other certificate.
  
  The problem now is that it's trying to find the issuer of
  certificate 3 which is not in my CApath and then fail with this
  message:
  139720205891240:error:21075075:PKCS7 routines:PKCS7_verify:certificate
  verify error:pk7_smime.c:342:Verify error:unable to get local issuer
  certificate
  
 Since the issuer of 3 (call it 4 for convenience) isn't in your truststore,
 yes this error is expected.
 
  When only certificate 2 and 1 are send, I the verififcation is
  succesful because it's now trying to find the issuer of 2, being
  3, and does find that in my CApath.
  
 Are you sure the '3' in your truststore is the same as the one sent? 
 If so, openssl should find 3 and then look for 4 and fail the same way.
 I'd bet you actually have '3A' -- a different cert for the same CA 
 name (and key), which is self signed and thus a root. In that case 
 the chain 1,2,3A verifies, but the chain 1,2,3,(4) fails.
 
  I assume this would also work if the 3rd certificate was a self
  signed version instead of the something that was signed by someone
  else.  The issuer would then be itself and it would look that up.
  
 If you have a self-signed cert in your truststore -- what I call 3A -- 
 yes that should work. Note that just sending 1,2,3A in the message 
 and not having 3A in your truststore would still fail. openssl must 
 always find the root locally whether or not it is sent.
 
  Wouldn't it make sense to check that any of the certificates that
  are send are in the CApath rather than just the issuer of the
  last one in the chain?
  
 In other words, try multiple or 'alternate' CA paths, not just 
 the 'first' one given by the message (or other protocol).
 Yes, many (most?) other SSL implementations do that. 
 openssl,at least through 1.0.1, does not. There are apparently 
 changes in cert/chain verification coming in 1.0.2, but I don't 
 know if it includes this.
 

The -trusted_first option of 1.0.2 should make it possible to verify that
message.

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
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #3212] smime verification failure

2014-01-06 Thread Kurt Roeckx
On Mon, Jan 06, 2014 at 05:38:27PM -0500, Dave Thompson wrote:
 
  When only certificate 2 and 1 are send, I the verififcation is
  succesful because it's now trying to find the issuer of 2, being
  3, and does find that in my CApath.
  
 Are you sure the '3' in your truststore is the same as the one sent? 
 If so, openssl should find 3 and then look for 4 and fail the same way.
 I'd bet you actually have '3A' -- a different cert for the same CA 
 name (and key), which is self signed and thus a root. In that case 
 the chain 1,2,3A verifies, but the chain 1,2,3,(4) fails.

The one in my trust store, let's call it 3A is not exactly the
same as the 3 I received.  That is, 3A is self signed, 3 isn't.

But 3A and 3 have the same subject, public key, and subject hash.

  Wouldn't it make sense to check that any of the certificates that
  are send are in the CApath rather than just the issuer of the
  last one in the chain?
  
 In other words, try multiple or 'alternate' CA paths, not just 
 the 'first' one given by the message (or other protocol).
 Yes, many (most?) other SSL implementations do that. 
 openssl,at least through 1.0.1, does not. There are apparently 
 changes in cert/chain verification coming in 1.0.2, but I don't 
 know if it includes this.

I think it would be useful if it could do that.


Kurt

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org