date:20120924

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-09-24 Thread Ashok C

Thanks Jacob, but in the three scenarios you mentioned, the first one *does
not* seem to be supported by openssl 1.0.0*. I think that was the subject
of this email thread in the beginning.

>>1. Changing expiry or other attributes while keeping the key.
Here the CA issues a new self-signed certificate with updated
attributes but unchanged key.

Here, if the expired one is encountered first, openSSL does not lookup the
non-expired CA certificate. This is then a bug right?

--
Ashok



On Tue, Sep 25, 2012 at 12:33 AM, Jakob Bohm  wrote:

> Does that work with any other serious X.509 validation toolkit?
>
> To make this work (assuming the old root CA cert has not yet expired), the
> validation code will need to actually verify the End Entity
> certificate against both public keys, which effectively reduces the
> algorithm security by allowing twice as many bit strings to be
> accepted as valid.
>
> Filtering based on criteria that do not involve actual signature
> validation would be cryptographically safe, but when falling back to
> validating against multiple signatures, extra care is needed for the
> above reason.
>
> As for trust anchor update scenarios, I know of 3 different scenarios
> that should be accepted by any good X.509 validation algorithm:
>
> 1. Changing expiry or other attributes while keeping the key.
> Here the CA issues a new self-signed certificate with updated
> attributes but unchanged key.
>
> 2. Changing the CA key when the old key has *not* been compromised.
> Here the CA generates a new key and issues two certificates for it:
>
>A. A self-signed new root with a serial number or other variation
>  in one of the subject name components.
>B. A certificate for the new key and the same subject and (optional)
>  SubjectKeyIdentifier as A, but issued by the old root certificate
>  identity and key.
>
> End Entities with certificates issued with the new key reference the
> modified subject as authority and should be configured to supply the
> transitional "B" certificate in chains sent to other end entities.
> Such end entities should then succeed validating against either the
> old root CA (via the B certificate supplied) or the new root CA
> (via finding it as a locally configured trust anchor).
>
> This is the scenario used by at least one major CA for its upgrade
> to larger keys, and SSL servers that forget the B certificate in
> the supplied chain get rejected by at least one common platform
> version (Android 2.3) because it only includes the old trust
> root in its store and uses an underdocumented BouncyCastly store
> format thus preventing the efficient deployment of the new A cert.
>
> 3. Setting up the CA to have keys for more than one algorithm (such
> as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
> certificate validation could SHOULD (but might not) match issued end
> entity certificates to the trust anchor by also comparing
> signatureAlgorithm in the issued certificate against
> subjectPublicKeyInfo.algorithm in the candidate issuer cert from the
> store.
>
> However because not all clients are going to do that, it is still
> recommended that the CA follows the scenario 2 procedures, except
> when it is a test CA for verifying handling of this scenario in
> X.509 implementations.
>
>
> On 9/24/2012 8:01 PM, Ashok C wrote:
>
>> Only the private and public keys are different.. Rest of the fields are
>> same.. Basically I am simulating the trust anchor update related
>> scenarios..
>> And yes Jacob, thanks for indicating, I'll make sure I don't use such
>> abbreviations from here on..
>>
>> Ashok
>>
>> On Sep 24, 2012 11:25 PM, "Jakob Bohm" > **> wrote:
>>
>> Hi,
>>
>> In your test case which fields actually differ between the
>> old root CA certificate and the new root CA certificate?
>>
>> P.S.
>>
>> Please do not use those 3 letter abbreviations of certificate
>> field names, very few people know those abbreviations.
>>
>> For the benefit of other readers:
>>
>> I think Ashok was referring to AuthorityKeyIdentifier and
>> SubjectKeyIdentifier fieldsbeing absent from the root
>> CA certificates in his scenario.
>>
>> On 9/24/2012 6:26 PM, Ashok C wrote:
>>
>> Hi,
>>
>> One more observation was made here in another test case.
>> _*Configuration:*_
>> One old root CA certificate oldca.pem with subject name say, C=IN
>> One new root CA certificate newca.pem with same subject name.
>> One EE certificate, ee.pem issued by new root CA.
>>
>> _*Test case 1:*_
>> Using CAFile option in openssl verify of the ee.pem,
>> If oldca.pem is placed on top and newca.pem below, verification
>> fails.
>> i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem
>>
>> _*Test case 2:*_
>> If newca.pem is placed on top and oldca.pem below that,
>> verification
>> su

OpenSSL support of Intel AES instruction set

2012-09-24 Thread Alex Chen

Sorry I did not use new mail command to start a new topic.  Let me start over 
again.

I remember seeing somewhere that OpenSSL supports Intel AES instruction set.  
If so, which release is that and what flag is needed to enable it.
Does the 'no-asm' flag in 'Configure' disable the use of these instructions?

Alex

Re: OpenSSL support of Intel AES instruction set.

2012-09-24 Thread jb-openssl


On 24-09-2012 22:34, Alex Chen wrote:

I remember seeing somewhere that OpenSSL supports Intel AES instruction set.  
If so, which release is that and what flag is needed to enable it.
Does the 'no-asm' flag in 'Configure' disable the use of these instructions?

Please start a new thread for your new question, you have posted
your question deep inside a thread on a completely unrelated topic.

I don't know the Apple mail user interface, but the rule for all
mailing lists is to never start a new topic with the "Reply" button
or menu command.

Always use the "New mail" command and then fill in the address
(openssl-users@openssl.org) manually or from your contacts.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
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

Self-signed certificate

2012-09-24 Thread Nou Dadoun

Quick question: is there a simple openssl api call which will tell me if an 
x509 certificate is self-signed?  ... N

---
Nou Dadoun
ndad...@teradici.com
604-628-1215 

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

OpenSSL support of Intel AES instruction set.

2012-09-24 Thread Alex Chen

I remember seeing somewhere that OpenSSL supports Intel AES instruction set.  
If so, which release is that and what flag is needed to enable it.
Does the 'no-asm' flag in 'Configure' disable the use of these instructions?

Alex

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

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-09-24 Thread Jakob Bohm


Does that work with any other serious X.509 validation toolkit?

To make this work (assuming the old root CA cert has not yet expired), 
the validation code will need to actually verify the End Entity

certificate against both public keys, which effectively reduces the
algorithm security by allowing twice as many bit strings to be
accepted as valid.

Filtering based on criteria that do not involve actual signature
validation would be cryptographically safe, but when falling back to
validating against multiple signatures, extra care is needed for the
above reason.

As for trust anchor update scenarios, I know of 3 different scenarios
that should be accepted by any good X.509 validation algorithm:

1. Changing expiry or other attributes while keeping the key.
Here the CA issues a new self-signed certificate with updated
attributes but unchanged key.

2. Changing the CA key when the old key has *not* been compromised.
Here the CA generates a new key and issues two certificates for it:

   A. A self-signed new root with a serial number or other variation
 in one of the subject name components.
   B. A certificate for the new key and the same subject and (optional)
 SubjectKeyIdentifier as A, but issued by the old root certificate
 identity and key.

End Entities with certificates issued with the new key reference the
modified subject as authority and should be configured to supply the
transitional "B" certificate in chains sent to other end entities.
Such end entities should then succeed validating against either the
old root CA (via the B certificate supplied) or the new root CA
(via finding it as a locally configured trust anchor).

This is the scenario used by at least one major CA for its upgrade
to larger keys, and SSL servers that forget the B certificate in
the supplied chain get rejected by at least one common platform
version (Android 2.3) because it only includes the old trust
root in its store and uses an underdocumented BouncyCastly store
format thus preventing the efficient deployment of the new A cert.

3. Setting up the CA to have keys for more than one algorithm (such
as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
certificate validation could SHOULD (but might not) match issued end
entity certificates to the trust anchor by also comparing 
signatureAlgorithm in the issued certificate against 
subjectPublicKeyInfo.algorithm in the candidate issuer cert from the

store.

However because not all clients are going to do that, it is still
recommended that the CA follows the scenario 2 procedures, except
when it is a test CA for verifying handling of this scenario in
X.509 implementations.

On 9/24/2012 8:01 PM, Ashok C wrote:

Only the private and public keys are different.. Rest of the fields are
same.. Basically I am simulating the trust anchor update related scenarios..
And yes Jacob, thanks for indicating, I'll make sure I don't use such
abbreviations from here on..

Ashok

On Sep 24, 2012 11:25 PM, "Jakob Bohm" mailto:jb-open...@wisemo.com>> wrote:

Hi,

In your test case which fields actually differ between the
old root CA certificate and the new root CA certificate?

P.S.

Please do not use those 3 letter abbreviations of certificate
field names, very few people know those abbreviations.

For the benefit of other readers:

I think Ashok was referring to AuthorityKeyIdentifier and
SubjectKeyIdentifier fieldsbeing absent from the root
CA certificates in his scenario.

On 9/24/2012 6:26 PM, Ashok C wrote:

Hi,

One more observation was made here in another test case.
_*Configuration:*_
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.

_*Test case 1:*_
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification
fails.
i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem

_*Test case 2:*_
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem > combined.pem; cat oldca.pem>>combined.pem

Test case 1 does not seem to correct behaviour as the trust store
contains newca.pem. Ideally the lookup needs to verify ee.pem
with the
newca.pem.

P.S. The CA and EE certificates are v3 but do not contain AKI or
SKI fields.

--
Ashok


On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm
mailto:jb-open...@wisemo.com>
>__>
wrote:

 On 9/13/2012 3:41 PM, Charles Mills wrote:

 Would it make sense to delete the expired certificate
from the
 Windows
 store? Duplicate expired

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-09-24 Thread Ashok C

Only the private and public keys are different.. Rest of the fields are
same.. Basically I am simulating the trust anchor update related scenarios..
And yes Jacob, thanks for indicating, I'll make sure I don't use such
abbreviations from here on..

Ashok
On Sep 24, 2012 11:25 PM, "Jakob Bohm"  wrote:

> Hi,
>
> In your test case which fields actually differ between the
> old root CA certificate and the new root CA certificate?
>
> P.S.
>
> Please do not use those 3 letter abbreviations of certificate
> field names, very few people know those abbreviations.
>
> For the benefit of other readers:
>
> I think Ashok was referring to AuthorityKeyIdentifier and
> SubjectKeyIdentifier fieldsbeing absent from the root
> CA certificates in his scenario.
>
> On 9/24/2012 6:26 PM, Ashok C wrote:
>
>> Hi,
>>
>> One more observation was made here in another test case.
>> _*Configuration:*_
>> One old root CA certificate oldca.pem with subject name say, C=IN
>> One new root CA certificate newca.pem with same subject name.
>> One EE certificate, ee.pem issued by new root CA.
>>
>> _*Test case 1:*_
>> Using CAFile option in openssl verify of the ee.pem,
>> If oldca.pem is placed on top and newca.pem below, verification fails.
>> i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem
>>
>> _*Test case 2:*_
>> If newca.pem is placed on top and oldca.pem below that, verification
>> succeeds.
>> i.e., cat newca.pem > combined.pem; cat oldca.pem>>combined.pem
>>
>> Test case 1 does not seem to correct behaviour as the trust store
>> contains newca.pem. Ideally the lookup needs to verify ee.pem with the
>> newca.pem.
>>
>> P.S. The CA and EE certificates are v3 but do not contain AKI or SKI
>> fields.
>>
>> --
>> Ashok
>>
>>
>> On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm > **> wrote:
>>
>> On 9/13/2012 3:41 PM, Charles Mills wrote:
>>
>> Would it make sense to delete the expired certificate from the
>> Windows
>> store? Duplicate expired/non expired CA certificates sounds to
>> me like a
>> problem waiting to happen.
>>
>> /Charles/
>>
>>
>>
>> Windows has built in support for using and checking time stamping
>> countersignatures in PKCS7 signatures.  If the countersignature is
>> signed with a currently valid certificate with the time stamping
>> extended usage enabled, then the outer PKCS7 signature and its
>> certificate is checked as if the current time was the one certified
>> by the time stamp (but still using up to date revocation
>> information, paying attention to revocation reasons and dates).
>>
>> Thus the Windows certificate store has good reason to keep around
>> expired CA certificates going back to ca. 1996 (when Microsoft
>> released the first version supporting time stamped signatures).
>>
>> P.S.
>>
>> I see no technical reason why such time stamp countersignature
>> support could not be added to the OpenSSL core code.
>>
>> The validation side implementation involves a few standard OIDs
>> (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
>> 1.2.840.113549.1.9.6 = counterSignature
>> unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
>> authenticated attribute).  The countersignature specifies the
>> signed data type to be "1.2.840.113549.1.7.1=data", but the
>> signed data is really the encryptedDigest/signatureValue from
>> the enclosing SignerInfo being countersigned (as per
>> PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
>> a counterSignature made by an entity with the timeStamping
>> extended key usage is simply the standard signingTime
>> authenticated attribute in the counterSignature itself.
>>
>> On the signing side, the signer simply submits his
>> encryptedDigest/signatureValue to a time stamping service he has
>> a contract with, using a simplified historic protocol as follows:
>>
>> POST url with "Accept: application/octet-string" "Content-Type:
>> application/octet-string" The post data is Base64 of DER of
>> SEQUENCE { -- Attribute
>>type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
>>SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
>>   content Type OID -- must be 1.2.840.113549.1.7.1 =data
>>   content [0] EXPLICIT OCTET STRING
>>  -- must be the outer encryptedDigest
>>   }
>>}
>>  }
>>
>> Response if successful is a 200 HTTP status with "Content-Type:
>> application/octet-string" and a value which is Base64 of DER of
>> a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
>> from the request. The time is indicated by the standard
>> signingTime authenticated attribute in the only SignerInfo in
>> signerInfos)
>>
>> This historic time stamping protocol is necessary because the
>> RFC3161 pro

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-09-24 Thread Jakob Bohm


Hi,

In your test case which fields actually differ between the
old root CA certificate and the new root CA certificate?

P.S.

Please do not use those 3 letter abbreviations of certificate
field names, very few people know those abbreviations.

For the benefit of other readers:

I think Ashok was referring to AuthorityKeyIdentifier and
SubjectKeyIdentifier fieldsbeing absent from the root
CA certificates in his scenario.

On 9/24/2012 6:26 PM, Ashok C wrote:

Hi,

One more observation was made here in another test case.
_*Configuration:*_
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.

_*Test case 1:*_
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem

_*Test case 2:*_
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem > combined.pem; cat oldca.pem>>combined.pem

Test case 1 does not seem to correct behaviour as the trust store
contains newca.pem. Ideally the lookup needs to verify ee.pem with the
newca.pem.

P.S. The CA and EE certificates are v3 but do not contain AKI or SKI 
fields.


--
Ashok


On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm mailto:jb-open...@wisemo.com>> wrote:

On 9/13/2012 3:41 PM, Charles Mills wrote:

Would it make sense to delete the expired certificate from the
Windows
store? Duplicate expired/non expired CA certificates sounds to
me like a
problem waiting to happen.

/Charles/



Windows has built in support for using and checking time stamping
countersignatures in PKCS7 signatures.  If the countersignature is
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its
certificate is checked as if the current time was the one certified
by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).

Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).

P.S.

I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.

The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
1.2.840.113549.1.9.6 = counterSignature
unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute).  The countersignature specifies the
signed data type to be "1.2.840.113549.1.7.1=data", but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.

On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:

POST url with "Accept: application/octet-string" "Content-Type:
application/octet-string" The post data is Base64 of DER of
SEQUENCE { -- Attribute
   type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
   SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
  content Type OID -- must be 1.2.840.113549.1.7.1 =data
  content [0] EXPLICIT OCTET STRING
 -- must be the outer encryptedDigest
  }
   }
 }

Response if successful is a 200 HTTP status with "Content-Type:
application/octet-string" and a value which is Base64 of DER of
a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)

This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10

This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



__

OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-09-24 Thread Ashok C

Hi,

One more observation was made here in another test case.
*Configuration:*
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.

*Test case 1:*
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem

*Test case 2:*
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem > combined.pem; cat oldca.pem>>combined.pem

Test case 1 does not seem to correct behaviour as the trust store contains
newca.pem. Ideally the lookup needs to verify ee.pem with the newca.pem.

P.S. The CA and EE certificates are v3 but do not contain AKI or SKI fields.

--
Ashok


On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm  wrote:

> On 9/13/2012 3:41 PM, Charles Mills wrote:
>
>> Would it make sense to delete the expired certificate from the Windows
>> store? Duplicate expired/non expired CA certificates sounds to me like a
>> problem waiting to happen.
>>
>> /Charles/
>>
>>
>>
> Windows has built in support for using and checking time stamping
> countersignatures in PKCS7 signatures.  If the countersignature is signed
> with a currently valid certificate with the time stamping
> extended usage enabled, then the outer PKCS7 signature and its certificate
> is checked as if the current time was the one certified
> by the time stamp (but still using up to date revocation
> information, paying attention to revocation reasons and dates).
>
> Thus the Windows certificate store has good reason to keep around
> expired CA certificates going back to ca. 1996 (when Microsoft
> released the first version supporting time stamped signatures).
>
> P.S.
>
> I see no technical reason why such time stamp countersignature
> support could not be added to the OpenSSL core code.
>
> The validation side implementation involves a few standard OIDs
> (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage, 1.2.840.113549.1.9.6
> = counterSignature
> unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
> authenticated attribute).  The countersignature specifies the
> signed data type to be "1.2.840.113549.1.7.1=data", but the
> signed data is really the encryptedDigest/signatureValue from
> the enclosing SignerInfo being countersigned (as per
> PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
> a counterSignature made by an entity with the timeStamping
> extended key usage is simply the standard signingTime
> authenticated attribute in the counterSignature itself.
>
> On the signing side, the signer simply submits his
> encryptedDigest/signatureValue to a time stamping service he has
> a contract with, using a simplified historic protocol as follows:
>
> POST url with "Accept: application/octet-string" "Content-Type:
> application/octet-string" The post data is Base64 of DER of
>SEQUENCE { -- Attribute
>   type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
>   SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
>  content Type OID -- must be 1.2.840.113549.1.7.1 =data
>  content [0] EXPLICIT OCTET STRING
> -- must be the outer encryptedDigest
>  }
>   }
> }
>
> Response if successful is a 200 HTTP status with "Content-Type:
> application/octet-string" and a value which is Base64 of DER of
> a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
> from the request. The time is indicated by the standard
> signingTime authenticated attribute in the only SignerInfo in
> signerInfos)
>
> This historic time stamping protocol is necessary because the
> RFC3161 protocol returns a signature which is not a valid RFC2985
> counterSignature.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
> Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> 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
>

RE: Intermediate certificate verification

2012-09-24 Thread Nou Dadoun

After I posted the question I found the earlier discussion from this year: 
http://www.mail-archive.com/openssl-users@openssl.org/msg66377.html 

Following the thread back at least indicates that I'm not the first one who 
made the incorrect assumption that providing an intermediate certificate as a 
"trusted" certificate was sufficient.

The one issue for us is that we're attempting to bridge the windows certificate 
store and the openssl verification machinery.  (We implement for several 
platforms so openssl is used in common with the windows crypto api/certificate 
store used to retrieve the certificates.)  I can certainly  load "chains" of 
certificates manually but this seems like an instance where the capi engine 
could be useful.   Unfortunately I never found sufficient documentation to use 
the capi engine to interface windows and openssl due to the associated 
development schedule.

This sounds like a well-defined small problem that could benefit from it 
though; are there any examples around of the capi engine used to retrieve 
certificates "as required" from a windows certificate store to do this kind of 
certificate verification?  (i.e. a windows " method that finds them 
dynamically")

Thanks to Dave for the response ... N

---
Nou Dadoun
ndad...@teradici.com
604-628-1215 


-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Dave Thompson
Sent: September 21, 2012 7:37 PM
To: openssl-users@openssl.org
Subject: RE: Intermediate certificate verification

> From: owner-openssl-us...@openssl.org On Behalf Of Nou Dadoun
> Sent: Friday, 21 September, 2012 15:29

> Just wanted to confirm an assumption, I've got 3 x509 certificates:
> 
> Root --> intermediate  --> leaf
> 
> I load the intermediate certificate (but not the Root 
> certificate) into the x509_store and set up the verify_ctx to 
> verify the leaf certificate.
> 
> I then use the "X509_verify_cert(verify_ctx)" function for 
> verification but the associated callback reports that the 
> verification fails (i.e. ok == 0) with an error of 2 ("unable 
> to get issuer certificate").
> 
> I assume that if I load the intermediate as a CA that I don't 
> have to provide the Root to verify the leaf (i.e. I'm stating 
> that I trust the intermediate as the CA).  Is this correct?  
> Does the Root also need to be loaded?
> 
No and sort-of. OpenSSL's cert_verify logic always checks to 
the root, even if an intermediate cert is in the truststore.
Unlike some other implementations/applications. It's arguable 
if this is the best way, but it has been this way since at least 
0.9.7, and I wouldn't hold my breath expecting a change soon.

The full chain including root needs to be *available from* 
the X509_STORE. This can be accomplished by having them loaded, 
or by having a method that finds them dynamically -- like 
the by_dir method invoked by commandline for -CApath .

> This setup certainly works with 2 certs (i.e. Root --> Leaf) 
> but I'm retrieving the certs using the windows crypto api so 
> I want to make sure that my openssl verify assumption is 
> correct before trying to run down the windows stuff.
> 
> Anybody know offhand?  Thanks .. N
> 

__
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: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

2012-09-24 Thread Jakob Bohm


On 9/13/2012 3:41 PM, Charles Mills wrote:

Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.

/Charles/




Windows has built in support for using and checking time stamping 
countersignatures in PKCS7 signatures.  If the countersignature is 
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its 
certificate is checked as if the current time was the one certified

by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).

Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).

P.S.

I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.

The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage, 
1.2.840.113549.1.9.6 = counterSignature

unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute).  The countersignature specifies the
signed data type to be "1.2.840.113549.1.7.1=data", but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.

On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:

POST url with "Accept: application/octet-string" "Content-Type: 
application/octet-string" The post data is Base64 of DER of

   SEQUENCE { -- Attribute
  type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
  SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
 content Type OID -- must be 1.2.840.113549.1.7.1 =data
 content [0] EXPLICIT OCTET STRING
-- must be the outer encryptedDigest
 }
  }
}

Response if successful is a 200 HTTP status with "Content-Type: 
application/octet-string" and a value which is Base64 of DER of

a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)

This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
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

[FWD] About SSL_connect error

2012-09-24 Thread Lutz Jaenicke

Forwarded to openssl-users for discussion

Best regards,
Lutz
--
Lutz Jaenicke   jaeni...@openssl.org
OpenSSL Project http://www.openssl.org/~jaenicke/
--- Begin Message ---
Dear OpenSSL developers


About the following source,I have 2 questions:


1.In OpenSSL library 0.9.8d, when executing more than 2 threads at the
same time, the following error sometimes appears:
SSL_connect error, ip=192.168.1.xxx,err:error:0001:lib(0):func(0):reason(1)
why?


2. But in OpenSSL OpenSSL1.0.1c, the error never happened.I want know the 
diference 
between the two version OpenSSL lib,Can you help me?


--
main（）
{
SSL_library_init();
SSL_load_error_strings();
m_ctx = SSL_CTX_new(TLSv1_method());
SSL_CTX_set_options(m_ctx, SSL_OP_ALL);


mutex_buf = (MUTEX_TYPE *)malloc(CRYPTO_num_locks( ) * sizeof(MUTEX_TYPE));
if (!mutex_buf) {
return 0;
}


for (i = 0; i < CRYPTO_num_locks( ); i++) {
MUTEX_SETUP(mutex_buf[i]);
}


CRYPTO_set_id_callback(id_function);
CRYPTO_set_locking_callback(locking_function);


CRYPTO_set_dynlock_create_callback(dyn_create_function);
CRYPTO_set_dynlock_lock_callback(dyn_lock_function);
CRYPTO_set_dynlock_destroy_callback(dyn_destroy_function);


for(nIndex = 0; nIndex < nThreadNum; nIndex++)
{


  nErrorNo = pthread_create(&thread_id[nIndex], NULL, ThreadProcess,
&diskArray[nIndex] );
  ..
  
}


}


ThreadProcess（）
{
call socket();
set non-block;
call connect();
call select();
call BIO_new_socket();
call SSL_new();
call SSL_set_bio();

while( TRUE != nEndFlag )
{


nStatus = SSL_connect(pstSocketInfo->m_ssl);
if(nStatus <= 0)
{
nErrorNo = SSL_get_error(pstSocketInfo->m_ssl, nStatus);
if((SSL_ERROR_WANT_WRITE == nErrorNo)||(SSL_ERROR_WANT_READ == 
nErrorNo))
{
Sleep(1000);
nTrySSLConTimes++;
if ( MAX_SSL_CON_TRY_TIMES < nTrySSLConTimes )
{
CleanSocket( pstSocketInfo );
return ERR;
}
continue;
}
else
{
★★★
printf("[ID:%04lx]SSL_connect error, ip=%s, err: 
%s\n",id_function(),szIPStr, 
ERR_error_string(nErrorNo, NULL));
CleanSocket( pstSocketInfo );
return ERR;
★★★
}
}
else 
{
nEndFlag = TRUE;
}
}
}




best regards


liuyb

--- End Message ---

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

OpenSSL support of Intel AES instruction set

Re: OpenSSL support of Intel AES instruction set.

Self-signed certificate

OpenSSL support of Intel AES instruction set.

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

RE: Intermediate certificate verification

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[FWD] About SSL_connect error

12 matches

Site Navigation

Mail list logo

Footer information