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 certific
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 ins
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
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.
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
_
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 allowi
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" wrot
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
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 ope
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
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
c
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.8
12 matches
Mail list logo